Description of problem:
writing and reading from an external USB harddisk seems to cause the computer to
Version-Release number of selected component (if applicable):
hung the computer 3 times today
Steps to Reproduce:
1.copy data to USB disk
2.at same time read from USB disk
computer should continue to work
This happened a few times today and I am sure this used to work fine with this
HD about a month ago. I am writing data (~700 kB/s from network) to the USB
disk. Everything works fine as long as I don't access the disk (much) at the
same time. Relevant part of /var/log/messages is attached.
Created attachment 154415 [details]
part of /var/log/messages
Created attachment 154416 [details]
Created attachment 154417 [details]
lsusb -v output
I don't think I can do much if a disconnect happens. It is always initiated
by device. Try to find an external enclosure which does not disconnect.
I think there are 2 problems:
1) the device is relatively new (5 months old) and worked fine until about 1
month ago. While it is of course possible that something went wrong with the
device I was wondering if there had been changes to the USB driver/kernel that
could cause that.
2) even if the device disconnects for some reason, it should not be able to
bring the computer to a crawling halt that I can only get out of by rebooting
(sometimes CTRL-Alt-Del works, sometimes only a power off!).
Quite so. Although the host does not ever disconnect any USB devices,
the software can precipitate a disconnect by making the firmware in the
device to crash. Some of them are really fragile, especially anything
OEM-ed from Gensys.
BTW, FC-6 ships with ub enabled. What does happen if you boot with
libusual.bias="ub" in grub.conf? Mind, the mount devce will move
from sda1 to uba1 for the test. Look into /proc/partitions to check.
I have been running today with libusual.bias="ub" and the drive seemed to work fine.
(This is a mass-update to all current FC6 kernel bugs in NEW state)
I'm reviewing this bug list as part of the kernel bug triage project, an attempt
to isolate current bugs in the Fedora kernel.
I am CC'ing myself to this bug, however this version of Fedora is no longer
Please attempt to reproduce this bug with a current version of Fedora (presently
Fedora 8). If the bug no longer exists, please close the bug or I'll do so in a
few days if there is no further information lodged.
Thanks for using Fedora!
I am currently using Fedora 7 and intend to wait for 9 before upgrading again.
About a month (IIRC) after I sent comment #7 the libusual.bias="ub" kernel
parameter vanished in FC6 and the behaviour of external USB drives got worse
again. I then switched to Fedora 7 to see if there was an improvement, but this
did not help.
The current manifestation of the problem is no longer a kernel lock up but a
shutdown of the USB subsystem (or so it seems). For example, if I have a USB
mouse connected, then connect the USB disk and write to the disk I will loose
the use of the USB mouse at a random point in time. Unplugging the mouse and
reconnecting it (to the same or another USB port) does not make it work. Only a
reboot makes the mouse available again, while the touchpad is working all the time.
Another manifestation under Fedora 7 is that the USB HDs disconnect (on read or
write) and then automatically reconnect. This is seen in the window manager as
the disk icon vanishing and then reappearing. This can happen a few times after
which the disk stays lost. Unplugging and plugging the disk back in again does
not make it accessable again. Only a reboot helps. The problem starts at a
random time and sometimes one can work for hours without a problem.
I have seen this problem now with 3 different enclosures. Apart from the i686
laptop I have also seen this happen with Fedora 7 on a x86_64 desktop, although
(it seemed) less frequently. Older versions of Fedora (eg. FC5) however do not
seem to have a problem with these external disks.
Correct, ub is not supported anymore in Fedora. It should be possible
to emulate some of its lighter load characteristics by:
echo 32 > /sys/block/sdb/queue/max_sectors_kb
But honestly I suspect a new motherboard is the solution here.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.
Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008.
Fedora 7 is no longer maintained, which means that it will not
receive any further security or bug fix updates. As a result we
are closing this bug.
If you can reproduce this bug against a currently maintained version
of Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.