Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 159301 - attaching USB memory stick freezes system
Summary: attaching USB memory stick freezes system
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-01 15:36 UTC by dj
Modified: 2015-01-04 22:19 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-05-04 13:48:55 UTC

Attachments (Terms of Use)
lshal from affected machine (deleted)
2005-06-16 23:45 UTC, Nick Lamb
no flags Details

Description dj 2005-06-01 15:36:53 UTC
Description of problem:
If I attach my 256MB USB memory stick ("EverDrive") after bootup (and login to
X) FC4T3 freezes.

If I attach it before booting, FC4T3 won't boot. It hangs at the hardware
initialisation stage, even before the frame buffer comes into action - I think
it initializes network, memory (?) and audio. In German it says "Netzwerk,
Speicher, Audio", but it doesn't get to "Audio" if USB stick is attached.

Version-Release number of selected component (if applicable):
# uname -srv
Linux 2.6.11-1.1286_FC4 #1 Wed May 4 11:13:05 EDT 2005

How reproducible:

Steps to Reproduce:
1. boot
2. attach usb drive

Actual results:
System freezes totally. Only hardware reset possible.

Expected results:
Auto mounting the USB device.

Additional info:
# lspci
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 746 Host (rev 10)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SG86C202
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media IO]
(rev 25)
00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller
00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast
Ethernet (rev 90)
00:0b.0 Multimedia controller: Philips Semiconductors SAA7134 (rev 01)
00:0d.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200]
(rev a1)

Comment 1 Pete Zaitcev 2005-06-01 16:17:23 UTC
Two questions:
 1. Does any other kernel or Fedora release work? Which one?
 2. Can you try adding "nmi_watchdog=1" to grub.conf and check if anything
    interesting is printed (the VGA has to be in text mode)?

Comment 2 Nick Lamb 2005-06-16 23:44:47 UTC
I have a similar problem in FC4 final.

Machine freezes if any of my USB flash devices are plugged in after booting, the
kernel certainly gets as far as noticing a new USB device connected, but freezes
almost immediately afterwards. Reproduced at least half a dozen times, first
time every time.

This is a total freeze (no network, no keyboard...)

However in my case if the device is plugged in before booting it works fine.

I will attach output of my 'lshal' which shows configuration of this somewhat
old Duron 700. The system was upgraded from FC3 where USB storage was working
(after various tribulations in earlier kernels) just fine.

Comment 3 Nick Lamb 2005-06-16 23:45:40 UTC
Created attachment 115585 [details]
lshal from affected machine

Comment 4 Nick Lamb 2005-06-18 15:47:27 UTC
I don't entirely understand "the VGA has to be in text mode", but assuming this
means to try it in a text console, I just did this with nmi_watchdog=1 and saw
nothing interesting, it locks hard with no output on console. I've also tried to
enable SysRq but can't seem to make it work so I have no crashlogs.

Comment 5 Dave Jones 2005-06-27 23:15:01 UTC
Mass update for bugs reported against -test:
Updating version field to FC4 final. Please retest with final FC4 release if you
have not already done so. Thanks.

Comment 6 Nick Lamb 2005-07-03 10:50:22 UTC
Just tested again on FC4 final with 2.6.12-1.1387_FC4

Still freezes almost immediately, hardware still as in attachment 115585 [details].

Comment 7 Nick Lamb 2005-07-08 08:52:56 UTC
and again with 2.6.12-1.1390_FC4

Still freezes, hardware unchanged

Comment 8 Nick Lamb 2005-08-09 00:36:35 UTC
and once again with 2.6.12-1.1398_FC4

Still freezes, hardware unchanged

Is there /anything/ I can do to help resolve this bug?

Comment 9 Pete Zaitcev 2005-08-09 01:15:32 UTC
See comment #1. Until I know what's happening, I cannot do anything.
We have to know what the CPU is doing.

Comment 10 Nick Lamb 2005-08-10 09:26:08 UTC
The affected hardware doesn't seem to work with nmi_watchdog=1 or nmi_watchdog=2
using a Fedora kernel. That is, with either NMI watchdog setting in the kernel
boot command line I see no NMI entries in /proc/interrupts and no watchdog ever
wakes to report the lock-up. Is there a trick to it?

However in the course of trying various settings I discovered that my lock-up
does NOT occur if the HAL daemon (service haldaemon) is not running when the
stick is inserted. A USB stick can then be inserted, mounted, files copied on/
off, and then unmounted without even a hiccup.

If the machine is booted with HAL disabled, and then later the HAL daemon is
started with the USB stick plugged in, the machine locks up solid immediately. I
will endeavour to provide more information about this (perhaps I can 'strace
hald' or something?) but not today. Please let me know if there's an easy way to
get the NMI watchdog working on this system.

Comment 11 Pete Zaitcev 2005-08-10 16:57:21 UTC
Very good! The lockup is obviously a kernel's responsibility, but I'll add
David Zeuten to cc:, maybe he has an idea about tracing.

Comment 12 Nick Lamb 2005-08-14 19:41:53 UTC

The HAL daemon, as I've complained in a previous bug, repeatedly polls /proc/apm
to monitor my non-existent battery and non-existent power management status. Of
course that requires a call into the APM BIOS, and APM BIOSes especially in
older machines, and even more especially in non-laptops are notoriously creaky...

I added 'apm=off' to my kernel boot parameters, rebooted, and sure enough even
with the HAL daemon started I can insert and remove USB storage devices, mount
them, read and write files etc.

Sorry Pete, I doubt there's any real kernel bug to fix here. The most you could
do would be to blacklist this BIOS/ motherboard. I can dig out the model number
etc. if you need that. The nitty gritty hardware information should all be in
the lshal attachment earlier in this bug.

Comment 13 Pete Zaitcev 2005-08-14 21:12:10 UTC
Good work. But now the bug is back to original requestor, dj.
I need him to try and convert this into a stack trace.

Comment 14 Dave Jones 2005-09-30 07:22:29 UTC
Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel ( As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.


Comment 15 Dave Jones 2005-11-10 21:57:37 UTC
Mass update to all FC4 bugs:

An update has been released (2.6.14-1.1637_FC4) which rebases to a new upstream
kernel ( As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.


Comment 16 Dave Jones 2006-02-03 06:17:49 UTC
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.

Comment 17 John Thacker 2006-05-04 13:48:55 UTC
Closing per previous comment.

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