Bug 2733
| Summary: | Reserve IRQs for motherboard devices - unable to grab IRQ 7 - _CRS outside _PRS | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Antoine REVERSAT (areversat) |
| Component: | Config-Interrupts | Assignee: | Len Brown (lenb) |
| Status: | REJECTED DUPLICATE | ||
| Severity: | high | CC: | acpi-bugzilla |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.6 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
Dmesg output (acpi on in normal mode)
dmesg output (acpi in strict mode) lspci -vv output acpidmp output |
||
|
Description
Antoine REVERSAT
2004-05-19 16:04:15 UTC
Ok got news... I traced this bug all day long and came out with some stuff.... First of all the cause of this is that the driver tries to grab the wrong IRQ (7 instead of 11) and the cause of the driver requesting the wrong irq is that the kernel thinks the card should use irq 7 because ACPI told him LNKB (PCI interrupt channel B) should use irq 7 which is untrue since this IRQ is used by the parralel port and doesn't seem to be shared. So i investigated the ACPI code and got to the conclusion that something in the function acpi_rs_irq_resource is wrong... Even though i can't tell what (i'm very new to all this). But what i can tell is that it reports valid irqs for LNKB being 7 and 9 and doesn't mention 11. (Even though the kernel mentiones irq 11 when it boots : May 28 00:12:24 nibbler kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11) May 28 00:12:24 nibbler kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *11 May 28 00:12:24 nibbler kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11) May 28 00:12:24 nibbler kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11) May 28 00:12:24 nibbler kernel: ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. May 28 00:12:24 nibbler kernel: ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) Note that irq 11 is outside the parenthesis though... I still can't figure out if the bug comes from my hardware or the kernel and i feel sorry to post a bug report not knowing if it is a kernel bug but i can't figure it out on myself so please let me know if you think my hardware is to blame here... This problem is not SOUND related though... Please confirm that you're running the latest BIOS for this system. Please attach 1. full dmesg 2. output from lspci -vv 3. output from acpidmp, available in /usr/sbin/, or in pmtools: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ I expect that they'll confirm what you've already noted, that this device is using LNKB for its sound interrupt. ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *11 The *11 means that _CRS (current resource settings) returned 11, but that 11 is not within _PRS (possible resource settings) It is a BIOS bug that _CRS returns a value outside _PRS, and that _PRS doesn't include 11, which apparently would work. Yes, this broke on purpose -- we used to leave interrupts on IRQs outside of _PRS, but we found that broke a number of systems. It is a Linux bug that the kernel tries to put the device onto IRQ 7, fails, and doesn't try IRQ 5 which may still be available. Please try disabling the parallel port in the BIOS and see if sound actually does work on IRQ7 -- you're really using this, though, right? Also try booting with "acpi_irq_isa=7", which will discourage the kernel from trying to use 7 and it may go for 5. Ok here are the files you requested... I did look at lspci -vv before saying that the card used lnkB... Anyways i also tried strict acpi (acpi=strict as a boot param) and it reports irq from CRS ouside of PRS... So it seems you made the right guess... Now we have to investigate why the kernel doesn't use irq 5 (which is available). Also my soundcard works fine using pci=noacpi and it detects irq 11 for my soundcard... Created attachment 3009 [details]
Dmesg output (acpi on in normal mode)
Created attachment 3010 [details]
dmesg output (acpi in strict mode)
Created attachment 3011 [details]
lspci -vv output
Created attachment 3012 [details]
acpidmp output
Sorry i forgot to mention earlier : if i desactivate my parallel port as you suggested it does work using irq 7 (the parport's irq). I do not need my parallel port right now but of course i would prefer not to have to desactivate it to use my sound card ;) Linux uses simple heuristics for assigning PCI Interrupt Links. It doesn't know at this point if IRQ5 or IRQ 7 are actually used. I think the real fix for this issue is that we need to replace these heuristics with a scan of the legacy ISA DSDT IRQs. linux, of course, also isn't smart enough to try IRQ5 when it discoveres that IRQ7 is not sharable -- because the PCI link assignment came earlier than that and is not changable. Is anything on IRQ5, and if you boot with "acpi_irq_isa=7" does it move the device to 5 and does it work there? (your parallel port should be able to be enabled and active on IRQ7 at the same time) Well this doesn't work. The soundcard still gets IRQ 7 assigned... that's strange, can you attach the dmesg and /proc/interrupts resulting from "acpi_irq_isa=7" oh, I see you're using stock 2.6.6. Please apply the patch for bug 2665 to 2.6.6, or use 2.6.7-rc1 I used 2.6.7-rc1 and acpi_irq_isa=7 does make the kernel assign irq 5 to the soundcard. So this works... Thanks for verifying the workaround "acpi_irq_isa=7" is effective.
There are 3 potential fixes, easiest to hardest:
1. BIOS update that lists IRQ11 as a legal IRQ for this link.
2. Linux update to scan legacy IRQ usage in DSDT
Replace heuristic table in pci_link.c with the result
This would tell the kernel to choose the free IRQ5
instead of the busy IRQ7 in this case.
3. Linux update to handle the case where a link
is programmed and it causes an IRQ sharing issue.
ie. here we recognized that we could not put
ISA-level and PCI-level devices on the same IRQ.
But all we could do was return an error, there
is no mechanism to re-program the PCI link.
Of course if #2 is successful, this may never
be necessary.
Len, there is a same issue in bug 3132. I attached proposal patch in the track. It basically doesn't do IRQ balance when _CRS outside _PRS if all IRQs listed in _PRS are legacy IRQs. Sure it's not sufficient. I'm also investigating the solution. And my idea is similar with your option 2. I think #2 should be ok. Legacy devices should be listed in DSDT. And if the device uses IRQ, its _CRS will have one entry like 'IRQNoFlags (){6}', this means IRQ 6 should not be used by PCI devices. One problem is #2 require ACPI scan all available PNP devices listed in DSDT, and we must have the huge PNP ID list. *** This bug has been marked as a duplicate of 2778 *** |