Running 2.6.18-rc5.mm1 on an Asus M2V mainboard with dual-core Athlon
cpu, the onboard audio device gets assigned and IRQ of 8410. Under
2.6.18-rc4-mm3, the same device gets assigned IRQ 17. Is this a way to
get around this?
/proc/interrupts:
CPU0 CPU1
0: 525177 0 IO-APIC-edge timer
1: 3016 0 IO-APIC-edge i8042
6: 5 0 IO-APIC-edge floppy
7: 0 0 IO-APIC-edge parport0
8: 0 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-fasteoi acpi
12: 4 0 IO-APIC-edge i8042
14: 18433 0 IO-APIC-edge ide0
20: 16017 0 IO-APIC-fasteoi uhci_hcd:usb1
21: 66080 0 IO-APIC-fasteoi uhci_hcd:usb3,
ehci_hcd:usb5, libata
22: 0 0 IO-APIC-fasteoi uhci_hcd:usb2
23: 0 0 IO-APIC-fasteoi uhci_hcd:usb4
36: 4600 0 IO-APIC-fasteoi eth0
8410: 193 0 PCI-MSI-<NULL> HDA Intel
NMI: 180 91
LOC: 525078 525029
ERR: 0
And here's the lspci output for the audio device:
08:01.0 Audio device: VIA Technologies, Inc. VIA High Definition Audio
Controller (rev 10)
Subsystem: ASUSTeK Computer Inc. Unknown device 81e7
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 8410
Region 0: Memory at fbffc000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] Message Signalled Interrupts: 64bit+
Queue=0/0 Enable+
Address: 00000000fee00000 Data: 406a
Capabilities: [70] Express Unknown type IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0,
ExtTag-
Device: Latency L0s <64ns, L1 <1us
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed unknown, Width x0, ASPM unknown,
Port 0
Link: Latency L0s <64ns, L1 <1us
Link: ASPM Disabled CommClk- ExtSynch-
Link: Speed unknown, Width x0
Capabilities: [100] Virtual Channel
00: 06 11 88 32 06 04 10 00 10 00 03 04 10 00 00 00
10: 04 c0 ff fb 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 e7 81
30: 00 00 00 00 50 00 00 00 00 00 00 00 01 01 00 00
40: 00 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 01 60 42 c8 00 00 00 00 00 00 00 00 00 00 00 00
60: 05 70 81 00 00 00 e0 fe 00 00 00 00 6a 40 00 00
70: 10 00 91 00 00 00 00 00 00 00 30 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jay Cliburn wrote:
> Running 2.6.18-rc5.mm1 on an Asus M2V mainboard with dual-core Athlon
> cpu, the onboard audio device gets assigned and IRQ of 8410. Under
> 2.6.18-rc4-mm3, the same device gets assigned IRQ 17. Is this a way to
> get around this?
What I meant to ask is: Is there a way to get around this?
Thanks,
Jay
Jay Cliburn wrote:
> Jay Cliburn wrote:
>> Running 2.6.18-rc5.mm1 on an Asus M2V mainboard with dual-core Athlon
>> cpu, the onboard audio device gets assigned and IRQ of 8410. Under
>> 2.6.18-rc4-mm3, the same device gets assigned IRQ 17. Is this a way
>> to get around this?
>
> What I meant to ask is: Is there a way to get around this?
>
> Thanks,
> Jay
What do you think needs to be "gotten around"? It is using MSI
interrupts, I think that the IRQ numbers will be different.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Robert Hancock wrote:
> Jay Cliburn wrote:
>> Jay Cliburn wrote:
>>> Running 2.6.18-rc5.mm1 on an Asus M2V mainboard with dual-core Athlon
>>> cpu, the onboard audio device gets assigned and IRQ of 8410. Under
>>> 2.6.18-rc4-mm3, the same device gets assigned IRQ 17. Is this a way
>>> to get around this?
>>
>> What I meant to ask is: Is there a way to get around this?
>>
>> Thanks,
>> Jay
>
> What do you think needs to be "gotten around"? It is using MSI
> interrupts, I think that the IRQ numbers will be different.
>
I'll have to go research what MSI interrupts are. Thanks for the pointer.
Unfortunately, Fedora Core's irqbalance segfaults when it encounters the
IRQ of 8410. I assumed this behavior indicated that an IRQ number
shouldn't be that large.
Thanks again.
Jay Cliburn wrote:
> Robert Hancock wrote:
>> Jay Cliburn wrote:
>>> Jay Cliburn wrote:
>>>> Running 2.6.18-rc5.mm1 on an Asus M2V mainboard with dual-core
>>>> Athlon cpu, the onboard audio device gets assigned and IRQ of 8410.
>>>> Under 2.6.18-rc4-mm3, the same device gets assigned IRQ 17. Is this
>>>> a way to get around this?
>>>
>>> What I meant to ask is: Is there a way to get around this?
>>>
>>> Thanks,
>>> Jay
>>
>> What do you think needs to be "gotten around"? It is using MSI
>> interrupts, I think that the IRQ numbers will be different.
>>
> I'll have to go research what MSI interrupts are. Thanks for the pointer.
Nothing I've read about MSI so far indicates that an IRQ number greater
than 255 is permissible, yet this device gets assigned an IRQ number of
8,410 when MSI is enabled. Booting 2.6.18-rc5-mm1 with pci=nomsi causes
the device to be assigned IRQ 17 instead of 8410.
The problem with the large IRQ number is made manifest in Fedora's
irqbalance program, which is run as an init script. An array is built
in that program that's indexed by IRQ number, with a max of 255. When
the program attempts to index element 8410, it segfaults.
Are IRQ numbers greater than 255 allowed with MSI?
On Mon, 04 Sep 2006 10:26:21 -0500
Jay Cliburn <[email protected]> wrote:
> Jay Cliburn wrote:
> > Running 2.6.18-rc5.mm1 on an Asus M2V mainboard with dual-core Athlon
> > cpu, the onboard audio device gets assigned and IRQ of 8410. Under
> > 2.6.18-rc4-mm3, the same device gets assigned IRQ 17. Is this a way to
> > get around this?
>
> What I meant to ask is: Is there a way to get around this?
>
MSI is rather busted and has been redone. Disabling CONFIG_MSI
may well help.
Jay Cliburn wrote:
> Nothing I've read about MSI so far indicates that an IRQ number greater
> than 255 is permissible, yet this device gets assigned an IRQ number of
> 8,410 when MSI is enabled. Booting 2.6.18-rc5-mm1 with pci=nomsi causes
> the device to be assigned IRQ 17 instead of 8410.
>
> The problem with the large IRQ number is made manifest in Fedora's
> irqbalance program, which is run as an init script. An array is built
> in that program that's indexed by IRQ number, with a max of 255. When
> the program attempts to index element 8410, it segfaults.
>
> Are IRQ numbers greater than 255 allowed with MSI?
I assume you're on x86-64 with CONFIG_NR_CPUS set to 255. In that case
the max IRQ number is 256 + (32 * NR_CPUS) or 8416. The MSI interrupts
will get assigned from highest IRQ to lowest, so you should expect to
see such high numbers..
It appears that irqbalance's assumption that IRQ cannot exceed 255 is
not valid on x86-64 (on i386 it is since NR_IRQS is 224).
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/