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
Isn't this bug a dup of #250349?
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).
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.
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
Oh, sorry, one more thing: I'm currently running fedora 8 on that laptop, and using kernel version: 2.6.23.9-85.fc8
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
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).