Bug 2733 - Reserve IRQs for motherboard devices - unable to grab IRQ 7 - _CRS outside _PRS
Summary: Reserve IRQs for motherboard devices - unable to grab IRQ 7 - _CRS outside _PRS
Status: REJECTED DUPLICATE of bug 2778
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Interrupts (show other bugs)
Hardware: i386 Linux
: P2 high
Assignee: Len Brown
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-05-19 16:04 UTC by Antoine REVERSAT
Modified: 2004-08-13 21:38 UTC (History)
1 user (show)

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


Attachments
Dmesg output (acpi on in normal mode) (11.90 KB, text/plain)
2004-05-28 14:48 UTC, Antoine REVERSAT
Details
dmesg output (acpi in strict mode) (11.94 KB, text/plain)
2004-05-28 14:48 UTC, Antoine REVERSAT
Details
lspci -vv output (7.79 KB, application/octet-stream)
2004-05-28 14:49 UTC, Antoine REVERSAT
Details
acpidmp output (52.24 KB, text/plain)
2004-05-28 14:49 UTC, Antoine REVERSAT
Details

Description Antoine REVERSAT 2004-05-19 16:04:15 UTC
Distribution: Debian
Hardware Environment: Mobile Pentium 4 2GHz, 512 mo ram, ati 9000 Mobility,
intel ICH4 chipset and ICH4 soundcard (82801DB)
Software Environment:
Problem Description: My soundcard won't work anymore (it used to work fine up to
2.6.5 kernel version). Since i have installed the 2.6.6 kernel it fails to probe
the soundcard. Here is what the kernel says about it : 
May 19 19:41:17 nibbler kernel: Advanced Linux Sound Architecture Driver Version
1.0.4rc2 (Tue Mar
 30 08:19:30 2004 UTC).
May 19 19:41:17 nibbler kernel: unable to grab IRQ 7
May 19 19:41:17 nibbler kernel: Intel ICH: probe of 0000:00:1f.5 failed with
error -16
May 19 19:41:17 nibbler kernel: unable to grab IRQ 7
May 19 19:41:17 nibbler kernel: Intel ICH Modem: probe of 0000:00:1f.6 failed
with error -16
May 19 19:41:17 nibbler kernel: ALSA device list:
May 19 19:41:17 nibbler kernel:   No soundcards found.


Steps to reproduce: just boot with the whole thing compiled in the kernel
(didn't try as a module).

Note : my kernel configuration is the same as it was with the 2.6.5 kernel. When
 I put back the 2.6.5 kernel it works back again.
Comment 1 Antoine REVERSAT 2004-05-27 20:32: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...
Comment 2 Antoine REVERSAT 2004-05-27 20:34:50 UTC
This problem is not SOUND related though...
Comment 3 Len Brown 2004-05-27 22:17:39 UTC
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. 
 
Comment 4 Antoine REVERSAT 2004-05-28 14:47:36 UTC
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...
Comment 5 Antoine REVERSAT 2004-05-28 14:48:26 UTC
Created attachment 3009 [details]
Dmesg output (acpi on in normal mode)
Comment 6 Antoine REVERSAT 2004-05-28 14:48:59 UTC
Created attachment 3010 [details]
dmesg output (acpi in strict mode)
Comment 7 Antoine REVERSAT 2004-05-28 14:49:22 UTC
Created attachment 3011 [details]
lspci -vv output
Comment 8 Antoine REVERSAT 2004-05-28 14:49:42 UTC
Created attachment 3012 [details]
acpidmp output
Comment 9 Antoine REVERSAT 2004-05-28 14:52:57 UTC
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 ;)
Comment 10 Len Brown 2004-05-28 19:46:30 UTC
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) 
 
Comment 11 Antoine REVERSAT 2004-05-28 20:08:40 UTC
Well this doesn't work. The soundcard still gets IRQ 7 assigned...
Comment 12 Len Brown 2004-05-28 21:03:14 UTC
that's strange, can you attach the dmesg and /proc/interrupts resulting from 
"acpi_irq_isa=7" 
Comment 13 Len Brown 2004-05-28 21:05:32 UTC
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 
 
Comment 14 Antoine REVERSAT 2004-05-29 08:56:35 UTC
I used 2.6.7-rc1 and acpi_irq_isa=7 does make the kernel assign irq 5 to the
soundcard. So this works...
Comment 15 Len Brown 2004-06-03 23:14:33 UTC
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. 
 
Comment 16 Shaohua 2004-08-12 18:49:39 UTC
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.
Comment 17 Len Brown 2004-08-13 21:38:42 UTC

*** This bug has been marked as a duplicate of 2778 ***

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