Re: [issue566] NATA a nonstarter with ATI SB600 on MSI K9AGM-FID

["J. Kanowitz" <jkanowitz@xxxxxxxx>]

--- Matthew Dillon <bugs@lists.dragonflybsd.org> 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