Bug 174270 - kernel panic - not syncing: bad locking during initializing hardware
Summary: kernel panic - not syncing: bad locking during initializing hardware
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 5
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
: 174438 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-11-26 23:45 UTC by Heath Wilkinson
Modified: 2015-01-04 22:23 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-05 02:05:00 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
UP kernel 1735 panic screenshot (195.50 KB, image/jpeg)
2005-12-03 11:47 UTC, Thomas M Steenholdt
no flags Details

Description Heath Wilkinson 2005-11-26 23:45:31 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.13 (X11; Linux i686; U;) Gecko/20040308

Description of problem:
Upgraded to FC5 test1 from FC4 using "yum -y upgrade".  After successful install, the kernel would panic during boot right after the udev step would start.

The message displayed is "Initializing hardware...  Kernel panic - not syncing: bad locking"

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.boot the computer -- panics right after udev step starts

Actual Results:  The message displayed is "Initializing hardware...  Kernel panic - not syncing: bad locking"

Additional info:

Comment 1 Thorsten Scherf 2005-11-28 05:09:05 UTC
had the same problem after installing the latest selinux-policy-strict package.
when rebooting the machine (before relabing) the machine hangs with kernel panic.

Comment 2 Thorsten Scherf 2005-11-28 12:13:50 UTC
forgot to mention, that I don't think it is a selinux problem, but a problem
with the kernel. 

Comment 3 Dave Jones 2005-11-28 18:47:03 UTC
if you add 'dontpanic' to the boot command line, it should continue past the
point where it would have hung.  If it then boots to a command line, can you
attach the output of dmesg -s 128000 please ?

Comment 4 Nalin Dahyabhai 2005-11-28 20:35:23 UTC
I'm also seeing this (Athlon MP).  The problem seems to have appeared in
2.6.14-1.1712_FC5smp, because 2.6.14-1.1711_FC5smp boots without problems
without any changes to the userland packages.

With "dontpanic", the system still hangs, but no panic message is printed before
it does so.

Comment 5 Heath Wilkinson 2005-11-28 21:44:32 UTC
I added the "dontpanic" to the boot command line.  The system no longer panics,
but hangs at the "Initializing hardware..." step.  I left it at that stage for
15 minutes before rebooting.

BTW, I have seen the same behaviour with the last two FC5 kernels
(2.6.14-1.1715_FC5smp and the one that came before that).

I also tried the Non-SMP FC5 kernels (same versions) and they also hang (no
kernel panic) at "Initializing hardware...".

Since I "yum -y upgrade"'d the system from FC4, I still have the
2.6.14-1.1637_FC4smp installed on the FC5 system.  I can successfully boot the
system with the FC4 kernel.  Would a dmesg or any other diagnostic output be
useful from this kernel on the FC5 system?

Comment 6 Dave Jones 2005-11-28 22:15:34 UTC
not really. the bit of info I'm after is the backtrace from the panic.

can you edit the /etc/rc.sysinit file and find the bit that looks like this..

load_module () {
    for module in $blacklist ; do
        [ "$1" = "$module" ] && return
    modprobe $1 >/dev/null 2>&1

and change it so that there's an

echo $1 on the line before the modprobe ?

that'll tell me which driver is being loaded which is causing the lockup

Comment 7 Heath Wilkinson 2005-11-28 23:52:46 UTC
I added the echo statement in load_module (), but the system panicked before any
output was produced.  So I put a "set -x" at the beginning of /etc/rc.sysinit
and here is the output from the udev part:

+ /sbin/start_udev
Starting udev:   [OK]
++ cat /proc/cmdline
+ cmdline='ro root=/dev/hda3 acpi=off'
+ sysctl -w kernel.hotplug=/sbin/udevsend
+ '[' -f /proc/sys/kernel/modprobe ']'
+ strstr 'ro root=/dev/hda3 acpi=off' nomodules
+ '[' 'ro root=/dev/hda3 acpi=off' = 'ro root=/dev/hda3 acpi=off' ']'
+ return 1
+ '[' -f /proc/modules ']'
+ sysctl -w 'Initializing hardware... '
Initializing hardware... + ide=
+ scsi=
+ network=
+ audio=
+ other=
++ kmodule -d
++ read devtype mod
Kernel panic - not syncing: bad locking

Comment 8 Dave Jones 2005-11-29 23:05:04 UTC
the 1720 kernel at http://people.redhat.com/davej/kernels/Fedora/devel/
should have this fixed. the ehci usb driver had some bad locking.

Comment 9 Dave Jones 2005-11-29 23:06:11 UTC
*** Bug 174438 has been marked as a duplicate of this bug. ***

Comment 10 Nalin Dahyabhai 2005-11-30 00:38:07 UTC
This appears to be fixed on my test system.

Comment 11 David Woodhouse 2005-11-30 00:58:35 UTC
There remains the question of why nobody actually saw the BUG() and the
backtrace -- only the panic. That really needs fixing.

Comment 12 Heath Wilkinson 2005-11-30 01:21:38 UTC
I tried the 2.6.14-1.1721_FC5 kernel at
http://people.redhat.com/davej/kernels/Fedora/devel/ and it fixed it for me. 
The system no longer panics and I can successfully boot the system.

Comment 13 Dave Jones 2005-11-30 04:23:43 UTC
probably got missed due to people having 'quiet' in their boot command line.
Those msgs don't seem to have printk levels, so they get hushed. I'll send a
patch upstream to fix that.

Comment 14 David Woodhouse 2005-11-30 07:16:03 UTC
I had 'debug' on my command line and I still didn't see it.

Comment 15 Matthew Carter 2005-12-01 08:37:44 UTC
Installed the latest updated kernel 2.6.14-1.1719 and I got the crash during
initializing hardware again. This doesnt occur with 2.6.14-1.1715, I tried one
of the latest ones on DaveJs space (2.6.14-1.1725) and the crash still occurs.

My Hardware:
Pentium-M 1.6
Intel 915 Mobo
GF 6200 TC
Fujitsu 60Gb SATA
Intel Pro 100/IPW2200 BG


Comment 16 Matthew Carter 2005-12-01 14:56:14 UTC
Have updated the kernel using yum today to 2.6.14-1.1729 still having the crash
during initializing hardware.


Comment 17 Dave Jones 2005-12-02 06:12:48 UTC
ok, can you try the procedure mentioned in comment #6 ?

also, make sure you dont have 'quiet' on your boot command line.

Comment 18 Matthew Carter 2005-12-02 10:13:13 UTC
Did as you asked, removed quiet from boot:

Kernel booted ok (saw lots of stuff wizz past me)
Initializing hardware....ahci

Then it froze, rebooted again to check and it didnt even get that far, on the
third reboot my laptop beeped at me when it froze again.

Comment 19 Matthew Carter 2005-12-03 08:44:47 UTC
Updated to Kernel 2.6.14-1.1735
Same issue stops at the same place, just a quick thing would it matter if I dont
have a floppy drive? The laptop doesnt have a floppy drive or floppy controller.

Comment 20 Thomas M Steenholdt 2005-12-03 11:06:37 UTC
The 1707 UP kernel is the last kernel that works on my Pentium M based Shuttle
PC. I get a few lines worth of backtrace on the console, doesn't look too
specific to me, but nothing gets to the logs. I'm attaching a screenshot instead
in hopes that it clears things up anyway. Apart from perhaps addresses, which I
haven't compared, the backtrace looks identical on UP and SMP kernels.

Comment 21 Thomas M Steenholdt 2005-12-03 11:47:47 UTC
Created attachment 121796 [details]
UP kernel 1735 panic screenshot

Comment 22 Matthew Carter 2005-12-06 17:42:56 UTC
Is there anything else I can do to help you test this problem with Pentium M's?
Should I try the SMP Kernel? I still dont get any Kernel Panics, Udev now
freezes and no hardware shows as of Kernel 2.6.14-1.1739, lucky I still have
Kernel 2.6.14-1.1715 to boot with :D


Comment 23 Matthew Carter 2005-12-06 17:52:33 UTC
Managed to get it to boot some drivers again still having issues after it hits
the floppy driver.

Comment 24 Matthew Carter 2005-12-06 22:01:25 UTC
Installed Kernel 2.6.14-1.1740 (it crashes) and added a "set -x" to the top of
my rc.sysinit to see what the output is.

+echo floppy
+modprobe floppy

I think that is the cause of my problem, no floppy drive or controller, is there
a way to exclude this from being initialized?

Comment 25 Thomas M Steenholdt 2005-12-08 16:37:17 UTC
Turns out, once i got to test this a little more thoroughly, that MY problem was
due to LVM on top of MD devices and the init process - I need to file a
different bug for that - once i get all the details sorted out, but it's clearly
unrelated to this bug. I reinstalled and i'm now booting with no problems on
2.6.14-1.1743_FC5smp and 2.6.14-1.1743_FC5 with no problems.

Comment 26 Matthew Carter 2005-12-16 07:33:47 UTC
I have a new Kernel Panic on Kernels after 1760:


I have udev set to debug atm due to the problems it is giving me, would you
prefer a non debug view?


Comment 27 Dave Jones 2005-12-16 08:11:16 UTC
booting with vga=791 will get you more lines of text onscreen, so you may be
able to get the top of the oops.

Tomorrows build will also pause after the first oops, which should give you a
better chance to grab the first one (Which is usually the only one that matters).

Comment 28 Matthew Carter 2005-12-28 17:06:54 UTC
Hi Dave

Still having the boot issue, managed to get a vga=791 screenshot this time:


In addition when I update my kernel i get a error when installing it, have
forgotten to take a screenshot sorry, not sure whether this is causing a problem.

You will know better than me.


Comment 29 Matthew Carter 2005-12-29 07:44:14 UTC
Hi Dave 

I grabbed the install error when updating to 2.6.14-1.1796 this morning:

/var/tmp/rpm-tmp.36540: line 1:  2960 Segmentation fault 
/usr/sbin/module_upgrade 2.6.14-1.1796_FC5

This is the install error, not the boot one, will let you know if i still get it
with 1796.


Comment 30 Matthew Carter 2005-12-29 07:54:00 UTC
Same booting problem during initializing hardware as 1786.

Comment 31 Dave Jones 2005-12-29 10:01:52 UTC
module_upgrade segfaulting is a kudzu bug, can you file a separate one for that
please ?  (If it dropped a core dump someplace, installing kudzu-debuginfo and
doing 'gdb /usr/sbin/module_upgrade core.dumpfilename' should show a backtrace
which should be interesting.

Comment 32 Matthew Carter 2006-01-02 22:58:19 UTC
Hi Dave

Neva managed to get the Kadzu grab as my install crash and I havent been able to
recover it. An now when I install I cant get into a GUI fedora, had to
re-install and how I cant boot fedora as it cant use the launch kernel (SMP
issue) and so far the only working kernel 2.6.14-1.1715 (due to the continuing
problems I have after  1715) and I dont have a copy of it anywhere (unless you
can provide one?). Think I am going to have to wait for test 2.


Comment 33 Dave Jones 2006-03-06 16:58:44 UTC
was test3 any better ?

Comment 34 John Thacker 2006-05-05 02:05:00 UTC
No response to request for information.  Closing.  If it still
happens in FC5 final, reopen.

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