Bug 176666 - usb stick connected at boot causes crash, 2.6.14-1.1653_FC4smp
usb stick connected at boot causes crash, 2.6.14-1.1653_FC4smp
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-12-29 04:40 EST by Alex Hornby
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-04 08:52:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alex Hornby 2005-12-29 04:40:54 EST
+++ This bug was initially created as a clone of Bug #140371 +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
REOPENED as still affects fc4 - kernel 2.6.14-1.1653_FC4smp 

When a USB stick/disk (non-bootable) is connected to the system prior
to boot, the system will crash shortly after bootup with an oops
complaining: 'kernel BUG at mm/slab.c:1453!'

While this report is specific to 2.6.9-1.{681,678}_FC3smp, I have had
trouble with FC2 x86_64 2.6.5-1.358, 2.6.8-1.521, 2.6.9-1{3,6} and RH9
(Shrike) 2.4.20-31.9smp.  In these cases, the system will simply
refuse to boot, specifically the systems will POST, finish additional
device BIOS loads, then black screen...no OS info.  To resolve the
problem, simply remove the USB device and reboot normally, then
reattach for normal use.

USB sticks/disks tested:
  0. Sandisk Cruzer-mini 128MB
  1. iOmega Mini-drive 128MB
  2. Maxtor OneTouch 300GB (3 separate drives)

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

How reproducible:

Steps to Reproduce:
1. power off system
2. attach USB stick/drive
3. attempt to boot machine

Actual Results:  kernel: slab error in kmem_cache_destroy(): cache
`scsi_cmd _cache': Can't free all objects
kernel:  [<02140807>] kmem_cache_destroy+0x99/0x132
kernel: kernel BUG at mm/slab.c:1453!

Expected Results:  normal boot, followed by normal USB mass storage
registration, i.e.:
 USB Mass Storage support registered.
 scsi.agent[4809]: disk at /devices/pci0000:00/0000:00:1d.
fstab-sync[4859]: added mount point /media/usbdisk for /dev/sda1

Additional info:

I have not checked this against Enterprise Linux 3u2.x or 3u3.x, but
hopefully, I will get around to it.

-- Additional comment from jason+redhat-bugzilla@maiar.org on 2004-11-22 12:16
EST --
Created an attachment (id=107193)

-- Additional comment from jason+redhat-bugzilla@maiar.org on 2004-11-22 12:17
EST --
Created an attachment (id=107194)
kernel oops: 'kernel BUG at mm/slab.c:1453!'

-- Additional comment from jason+redhat-bugzilla@maiar.org on 2004-11-22 12:18
EST --
Created an attachment (id=107195)
/var/log/messages from boot to precrash 2.6.9-1.681_FC3smp

-- Additional comment from jason+redhat-bugzilla@maiar.org on 2004-11-22 12:18
EST --
Created an attachment (id=107196)
/var/log/messages from boot to precrash 2.6.9-1.678_FC3smp

-- Additional comment from jason+redhat-bugzilla@maiar.org on 2004-11-22 12:19
EST --
Created an attachment (id=107197)
expected usb device behaviour, after normal (no usb connected) boot

-- Additional comment from alex@hornby.org.uk on 2005-01-01 06:27 EST --
I'm seeing booting hang if my usb card reader is attached. It works
fine if plugged in after booting.

The device description in /proc/bus/usb/devices is below:

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=07cc ProdID=0500 Rev=91.38
S:  Manufacturer=USB2.0
S:  Product=CardReader
S:  SerialNumber=1234600
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

-- Additional comment from davej@redhat.com on 2005-07-15 14:33 EST --
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.

-- Additional comment from davej@redhat.com on 2005-10-02 20:55 EST --
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.

There are a large number of inactive bugs in the database, and this is the only
way to purge them.

Thank you.
Comment 1 Pete Zaitcev 2005-12-29 15:22:13 EST
Please try with a Rawhide kernel (install it with rpm, it should sit ok
on top of FC4 userland). The Stern's fix for devices needlessly offlined
may help here (the return 1 -> return 0 in scsi_eh_tur).
Comment 2 Dave Jones 2005-12-29 19:12:59 EST
actually, a better choice for a 2.6.15rc based kernel on fc4 is at

The rawhide one probably has a bunch of dependancies.  The FC4 variant also
needs a udev update for some systems, which isn't available yet :-/
It should install though.
Comment 3 Alex Hornby 2005-12-31 05:11:40 EST
Hi Dave,  I get a 404 not found from that URL.  I poked around a bit in
http://people.redhat.com/davej/kernels/Fedora/FC4/RPMS.kernel/ but couldn't see
any 2.6.15rc based kernels in there.  What's the right URL?

Comment 4 Dave Jones 2005-12-31 16:58:21 EST
thats the right url. 1779 is currently there, which is based on 2.6.15rc7
(1780 will appear there in an hour or two based on todays upstream snapshot).
Comment 5 Alex Hornby 2006-01-05 14:56:01 EST
I still see the problem with 2.6.14-1.1781_FC4smp 
Comment 6 Pete Zaitcev 2006-01-05 16:21:59 EST
Yeah, Dave, thanks for runing my game plan (j/k, but...)
The second move was supposed to be offering libusual.bias="ub"
and voila, problem solved :-)  Gotta get some profit from our
hard work on ub now.

The difficulty with the usb-storage here is that it's a little difficult
fixing it without having the reproducer on hand. I see that the device
gets offlined, but Alex reports that Stern's fix does not fix it.
So, what can it be? Hell on Earth fixing that without SCSI debugging
Comment 7 Dave Jones 2006-01-05 21:27:24 EST
hmm, actually I hadn't built UB in the FC4 pending update.  If you're ok with it
(the same code as was in 2.6.15 right now), I'll turn it on when I push it out
to updates-testing.
Comment 8 Dave Jones 2006-02-03 00:30:34 EST
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 9 John Thacker 2006-05-04 08:52:49 EDT
Closing per previous comment.

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