Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 190592 - spinlock bad magic init'ing udev
spinlock bad magic init'ing udev
Status: CLOSED DUPLICATE of bug 190776
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-05-03 15:35 EDT by Steve Grubb
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-07 08:23:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test patch (873 bytes, patch)
2006-05-07 08:05 EDT, Alexander Viro
no flags Details | Diff

  None (edit)
Description Steve Grubb 2006-05-03 15:35:23 EDT
Description of problem:
Starting udev: BUG: spinlock bad magic on CPU#0, events/0/5 (Not tainted)
 lock: ffff810037c90280, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
Kernel panic - not syncing: bad locking

Version-Release number of selected component (if applicable):
kernel builds 2181 & 2185

How reproducible:
Most of the time it locks up. Adding dontpanic to kernel boot leads to spinlock
lockup on CPU#0. It sometimes boots though.

Steps to Reproduce:
1. Boot
Actual results:
Locks up requiring a power cycle to get going again.

Expected results:
No lockup.
Comment 1 Steve Grubb 2006-05-03 18:09:24 EDT
I modified the start_udev script to find out what is happening. It seems that
calling udevtrigger is the culprit. If I add --dry-run, then I do not get the
spinlock bad magic and boot procedes. Not everything works, though. I am trying
to narrow down the subsystem more but I don't know exactly how. There's about
179 events getting replayed. Any ideas ?
Comment 2 Steve Grubb 2006-05-06 21:19:42 EDT
I modified the kernel a little to get some info. The call chain seems to be
include/linux/netdevice.h:895, spinlock.c:95.

I also added a printk( "%s", dev->name) to line 895 of netdevice.h. When it
fails to boot, it outputs "eth%d <0>". When bootup succeeds, it prints "eth0 <6>

This seems like there is a race where sometimes it inited and sometimes its not.
Probably needs some sync mechanism. Does this help narrow things down any?
Comment 3 Alexander Viro 2006-05-07 08:05:59 EDT
Created attachment 128706 [details]
test patch
Comment 4 Alexander Viro 2006-05-07 08:10:14 EDT
I see what's going on here - bcm43xx_attach_board() does
schedule_work(), causing execution of ieee80211softmac_assoc_work()
and does that before the caller of that sucker gets to registering
net_dev.  I'm not familiar with ieee80211 code, so suggested variant
may be BS and definitely needs an ACK from somebody who knows the
area; said that, try the patch attached above and see what happens.
Comment 5 David Woodhouse 2006-05-07 08:23:13 EDT

*** This bug has been marked as a duplicate of 190776 ***

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