From: Emiliano Garcia <emi@vinyltribe.com>
To: linux-kernel@vger.kernel.org
Subject: RE: [BUG: multiple kernels] data corruption while reading from an USB2 connected HD
Date: Wed, 06 Oct 2004 18:33:26 -0700 [thread overview]
Message-ID: <41649CE6.6010405@vinyltribe.com> (raw)
Hello Everyone,
I can confirm I am also experiencing problems with usb-storage on
usb 2.0 devices. I have two separate usb 2.0 drives, one with the oxford
911 usb/firewire chipset and another with a gensys chip. Anyhow, I tar
up my servers once a week and copy the bzipped tar to my usb hard drive.
I have found now that I cannot extract the tar.bz2 files due to crc
errors. When I run bzip2 -tvv on the original archive on the server, it
passes without failure. When I run the test (bzip2 -tvv) on the copy of
the archive on the usb 2.0 disks, it says they have crc errors. dmesg
does not show anything exciting besides the mounting/detection of the
drives. Please help!
Thanks to all of you for you hard work.
Emiliano Garcia
* /To/: linux-kernel@vger.kernel.org
<mailto:linux-kernel%40vger.kernel.org>
* /Subject/: [BUG: multiple kernels] data corruption while reading
from an USB2 connected HD
* /From/: Hajo Simons <simons@dc-systeme.de
<mailto:simons%40dc-systeme.de>>
* /Date/: Mon, 27 Sep 2004 11:06:06 +0200
* /Cc/: hsimons@gmx.de <mailto:hsimons%40gmx.de>
* /Organization/: dc-Systeme
* /Sender/: linux-kernel-owner@vger.kernel.org
<mailto:linux-kernel-owner%40vger.kernel.org>
* /User-agent/: KMail/1.7
------------------------------------------------------------------------
usb-storage sporadically loses data while reading
In a data stream of 20M about 10 bytes get lost averagely while reading from a
HD connected via USB 2.0 which practically means that most files stored on
that HD show different md5 fingerprints if the IO read buffer was flushed
meanwhile.
keywords:
usb-storage, external Disk, USB 2.0, data corruption while reading
data get lost while reading on:
2.4.27
2.6.8.1
2.6.8-gentoo-r3
2.6.8-gentoo-r4 preemptive/non-preemptive
2.6.9-rc1
whereas no faults are seen on:
Windows XP SP1 (without specific drivers for that USB2 disk device)
system:
Barton 3.2 200
Asus A7N8XX (nforce2) FSB at 192MHz, CPU at FSB*11.5
(A7N8* or CPU (don't know) cannot run stable for over a week at 200MHz FSB)
1G 400MHz DDR RAM (tested) runnung at FSB Speed
2 IDE disks connected to the onboard nforce2 IDE controller
1 IDE disk USB2ish connected to ALi (ID 0402:5621 ALi Corp.) via onboard
nforce2 USB controller
test:
(UAHD: usb attached HD)
create a big file on a UAHD, say 20M
md5sum it
umount UAHD
remount it
md5sum that file again
chances are 50/50, that you get a different number
if md5sums are equal, repeat the procedure
( did the same test on that mentioned WinXP: everything ok;
and yes, I did unplug the device between the reads )
note:
system behaves rock-solid besides that issue
tried blk_queue_max_sectors(sdev->request_queue, 1) in
scsiglue.c:slave_configure() to no avail
tried PREEMPTIVE on/off, same
details:
....
snip
next reply other threads:[~2004-10-07 1:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-07 1:33 Emiliano Garcia [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-09-27 9:06 [BUG: multiple kernels] data corruption while reading from an USB2 connected HD Hajo Simons
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=41649CE6.6010405@vinyltribe.com \
--to=emi@vinyltribe.com \
--cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.