Bug 145875 - kernel panic at boot: spin_is_locked on uninitialized spinlock
Summary: kernel panic at boot: spin_is_locked on uninitialized spinlock
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: 3
Hardware: All Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-22 22:56 UTC by Ville Skyttä
Modified: 2015-01-04 22:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-07-16 15:48:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
lspci -v (4.98 KB, text/plain)
2005-02-20 17:43 UTC, Ville Skyttä
no flags Details
lsusb -v (5.68 KB, text/plain)
2005-02-20 17:44 UTC, Ville Skyttä
no flags Details

Description Ville Skyttä 2005-01-22 22:56:55 UTC
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.

Comment 1 Didier Heyden 2005-02-03 08:32:35 UTC
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

Comment 2 Ville Skyttä 2005-02-20 17:43:48 UTC
Created attachment 111240 [details]
lspci -v

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
/proc/interrupts is:

  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
NMI:	      0
ERR:	      0

Note that this is with the "fixed" setup.  The problems arose when em8300 and
uhci_hcd were sharing IRQ's.

Comment 3 Ville Skyttä 2005-02-20 17:44:18 UTC
Created attachment 111241 [details]
lsusb -v

Comment 4 Rik van Riel 2005-02-28 16:25:34 UTC
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...

Comment 5 Rik van Riel 2005-02-28 16:27:49 UTC
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 ;)

Comment 6 Ville Skyttä 2005-02-28 16:57:30 UTC
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.

Comment 7 Dave Jones 2005-07-15 20:14:58 UTC
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'.

Thank you.

Comment 8 Ville Skyttä 2005-07-16 15:48:57 UTC
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. 

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