Red Hat Bugzilla – Bug 483405
CONFIG_NUMA_MIGRATE_IRQ_DESC renders HP dl785g5 unusable
Last modified: 2009-02-10 02:02:39 EST
(this is actually the exact e-mail I sent to lkml, maybe we should turn it off in Fedora till it gets fixed?) I have an hp dl785g5 which is unable to successfully run 2.6.29-0.66.rc3.fc11.x86_64 or 2.6.29-rc2-next-20090126. During bootup (early in userspace daemons starting) I get the below BUG, which quickly renders the machine dead. I assume it is because sparse_irq_lock never gets released when the BUG kills that task. But maybe it dies for some other reason, but the machine is dead, gotta hit the vitual power button. setting CONFIG_NUMA_MIGRATE_IRQ_DESC=n allowed me to successfully boot the linux-next kernel. 2.6.28 booted and worked fine (although it doesn't have this config option, so that isn't surprising.) attached you will find the linux-next config and dmesg output from the machine in question when booted using linux-next WITHOUT the MIGRATE_IRQ_DESC. The only difference between the working and broken config is if CONFIG_NUMA_MIGRATE_IRQ_DESC is set or not. Please if there is anything I can collect, test, or do, don't hesitate to let me know. -Eric ========================= [ BUG: held lock freed! ] ------------------------- swapper/0 is freeing memory ffff88042c53b6c0-ffff88042c53b8bf, with a lock still held there! (&irq_desc_lock_class){++..}, at: [<ffffffff8109786e>] handle_fasteoi_irq+0xa9/0xd4 2 locks held by swapper/0: #0: (&irq_desc_lock_class){++..}, at: [<ffffffff8109786e>] handle_fasteoi_irq+0xa9/0xd4 #1: (sparse_irq_lock){+...}, at: [<ffffffff810986ed>] move_irq_desc+0x6d/0x1bc stack backtrace: Pid: 0, comm: swapper Not tainted 2.6.29-0.66.rc3.fc11.x86_64 #1 Call Trace: <IRQ> [<ffffffff8106d859>] debug_check_no_locks_freed+0x10d/0x14f [<ffffffff810d6637>] kfree+0x84/0x103 [<ffffffff81098811>] ? move_irq_desc+0x191/0x1bc [<ffffffff81098811>] move_irq_desc+0x191/0x1bc [<ffffffff810247b2>] irq_complete_move+0x79/0xa6 [<ffffffff8102505d>] ack_apic_level+0x22/0x74 [<ffffffff8109786e>] ? handle_fasteoi_irq+0xa9/0xd4 [<ffffffff8109787f>] handle_fasteoi_irq+0xba/0xd4 [<ffffffff81013b0c>] do_IRQ+0xdc/0x154 [<ffffffff81011e13>] ret_from_intr+0x0/0x2e <EOI>
Suuposedly fixed by commit 10b888d6cec2688e65e9e128b14bf98ecd199da2
That commit is in .29-rc4