Bug 116501 - Badness in pci_get_subsys at drivers/pci/search.c:234
Summary: Badness in pci_get_subsys at drivers/pci/search.c:234
Status: RESOLVED WONTFIX
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Kernel (show other bugs)
Version: RC 1
Hardware: i686 All
: P5 - None : Minor
Target Milestone: ---
Assignee: Greg Kroah-Hartman
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-12 14:12 UTC by Carl-Daniel Hailfinger
Modified: 2005-11-08 23:02 UTC (History)
1 user (show)

See Also:
Found By: Development
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Carl-Daniel Hailfinger 2005-09-12 14:12:15 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.
Comment 1 Vojtech Pavlik 2005-10-31 14:39:04 UTC
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?
Comment 2 Greg Kroah-Hartman 2005-11-08 22:45:52 UTC
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?
Comment 3 Greg Kroah-Hartman 2005-11-08 22:47:47 UTC
Hey, you don't get away that easy :)
Comment 4 Greg Kroah-Hartman 2005-11-08 23:01:50 UTC
I don't think this is a real big issue, as you are rebooting anyway.
Comment 5 Greg Kroah-Hartman 2005-11-08 23:02:30 UTC
Ok, in looking at the code path some more, this is harmless, but I can't
get rid of that warning, sorry.