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.
next reply other threads:[~2004-05-05 1:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-05 1:26 Philippe Troin [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-06-06 14:48 Patch for iriver-mp3player James Bottomley
2004-06-07 14:47 ` iRiver H100 series and usb-storage issues Alan Stern
2004-06-07 19:43 ` Philippe Troin
2004-06-07 20:22 ` Alan Stern
2004-06-07 21:18 ` Philippe Troin
2004-06-08 14:19 ` Alan Stern
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 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.