Bug 1283

Summary: USB failure starting in 2.4.23-pre5 on SIS 648 IOAPIC
Product: ACPI Reporter: Luming Yu (luming.yu)
Component: Config-InterruptsAssignee: Len Brown (lenb)
Severity: normal CC: acpi-bugzilla, david.vanhoose
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.4.23-pre5 Subsystem:
Regression: --- Bisected commit-id:
Attachments: config file
Dmesg for 2.4.23-pre6
acpidmp output for the success case. (pre4)
acpidmp output for the failure case. (pre6)
config for 2.4.23-pre4
config for 2.4.23-pre6
dmesg for 2.4.23-pre4
dmesg for 2.4.23-pre6
dmidecode output for 2.4.23-pre4
dmidecode output for 2.4.23-pre6
output from 'cat /proc/interrupts' for 2.4.23-pre4
output from cat '/proc/interrupts' for 2.4.23-pre6
output from 'cat /proc/interrupts' for 2.4.23-pre6 w/ acpi=off
lspci -vv output (2.4.23-pre4)
output from 'cat /proc/interrupts' for 2.4.23-pre4 w/ acpi=off
config for 2.6.0-test8-bk2
Boot messages for 2.6.0-test8-bk2
output from 'cat /proc/interrupts' for 2.6.0-test8-bk2
config for 2.4.23-pre8
boot messages for 2.4.23-pre8
output from 'cat /proc/interrupts' for 2.4.23-pre8
SIS I2C quirk foundin 2.6 but not in 2.4
patch to add SIS quirk to 2.4.23
patch to print IOAPIC after ACPI has programmed it 2.6 only
dmesg for 2.4.23-pre4 with IO-APIC patch
dmesg for 2.4.23-pre9 with IO-APIC patch
dmesg for 2.6.0-test9 with IO-APIC patch
dmesg for 2.4.23-pre9 with correct IO-APIC patch
2.4.23 patch to mpparse.c mp_override_legacy_irq()
dmesg of working 2.4.23-pre9
output of 'cat /proc/interrupts' for the working 2.4.23-pre9

Description Luming Yu 2003-09-28 20:42:19 UTC

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.
Comment 1 Luming Yu 2003-09-28 20:44:19 UTC
Created attachment 953 [details]
config file
Comment 2 Luming Yu 2003-09-28 20:45:24 UTC
Created attachment 954 [details]
Comment 3 David van Hoose 2003-10-02 04:14:50 UTC
Created attachment 970 [details]
Dmesg for 2.4.23-pre6
Comment 4 David van Hoose 2003-10-02 04:15:52 UTC
Bug still exists in 2.4.23-pre6.
Attached new dmesg.
Comment 5 Len Brown 2003-10-06 10:35:46 UTC
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? 
Also, please attach the output from acpidmp, available in /usr/sbin/, or in here 
Comment 6 David van Hoose 2003-10-09 07:20:22 UTC
As per requested I am attaching the dmesg, config, /proc/interrupts info,
dmidecode info, and acpidmp info for both pre4 and pre6.
Comment 7 David van Hoose 2003-10-09 07:21:52 UTC
Created attachment 1010 [details]
acpidmp output for the success case. (pre4)
Comment 8 David van Hoose 2003-10-09 07:22:23 UTC
Created attachment 1011 [details]
acpidmp output for the failure case. (pre6)
Comment 9 David van Hoose 2003-10-09 07:22:56 UTC
Created attachment 1012 [details]
config for 2.4.23-pre4
Comment 10 David van Hoose 2003-10-09 07:23:24 UTC
Created attachment 1013 [details]
config for 2.4.23-pre6
Comment 11 David van Hoose 2003-10-09 07:24:08 UTC
Created attachment 1014 [details]
dmesg for 2.4.23-pre4
Comment 12 David van Hoose 2003-10-09 07:24:37 UTC
Created attachment 1015 [details]
dmesg for 2.4.23-pre6
Comment 13 David van Hoose 2003-10-09 07:25:12 UTC
Created attachment 1016 [details]
dmidecode output for 2.4.23-pre4
Comment 14 David van Hoose 2003-10-09 07:25:36 UTC
Created attachment 1017 [details]
dmidecode output for 2.4.23-pre6
Comment 15 David van Hoose 2003-10-09 07:26:04 UTC
Created attachment 1018 [details]
output from 'cat /proc/interrupts' for 2.4.23-pre4
Comment 16 David van Hoose 2003-10-09 07:26:42 UTC
Created attachment 1019 [details]
output from cat '/proc/interrupts' for 2.4.23-pre6
Comment 17 Len Brown 2003-10-09 23:50:40 UTC
Thanks for all the info.  Looks like in pre5 one of your three usb-ohci's 
is now sharing an interrupt with acpi. 
  9:       4756    IO-APIC-edge  usb-ohci 
 20:       6927   IO-APIC-level  acpi 
 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 
says it has an SiS 648 chip-set. 
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. 
Comment 18 Len Brown 2003-10-10 00:23:20 UTC
Looking at the DSDT... 
            Name (APIC, Package (0x25) 
                Package (0x04) 
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. 
Comment 19 David van Hoose 2003-10-10 05:23:03 UTC
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.
Comment 20 David van Hoose 2003-10-10 05:24:05 UTC
Created attachment 1025 [details]
output from 'cat /proc/interrupts' for 2.4.23-pre6 w/ acpi=off
Comment 21 David van Hoose 2003-10-10 05:24:38 UTC
Created attachment 1026 [details]
lspci -vv output (2.4.23-pre4)
Comment 22 Shaohua 2003-10-10 05:36:10 UTC
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
Comment 23 David van Hoose 2003-10-10 10:11:08 UTC
Created attachment 1027 [details]
output from 'cat /proc/interrupts' for 2.4.23-pre4 w/ acpi=off
Comment 24 Sérgio M Basto 2003-10-10 17:43:48 UTC
>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
Comment 25 Len Brown 2003-10-10 21:33:06 UTC
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. 
Comment 26 Shaohua 2003-10-10 22:34:19 UTC
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. 
Comment 27 David van Hoose 2003-10-16 10:51:54 UTC
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.
Comment 28 Len Brown 2003-10-24 08:44:53 UTC
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? 
Comment 29 David van Hoose 2003-10-24 09:40:19 UTC
Created attachment 1172 [details]
config for 2.6.0-test8-bk2
Comment 30 David van Hoose 2003-10-24 09:40:47 UTC
Created attachment 1173 [details]
Boot messages for 2.6.0-test8-bk2
Comment 31 David van Hoose 2003-10-24 09:41:37 UTC
Created attachment 1174 [details]
output from 'cat /proc/interrupts' for 2.6.0-test8-bk2
Comment 32 David van Hoose 2003-10-24 09:44:35 UTC
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.
Comment 33 David van Hoose 2003-10-24 09:45:04 UTC
Created attachment 1175 [details]
config for 2.4.23-pre8
Comment 34 David van Hoose 2003-10-24 09:45:27 UTC
Created attachment 1176 [details]
boot messages for 2.4.23-pre8
Comment 35 David van Hoose 2003-10-24 09:46:03 UTC
Created attachment 1177 [details]
output from 'cat /proc/interrupts' for 2.4.23-pre8
Comment 36 Len Brown 2003-10-24 10:47:51 UTC
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? 
Comment 37 Len Brown 2003-10-24 11:53:49 UTC
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:

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
so you may want to disable that first), and observering the
/proc/interrupts row for acpi incrementing for each button press.

thanks, -Len
Comment 38 Len Brown 2003-10-24 13:04:31 UTC
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.
Comment 39 David van Hoose 2003-10-26 18:29:02 UTC
Can you make that patch for 2.6.0-test9?
Comment 40 David van Hoose 2003-10-28 19:21:01 UTC
2.6 does not misbehave when I remove the SiS quirk.
My USB works and ACPI works.
Comment 41 Len Brown 2003-11-05 11:07:41 UTC
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. 
Comment 42 David van Hoose 2003-11-05 13:03:53 UTC
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?
Comment 43 Len Brown 2003-11-07 01:22:41 UTC
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 
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. 
Comment 44 Len Brown 2003-11-07 02:12:38 UTC
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.

Comment 45 David van Hoose 2003-11-07 15:55:42 UTC
Created attachment 1389 [details]
dmesg for 2.4.23-pre4 with IO-APIC patch
Comment 46 David van Hoose 2003-11-07 15:56:13 UTC
Created attachment 1390 [details]
dmesg for 2.4.23-pre9 with IO-APIC patch
Comment 47 David van Hoose 2003-11-07 15:56:40 UTC
Created attachment 1391 [details]
dmesg for 2.6.0-test9 with IO-APIC patch
Comment 48 Len Brown 2003-11-07 22:55:10 UTC
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;-) 
Comment 49 David van Hoose 2003-11-08 00:09:39 UTC
Created attachment 1392 [details]
dmesg for 2.4.23-pre9 with correct IO-APIC patch
Comment 50 Len Brown 2003-11-08 01:18:31 UTC
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.

Comment 51 David van Hoose 2003-11-08 08:12:57 UTC
The patch to override legacy irq() worked.
All 6 USB ports work perfectly.
Comment 52 David van Hoose 2003-11-08 08:16:08 UTC
Created attachment 1402 [details]
dmesg of working 2.4.23-pre9
Comment 53 David van Hoose 2003-11-08 08:16:47 UTC
Created attachment 1403 [details]
output of 'cat /proc/interrupts' for the working 2.4.23-pre9
Comment 54 Len Brown 2003-11-12 17:02:47 UTC
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. 
Comment 55 Len Brown 2003-11-24 15:44:18 UTC
*** Bug 1582 has been marked as a duplicate of this bug. ***
Comment 56 Len Brown 2003-12-02 12:56:05 UTC
shipped in 2.4.23 -- closing.