Bug 10884
|
Description
Lars Luthman
2008-06-07 12:38:02 UTC
Created attachment 16430 [details]
dmesg output without acpi=off
Created attachment 16431 [details]
dmesg output with acpi=off
>ACPI Error (evregion-0316): No handler for Region [ERAM] (ffff81007f35e720) >[Emb eddedControl] [20070126] hmm, could you please attach the acpidump output? you can get the latest pmtools at http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ Created attachment 16455 [details]
acpidump output
Created attachment 16456 [details]
lspci -v output too, in case it's useful
dmesg.acpi=off shows the device: ata4: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x1810 irq 14 ... ata4.01: ATAPI: TSSTcorp CDDVDW SN-S082H, SB00, max UDMA/33 ata4.01: configured for UDMA/33 scsi 3:0:1:0: CD-ROM TSSTcorp CDDVDW SN-S082H SB00 PQ: 0 ANSI: 5 Uniform Multi-Platform E-IDE driver ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Driver 'sr' needs updating - please use bus_type methods sr0: scsi3-mmc drive: 62x/62x writer dvd-ram cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 3:0:1:0: Attached scsi CD-ROM sr0 sd 0:0:0:0: Attached scsi generic sg0 type 0 sr 3:0:1:0: Attached scsi generic sg1 type 5 When you use this device, does its interrupts show up on irq 14? please attach the /proc/interrupts for both normal and acpi=off boots. Rather than "acpi=off", does booting with any of these help?: pci=nommconf acpi=noirq noapic Attaching /proc/interrupts for normal and acpi=off boots. None of pci=nommconf, acpi=noirq and noapic gets me a device file for the device, attaching dmesg output for all three cases. Created attachment 16467 [details]
/proc/interrupts without any ACPI boot options
Created attachment 16468 [details]
/proc/interrupts with acpi=off
Created attachment 16469 [details]
dmesg output for pci=nommconf
Created attachment 16470 [details]
dmesg output for acpi=noirq
Created attachment 16471 [details]
dmesg output for noapic
how about boot option libata.noacpi=1? libata.noacpi=1 does not help, attaching dmesg output. Created attachment 16594 [details]
dmesg output with libata.noacpi=1
I tried to reproduce your problem on my laptop. it only happens if I set the AHCI to a specific mode, and it seems that this is not a Linux kernel bug. Please lists all your bios options about SATA/IDE setting. Attaching screenshots from the relevant BIOS setup screens (Main, Main/IDE Channel 1 Master, Main/IDE Primary/Slave, Advanced). The comments for the option Advanced/Large Disk Access Mode said that it should be set to "Other" for UNIX (it didn't mention Linux) so I tried that - it didn't help with the CD/DVD device and it broke my SD card reader, so I set it back to "DOS". Created attachment 16787 [details]
BIOS screenshot, Main
Created attachment 16788 [details]
BIOS screenshot, Main/IDE Channel 1 Master
Created attachment 16789 [details]
BIOS screenshot, Main/IDE Primary/Slave
Created attachment 16790 [details]
BIOS screenshot, Advanced
could you please change the type of IDE PRIMARY/SLAVE to "auto" and see if it helps? please attach the screenshot after setting it to "auto". Screenshot attached. The only change was that some of the options on the Primary/Slave page got greyed out. It is still reported as [CD-ROM] on the Main page, and no device file appears in /dev. While booting with a patched 2.6.22.5 (for audio and wireless) I found this in the dmesg output: PCI: Probing PCI hardware (bus 00) PCI: Transparent bridge - 0000:00:1e.0 PCI: Bus #07 (-#0a) is hidden behind transparent bridge #06 (-#07) (try 'pci=assign-busses') Please report the result to linux-kernel to fix this permanently Could it be relevant? Will try pci=assign-busses later, have to leave for a couple of hours now. Created attachment 16795 [details]
BIOS screenshot, Main/IDE Primary/Slave, AUTO
does the problem still exists in the latest kernel? I did some tests on my test box and found that enabling/disabling ACPI can result in the different sata register values. but sorry I've no idea how to debug this problem, and IMO, this may be a ata/scsi problem? cc Tejun and Jeff. That's one weird bug. Can you try 2.6.27.6 and whether the problem is still there? ACPI on/off is somehow affecting device presence detection on PATA, which is really weird. I'll prep debug patches for 2.6.27.6 as soon as the problem is confirmed on 2.6.27. Thanks. Tried with 2.6.27.6 now, the behaviour is a bit different. Without acpi=off the kernel doesn't even finish booting, it gets stuck printing line after line of ACPI: EC: non-query interrupt received, switching to interrupt mode After five minutes of this I rebooted with acpi=off, and then the DVD drive works, just as with earlier versions. It appears as /dev/scd0 (with a symbolic link /dev/sr0) and I can mount and read DVDs. So not only is the problem still there in 2.6.27.6, it has gotten worse. Or maybe it's just detected earlier. Zhang Rui, can you please help here? I don't got a clue. okay, the symptom on my test box is not the same to Lars'. i.e. I have this problem only if the AHCI mode is disabled in the BIOS. I probably don't have this issue when SATA is set to the AHCI mode, but I need to double check later. some debug info is attached. Created attachment 18919 [details]
dmesg-acpi-off-ahci-disable
Created attachment 18920 [details]
dmesg-acpi-on-ahci-disable
Created attachment 18921 [details]
tree /sys/bus/scsi/devices/ when acpi=off
Created attachment 18922 [details]
tree /sys/bus/scsi/devices/ when acpi=on
Created attachment 18923 [details]
lspci -vxxx when acpi=off
Created attachment 18924 [details]
lspci -vxxx when acpi=on
when in AHCI mode, with ACPI enabled, I can only get one SCSI device i.e. #tree /sys/bus/scsi/devices/ /sys/bus/scsi/devices/ `-- 1:0:0:0 -> ../../../devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 when acpi=off, kernel failed to get the rootfs. Hi, Tejun, any other info needed? Does the following patch help? http://article.gmane.org/gmane.linux.ide/36218/raw no, :( last time when I investigated this bug, I found that one port/link is inactive while it's active if acpi=off. And the status of this port/link is read from a register. I forget what the register is, but if you want, I can try to find it out. You're getting nobody cared on the interrupt handler, so the driver wouldn't really work right. The misdetection could be a different problem tho. Can you please post kernel log with the above patch applied? Let's first clear the irq problem out of the way; then, I'll prep a patch to follow the detection sequence. Thanks. Created attachment 19026 [details]
dmesg without the patch
Created attachment 19027 [details]
dmesg with the patch
Can you please try acpi=off w/o and w/ the patch? Thanks. Created attachment 19043 [details]
dmesg without the patch when acpi is enabled
hah, I don't have this problem in 2.6.28-rc6.
do i still need to try the patch?
Created attachment 19044 [details]
dmesg-acpi-off-ahci-disable
oops, forget what I said. :)
the problem only exists if acpi=off and ahci mode is disabled.
Ah.. strange. W/ acpi off, your machine is experiencing IRQ storm and this is with the spurious IRQ detection patch applied, right? libata definitely needs to be more resilient against these problems but as for this specific problem, I'm running out of ideas. Does irqpoll help? Created attachment 19059 [details] dmesg-acpi-off-ahci-disable-with-the-patch well, the dmesg in comment #45 is gotten without the patch. and with the patch applied, everything works fine. :p Thanks for confirming. There are still issues regarding the patch but we now know what the problem is. I'll keep discussing it on linux-ide. hmmm, the irq problem is clear now. next is the sata detection problem, :) I can do the tests as soon as the patch is available. Created attachment 19060 [details]
detection-debug.patch
Heh... almost forgot about that. Here it is.
Created attachment 19098 [details]
dmesg-acpi-off-with-sata-detect-patch
Created attachment 19099 [details]
dmesg-acpi-on-with-sata-detect-patch
things don't change, still one active link detected. This is interesting. The following is w/ acpi off. [ 11.640762] ata1: XXX devmask=0x3 [ 11.791030] ata1: XXX WAIT_READY M 0 [ 11.791147] ata1: XXX WAIT_READY S 0 [ 11.791286] ata1.00: XXX CLASSIFY TF 00/01:01:14:eb [ 11.791413] ata1.01: XXX CLASSIFY TF 00/04:01:14:eb and acpi on. [ 0.886948] ata1: XXX devmask=0x0 [ 1.038015] ata1: XXX WAIT_READY M 0 [ 1.038147] ata1.00: XXX CLASSIFY TF 7f/7f:7f:7f:7f [ 1.038277] ata1.01: XXX CLASSIFY TF 7f/7f:7f:7f:7f devmask is determined by writing values to IDE TF registers and reading back. If device is attached to the channel, the device will store the value and reply the stored value. If not, bogus value will be reported. Classification works by reading TF registers after SRST. After SRST is complete, the device posts its status and classification code in its TF registers and libata uses the values to determine whether device is attached and if so which type. With acpi turned on, the device is failing both detection methods and behaving exactly as if there is no device attached to the channel at all. This is really strange. I've never seen something like this. I can't really think of any way acpi can affect this low level operation of ATA. :-( Can you attach the results of "lspci -nnvvvxxx" with acpi turned off and on. Maybe the controller channel has been disabled somehow. Created attachment 19114 [details]
lspci acpi=off
Created attachment 19115 [details]
lspci acpi=on
Thanks, that explained what was going on. With ACPI turned on, bits 16-17 of 00:1f.1:54-57 which is the SIG_MODE of IDE_CONFIG register is set to 01b which is Tri-state (Disabled) while with ACPI off it's 00b - Normal (Enabled). The signal pins are tristated and thus the controller can't see the device. This probably has something to do with ACPI docking support. cc'ing Holger Macht. Holger, with ACPI turned on, this laptop tristates the IDE port and thus fail to detect the cdrom attached there. This smells like something regarding the dock didn't go as planned. Any ideas? eek... Holger is not registered to OSDL bz. I'll ask him to take a look via email. Just to make sure, all the latest dmesg output is with 2.6.28-rc-something, right? Or still 2.6.27.6? Anyway, there's [ 0.242695] ACPI: ACPI Dock Station Driver: 1 docks/bays found in the log, and I wonder whether this actually is the ata drive or a possible other dock station. Actually I can't find anything in acpidump ;-) So what does /sys/devices/platform/dock.?/type contain? yes, they are gotten from 2.6.28-rcX #cat /sys/devices/platform/dock.0/type dock_station In fact, I uses an ATX box for this mobile board, and there is no dock station available. I just tested kernel 2.6.28, the bug is still there. No DVD device file when I boot without acpi=off. Tested again with 2.6.29, same problem. The bug is still there. Turns out this bug has been fixed by a BIOS upgrade. Not Linux's fault then. Everything seems to work now. Resolving as invalid. Thanks. |