From: Philippe Troin <phil@fifi.org>
To: linux-kernel@vger.kernel.org
Cc: Greg KH <greg@kroah.com>
Subject: iRiver H100 series and usb-storage issues
Date: 04 May 2004 18:26:06 -0700 [thread overview]
Message-ID: <87llk77jgx.fsf@ceramic.fifi.org> (raw)
Lads,
I've had a discussion with Matthew Dharm
<mdharm-usb@one-eyed-alien.net> on the Linux-usb mailing list
<linux-usb-users@lists.sourceforge.net> and I'm taking the topic
here...
Mailing list threads:
http://marc.theaimsgroup.com/?l=linux-usb-users&m=108329645220736&w=2
http://marc.theaimsgroup.com/?l=linux-usb-users&m=108332081125990&w=2
http://marc.theaimsgroup.com/?l=linux-usb-users&m=108370356206121&w=2
Here's the problem:
The iRiver H100 series MP3 players work with linux, but quite
unreliably. By unreliable, I mean that repetitively md5sum'ing the
files on the device yield different results:
find <mountpoint> -type f -print0 | sort -z | xargs -r0 md5sum > sums.1
find <mountpoint> -type f -print0 | sort -z | xargs -r0 md5sum > sums.2
diff sums.1 sums.2
will dump a bunch of diffs. Bad, bad, bad...
With vanilla 2.4.26, these kernel messages are issued and an I/O error
is returned to user space:
USB Mass Storage device found at 18
SCSI disk error : host 1 channel 0 id 0 lun 0 return code = 8000000
Current sd08:21: sense key None
I/O error: dev 08:21, sector 2225382
The sector numbers change all the time... Retrying a faulty sector
will give a good result.
After recompiling with debug message, here are the messages before and
during the error (2.4.26 too):
usb-storage: queuecommand() called
usb-storage: *** thread awakened.
usb-storage: Command READ_10 (10 bytes)
usb-storage: 28 00 01 e5 1f 5c 00 00 01 00 00 00
usb-storage: Bulk command S 0x43425355 T 0x944 Trg 0 LUN 0 L 512 F 128 CL 10
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_transfer_partial(): xfer 512 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 512/512
usb-storage: usb_stor_transfer_partial(): transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: Bulk status result = 0
usb-storage: Bulk status Sig 0x53425355 T 0x944 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
usb-storage: queuecommand() called
usb-storage: *** thread awakened.
usb-storage: Command READ_10 (10 bytes)
usb-storage: 28 00 00 a3 e9 21 00 00 01 00 00 00
usb-storage: Bulk command S 0x43425355 T 0x945 Trg 0 LUN 0 L 512 F 128 CL 10
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_transfer_partial(): xfer 512 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 0/512
usb-storage: Bulk data transfer result 0x1
usb-storage: Attempting to get CSW...
usb-storage: clearing endpoint halt for pipe 0xc0011e80
usb-storage: usb_stor_clear_halt: result=0
usb-storage: Attempting to get CSW (2nd try)...
usb-storage: Bulk status result = 0
usb-storage: Bulk status Sig 0x53425355 T 0x945 R 512 Stat 0x0
usb-storage: -- unexpectedly short transfer
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk command S 0x43425355 T 0x946 Trg 0 LUN 0 L 18 F 128 CL 6
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_transfer_partial(): xfer 18 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 18/18
usb-storage: usb_stor_transfer_partial(): transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: Bulk status result = 0
usb-storage: Bulk status Sig 0x53425355 T 0x946 R 0 Stat 0x0
usb-storage: -- Result from auto-sense is 0
usb-storage: -- code: 0x70, key: 0x0, ASC: 0x0, ASCQ: 0x0
usb-storage: No Sense: no additional sense information
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
SCSI disk error : host 1 channel 0 id 0 lun 0 return code = 8000000
Current sd08:21: sense key None
I/O error: dev 08:21, sector 10741986
When using vanilla 2.6.5, I get no I/O errors, but the md5 diffs are
still generated, so there is still something wrong...
Apparently, the problem is that the device posts an empty reply to a
valid query (save an bug in linux, which I could not pinpoint (yet?)).
I have tried running the device on different computers with different
USB chipsets, and I could reproduce the problem every time.
I am posting here to see if anyone can provide any debugging help or
other clues before I call it quit.
Thanks,
Phil.
reply other threads:[~2004-05-05 1:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=87llk77jgx.fsf@ceramic.fifi.org \
--to=phil@fifi.org \
--cc=greg@kroah.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox