From: bugme-daemon@bugzilla.kernel.org
To: linux-scsi@vger.kernel.org
Subject: [Bug 12730] New: USB memory stick moved to different device on error / may be due to problem with high concurrent load on two USB devices
Date: Tue, 17 Feb 2009 14:25:55 -0800 (PST) [thread overview]
Message-ID: <bug-12730-11613@http.bugzilla.kernel.org/> (raw)
http://bugzilla.kernel.org/show_bug.cgi?id=12730
Summary: USB memory stick moved to different device on error /
may be due to problem with high concurrent load on two
USB devices
Product: IO/Storage
Version: 2.5
KernelVersion: 2.6.27.17
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: SCSI
AssignedTo: linux-scsi@vger.kernel.org
ReportedBy: wagner@tik.ee.ethz.ch
Latest working kernel version: No idea
Earliest failing kernel version: No idea
Distribution: Debian Lenny
Hardware Environment: USB is EHCI by ATI/AMD SB600. CPU is a single core
Sempron LE-1250
Software Environment: dd_rescue and a self-written flash exerciser
Problem Description: I have a 2GB flash as /dev/sdd and a 16GB flash as
/dev/sde. The 2 GB is exercised by a tester that writes and verifies. (This is
intended to be run until there are read errors. I expect that may take up to a
year or longer.) The 16GB I wanted to do a speed test using dd_rescue /dev/sde
/dev/null. It seems this somehow caused a problem leadung to high volume
console output and USB disconnects for both devices (found in the logs).
I have tried the read from the 16GB without the exerciser running, this seems
to work. Unfortunately I did not find any error diagnotics in the logs besides
the USB disconnect, at least not anythign I recognized. What I did should not
have caused USB disconnects in the first place, so this may also be an USB
driver problem or the like.
Now the interesting thing is that the kernel seems to have disabled /dev/sdd
and used the 16GB flash as new /dev/sdd. The 2GB flash did not turn up again.
Not good, devices should not change without an explicit re-plug.
If an USB disconnect is indistinguishable in software from a physical unplug
and replug, I understand that nothing can be done. But if it can be
distinguished, devices should be prevented from moving around on error.
Steps to reproduce: I tried to run this again. Just a reading of the 16GB flash
with dd_rescue did not produce any problems. Starting the flash exerciser again
after replugging both flash devices to get them to their original devices
worked. I could not recreate the original situation, since the port with the
2GB device was now only using OHCI and a reboot on this machine causes some
effort. This may therefore also be an USB driver issue with the EHCI driver
being crashy.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
next reply other threads:[~2009-02-17 22:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-17 22:25 bugme-daemon [this message]
2009-02-17 22:26 ` [Bug 12730] USB memory stick moved to different device on error / may be due to problem with high concurrent load on two USB devices bugme-daemon
2009-02-18 15:19 ` bugme-daemon
2009-02-18 18:32 ` bugme-daemon
2009-03-12 15:55 ` bugme-daemon
2010-01-25 14:49 ` bugzilla-daemon
2010-01-25 14:49 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-12730-11613@http.bugzilla.kernel.org/ \
--to=bugme-daemon@bugzilla.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).