Bug 155979 - XFS Causes Kernel Panic on Reboot
Summary: XFS Causes Kernel Panic on Reboot
Keywords:
Status: CLOSED DUPLICATE of bug 155472
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 3
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-04-26 12:53 UTC by Gary A. McGee
Modified: 2015-01-04 22:19 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-25 00:30:59 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
/var/log/Xorg.0.log (34.26 KB, text/plain)
2005-04-26 14:20 UTC, Gary A. McGee
no flags Details

Description Gary A. McGee 2005-04-26 12:53:29 UTC
Description of problem:
During reboot, the system will hang while shutting down XFS.  When the system
hangs, I observe the following message:

Shutting down xfs:  Kernel panic - not syncing:
drivers/block/cfq-iosched.c:1065: spin_is_locked on uninitialized spinlock
ed9d4ck. (Tainted:  P   )  

Version-Release number of selected component (if applicable):
kernel-2.6.11-1.14_FC3
kernel-utils-2.4-13.1.49_FC3
xorg-x11-xfs-6.8.2-1.FC3.13

How reproducible:
Sometimes

Steps to Reproduce:
1. Reboot/Shutdown
2.
3.
  
Actual results:
System Hangs on reboot/shutdown.

Expected results:
System should shutdown cleanly.

Additional info:
The log files did not seem to reveal anything, except that shutdown got as far
as XFS.  I am still trying to determine whether this problem is associated with
the use of a usbdisk.  Seems like when I have used my usbdisk (1 GB memory
stick) this occurs, but I must confirm it.

Comment 1 Gary A. McGee 2005-04-26 14:13:28 UTC
I can reproduce the problem reliably now, but I am not sure what this has to do
with shutting down XFS.  The problem is associated with the use of a usbdisk
removable memory.

Here is what happens.  When I insert the device into the usb port, it is mounted
as one would expect.  I then right click on the desktop icon to unmount the
device.  The icon goes away, and "df -h" shows that the device has been
unmounted.  After the device is umounted, I notice that the device light is
still on, but not flashing.  Assuming the device is safe to remove, I take it
out.  I log out and then initiate a reboot.  When the shutdown process gets to
XFS, it hangs as described in the initial report.

I have observed that there is a work-around for this.  If I follow the same
procedure, as in the preceding paragraph, but do not take the device out of the
usb port during the reboot, it does not hang.

It seems to me that when the device is unmounted that it should be safe to
remove without impacting the system.

Comment 2 Gary A. McGee 2005-04-26 14:20:28 UTC
Created attachment 113668 [details]
/var/log/Xorg.0.log

Here is the Xorg.log.

Comment 3 Rik van Riel 2005-04-26 16:21:45 UTC
Gary,

which 3rd party kernel module are you using ?

Comment 4 Mike A. Harris 2005-04-26 16:44:14 UTC
A kernel panic is not an X font server bug, nor an Xorg bug at all.  A kernel
panic is due to a bug in the kernel or a hardware fault.

Your kernel is tainted by 3rd party kernel modules, so it is not a Red Hat
kernel anymore.

If you can reproduce the problem with a stock kernel with no 3rd party
modules loaded whatsoever, reopen the bug.

Comment 5 Gary A. McGee 2005-04-26 17:17:18 UTC
I am using the Linuxant DriverLoader for my internal Broadcom Wireless card.

Comment 6 Gary A. McGee 2005-04-26 18:03:36 UTC
I removed the Linuxant driverloader-2.27_k2.6.11_1.14_FC3-1fdr.i686.rpm with
the following command:

        $ rpm -e driverloader

        Removed driverloader from /lib/modules/

Comment 7 Gary A. McGee 2005-04-26 18:08:24 UTC
After reboot "lsmod" shows the following:

        $ lsmod
        Module                  Size  Used by
        radeon                 74177  1
        parport_pc             28421  0
        lp                     12489  0
        parport                40201  2 parport_pc,lp
        autofs4                26181  0
        i2c_dev                11201  0
        i2c_core               21953  1 i2c_dev
        sunrpc                164485  1
        pcmcia                 26465  2
        ipt_REJECT              7105  1
        ipt_state               1857  1
        ip_conntrack           40601  1 ipt_state
        iptable_filter          2881  1
        ip_tables              19777  3 ipt_REJECT,ipt_state,iptable_filter
        md5                     4161  1
        ipv6                  259201  12
        dm_mod                 59221  0
        video                  15813  0
        button                  6609  0
        battery                 9285  0
        ac                      4805  0
        ohci1394               39129  0
        ieee1394              309145  1 ohci1394
        yenta_socket           21065  1
        rsrc_nonstatic         10433  1 yenta_socket
        pcmcia_core            47993  3 pcmcia,yenta_socket,rsrc_nonstatic
        uhci_hcd               33497  0
        ehci_hcd               39501  0
        snd_ali5451            28421  2
        snd_ac97_codec         71097  1 snd_ali5451
        snd_pcm_oss            51953  0
        snd_mixer_oss          18241  2 snd_pcm_oss
        snd_pcm                99657  3 snd_ali5451,snd_ac97_codec,snd_pcm_oss
        snd_timer              33093  1 snd_pcm
        snd                    56741  8
        snd_ali5451,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
        soundcore              10785  2 snd
        snd_page_alloc          9669  1 snd_pcm
        natsemi                33697  0
        floppy                 64753  0
        ext3                  131145  9
        jbd                    82777  1 ext3

Comment 8 Rik van Riel 2005-04-26 18:11:44 UTC
Can the bug be reproduced without the Linuxant drivers present ?

If yes, please reopen this bug and reassign it to the "kernel" component.

If the bug is dependant on the Linuxant driver, please open a bug report with
the Linuxant developers. They will be the only ones who can help you at that
point - after all they have our source, we don't have theirs.

Comment 9 Gary A. McGee 2005-04-26 18:17:27 UTC
I followed the same procedure as outlined in comment #1, paragraph #2 and received 
the following results right after XFS was successfully shutdown.

        Shutting down console mouse services:  Kernel panic - not syncing:
        drivers/block/cfg-iosched.c:1065:  spin_is_locked on uninitialized
        spinlock ee86341c. (Not tainted)

It is obvious to me now that this is not an XFS issue, and that the issue
exists, for some reason, even though I am using a stock kernel.

Other than DriverLoader, which I uninstalled, this is a stock kernel.  I did
the FC3 installation yesterday, followed by "yum update".

Comment 10 Gary A. McGee 2005-04-26 18:18:20 UTC
Please advise what I should do next.

Comment 11 Rik van Riel 2005-04-26 18:22:43 UTC
Did the kernel print out anything else than that panic ?

Any backtraces, etc... ?

Comment 12 Gary A. McGee 2005-04-26 18:46:06 UTC
No, that was the last message on the console when it froze up.  Is there another
place I should look in order to glean information?  The logs did not seem to
reveal anything.

Comment 13 Dave Jones 2005-04-26 22:08:33 UTC
http://people.redhat.com/davej/kernels/Fedora/FC3 has a work-in-progress kernel
that should fix this.
 

Comment 14 Gary A. McGee 2005-05-23 23:22:13 UTC
I upgraded to kernel-2.6.11-1.27_FC3 today, and was not able to reproduce the
problem.

Thank you.

Comment 15 Dave Jones 2005-05-25 00:30:59 UTC

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


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