Bug 8051

Summary:	[ata_piix] DVD drive not detected (slave without master)
Product:	IO/Storage	Reporter:	Vincent Legoll (vincent.legoll)
Component:	Serial ATA	Assignee:	Tejun Heo (htejun)
Status:	RESOLVED CODE_FIX
Severity:	normal	CC:	albertcc, bunk, dangelis, htejun, jgarzik
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.20	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	lspci output dmesg from (working) ubuntu install cd - 2.6.15-23 dmesg from (not working) boot from HD - 2.6.17-11 (ubuntu) dmesg from (not working) boot from HD - install cd kernel - 2.6.15-23 dmesg from (not working) boot from HD - 2.6.20 vanilla kernel debug patch full dmesg output when booting kernel-2.6.20.1 from HD full dmesg output when booting kernel-2.6.20.1 from bootable CD lspci -vv output from my laptop lspci -nnvvvxxx HD boot no CD found lspci -nnvvvxxx CD boot dmidecode outpout ata_piix-enable_signal.patch ata_piix-enable_signal-1.patch ata_piix-iocfg-bit18-quirk.patch

Description Vincent Legoll 2007-02-21 11:50:16 UTC

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.

Comment 1 Vincent Legoll 2007-02-21 11:59:06 UTC

Created attachment 10486 [details]
lspci output

Comment 2 Vincent Legoll 2007-02-21 12:01:51 UTC

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.

Comment 3 Vincent Legoll 2007-02-21 12:05:38 UTC

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.

Comment 4 Vincent Legoll 2007-02-21 12:16:05 UTC

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.

Comment 5 Vincent Legoll 2007-02-21 12:21:06 UTC

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)

Comment 6 Tejun Heo 2007-02-23 22:38:57 UTC

Thanks for the detailed info.  Can you please apply the attached patch over
2.6.20 and report what the kernel says?

Comment 7 Tejun Heo 2007-02-23 22:41:17 UTC

Created attachment 10516 [details]
debug patch

Comment 8 Vincent Legoll 2007-02-24 03:59:12 UTC

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.

Comment 9 D. Angelis 2007-03-08 10:58:55 UTC

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
	......

Comment 10 D. Angelis 2007-03-08 11:03:09 UTC

Created attachment 10656 [details]
full dmesg output when booting kernel-2.6.20.1 from HD

Comment 11 D. Angelis 2007-03-08 11:03:56 UTC

Created attachment 10657 [details]
full dmesg output when booting kernel-2.6.20.1 from bootable CD

Comment 12 D. Angelis 2007-03-08 11:05:00 UTC

Created attachment 10658 [details]
lspci -vv output from my laptop

Comment 13 Tejun Heo 2007-06-20 00:52:06 UTC

Please test 2.6.22-rc5 and report the result.  Thanks.

Comment 14 Vincent Legoll 2007-06-20 16:22:16 UTC

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.

Comment 15 Tejun Heo 2007-06-20 20:06:48 UTC

Yeap, thanks.

Comment 16 D. Angelis 2007-08-06 08:50:15 UTC

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
...

Comment 17 Tejun Heo 2007-08-06 09:47:41 UTC

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.

Comment 18 Vincent Legoll 2007-08-08 07:37:19 UTC

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

Comment 19 Tejun Heo 2007-08-08 21:15:35 UTC

Thanks, Vincent.  Will wait for the result.

Comment 20 Vincent Legoll 2007-08-09 02:43:22 UTC

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

Comment 21 Tejun Heo 2007-08-09 03:40:36 UTC

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.

Comment 22 Vincent Legoll 2007-08-09 04:00:18 UTC

I'll be on holidays for the next 2 weeks...
When I come back...

Comment 23 D. Angelis 2007-08-09 10:31:37 UTC

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

Comment 24 Tejun Heo 2007-08-10 02:40:39 UTC

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.

Comment 25 Vincent Legoll 2007-08-10 03:04:28 UTC

(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.

Comment 26 Eric Polin 2007-08-10 09:44:52 UTC

(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!

Comment 27 Tejun Heo 2007-08-10 09:50:15 UTC

Vincent, how reproducible is your boot failure?  Eric, can you repeat booting several times and report the result?

Comment 28 D. Angelis 2007-08-13 02:43:32 UTC

Created attachment 12357 [details]
lspci -nnvvvxxx HD boot no CD found

Comment 29 D. Angelis 2007-08-13 02:44:48 UTC

Created attachment 12358 [details]
lspci -nnvvvxxx CD boot

Comment 30 D. Angelis 2007-08-13 02:58:15 UTC

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

Comment 31 Tejun Heo 2007-08-13 19:22:43 UTC

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

Comment 32 D. Angelis 2007-08-14 08:45:38 UTC

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!

Comment 33 D. Angelis 2007-08-14 10:01:45 UTC

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)

Comment 34 Tejun Heo 2007-08-15 00:49:57 UTC

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'.

Comment 35 D. Angelis 2007-08-15 23:47:16 UTC

Created attachment 12398 [details]
dmidecode outpout

Comment 36 D. Angelis 2007-08-15 23:49:03 UTC

(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]

Comment 37 Tejun Heo 2007-08-16 07:24:59 UTC

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.

Comment 38 D. Angelis 2007-08-16 12:04:25 UTC

(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!

Comment 39 Tejun Heo 2007-08-17 18:46:15 UTC

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?

Comment 40 D. Angelis 2007-08-20 01:28:28 UTC

(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.

Comment 41 D. Angelis 2007-08-21 11:46:54 UTC

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

Comment 42 Tejun Heo 2007-08-21 18:24:16 UTC

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.

Comment 43 Tejun Heo 2007-08-21 20:00:23 UTC

Created attachment 12478 [details]
ata_piix-iocfg-bit18-quirk.patch

Okay, here it is.  Please test and report.  Thanks.

Comment 44 D. Angelis 2007-08-22 08:49:52 UTC

(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.

Comment 45 D. Angelis 2007-08-22 09:34:27 UTC

(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.

Comment 46 Tejun Heo 2007-08-22 18:13:13 UTC

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.

Comment 47 D. Angelis 2007-08-23 02:07:53 UTC

(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.