Hi Leann, I'm not sure you saw my comment #5; this bug is a race condition that exists in the ite-cir driver (from driver's introduction last year to current mainline). The driver installs an ISR before properly initializing. If an IRQ occurs after the driver has installed the ISR (via request_irq) but before it has initialized its internal call tables, the ite_cir_isr() function will panic (by accessing vma 0). Incidentally, that's not the only problem with initialization order in this driver: it hasn't initialized hardware either before installing the ISR.
Although initially I believed this bug's easy reproducibility was due to CONFIG_IRQ_REMAP being on, I realize now that's not the case (or, at least, not exclusively). After more extensive static analysis, the most likely possibility is "genirq: Handle pending irqs in irq_startup()" which was introduced in stable v.3.2.9. This retriggers pending edge-type interrupts when installing an ISR: request_irq => request_threaded_irq => __setup_irq => irq_startup => check_irq_resend => irq_retrigger The only way to be certain would be with git bisect. Of course, understanding the easy reproducibility is mostly academic as the actual bug is a race condition that has always existed (at least since the driver's introduction). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/972723 Title: linux 3.2.0-18 - 22 kernel panic on boot, Alienware m17x, Dell xps 1340 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972723/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
