--- Matthew Dillon <[EMAIL PROTECTED]> wrote: Hey, thanks for giving this your attention!
> :-Finally gave in/gave up and ordered some PATA-to-SATA bridges last > : week, so I'll be able to test the theory that this is only a problem > : with the legacy PATA controller when they arrive. > > PATA to SATA bridge? You mean something that plugs into a PATA > header and provides a SATA port? That can't be right... do people > actually make those? I'd be amazed if that sort of thing worked > reliably. Yep, they're converter boards that turn a PATA disk into a SATA disk, the chipsets are from known quantities like Silicon Image and JMicron, they've been around for a few years now and have got to be at least as reliable as a PATA to USB/1394 design. Someone on IRC was begging me to try one back when I first opened this bug. Some of the chipsets are actually bidirectional, so they really are bridges (subject to board implementation)... I have a big pile of brand new PATA disks, if there's actually trouble using the SATA ports then I'll give up and buy a native disk to eliminate variables. :} Buying a new controller would take all the "fun" out of making the SB600 work. The theory was that the SATA ports are probably perfectly supported already, and I'm the only person in BSD-land who has ever bothered trying to use the PATA port. ;) > :-Just tried the new -PREVIEW with the big NATA update, and things > : haven't improved much if at all for this configuration. I can "sort > : of" boot (if I can avoid fsck, e.g. single-user), the disk comes up > : in UDMA33, ICRC errors galore, I couldn't convince natacontrol to > : raise it *above* UDMA33, but trying to choose BIOSDMA took it all > : the way back to PIO4, which seems to be stable enough for me to > : build a kernel with the old driver like I should've done before I > : embarked on the test. > NATA doesn't report irq assignments, I haven't looked into why not. TGEN was puzzled too and almost blaming that at first glance, per http://bugs.dragonflybsd.org/msg2326 . Of course, it probably wouldn't work at all, then... > Please post the 'atapci', 'ata', 'acd', and 'ad' lines in the boot. As I type this, that machine is limping through a buildkernel for the old driver using the NATA kernel at PIO4. Since this makes it stable (albeit slower even than BIOSDMA), I should be able to save and post both NATA and decaf dmesgs once it's done. Might be an hour. Please have a glance at the existing attachments to http://bugs.dragonflybsd.org/issue566 , for instance the pciconf information is still good: http://bugs.dragonflybsd.org/file197/pciconf%20-lv It's a UDMA100 drive, UDMA100 cable (came with the drive), I have no idea where the UDMA33 limitation arises. Perhaps a UDMA33 drive would even work right and this Western Digital doesn't like being forced to fall back that far, or the 80-wire cable is actually out-of-spec for that signaling. Of course, it only likes to play in BIOSDMA mode with the old driver, too, which I chalked up to the SB600 being 'too new.' The exact disk and cable played nice at UDMA66 with my previous system's Via 686A. AMD says of the SB600 (part of the "Radeon Xpress 1100"): "ATA 133 controller support up to UDMA mode 6 with 2 drives (disk or optical)" That's been wordy and speculative, pardon. dmesgs should be coming. -Joe "Floid" Kanowitz
