Re: ATA anomaly Question

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Joerg Anslik wrote:

> Hey,
>
>
> > Add-on controllers, SATA:
> >
> > - booting may report in dmesg: 'DMA limited to UDMA 33, non-ATA66 cable 
> > or device'
>
>
> This also holds true for on board SATA controllers. I get this message
> every time I boot my Shuttle SN95G with one disk being attached to the
> first internal SATA port. The second disk is IDE, attached via
> UDMA-100 cable; I don't see the message here. But then, disk speed
> seems to be "normal" for both disks.
ACK - well it would take a serious benchtest to tell - in typical 'real 
world'
use an IDE drive spends enough time repositioning the R/W heads it won't
often be able to fill even a DMA-33 channel.

> > - Promise Fastrak S-150 TX-2 Plus is not detected by DragonFly.
>
>
> My test machine here's equipped with a Promise Ultra-100 TX PCI board,
> which doesn't cause any problems and is correctly detected by DFly.

I have similar (PATA RAID only) items onboard an I-Will and a Giga-Byte 
here.
ONe an HPT-372, the Other a Promise Fastrk-100.

Both are shut-of by jumper and BIOS.  The onboard 'plain' ATA-33 work OK,
But the The alleged-RAID controllers want to interfere with the (several)
different breeds of SCSI controllers, RAID and non, in each of those boxes.
The OS/2 box has its 'tarball' 80 GB SATA drives on an add-on Sil3112,
which does behave (under Warp anyway...).

> I'm not sure, but I think it's because the Fastrak family boards have
> different [newer] chipsets, probably not yet being probed for. But
> that's just a guess.

The 'opportunity' is that, AFAIK, not all drivers are available and ata(4)
is no longer 'universal' enough....

'conventional' IDE/ATA ata(4) driver, as shipped with FreeBSD-4.11
anyway - seems to cover the Sil, most HPT, *claims* to cover most Promise.
That driver is as common as fly poop - it's everywhere.

High Point RocketRAID 18XX & SATA, per FreeBSD 5.3,  want: hptmv(4)
- DragonFlyBSD STABLE doesn't include that, though ata(4) seems to
serve just fine.

Promise 'SuperTrak' want: pst(4) - DragonFlyBSD STABLE doesn't include that,
and the Fastrak-150 TX-2 plus are 'invisible'.

HPT and Promise now ship *BSD as well as Linux drivers, (soon to be
tried) - but that's not a lot of help if one is trying to use a Promise SATA
controller to do initial setup of the only HDD(s) in the system.

FWIW, out of this bunch, there are good reasons to use *only* the
Sil 31120/40 for boot devices - if you must.

Simply do NOT tell the Sil BIOS the drives are a RAID array, and use it
as a basic multi-channel 'non-RAID'. It goes away and eats its oatmeal
w/o complaint while you create the array with atacontrol and put bootblocks
on everything in sight - /dev/adx(prime) and /dev/adx(secundus) as well
as /dev/ar0 that was created from them.

The HPT and Promise BIOS OTOH, detect that subterfuge.

Given a HDD failure, they are like the odd couple from Khartoum,
who would argue all night, as to who has the right,
to do what, with which, and to whom.

The HPT BIOS wants to sit (until Hell freezes or it get's a keystroke),
and the Promise wants to sit and wait 30 seconds and/or re-configure
a broken RAID1 as RAID0 if the failed (or just flagged dirty) drive
is otherwise detectable.

The Sil, by contrast, non grantum rodentus ani and just boots whatever
has a detectable bootblock.  In 3 seconds, yet.  I said 'cheap and 
cheerful'.
But any decent SCSI RAID, or PATA on 'plain IDE' with atacontrl is far
easier to recover remotely.

Now to figure out why only two of the four channels are reliable
on 2 for 2 units of the Sil 31140, and the second two at that...

Bill



> --j
>
> -----------------------------------------------------
> who | grep -i blonde | talk; cd ~; wine; talk; touch;
> unzip; touch; strip; gasp; finger; gasp; mount;
> fsck; more; yes; gasp; umount; make clean; sleep