-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I saw a thread recently about serial IRQ conflicts and I am having
similar problems. However, my machine has no ISA, which was given as the
cause.
The contents of /proc/irq/* is below, dmesg and my kernel config are
attached. I also have the nvidia binary module and the lirc modules.
For reference, the BIOS has the serial devices set on IRQ3 (this
setting, including disabled, appears to do nothing). All the PCI
interrupts are set to 'auto' but setting them to other IRQs manually
always ends up with something clashing.
Thanks,
Matt
mjj29@adonis:~ $ ls /proc/irq/*
/proc/irq/0:
/proc/irq/1:
i8042
/proc/irq/10:
EMU10K1 ohci_hcd:usb3
/proc/irq/11:
cx88[0] nvidia ohci_hcd:usb2 uhci_hcd:usb4 uhci_hcd:usb5
uhci_hcd:usb6
/proc/irq/12:
/proc/irq/13:
/proc/irq/14:
ide0
/proc/irq/15:
ide1
/proc/irq/2:
/proc/irq/3:
/proc/irq/4:
ehci_hcd:usb1 eth0 ohci1394
/proc/irq/5:
parport0
/proc/irq/6:
/proc/irq/7:
/proc/irq/8:
rtc
/proc/irq/9:
acpi
- --
Matthew Johnson
http://www.matthew.ath.cx/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFE3EWHpldmHVvob7kRAmmbAKDlF++y8rXYohImxZCQthctuby5AgCdFgMQ
FVMmSKCdtSqybIRdTAwQosE=
=eEF9
-----END PGP SIGNATURE-----
On Friday 11 August 2006 04:53, Matthew Johnson wrote:
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 4
PCI: setting IRQ 4 as level-triggered
ACPI: PCI Interrupt 0000:00:0f.0[A] -> Link [LNKC] -> GSI 4 (level, low) -> IRQ 4
3c59x: Donald Becker and others. http://www.scyld.com/network/vortex.html
0000:00:0f.0: 3Com PCI 3c905B Cyclone 100baseTx at e0802000.
setup_irq: irq handler mismatch
<c0135b3e> setup_irq+0x10d/0x11a <e2024b74> irq_handler+0x0/0x4e0 [lirc_serial]
<c0135bba> request_irq+0x6f/0x8b <e202410a> set_use_inc+0xab/0x1b9 [lirc_serial]
<e201f467> irctl_open+0x155/0x1e8 [lirc_dev] <c015678b> chrdev_open+0x15e/0x17a
<c015662d> chrdev_open+0x0/0x17a <c014e9d7> __dentry_open+0xe0/0x1cf
<c014eb2a> nameidata_to_filp+0x19/0x28 <c014eb64> do_filp_open+0x2b/0x31
<c014ec4a> do_sys_open+0x3c/0xae <c014ece9> sys_open+0x16/0x18
<c0102a5f> syscall_call+0x7/0xb
lirc_serial: IRQ 4 busy
----------
Matthew,
I think this is an ACPI IRQ routing bug where PCI and legacy clash.
While I don't expect it to make a difference, please reproduce without the NVIDIA binary module.
I expect you will be able to work around this issue by booting with
"acpi_irq_isa=4"
Then try with "acpi=off" or "acpi=noirq"
If it works, then by definition this is an ACPI bug.
Collect the dmesg -s64000 and /proc/interrupts for the the success and failure case,
the .config, the output from adpidump (available in pmtools here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
and attach them to a bugzilla here:
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
and mention if this worked before, or if this configuration has always failed.
thanks,
-Len
On Friday 11 August 2006 09:44, Len Brown wrote:
> On Friday 11 August 2006 04:53, Matthew Johnson wrote:
>
> ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 4
> PCI: setting IRQ 4 as level-triggered
> ACPI: PCI Interrupt 0000:00:0f.0[A] -> Link [LNKC] -> GSI 4 (level, low) -> IRQ 4
> 3c59x: Donald Becker and others. http://www.scyld.com/network/vortex.html
> 0000:00:0f.0: 3Com PCI 3c905B Cyclone 100baseTx at e0802000.
>
> setup_irq: irq handler mismatch
> <c0135b3e> setup_irq+0x10d/0x11a <e2024b74> irq_handler+0x0/0x4e0 [lirc_serial]
> <c0135bba> request_irq+0x6f/0x8b <e202410a> set_use_inc+0xab/0x1b9 [lirc_serial]
> <e201f467> irctl_open+0x155/0x1e8 [lirc_dev] <c015678b> chrdev_open+0x15e/0x17a
> <c015662d> chrdev_open+0x0/0x17a <c014e9d7> __dentry_open+0xe0/0x1cf
> <c014eb2a> nameidata_to_filp+0x19/0x28 <c014eb64> do_filp_open+0x2b/0x31
> <c014ec4a> do_sys_open+0x3c/0xae <c014ece9> sys_open+0x16/0x18
> <c0102a5f> syscall_call+0x7/0xb
> lirc_serial: IRQ 4 busy
Is this problem new with 2.6.17.7? On the face of it, it looks
like every kernel should have this problem if you have other
devices on IRQ 4.
Other devices (ehci_hcd:usb1 eth0 ohci1394) are already using
IRQ 4. lirc_serial doesn't request a shared IRQ unless you use
the "share_irq" module parameter. A request for exclusive use
of IRQ 4 will fail if it's already in use. So I suspect that if
you use the "share_irq" parameter, it will work.
I recently fixed a similar bug in the 8250_pnp driver:
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cb6358eb69d9854f65f2979c0ce9280eee041828
It would be nice if lirc_serial used PNP to discover its resources.
Then we should be able to handle this automatically, without any
module parameters.
Bjorn
On Fri, 11 Aug 2006, Bjorn Helgaas wrote:
> Is this problem new with 2.6.17.7? On the face of it, it looks
> like every kernel should have this problem if you have other
> devices on IRQ 4.
It's a recent problem, certainly.
> Other devices (ehci_hcd:usb1 eth0 ohci1394) are already using
> IRQ 4. lirc_serial doesn't request a shared IRQ unless you use
> the "share_irq" module parameter. A request for exclusive use
> of IRQ 4 will fail if it's already in use. So I suspect that if
> you use the "share_irq" parameter, it will work.
This stops the errors coming up, I just get no data afaict. I'll spend
some more time trying to diagnose the problem.
Thanks,
Matt
--
Matthew Johnson
http://www.matthew.ath.cx/