Bugzilla – Bug 116501
Badness in pci_get_subsys at drivers/pci/search.c:234
Last modified: 2005-11-08 23:02:30 UTC
When I issue SysRq-B, I get the following backtrace: Badness in pci_get_subsys at drivers/pci/search.c:234 [<c01fa241>] pci_get_subsys+0xe1/0xf0 [<c01fa25b>] pci_get_device+0xb/0x10 [<c0115d62>] mach_reboot_fixups+0x12/0x30 [<c01122da>] machine_emergency_restart+0x3a/0xb0 [<c0249632>] __handle_sysrq+0x72/0x100 [<c02496d7>] handle_sysrq+0x17/0x20 [<c024478c>] kbd_event+0x9c/0xc0 [<c026ef93>] input_event+0xb3/0x400 [<c02728b2>] atkbd_report_key+0x22/0xa0 [<c0272ac9>] atkbd_interrupt+0x199/0x580 [<c024c739>] serio_interrupt+0x19/0x3d [<c024d3a1>] i8042_interrupt+0xf1/0x200 [<c013bc23>] handle_IRQ_event+0x33/0x60 [<c013bcd5>] __do_IRQ+0x85/0xd0 [<c01055e8>] do_IRQ+0x38/0x60 [<c0103dea>] common_interrupt+0x1a/0x20 [<e0831c17>] acpi_processor_idle+0x10e/0x26f [processor] [<c01010ae>] cpu_idle+0xe/0x50 [<c03ae730>] start_kernel+0x160/0x1b0 No reboot fixup found for your hardware After that, the machine reboots.
The problem comes from the fact that pci_get_subsys() doesn't expect to be called from an interrupt. SysRq handling is done in interrupt for obvious reasons. I think the reason for pci_get_subsys() not wanting to be called from interrupt is the spin_lock() used there instead of a full blown spin_lock_irqsave(). Greg, any suggestions what do do here?
Yeah, you can not call the pci_get_ functions from interrupt context at all, due to hotplug issues. Anyway to save off a pointer to the device you want ahead of time?
Hey, you don't get away that easy :)
I don't think this is a real big issue, as you are rebooting anyway.
Ok, in looking at the code path some more, this is harmless, but I can't get rid of that warning, sorry.