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 serial/USB converter.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:36 UTC