ATA tag queuing broken...

[Sean Chittenden]

> > Alright, well it's apparently no surprise to folks that ATA tag
> > queuing is broken at the moment.  Are there any objections to me
> > adding a few cautious words to ata(4) and tuning(7) that advise
> > _against_ the use of ata tag queuing given that they're likely the
> > fastest way to reboot a -STABLE box?
> >
> > Here's a PR that I tacked a tad bit of info into:
> >
> > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/42563
> 
> That's news to me, works just fine here (4.8-R).

That's what my box is as well.  See the bottom of the PR for details,
but an egrep -r via NFS reboots the box consistently as well as a
local CVSup + nice +20 buildworld.

> What do you mean by "at the moment"? That pr is six months old.

Agreed, but since there's no voting for bugs in gnats, I figured I'd
"me too" the PR with an updated time/date and slightly more info.

> Did you check the list first? I sent another "works for me" less
> than a month ago. (Thread: Status of ATA tagging in Stable Kevin
> Oberman 20030329)

Yup.  It "works" in the sense that under low load, the box works.  As
soon as I push it, however, it panics and resets.

> I note that the pr originator also has the *known to be broken* DTLA
> drives.

Hrm, well, according to the man pages I've got the right stuff... or
not, I don't remember the qualifications mentioned in tuning(7):

atapci0: <VIA 8233 ATA100 controller> port 0xdc00-0xdc0f at device 17.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
ad0: 58644MB <IC35L060AVER07-0> [119150/16/63] at ata0-master tagged UDMA100
ad2: 58644MB <IC35L060AVER07-0> [119150/16/63] at ata1-master tagged UDMA100

Grump, nm.  I may extend the warning from tuning(7) over into ata(4)
simply because tuning(7) seems to contain more info on ata(4) in this
regard.  -sc

-- 
Sean Chittenden