Distribution: Hardware Environment: HP psc2110xi and a Logitech Cordless Optical Mouse (Logitech Click! Plus Software Environment: Problem Description: I(David van Hoose [david.vanhoose@comcast.net]) compiled and booted 2.4.23-pre5 the other morning, and my USB didn't work. My USB does work under 2.4.23-pre4.
Created attachment 953 [details] config file
Created attachment 954 [details] dmesg
Created attachment 970 [details] Dmesg for 2.4.23-pre6
Bug still exists in 2.4.23-pre6. Attached new dmesg.
yep, once dos2unix'd, the dmesg for -pre5 and pre6 are pretty much the same. Any chance you can attach the dmesg for -pre4 for the success case? It would also be helpful to see /proc/interrupts for the success and failing case. I'm not familiar with the psc21110xi, can you attach the dmidecode output to describe it? http://www.nongnu.org/dmidecode/ Also, please attach the output from acpidmp, available in /usr/sbin/, or in here http://www.intel.com/technology/iapc/acpi/downloads/pmtools-20010730.tar.gz thanks, -Len
As per requested I am attaching the dmesg, config, /proc/interrupts info, dmidecode info, and acpidmp info for both pre4 and pre6.
Created attachment 1010 [details] acpidmp output for the success case. (pre4)
Created attachment 1011 [details] acpidmp output for the failure case. (pre6)
Created attachment 1012 [details] config for 2.4.23-pre4
Created attachment 1013 [details] config for 2.4.23-pre6
Created attachment 1014 [details] dmesg for 2.4.23-pre4
Created attachment 1015 [details] dmesg for 2.4.23-pre6
Created attachment 1016 [details] dmidecode output for 2.4.23-pre4
Created attachment 1017 [details] dmidecode output for 2.4.23-pre6
Created attachment 1018 [details] output from 'cat /proc/interrupts' for 2.4.23-pre4
Created attachment 1019 [details] output from cat '/proc/interrupts' for 2.4.23-pre6
Thanks for all the info. Looks like in pre5 one of your three usb-ohci's is now sharing an interrupt with acpi. pre4: 9: 4756 IO-APIC-edge usb-ohci 20: 6927 IO-APIC-level acpi pre5: 20: 1 IO-APIC-level acpi, usb-ohci $ acpixtract APIC acpidmp |madt ACPI: APIC (v001 ASUS P4S8X 0x42302e31 MSFT 0x31313031) @ 0x(nil) ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0]) ACPI: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x0] trigger[0x1]) ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x14] polarity[0x3] trigger[0x3]) ACPI: LAPIC_NMI (acpi_id[0x00] polarity[0x1] trigger[0x1] lint[0x1]) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Length 90 OK Checksum OK So IRQ20 looks correct for the ACPI interrupt. Though it is curious that it was registering acpi events in -pre4 but just 1 intr in -pre5. It seems that -pre4 failed to find an interrupt for USB and left it at 9 while -pre5 assigned 20: < pci_irq-0302 [18] acpi_pci_irq_derive : Unable to derive IRQ for device 00:03.0 < PCI: No IRQ known for interrupt pin A of device 00:03.0 < host/usb-ohci.c: USB OHCI at membase 0xe081a000, IRQ 9 --- > host/usb-ohci.c: USB OHCI at membase 0xe081a000, IRQ 20 This should be a _good_ thing;-) dmidecode shows that this is a Award Software, Inc. ASUS P4S8X ACPI BIOS Revision 1004 http://www.asus.com.tw/mb/socket478/p4s8x/overview.htm says it has an SiS 648 chip-set. http://www.asus.com.tw/support/download/item.aspx?ModelName=P4S8X&Type=All says that its 10/4/2002 BIOS 1004 is the latest. Can you attach the output from lspci -vv (run under any version) so we can verify that device 00:03.0 is your USB and the exact chip-set id? Please boot -pre5 or later with acpi=off and verify that USB works, and attach the output of /proc/interrupts. I expect we will not see USB on IRQ 20, which I think is our smoking gun. Thanks.
Looking at the DSDT... Name (APIC, Package (0x25) { ... Package (0x04) { 0x0003FFFF, 0x00, 0x00, 0x14 }, says that this puppy (Pin A of Device 3) should indeed be on IRQ20 (assuming we have the right puppy;-) So the bug must be related to sharing the IRQ with the acpi interrupt. We can't verify by moving the controller to another slot to pick up an other interrupt, but it would be good to confirm that the other USB controllers work -- let me know if the devices work if you plug them into the other USB connectors. Thanks.
Okay. I tried plugging the devices into the other connectors on my system. Oddly enough both connectors on the USB controller expansion slot work. However, only one connector works on each of the other two controllers. Under pre4 and pre6 (w/ acpi=off) all 6 connectors work. Under pre5 and pre6 (w/ acpi) only 4 connectors work.
Created attachment 1025 [details] output from 'cat /proc/interrupts' for 2.4.23-pre6 w/ acpi=off
Created attachment 1026 [details] lspci -vv output (2.4.23-pre4)
The problem is wrong irq makes USB work, but correct makes it failure. another strange thing is acpi interrupt quantity in -pre4 is very high: >20: 6927 IO-APIC-level acpi This vaule is rare unusally and less than 100, especially for a desktop. Please attach '/proc/interrupts' with acpi=off but ioapic is on
Created attachment 1027 [details] output from 'cat /proc/interrupts' for 2.4.23-pre4 w/ acpi=off
>The problem is wrong irq makes USB work, but correct makes it failure. >another strange thing is acpi interrupt quantity in -pre4 is very high: >>20: 6927 IO-APIC-level acpi so 20 is right or wrong? 20 is what is in DSDT?(yes!?), is DSDT right or wrong ? well I think, we know what patches make USB fail, are Ext irq patch made by Andrew de Q, the same person made a fall back patch that can be applied , to work around this problem, and you can test it with 2.4.22-ac4. Now the question, since finally some guy appears and say well, I can read ext irq from DSDT is easy, and this appears in kernel (for me, with more than one year in delay) , I ask is USB ready to work with ext irqs? or should we say no, the problem is DSDT that have a bug here and DSDT should say the same irq of what you have in Microsoft windows. And what irqs you have under Microsoft Windows? isn't your machine windows XP pr
Re: USB ports no telling which plug is wired to which controller, but the fact that 4/6 work is promising as it confirms that the IOAPIC USB interrupts > 16 not shared with acpi are working. Re: /proc/interrupts with IOAPIC, but without ACPI. Both the pre4 and -pre5 acpi=off results put the system in XT-PIC mode, not IOAPIC. It is likely that the IOAPIC on this box is accessible only in ACPI mode. Just to be sure, boot a CONFIG_SMP kernel (w/o ACPI) and see if /proc/interrupts has got your IOAPIC, or still XT-PIC. Re: windows yes, it would be interesting to know if windows enables the IOAPIC on this box, and if they put the USB interrupt with ACPI on IRQ20. It appers that is the proper thing to do, but Linux doesn't get it right. Re: IRQ20 getting 1 interrupt If you boot the latest with ACPI enabled, does /proc/interrupts increment past 1 if you provoke ACPI events -- say by pressing the power button a few times? Re: lspci 00:03.0 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB Controller (rev 0f) (prog-if 10 [OHCI]) Interrupt: pin A routed to IRQ 9 00:03.1 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB Controller (rev 0f) (prog-if 10 [OHCI]) Interrupt: pin B routed to IRQ 21 00:03.2 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB Controller (rev 0f) (prog-if 10 [OHCI]) Interrupt: pin C routed to IRQ 22 Thanks, this confirms that 00:03.0 is indeed the controller of interest, and thus the AML does indeed say this controller should be on IRQ20. Re: what is wrong I think Luming is correct. USB0 seems to have been working by accident in -pre4. Unclear how it got any interrupts down on IRQ9. But now that it is assigned to what appears to the correct IRQ, it starves for interrupts. As the other USB ports are working fine, surely this one got nailed because it is sharing an IRQ with acpi events -- a special case where we've had problems before.
If USB has the wrong IRQ, unusally interrupt storm occurs and report a 'interrupt nobody cared', as we have seen before. But in -pre4, we can't see such thing. weird! Currently some USB bugs occur because of USB driver's bug. See Bug 1240. try if it can resolve your problem.
Here is a kicker for you all. Linux 2.6.0-test7 through bk8 works perfectly on my system with ACPI and USB. Not even a warning. If you would like to see any outputs under 2.6.0, let me know.
Does 2.6.0-test8 work as well as "2.6.0-test7 through bk8"? Does 2.4.23-pre8 work? can you attach the /proc/interrupts and dmesg for each?
Created attachment 1172 [details] config for 2.6.0-test8-bk2
Created attachment 1173 [details] Boot messages for 2.6.0-test8-bk2
Created attachment 1174 [details] output from 'cat /proc/interrupts' for 2.6.0-test8-bk2
2.6.0-test7 through 2.6.0-test8-bk2 work perfectly. Haven't updated my kernel since bk2 though. 2.4.23-pre5 through 2.4.23-pre8 do not work.
Created attachment 1175 [details] config for 2.4.23-pre8
Created attachment 1176 [details] boot messages for 2.4.23-pre8
Created attachment 1177 [details] output from 'cat /proc/interrupts' for 2.4.23-pre8
I'm delighted that 2.6 is working. The quesion now is: 1. why did 2.4.23-pre4 work with USB on IRQ9? this has a echo of the weird linking between USB on IRQ20 and IRQ 9 seen on SiS 645 in bug #1352 but there USB and ACPI share IRQ9 in PIC mode, and in APIC mode USB moves to 20 and ACPI stays at 9. 2. 2.4.23 and 2.6 both have USB with ACPI on IRQ20, so why does 2.6 work but 2.4 does not?
Created attachment 1185 [details] SIS I2C quirk foundin 2.6 but not in 2.4 One difference between 2.4 and 2.6 is the attached SIS quirk added for I2C. Please back that quirk out of your 2.6 tree like so: patch --dry-run -Rp1 </tmp/sis_quirk_26.diff remove the code that depends on it from your .config: CONFIG_I2C_SIS96X=n and see if that makes 2.6 mis-behave like 2.4, or if USB still runs. Also, please verify for me that you get ACPI events properly. If you connect your USB mouse to one of the ports that isn't shared with acpi, then you should be able to trigger ACPI interrupts by pressing your power button. (if acpid is enabled, it may shut down your system, so you may want to disable that first), and observering the /proc/interrupts row for acpi incrementing for each button press. thanks, -Len
Created attachment 1186 [details] patch to add SIS quirk to 2.4.23 totally untested, but in case removing the SIS quirk from 2.6 causes failure, here is a patch to add it to 2.4.23.
Can you make that patch for 2.6.0-test9?
2.6 does not misbehave when I remove the SiS quirk. My USB works and ACPI works.
Re: why -pre4 worked and -pre5 stopped working This box has no MPS, so with ACPI off it runs in XT-PIC mode: > 9: 282 XT-PIC ehci_hcd, usb-ohci, usb-ohci, usb-ohci, eth0 This means that if left untouched, the PIRQ routers direct all the PCI devices to IRQ9 on the PIC. -pre4 ACPI failed to discover the IRQ for the USB controller of interest: > pci_irq-0302 [19] acpi_pci_irq_derive : Unable to derive IRQ for device 00:03.0 > PCI: No IRQ known for interrupt pin A of device 00:03.0 this was because it didn't have the fix for bug #1165 which applies to systems which share the ACPI SCI with a PCI device. So -pre4 programmed the SCI properly, but left USB down on IRQ9: > 9: 4756 IO-APIC-edge usb-ohci > 20: 6927 IO-APIC-level acpi The interrupt pin of device 00:03.0, the USB controller, is connected both to the IRQ20 pin of the IOAPIC, and to the PIRQ router (LNKE) which has it directed to IRQ9 of the PIC, which is set to level sensitive. All bets are off in this situation, but apparently the failure didn't cause symptoms that a user would notice.
So can this problem be fixed or do I have to rely on a bug? And is there any reason why does this problem not exist under 2.6.0?
2.4.23-pre8: IO-APIC (apicid-pin) 2-0, 2-16,...not connected. NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 09 001 01 0 0 0 0 0 1 1 71 14 001 01 1 1 0 1 0 1 1 71 IRQ to pin mappings: IRQ9 -> 0:9-> 0:20 2.6.0-test8: IO-APIC (apicid-pin) 2-0, 2-9, 2-16...not connected. NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 09 000 00 1 0 0 0 0 0 0 00 14 001 01 1 1 0 1 0 1 1 A1 IRQ9 -> 0:20 So 2.4 has IRQ9 enabled when 2.6 does not, and it has pin 20 mapped to it. The other difference is 2.6 has sis_apic_bug -- though i'm not sure if that code is running on this box.
Created attachment 1378 [details] patch to print IOAPIC after ACPI has programmed it 2.6 only Please apply this patch to the working 2.6 and failing 2.4 kernels and attach the resulting dmesg. thanks, -Len
Created attachment 1389 [details] dmesg for 2.4.23-pre4 with IO-APIC patch
Created attachment 1390 [details] dmesg for 2.4.23-pre9 with IO-APIC patch
Created attachment 1391 [details] dmesg for 2.6.0-test9 with IO-APIC patch
shoot, looks like that patch applied to 2.6 but mis-applied to 2.4. Please apply the patch below to 2.4.23-pre9 and attach the dmesg. (no need to run further tests on -pre4, its evil ways are well known;-) http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.4.22/20031107180852-print_IO_APIC.patch thanks, -Len
Created attachment 1392 [details] dmesg for 2.4.23-pre9 with correct IO-APIC patch
Created attachment 1393 [details] 2.4.23 patch to mpparse.c mp_override_legacy_irq() Please apply this patch to 2.4.23 and attach the dmesg. It will cause the over-ride entry for pin20 to replace the entry for pin9 on IRQ9, rather than creating an additional entry for IRQ9. This fix was originally made to 2.6 by Unisys for ES7000 support, and was integrated into 2.6 by akpm on June 14th. thanks, -Len
The patch to override legacy irq() worked. All 6 USB ports work perfectly.
Created attachment 1402 [details] dmesg of working 2.4.23-pre9
Created attachment 1403 [details] output of 'cat /proc/interrupts' for the working 2.4.23-pre9
Thinking about the root cause of this bug... It is not a coincidence that IRQ20 in the failure case always registers 1 interrupt, and never any more. This must mean that the IO-APIC has the interrupt set in level triggered mode, and is waiting for an EOI message to clear its Remote IIR. But the Local APIC must have the interrupt set for level triggered mode, so its EOI never sends the appropriate message to the IOAPIC, and thus no new interrupts on that pin are seen.
*** Bug 1582 has been marked as a duplicate of this bug. ***
shipped in 2.4.23 -- closing.