Red Hat Bugzilla – Bug 233586
IRQ handler type mismatch for IRQ 0 (parport)
Last modified: 2008-10-05 06:13:39 EDT
Description of problem: Found this in the syslog today with the 2.6.20-1.3003 kernel Mar 23 08:48:45 localhost kernel: parport: PnPBIOS parport detected. Mar 23 08:48:45 localhost kernel: parport0: PC-style at 0x378 (0x778), irq 0 [PCSPP,TRISTATE] Mar 23 08:48:45 localhost kernel: IRQ handler type mismatch for IRQ 0 Mar 23 08:48:45 localhost kernel: current handler: timer Mar 23 08:48:45 localhost kernel: [<c04061ed>] show_trace_log_lvl+0x1a/0x2f Mar 23 08:48:45 localhost kernel: [<c04067b1>] show_trace+0x12/0x14 Mar 23 08:48:45 localhost kernel: [<c0406835>] dump_stack+0x16/0x18 Mar 23 08:48:45 localhost kernel: [<c04592bf>] setup_irq+0x196/0x1ae Mar 23 08:48:45 localhost kernel: [<c0459484>] request_irq+0xd9/0xf9 Mar 23 08:48:45 localhost kernel: [<f8b34f3a>] parport_pc_probe_port+0x711/0x882 [parport_pc] Mar 23 08:48:45 localhost kernel: [<f8b3515f>] parport_pc_pnp_probe+0xb4/0xcf [parport_pc] Mar 23 08:48:45 localhost kernel: [<c0537419>] pnp_device_probe+0x66/0x85 Mar 23 08:48:45 localhost kernel: [<c05621d5>] really_probe+0xc7/0x150 Mar 23 08:48:45 localhost kernel: [<c05622f3>] driver_probe_device+0x95/0xa1 Mar 23 08:48:45 localhost kernel: [<c056241b>] __driver_attach+0x76/0xaf Mar 23 08:48:45 localhost kernel: [<c05617a9>] bus_for_each_dev+0x3a/0x5f Mar 23 08:48:45 localhost kernel: [<c056203f>] driver_attach+0x19/0x1b Mar 23 08:48:45 localhost kernel: [<c0561a90>] bus_add_driver+0x6a/0x170 Mar 23 08:48:45 localhost kernel: [<c0562641>] driver_register+0x79/0x7e Mar 23 08:48:45 localhost kernel: [<c0537204>] pnp_register_driver+0x17/0x19 Mar 23 08:48:45 localhost kernel: [<f89a53c9>] parport_pc_init+0x2ba/0x36e [parport_pc] Mar 23 08:48:45 localhost kernel: [<c0449755>] sys_init_module+0x159b/0x16ea Mar 23 08:48:45 localhost kernel: [<c040507c>] syscall_call+0x7/0xb Mar 23 08:48:45 localhost kernel: ======================= Mar 23 08:48:45 localhost kernel: parport0: irq 0 in use, resorting to polled operation Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Still the same with the latest kernel in rawhide.
Now it has morphed into this: Mar 4 09:46:59 localhost kernel: IRQ handler type mismatch for IRQ 7 Mar 4 09:46:59 localhost kernel: current handler: parport0 Mar 4 09:46:59 localhost kernel: Pid: 3245, comm: hald-probe-seri Not tainted 2.6.25-0.82.rc3.git2.fc9 #1 Mar 4 09:46:59 localhost kernel: [<c0461484>] setup_irq+0x19a/0x1b2 Mar 4 09:46:59 localhost kernel: [<c0461590>] request_irq+0xf4/0x112 Mar 4 09:46:59 localhost kernel: [<c056a4cc>] ? serial8250_interrupt+0x0/0x104 Mar 4 09:46:59 localhost kernel: [<c056a174>] serial8250_startup+0x3e3/0x53c Mar 4 09:46:59 localhost kernel: [<c0566c8b>] uart_startup+0x77/0x135 Mar 4 09:46:59 localhost kernel: [<c0567992>] uart_open+0x148/0x382 Mar 4 09:46:59 localhost kernel: [<c063a74d>] ? _spin_unlock+0x1d/0x20 Mar 4 09:46:59 localhost kernel: [<c0549d39>] ? check_tty_count+0x3b/0x8a Mar 4 09:46:59 localhost kernel: [<c054c9f4>] tty_open+0x188/0x287 Mar 4 09:46:59 localhost kernel: [<c048bfd8>] chrdev_open+0x119/0x135 Mar 4 09:46:59 localhost kernel: [<c0488424>] __dentry_open+0xcf/0x185 Mar 4 09:46:59 localhost kernel: [<c048854b>] nameidata_to_filp+0x1f/0x33 Mar 4 09:46:59 localhost kernel: [<c048bebf>] ? chrdev_open+0x0/0x135 Mar 4 09:46:59 localhost kernel: [<c048858d>] do_filp_open+0x2e/0x35 Mar 4 09:46:59 localhost kernel: [<c048833f>] ? get_unused_fd_flags+0xc9/0xd3 Mar 4 09:46:59 localhost kernel: [<c063a74d>] ? _spin_unlock+0x1d/0x20 Mar 4 09:46:59 localhost kernel: [<c048833f>] ? get_unused_fd_flags+0xc9/0xd3 Mar 4 09:46:59 localhost kernel: [<c04885d4>] do_sys_open+0x40/0xb5 Mar 4 09:46:59 localhost kernel: [<c0488675>] sys_open+0x16/0x18 Mar 4 09:46:59 localhost kernel: [<c0405d16>] syscall_call+0x7/0xb Mar 4 09:46:59 localhost kernel: ======================= Or maybe this is a different issue. The former trace is gone from my logs now.
Doesn't look like there is much that can be done about this, other than trying to reconfigure the hardware so it doesn't put serial and parallel devices on the same interrupt. If you don't have any devices attached to either of those ports you can just ignore the message.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Closing this since the message is gone in current rawhide.