Bug 4197
Summary: | PCI interrupts being set as edge, not level | ||
---|---|---|---|
Product: | ACPI | Reporter: | Matthew Garrett (mjg59-kernel) |
Component: | Config-Interrupts | Assignee: | Shaohua (shaohua.li) |
Status: | CLOSED PATCH_ALREADY_AVAILABLE | ||
Severity: | normal | CC: | acpi-bugzilla |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.10 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
dmesg from normal boot. Interrupts end up as edge triggered.
dmesg with pci=noacpi - machine works correctly acpidmp output 2.6.11 patch to set interrupt polarity in no GSI error case lpsci -vv output |
Description
Matthew Garrett
2005-02-10 18:23:14 UTC
Created attachment 4536 [details]
dmesg from normal boot. Interrupts end up as edge triggered.
Created attachment 4537 [details]
dmesg with pci=noacpi - machine works correctly
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? Created attachment 4594 [details]
acpidmp output
>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)
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? 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 }, Yes, booting with noapic appears to work. I'll try to get the dmesg and lspci output for you. 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.
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! 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
A similar patch has been merged in base kernel. Closing! |