Bug 190592
Summary: | spinlock bad magic init'ing udev | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Steve Grubb <sgrubb> | ||||
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||
Status: | CLOSED DUPLICATE | QA Contact: | Brian Brock <bbrock> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | wtogami | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2006-05-07 12:23:13 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Steve Grubb
2006-05-03 19:35:23 UTC
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 ? 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> SoftMAC". 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? Created attachment 128706 [details]
test patch
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. |