Red Hat Bugzilla – Bug 145875
kernel panic at boot: spin_is_locked on uninitialized spinlock
Last modified: 2015-01-04 17:16:04 EST
I'm not sure which component this should be filed against. Probably at least
the kernel, but because I haven't changed it very recently, it's more likely to
be (also?) somewhere else. Please reassign to a suitable component if you can
think of a better one.
Today, when booting my FC3 box, I suddenly started receiving this:
Initializing hardware... storage network audioKernel panic - not syncing:
kernel/sched.c:2781: spin_is_locked on uninitialized spinlock e0a5c7a8
This is kernel 2.6.10-1.741_FC3 i686 on a P4 box. I have had no problems with
this kernel earlier, and have not added any modules recently.
The panic occurs in /etc/rc.sysinit somewhere. I tried booting with
"nomodules", and got the same results (except that then, I saw the "done" and
"ok" after "audio" above), so maybe it's not a problem with loading the modules.
Recently installed updates include hal-0.4.6-1.FC3 and initscripts-7.93.6-1.
Other maybe related things: I have erased the rhgb package a long time ago and
removed rhgb from the command line in /etc/grub.conf.
I got the above panic some 5 times in a row in subsequent reboots, then left the
box alone for half an hour or so, came back and tried booting by adding rhgb to
the boot command line in /etc/grub.conf. And... it booted just fine. Then, did
a reboot without grub in the command line, and it booted flawlessly again. I'm
not going to push my luck by rebooting any more for now unless I really have to...
Suggestions? Time to memtest? This box has been running perfectly stable for a
couple of years, and no fiddling with h/w has been done recently.
I got it too, but it happened only once until now. rhgb was enabled,
and the subsequent reboot went fine. Same kernel and same CPU; so a
hardware problem seems very unlikely. The box here is now fully
up-to-date, running kernel-2.6.10-1.760_FC3, but has shown no sign of
trouble yet -- though unfortunately, this doesn't seem to be easily
Created attachment 111240 [details]
This still happens with 2.6.10-1.766_FC3, but I managed to narrow it down
When trying to boot having a USB device (tested with a X10 receiver for a ATI
Remote Wonder remote controller and a USB keyboard) plugged into a hub that
shares IRQ with a Sigma Designs Hollywood+ MPEG decoder card, the panic at boot
happens _almost_ always. Not 100%, but I guesstimate something like 95%.
If no USB devices are plugged in, there are no problems.
Ditto, everything seems to be fine now that I've shuffled PCI cards so that the
HW+ and USB stuff never share an IRQ.
This setup with HW+ and USB sharing IRQ and USB devices plugged in has worked
with no problems noticed before; the first kernel I witnessed problems with was
Will attach the output of lspci -v and lsusb -v. Additionally, the current
0: 65393843 XT-PIC timer
1: 7 XT-PIC i8042
2: 0 XT-PIC cascade
5: 4790742 XT-PIC saa7146 (0), ohci1394
8: 1 XT-PIC rtc
9: 0 XT-PIC acpi
10: 1580052 XT-PIC ide2, eth1
11: 314586 XT-PIC uhci_hcd, uhci_hcd, eth0
12: 6389228 XT-PIC EMU10K1, em8300
14: 587776 XT-PIC ide0
Note that this is with the "fixed" setup. The problems arose when em8300 and
uhci_hcd were sharing IRQ's.
Created attachment 111241 [details]
This bug should be fixed by the RHEL4 0day errata's 4/4G split fix. Previously
on 3:1 split kernels with the 4/4 split patch applied there was a bug that could
leave the kernel page tables inconsistent between processes...
Note that if my guess is right, the bug only hits after X has been started and
quit. If the bug is hit without ever starting X, my guess is wrong ;)
In that case, I'm afraid your guess is wrong :(. The panic occurred very early
during boot, at the time rc.sysinit loads "other" modules. No X. And I don't
have rhgb installed.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
I have moved on to FC4, and in the meantime, the possible culprit here (the
out-of-tree em8300 driver) has got some changes that may have solved this
Anyway, I haven't seen this occur in a long time, nor on FC3 or FC4. Will
close, and reopen later if I happen to run into it again.