Any objections/comments on axing out old ATA stack?
mandree at FreeBSD.org
Tue Apr 2 18:39:27 UTC 2013
Am 31.03.2013 23:02, schrieb Scott Long:
> So what I hear you and Matthias saying, I believe, is that it should be easier to
> force disks to fall back to non-NCQ mode, and/or have a more responsive
> black-list for problematic controllers. Would this help the situation? It's hard to
> justify holding back overall forward progress because of some bad controllers;
> we do several Tbps off of AHCI controllers with NCQ enabled on FreeBSD 9.x,
> enough to make up a sizable percentage of the internet's traffic, and we see no
> problems. How can we move forward but also take care of you guys with
> problematic hardware?
Well, I am running the driver fine off of my WD Caviar RE3 disk, and the
problematic drive also works just fine with Windows and Linux, so it
must be something between the problematic drive and the FreeBSD driver.
I would like to see any of this, in decreasing order of precedence:
- debugged driver
- assistance/instructions on helping how to debug the driver/trace NCQ
stuff/... (as in Jeremy Chadwick's followup in this same thread - this
helps, I will attempt to procure the required information; "back then",
reducing the number of tags to 31 was ineffective, including an error
message and getting a value of 32 when reading the setting back)
- "user-space" contingency features, such as letting camcontrol limit
the number of open NCQ tags, or disable NCQ, either on a per-drive basis
I am capable of debugging C - mostly with gdb command-line, and
graphical Windows IDEs - but am unfamiliar with FreeBSD kernel
debugging. If necessary, I can pull up a second console, but the PC that
is affected is legacy-free, so serial port only works through a
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 261 bytes
Desc: OpenPGP digital signature
More information about the freebsd-stable