Bug 4197 - PCI interrupts being set as edge, not level
Summary: PCI interrupts being set as edge, not level
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Interrupts (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Shaohua
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-10 18:23 UTC by Matthew Garrett
Modified: 2005-08-24 23:52 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.10
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
dmesg from normal boot. Interrupts end up as edge triggered. (14.43 KB, text/plain)
2005-02-10 18:24 UTC, Matthew Garrett
Details
dmesg with pci=noacpi - machine works correctly (12.63 KB, text/plain)
2005-02-10 18:26 UTC, Matthew Garrett
Details
acpidmp output (73.13 KB, text/plain)
2005-02-23 04:49 UTC, Matthew Garrett
Details
2.6.11 patch to set interrupt polarity in no GSI error case (831 bytes, patch)
2005-03-03 22:22 UTC, Len Brown
Details | Diff
lpsci -vv output (6.71 KB, text/plain)
2005-04-02 07:26 UTC, Diego Calleja
Details

Description Matthew Garrett 2005-02-10 18:23:14 UTC
Distribution: Ubuntu 4.10
Hardware Environment: Microstart MS6390

Steps to reproduce:

Booting kernel 2.6 gives the following in /proc/interrupts:

           CPU0       
  0:      54678    IO-APIC-edge  timer
  1:         99    IO-APIC-edge  i8042
  5:          0    IO-APIC-edge  eth0, YMFPCI
  8:          1    IO-APIC-edge  rtc
  9:          0    IO-APIC-edge  ohci_hcd, uhci_hcd, uhci_hcd
 11:          0   IO-APIC-level  acpi, ohci1394, ohci_hcd, ehci_hcd
 12:         78    IO-APIC-edge  i8042
 14:       2959    IO-APIC-edge  ide0
 15:         25    IO-APIC-edge  ide1
NMI:          0 
LOC:      54628 
ERR:          0
MIS:          0

Note the lack of interrupts on interrupts 5 and 9. The sound card, network card
and USB fail to work. These are PCI interrupts, but are set to IO-APIC-edge.
Booting with pci=noacpi results in things working. I'll attach the dmesgs for
the two cases (from 2.6.8.1, but the same thing happens with 2.6.10)
Comment 1 Matthew Garrett 2005-02-10 18:24:28 UTC
Created attachment 4536 [details]
dmesg from normal boot. Interrupts end up as edge triggered.
Comment 2 Matthew Garrett 2005-02-10 18:26:05 UTC
Created attachment 4537 [details]
dmesg with pci=noacpi - machine works correctly
Comment 3 Shaohua 2005-02-20 17:18:20 UTC
Does the system work with noapic? It would be great to look at the acpidmp of 
the system, could you please attach it?

Len,
You mentioned before that the no IRQ entry case also should 
call 'acpi_register_gsi', which should address the IRQ edge/level issue. 
What's the status?
Comment 4 Matthew Garrett 2005-02-23 04:49:38 UTC
Created attachment 4594 [details]
acpidmp output
Comment 5 Shaohua 2005-02-23 18:26:12 UTC
>ACPI: PCI interrupt 0000:00:05.0[A]: no GSI - using IRQ 11
>ACPI: PCI interrupt 0000:00:06.0[A]: no GSI - using IRQ 5
The dmesg is strange. Is there the similar message with latest kernel? I can't 
imagine ACPI still has such kind of bug (eg. BIOS defined PRT entry for 
devices but ACPI can't find them)
Comment 6 Len Brown 2005-03-01 20:29:12 UTC
please attach the output from lspci -vv 
 
yes, we've got a patch that should handle this error case better, 
but we should find out exactly why we went down the "no GSI" path... 
 
Matthew, per Shaohua's request, can you also boot with "noapic" and 
attach the resulting dmesg and /proc/interrupts? 
Comment 7 Len Brown 2005-03-01 20:36:39 UTC
I suspect that the "noapic" PIC-mode test will succeed. 
Looking at the DSDT, the PIC-mode _PRT is well formed: 
 
           Name (PICM, Package (0x20) 
            { 
                Package (0x04) 
                { 
                    0x0005FFFF, 
                    0x00, 
                    \_SB.PCI0.LNKA, 
                    0x00 
                }, 
	... 
 
But the APIC mode _PRT may have a scoping issue on the entries 
that use links, such as this one using ALKA: 
 
            Name (APIC, Package (0x20) 
            { 
... 
                Package (0x04) 
                { 
                    0x0010FFFF, 
                    0x02, 
                    ALKB, 
                    0x00 
                }, 
 
 
 
Comment 8 Matthew Garrett 2005-03-02 02:40:11 UTC
Yes, booting with noapic appears to work. I'll try to get the dmesg and lspci
output for you.
Comment 9 Len Brown 2005-03-03 22:22:03 UTC
Created attachment 4658 [details]
2.6.11 patch to set interrupt polarity in no GSI error case

Please test this patch and report if it treats the symptom in the IOAPIC case. 
Include the /proc/interrupts and attach the dmesg -s64000 output.

Note that this is an attempt to fix the error path.  Need the lspci -vv output
to confirm why we're headed down the error path in the first place.
Comment 10 Diego Calleja 2005-03-12 09:48:17 UTC
Hi, I've been having exatly this same bug for years? I was reading the bug
reports before submitting it and I saw this one, I tried that patch and it works
- yay!. This is what I had before this patch:

USB Universal Host Controller Interface driver v2.2
 pci_irq-0370 [02] acpi_pci_irq_derive   : Unable to derive IRQ for device 0000:
00:07.2
ACPI: PCI Interrupt 0000:00:07.2[D]: no GSI - using IRQ 11
uhci_hcd 0000:00:07.2: UHCI Host Controller
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:07.2: irq 11, io base 0x0000d400
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected

and then when pluggin in the webcam:
usb 1-1: new full speed USB device using uhci_hcd and address 2
uhci_hcd 0000:00:07.2: Unlink after no-IRQ?  Controller is probably using the wr
ong IRQ.
usb 1-1: device not accepting address 2, error -110
usb 1-1: new full speed USB device using uhci_hcd and address 3
usb 1-1: device not accepting address 3, error -110
usb 1-1: new full speed USB device using uhci_hcd and address 4
usb 1-1: device not accepting address 4, error -110
usb 1-1: new full speed USB device using uhci_hcd and address 5
usb 1-1: device not accepting address 5, error -110

and irq reported to the usb irq


With this patch I see:

USB Universal Host Controller Interface driver v2.2
 pci_irq-0370 [02] acpi_pci_irq_derive   : Unable to derive IRQ for device 0000:
00:07.2
ACPI: PCI Interrupt 0000:00:07.2[D]: no GSI - using IRQ 11
ACPI: PCI Interrupt 0000:00:07.2[D] -> GSI 11 (level, low) -> IRQ 11
uhci_hcd 0000:00:07.2: UHCI Host Controller
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:07.2: irq 11, io base 0x0000d400
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
[...]
w9968cf: V4L driver for W996[87]CF JPEG USB Dual Mode Camera Chip 1:1.33-basic
ovcamchip: v2.27 for Linux 2.6 : OV camera chip I2C driver
usb 1-1: Creative Labs Video Blaster WebCam Go Plus detected
usb 1-1: V4L device registered as /dev/video0


ie: it works. It has also solved a problem with sound - I could not have sound
(if it's useful for you, I can post the neccesary info dmesg etc of how it was
working before and after the patch)


The one problem I still have with acpi is:
# cat /proc/acpi/event       
cat: /proc/acpi/event: Device or resource busy

but I guess that's for another bug report. Thanks for all your hard work!
Comment 11 Diego Calleja 2005-04-02 07:26:37 UTC
Created attachment 4845 [details]
lpsci -vv output

This is my lspci output. Original poster doen't seems to answer. If you need
more info to debug this problem - ask for it, I'm avaliable
Comment 12 Shaohua 2005-08-24 23:52:24 UTC
A similar patch has been merged in base kernel. Closing!

Note You need to log in before you can comment on or make changes to this bug.