Most recent kernel where this bug did *NOT* occur: Distribution: ubuntu Hardware Environment: laptop with ICH7 Software Environment: ubuntu Problem Description: A friend of mine has bought a laptop that has a DVDRAM (Matshita UJ-850S) that is not detected by libata (ata_piix), unless it has booted on a cdrom inserted in that drive. A strange thing is that the drive is listed in the BIOS as being slave on channel 1, with no master. Whereas the HD is master on channel 0 with no slave connected. He had no problem installing ubuntu with a cdrom, but after install, when booting from the HD, the BIOS is probably not initializing the controller (ICH7) the same way and the DVDRAM is not detected by libata. I tried with different kernels, 2.6.17-11 (ubuntu current), 2.6.20 (built manually) or even the 2.6.15-23 (ubuntu install CD) that was the one used for installation. Nothing in dmesg, Just the standard line for the PATA channel. will attach both dmesg & lspci. Steps to reproduce: Boot install CD, drive is detected, distro can be installed. Boot installed distro (from HD), DVD drive is not detected.
Created attachment 10486 [details] lspci output
Created attachment 10487 [details] dmesg from (working) ubuntu install cd - 2.6.15-23 when the ubuntu install CD is booted the Matsushita UJ-850S DVDRAM drive is detected, here is the dmesg output showing that. The drive is usable as the full install process has been made.
Created attachment 10488 [details] dmesg from (not working) boot from HD - 2.6.17-11 (ubuntu) This is the dmesg from booting the current (2.6.17-11) ubuntu kernel, not detecting the DVDRAM drive.
Created attachment 10489 [details] dmesg from (not working) boot from HD - install cd kernel - 2.6.15-23 this it the dmesg from the install cd kernel (ubuntu 2.6.15-23) but booting from HD instead of CD.
Created attachment 10490 [details] dmesg from (not working) boot from HD - 2.6.20 vanilla kernel this is a dmesg from vanilla 2.6.20 (make oldconfig from ubuntu config)
Thanks for the detailed info. Can you please apply the attached patch over 2.6.20 and report what the kernel says?
Created attachment 10516 [details] debug patch
I'm sorry I won't be able to test your patch this week as I gave the laptop back to its owner which is absent for a week. I'll report the output when I get it again.
Since Vincent is not able to provide the feedback required by Tejun Heo's patch I'm stepping in. I have a similarly configured laptop with the same problem : when i boot from a bootable CD my DVD is recognized by libata but it fails when booting from HD. (I'm using the same kernel in both cases 2.6.20.1) Same story when using ide instead of libata. I'm attaching dmesg from CD boot and DVD boot with kernel-2.6.20.1 and Tejun Heo's patch applied. In brief the patch output from HD boot is : ....... libata version 2.00 loaded. ata_piix 0000:00:1f.2: version 2.00ac7 ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 20 PCI: Setting latency timer of device 0000:00:1f.2 to 64 ata1: PORT_FLAGS=0x1c800003 ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x18B0 irq 14 ata2: PORT_FLAGS=0x10800001 ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x18B8 irq 15 scsi0 : ata_piix ata1: CLASSIFY: device 0 50:01 01:00:00 ata1: CLASSIFY: device 1 00:01 01:00:00 ata1.00: ATA-7, max UDMA/133, 195371568 sectors: LBA48 NCQ (depth 0/32) ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/133 scsi1 : ata_piix ata2: CLASSIFY: device 0 7f:7f 7f:7f:7f ata2: CLASSIFY: device 1 7f:7f 7f:7f:7f ATA: abnormal status 0x7F on port 0x177 scsi 0:0:0:0: Direct-Access ATA ST9100824AS 3.04 PQ: 0 ANSI: 5 SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 < sda5 > sd 0:0:0:0: Attached scsi disk sda ........... and from CD boot: ...... libata version 2.00 loaded. ata_piix 0000:00:1f.2: version 2.00ac7 ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 20 PCI: Setting latency timer of device 0000:00:1f.2 to 64 ata1: PORT_FLAGS=0x1c800003 ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x18B0 irq 14 ata2: PORT_FLAGS=0x10800001 ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x18B8 irq 15 scsi0 : ata_piix ata1: CLASSIFY: device 0 50:01 01:00:00 ata1: CLASSIFY: device 1 00:01 01:00:00 ata1.00: ATA-7, max UDMA/133, 195371568 sectors: LBA48 NCQ (depth 0/32) ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/133 scsi1 : ata_piix ata2: CLASSIFY: device 0 7f:7f 7f:7f:7f ata2: CLASSIFY: device 1 10:01 01:14:eb ATA: abnormal status 0x7F on port 0x177 ata2.01: ATAPI, max UDMA/33 ata2.01: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA ST9100824AS 3.04 PQ: 0 ANSI: 5 SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 < sda5 > sd 0:0:0:0: Attached scsi disk sda scsi 1:0:1:0: CD-ROM TSSTcorp CD/DVDW TS-L632D TI03 PQ: 0 ANSI: 5 ......
Created attachment 10656 [details] full dmesg output when booting kernel-2.6.20.1 from HD
Created attachment 10657 [details] full dmesg output when booting kernel-2.6.20.1 from bootable CD
Created attachment 10658 [details] lspci -vv output from my laptop
Please test 2.6.22-rc5 and report the result. Thanks.
Subject: Re: [ata_piix] DVD drive not detected (slave without master) > Please test 2.6.22-rc5 and report the result. Thanks. Just a note to say I'm not dead, but still cannot test currently as the laptop is not mine. I definitely will do.
Yeap, thanks.
No luck with kernel 2.16.22.1 here: Same behavior except that I had to completely disable IDE in order to get my SATA disc handled by libata (combined_mode module parameter is not supported any more). Kernel 2.16.22.1 cdrom boot dmesg output: ... SCSI subsystem initialized libata version 2.21 loaded. ata_piix 0000:00:1f.2: version 2.11 ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 20 PCI: Setting latency timer of device 0000:00:1f.2 to 64 scsi0 : ata_piix scsi1 : ata_piix ata1: SATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x000118b0 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x000118b8 irq 15 ata1.00: ATA-7: ST9100824AS, 3.04, max UDMA/133 ata1.00: 195371568 sectors, multi 16: LBA48 NCQ (depth 0/32) ata1.00: configured for UDMA/133 ata2.01: ATAPI: TSSTcorpCD/DVDW TS-L632D, TI03, max UDMA/33 ata2.01: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA ST9100824AS 3.04 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 < sda5 > sd 0:0:0:0: [sda] Attached SCSI disk scsi 1:0:1:0: CD-ROM TSSTcorp CD/DVDW TS-L632D TI03 PQ: 0 ANSI: 5 sr0: scsi3-mmc drive: 16x/16x writer dvd-ram cd/rw xa/form2 cdda tray sr 1:0:1:0: Attached scsi CD-ROM sr0 ... Kernel 2.16.22.1 disk boot dmesg output: ... SCSI subsystem initialized libata version 2.21 loaded. ata_piix 0000:00:1f.2: version 2.11 ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 20 PCI: Setting latency timer of device 0000:00:1f.2 to 64 scsi0 : ata_piix scsi1 : ata_piix ata1: SATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x000118b0 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x000118b8 irq 15 ata1.00: ATA-7: ST9100824AS, 3.04, max UDMA/133 ata1.00: 195371568 sectors, multi 16: LBA48 NCQ (depth 0/32) ata1.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA ST9100824AS 3.04 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 < sda5 > sd 0:0:0:0: [sda] Attached SCSI disk ...
Please apply the following patch on top of 2.6.22.1 and report the boot log. http://bugzilla.kernel.org/attachment.cgi?id=12274 Thanks.
Hello Tejun, I have prepared 3 kernels for the guy with this machine to test, I hope to have the results soon. I've done: libata only, IDE only, combined libata+IDE (like in his original ubuntu kernel) and asked him to test those kernels -- Vincent - I'm not a dead tester - Legoll
Thanks, Vincent. Will wait for the result.
And right here it is: Congratulations Tejun, you fixed it ! Here is the related part of dmesg: I can attach the full bootlog, if you need it, just ask... I'll let you change the bug's status to "fixed". [ 22.726953] ata_piix 0000:00:1f.2: version 2.11 [ 22.726962] ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ] [ 22.884872] PCI: Setting latency timer of device 0000:00:1f.2 to 64 [ 22.884946] scsi0 : ata_piix [ 22.885088] scsi1 : ata_piix [ 22.885204] ata1: SATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x000118b0 irq 14 [ 22.885284] ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x000118b8 irq 15 [ 23.044296] ata1: XXX devmask=0x3 [ 23.044376] ata1.00: XXX: class=1, present=1, dfail=0, err=0x1 [ 23.044457] ata1.01: XXX: class=1, present=2, dfail=0, err=0x1 [ 23.064695] ata1.00: ATA-7: TOSHIBA MK1637GSX, DL021A, max UDMA/100 [ 23.064765] ata1.00: 312581808 sectors, multi 16: LBA48 NCQ (depth 0/32) [ 23.084654] ata1.00: configured for UDMA/100 [ 23.243965] ata2: XXX devmask=0x2 [ 23.244067] ata2.01: XXX: class=3, present=2, dfail=0, err=0x1 [ 23.424225] ata2.01: ATAPI: MATSHITADVD-RAM UJ-850S, 1.20, max UDMA/33 [ 23.623827] ata2.01: configured for UDMA/33 [ 23.624031] scsi 0:0:0:0: Direct-Access ATA TOSHIBA MK1637GS DL02 PQ: 0 ANSI: 5 [ 23.624244] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) [ 23.624328] sd 0:0:0:0: [sda] Write Protect is off [ 23.624395] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 23.624420] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 23.624563] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) [ 23.624644] sd 0:0:0:0: [sda] Write Protect is off [ 23.624712] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 23.624736] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 23.624817] sda: sda1 sda2 < sda5 > [ 23.679579] sd 0:0:0:0: [sda] Attached SCSI disk [ 23.679738] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 23.681677] scsi 1:0:1:0: CD-ROM MATSHITA DVD-RAM UJ-850S 1.20 PQ: 0 ANSI: 5 [ 23.688310] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray [ 23.688389] Uniform CD-ROM driver Revision: 3.20 [ 23.688533] sr 1:0:1:0: Attached scsi CD-ROM sr0 [ 23.688623] sr 1:0:1:0: Attached scsi generic sg1 type 5
Hmmm... It's a bit weird tho. The diagnostic failure handling code didn't kick in actually. Can you please run a control test (the same kernel without the patch) and double check stuff? Thanks.
I'll be on holidays for the next 2 weeks... When I come back...
I think that the user in the previous test was booting from the CDROM. That explains the "success" of the patch. It does not work here :ata2 DEVMASK is 0x00 witch to my understanding means no devices are attached to the second channel. here is the outpout 2.6.22.1_patched DISK boot: scsi0 : ata_piix scsi1 : ata_piix ata1: SATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x000118b0 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x000118b8 irq 15 ata1: XXX devmask=0x3 ata1.00: XXX: class=1, present=1, dfail=0, err=0x1 ata1.01: XXX: class=1, present=2, dfail=0, err=0x1 ata1.00: ATA-7: ST9100824AS, 3.04, max UDMA/133 ata1.00: 195371568 sectors, multi 16: LBA48 NCQ (depth 0/32) ata1.00: configured for UDMA/133 ata2: XXX devmask=0x0 scsi 0:0:0:0: Direct-Access ATA ST9100824AS 3.04 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 < sda5 > sd 0:0:0:0: [sda] Attached SCSI disk
devmask tests whether TF registers are accessible. It just writes certain values to registers and read them back and compare those registers echo the written values. The IDE piix driver fails too, right? If so, please post the result of 'lspci -nnvvvxxx'. Thanks.
(In reply to comment #23) > I think that the user in the previous test was booting from the CDROM. That > explains the "success" of the patch. No, I don't think so. But the portion of the log missed the relevant information, here is the end of it, where / is mounted, and the cdrom: [ 34.367669] Adding 6072528k swap on /dev/disk/by-uuid/64b9aefe-0a63-4b19-8b35-ad64ef65016c. Priority:-1 extents:1 across:6072528k [ 34.498683] EXT3 FS on sda1, internal journal [ 378.470966] ISO 9660 Extensions: Microsoft Joliet Level 3 [ 378.473371] ISOFS: changing to secondary root CDRom comes almost 6 minutes after boot, and sda is TOSHIBA MK1637GSX hard disk.
(In reply to comment #23) > I think that the user in the previous test was booting from the CDROM. That > explains the "success" of the patch. Hello, I am the owner of the PC. Definitely, I was booting from the HD and it worked. Thanks a lot!
Vincent, how reproducible is your boot failure? Eric, can you repeat booting several times and report the result?
Created attachment 12357 [details] lspci -nnvvvxxx HD boot no CD found
Created attachment 12358 [details] lspci -nnvvvxxx CD boot
My apologies to Eric and Vincent for mistrusting you. Tejun > The IDE piix driver fails too, right? Yes > If so, please post the > result of 'lspci -nnvvvxxx'. Thanks. I have noticed a difference in the results of lscpi when booting from HD or CD, so I posted both (see attachments 12357 and 12358). The PCI Id of the ICH7 controller is 00:1f.2
Hmmm... Your BIOS is tri-stating the channel cdrom lives on. Please run the following commands as root and see whether the cdrom is detected. # setpci -D -s 1f.2 56.b=0 # echo - - - > /sys/class/scsi_host/host1/scan
Tejun >Hmmm... Your BIOS is tri-stating the channel cdrom lives on. Please run the >following commands as root and see whether the cdrom is detected. ># setpci -D -s 1f.2 56.b=0 ># echo - - - > /sys/class/scsi_host/host1/scan Yeap it does (that is if the -D option is omitted in setpci command). Here is the dmesg output: ata2: soft resetting port ata2: XXX devmask=0x2 ata2.01: XXX: class=3, present=2, dfail=0, err=0x1 ata2.01: ATAPI: TSSTcorpCD/DVDW TS-L632D, TI03, max UDMA/33 ata2.01: configured for UDMA/33 ata2: EH complete scsi 1:0:1:0: CD-ROM TSSTcorp CD/DVDW TS-L632D TI03 PQ: 0 ANSI: 5 scsi 1:0:1:0: Attached scsi generic sg1 type 5 sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 1:0:1:0: Attached scsi CD-ROM sr0 Note that it works with kernel 2.6.22.1-32.fc6 without your patch applied too and even with kernel 2.6.20-1.2962.fc6. So I have added the following lines in my /etc/rc.local: PCIVAL=`/sbin/setpci -s 1f.2 56.b` if [ ! "x$PCIVAL" = x00 ]; then /sbin/setpci -s 1f.2 56.b=0 echo - - - > /sys/class/scsi_host/host1/scan fi Would it be fixed in the kernel or should I have to live with the rc.local solution ? Tanks a lot!
Tejun After I send my last report I have noticed the following lines in my dmesg output immediately after the last line reported: ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x25 data 8 in res 40/00:03:00:00:00/00:00:00:00:00/b0 Emask 0x4 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: device not ready (errno=-16), forcing hardreset ata2: soft resetting port ata2.01: configured for UDMA/33 ata2: EH complete They have appeared about 2 minutes after the detection of CDROM. Everything works fine thought(CDROM,HD)
Hmmmm... Is the cdrom device detachable? Tristating the port is probably necessary for the device to be plugged in and out. Also, please post the result of 'dmidecode'.
Created attachment 12398 [details] dmidecode outpout
(In reply to comment #34) > Hmmmm... Is the cdrom device detachable? Tristating the port is probably > necessary for the device to be plugged in and out. Yes it is. > Also, please post the result of 'dmidecode'. See attachment 12398 [details]
Created attachment 12405 [details] ata_piix-enable_signal.patch Please apply the attached patch on top of 2.6.23-rc3 and report the result. Thanks.
(In reply to comment #37) > Created an attachment (id=12405) [details] > ata_piix-enable_signal.patch > > Please apply the attached patch on top of 2.6.23-rc3 and report the result. > Thanks. > Well it worked after I tweaked it a little: Here is the output of some PRINTKs that I have added in piix_init_one() in order to make it work: ata_piix 0000:00:1f.2: version 2.11 ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ] ata_piix 0000:00:1f.2: (port_flags & ATA_FLAG_SATA)=0x2 ata_piix 0000:00:1f.2: iocfg=0x41011 sigmode=0x0 That means that the patch code never gets executed for two reasons : 1. The condition "if (!(port_flags & ATA_FLAG_SATA))" is false. I removed the ! from the condition since the function is called just once for my hardware. 2. sigmode is always zero because PIIX_SIG_MODE_MASK = 0x30000. I do not know anything about the registers values but I figure out by studying the patch code that the PIIX_SIG_MODE_SHIFT should be 18 instead of 16 so in my hardware will print the correct signal_mode[] ("tri-stated"). Here is the output of the modified patch: ata_piix 0000:00:1f.2: version 2.11 ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ] ata_piix 0000:00:1f.2: ATA_FLAG_SATA=0x2 ata_piix 0000:00:1f.2: iocfg=0x41011 sigmode=0x1 ata_piix 0000:00:1f.2: signal pins enabled (was tri-stated) ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 20 PCI: Setting latency timer of device 0000:00:1f.2 to 64 scsi0 : ata_piix scsi1 : ata_piix ata1: SATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x000118b0 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x000118b8 irq 15 ata1.00: ATA-7: ST9100824AS, 3.04, max UDMA/133 ata1.00: 195371568 sectors, multi 16: LBA48 NCQ (depth 0/32) ata1.00: configured for UDMA/133 ata2.01: ATAPI: TSSTcorpCD/DVDW TS-L632D, TI03, max UDMA/33 ata2.01: configured for UDMA/33 By the way regarding comment 33 of this it only happens with kernel 2.6.22.1 or newer and only when the CDROM tray is empty. I have the feeling that is not related to this bug but I saw in LKM lists a similar problem with a HD. Thanks a lot!
Created attachment 12433 [details] ata_piix-enable_signal-1.patch Hmmm... That's weird. Both ICH6 and 7 datasheets specify bits 16 and 17 are SIG_MODE. 18 and 19 are reserved. Can you please give a shot at the attached patch? Also, how reproducible is the timeout in comment 33 and if reproducible how often does it happen?
(In reply to comment #39) > Hmmm... That's weird. Both ICH6 and 7 datasheets specify bits 16 and 17 are > SIG_MODE. 18 and 19 are reserved. So my BIOS is not tri-stating the second channel as you mention in comment 31 but sets a reserved bit (namely 18th bit). > Can you please give a shot at the attached patch? Tried it and failed. The reason is that the line : iocfg &= ~PIIX_SIG_MODE_MASK; clears bits 16 and 17 which are already clear. Bit 18 is the cause of the problem and therefore what it should be cleared( or even the whole byte as /sbin/setpci -s 1f.2 56.b=0 does). > Also, how reproducible is the timeout in comment 33 100% reproducible > and if reproducible how often does it happen? Not very often and rather irregularly: Just 4 times over this weekend. Time intervals range from 5 minutes to 24 hours I will investigate it more to see if it has something to do with CD tray activity (open/close) and/or desktop applications.
Tejun The documentation of ICH7 provided by Intel states that bits 18,19 of IDE_CONFIG (PIIX_IOCFG) Register are: "No Operation (NOP) — R/W. These bits are read/write for legacy software compatibility, but have no functionality in the Intel® ICH7." witch is not true as we have discovered. Any way at least they are not "Reserved" so it is not a problem to clear them unconditionally. By the way searching for IDE_CONFIG register accesses in ata_piix.c driver I came across a "hidden" one in function do_pata_set_dmamode() where the register is referenced by its offset value "0x54" and not as PIIX_IOCFG enumeration. In this code fragment only the lower word of the register is accessed but there is a comment about the need to set the 10th bit (which according to documentation is reserved) but there is no code to do it. Regarding comment 33 timeout issue: I have not found any relation to CDROM activity (open/close tray, mount/umount CDs, burn/erase CDs) or desktop applications (user is logged in/out). The only rule is that it happens two times within 30 min after every boot (about two min between each timeout ) and then very rarely and randomly (12 hours to 24 hours). This is what "grep ata2 /var/log/messages" gives: Boot time : Aug 20 10:19:04 localhost kernel: ata2.01: ATAPI: TSSTcorpCD/DVDW TS-L632D, TI03, max UDMA/33 Aug 20 10:19:05 localhost kernel: ata2.01: configured for UDMA/33 30 minutes later: Aug 20 10:51:11 localhost kernel: ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Aug 20 10:51:11 localhost kernel: ata2.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x25 data 8 in Aug 20 10:51:16 localhost kernel: ata2: port is slow to respond, please be patient (Status 0xd0) Aug 20 10:51:21 localhost kernel: ata2: device not ready (errno=-16), forcing hardreset Aug 20 10:51:21 localhost kernel: ata2: soft resetting port Aug 20 10:51:21 localhost kernel: ata2.01: configured for UDMA/33 Aug 20 10:51:21 localhost kernel: ata2: EH complete Aug 20 10:52:25 localhost kernel: ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Aug 20 10:52:25 localhost kernel: ata2.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x1e data 0 Aug 20 10:52:30 localhost kernel: ata2: port is slow to respond, please be patient (Status 0xd0) Aug 20 10:52:35 localhost kernel: ata2: device not ready (errno=-16), forcing hardreset Aug 20 10:52:35 localhost kernel: ata2: soft resetting port Aug 20 10:52:35 localhost kernel: ata2.01: configured for UDMA/33 Aug 20 10:52:35 localhost kernel: ata2: EH complete 14 hours later: Aug 21 00:19:29 localhost kernel: ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Aug 21 00:19:29 localhost kernel: ata2.01: cmd a0/00:00:00:00:20/00:00:00:00:00/b0 tag 0 cdb 0x25 data 8 in Aug 21 00:19:34 localhost kernel: ata2: port is slow to respond, please be patient (Status 0xd0) Aug 21 00:19:39 localhost kernel: ata2: device not ready (errno=-16), forcing hardreset Aug 21 00:19:39 localhost kernel: ata2: soft resetting port Aug 21 00:19:40 localhost kernel: ata2.01: configured for UDMA/33 Aug 21 00:19:40 localhost kernel: ata2: EH complete
I know where the timeout is coming from. [cc'ing Albert] If you keep a data cd in the drive, does it go away? And, yeah, the doc says the bits are no-op. I was trying to implement a generic solution in my previous patch thinking those were the SIG_MODE bits. I guess we'll need more specific workaround for your machine. I'll prep one soon. Thanks.
Created attachment 12478 [details] ata_piix-iocfg-bit18-quirk.patch Okay, here it is. Please test and report. Thanks.
(In reply to comment #42) > I know where the timeout is coming from. [cc'ing Albert] If you keep a data > cd > in the drive, does it go away? Yes it does.
(In reply to comment #43) > > Okay, here it is. Please test and report. Thanks. > Worked fine. My objection is that there is no need to be so picky on which vendors model the iocfg-bit18-quirk would be applied. I am sure there are more models of the same or other vendor having the same issue. Clevo M575U (http://www.clevo.com.tw/products/M575U.asp) for instance is too similar to M570U (ICH7M based too) and surely it has the same issue since it uses the same BIOS. Thanks a lot.
Thanks for testing. I'll forward the patch upstream. The thing is ata_piix covers way too many chips and I don't want to poke the bit on all of them. It seems too risky and other developers won't like it either. I think the only way is to build the DMI ID table as we go along. Also, do you care to file another bug report about the timeout problem and cc me and Albert? We know what's wrong but haven't figured out how to fix it yet and it would be nice to have one more person to test it. Thanks.
(In reply to comment #46) > Also, do you care to file another bug report about the timeout problem and cc > me and Albert? We know what's wrong but haven't figured out how to fix it > yet > and it would be nice to have one more person to test it. Thanks. > Yes I will be glad to help. Here is the new bug url: http://bugzilla.kernel.org/show_bug.cgi?id=8926 See you there.