Bug 483405 - CONFIG_NUMA_MIGRATE_IRQ_DESC renders HP dl785g5 unusable
CONFIG_NUMA_MIGRATE_IRQ_DESC renders HP dl785g5 unusable
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-31 16:21 EST by Eric Paris
Modified: 2009-02-10 02:02 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-10 02:02:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eric Paris 2009-01-31 16:21:27 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>
Comment 1 Chuck Ebbert 2009-02-05 19:35:04 EST
Suuposedly fixed by commit 10b888d6cec2688e65e9e128b14bf98ecd199da2
Comment 2 Chuck Ebbert 2009-02-10 02:02:39 EST
That commit is in .29-rc4

Note You need to log in before you can comment on or make changes to this bug.