Bug 327931 - Add another SATA drive to NCQ blacklist
Add another SATA drive to NCQ blacklist
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-11 12:38 EDT by Matthew Gillen
Modified: 2008-05-19 11:34 EDT (History)
4 users (show)

See Also:
Fixed In Version: 9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-19 11:34:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Gillen 2007-10-11 12:38:32 EDT
Description of problem:
My Dell Latitude D630, when using the ahci access method, gets "HSM violation"
messages, along with "spurious completions during NCQ".  The errors go away if I
add 
  echo 1 > /sys/block/sda/device/queue_depth
to rc.local (although they still happen on bootup before rc.local gets executed).

Version-Release number of selected component (if applicable):
kernel-2.6.22.9-91.fc7


Additional info:
hdparm -i /dev/sda

/dev/sda:

 Model=Hitachi HTS722012K9A300                 , FwRev=DCCOC54P,
SerialNo=070703DP0C00DSG0G5MA
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=DualPortCache, BuffSize=15203kB, MaxMultSect=16, MultSect=?0?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=234441648
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 
 AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5
ATA/ATAPI-6 ATA/ATAPI-7

 * signifies the current active mode

----------

Here's the syslog messages from boot time:
kernel: ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 3 ports 3 Gbps 0x5 impl SATA mode
kernel: ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part
kernel: scsi0 : ahci
kernel: scsi1 : ahci
kernel: scsi2 : ahci
kernel: ata1: SATA max UDMA/133 cmd 0xffffc20000646900 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 2299
kernel: ata2: DUMMY
kernel: ata3: SATA max UDMA/133 cmd 0xffffc20000646a00 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 2299
kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
kernel: ata1.00: ATA-8: Hitachi HTS722012K9A300, DCCOC54P, max UDMA/133
kernel: ata1.00: 234441648 sectors, multi 8: LBA48 NCQ (depth 31/32)
kernel: ata1.00: configured for UDMA/133
kernel: scsi 0:0:0:0: Direct-Access     ATA      Hitachi HTS72201 DCCO PQ: 0 ANSI: 5
kernel: sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB)
kernel: sd 0:0:0:0: [sda] Write Protect is off
kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
kernel: sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB)
kernel: sd 0:0:0:0: [sda] Write Protect is off
kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
kernel:  sda: sda1 sda2 sda3
kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Comment 1 Rui Matos 2007-10-28 19:53:58 EDT
Isn't this bug a dup of #250349?
Comment 2 Rui Matos 2007-10-28 20:17:02 EDT
Hmm, after some research it seems this a disk lack of features and the specific
model need to be added to a blacklist *sigh*

I'll just add mine here on this bug:

[jman@hive ~]$ uname -a
Linux hive 2.6.23.1-37.fc8 #1 SMP Fri Oct 26 12:36:34 EDT 2007 i686 i686 i386
GNU/Linux
[jman@hive ~]$ dmesg | grep ^ata 
ata1: SATA max UDMA/133 cmd 0xf884a900 ctl 0x00000000 bmdma 0x00000000 irq 219
ata2: DUMMY
ata3: SATA max UDMA/133 cmd 0xf884aa00 ctl 0x00000000 bmdma 0x00000000 irq 219
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-7: ST9160823AS, 3.ADB, max UDMA/133
ata1.00: 312581808 sectors, multi 8: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
ata3: SATA link down (SStatus 0 SControl 300)
ata_piix 0000:00:1f.1: version 2.12
ata4: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00016fa0 irq 14
ata5: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x00016fa8 irq 15
ata4.00: ATAPI: PBDS DVD+/-RW DS-8W1P, BD1B, max UDMA/33
ata4.00: configured for UDMA/33
ata5: port disabled. ignoring.
ata1.00: exception Emask 0x2 SAct 0x18 SErr 0x0 action 0x2 frozen
ata1.00: spurious completions during NCQ issue=0x0 SAct=0x18 FIS=004040a1:00000004
ata1.00: cmd 61/08:18:97:ba:b8/00:00:06:00:00/40 tag 3 cdb 0x0 data 4096 out
ata1.00: cmd 61/18:20:87:ba:d8/00:00:06:00:00/40 tag 4 cdb 0x0 data 12288 out
ata1: soft resetting port
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: configured for UDMA/133
ata1: EH complete

This is a Dell Latitude D630 on an updated F8 (rawhide).
Comment 3 Christopher Brown 2008-01-14 13:37:14 EST
Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.
Comment 4 Matthew Gillen 2008-01-14 13:53:10 EST
Yes, I'm still errors if I remove that 'echo 1 > /sys/...' line from
/etc/rc.local.  Here's the exact output from dmesg after a reboot:

ata1.00: exception Emask 0x2 SAct 0x38 SErr 0x0 action 0x2 frozen
ata1.00: spurious completions during NCQ issue=0x0 SAct=0x38 FIS=005040a1:00000004
ata1.00: cmd 61/20:18:ff:65:bb/00:00:09:00:00/40 tag 3 cdb 0x0 data 16384 out
         res 50/00:08:67:7d:22/00:00:0c:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/28:20:b7:f0:30/00:00:0b:00:00/40 tag 4 cdb 0x0 data 20480 in
         res 50/00:08:67:7d:22/00:00:0c:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/08:28:67:7d:22/00:00:0c:00:00/40 tag 5 cdb 0x0 data 4096 in
         res 50/00:08:67:7d:22/00:00:0c:00:00/40 Emask 0x2 (HSM violation)
ata1: soft resetting port
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: configured for UDMA/133
ata1: EH complete
Comment 5 Matthew Gillen 2008-01-14 13:54:18 EST
Oh, sorry, one more thing:  I'm currently running fedora 8 on that laptop, and
using kernel version: 2.6.23.9-85.fc8

Comment 6 Bug Zapper 2008-05-14 10:42:53 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Matthew Gillen 2008-05-19 11:34:40 EDT
This problem has gone away with the latest Fedora 9 kernel
(2.6.25.3-18.fc9.x86_64), and the queue_depth is not 1 (which means the fix was
something better than blacklisting the drive).

Note You need to log in before you can comment on or make changes to this bug.