From: Alan Stern <stern@rowland.harvard.edu>
To: Robert Hancock <hancockr@shaw.ca>
Cc: Tomas Styblo <tripie@cpan.org>, <linux-kernel@vger.kernel.org>,
<linux-usb@vger.kernel.org>,
<usb-storage@lists.one-eyed-alien.net>
Subject: Re: [PATCH] JMicron JM20337 USB-SATA data corruption bugfix - device 152d:2338
Date: Mon, 21 Jul 2008 22:37:25 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.44L0.0807212232001.5882-100000@netrider.rowland.org> (raw)
In-Reply-To: <4884E585.2050104@shaw.ca>
On Mon, 21 Jul 2008, Robert Hancock wrote:
> (adding CCs)
>
> Tomas Styblo wrote:
> >
> > Hello,
> >
> > this message includes a patch that provides a workaround for
> > a silent data corruption bug caused by incorrect error handling in
> > the JMicron JM20337 Hi-Speed USB to SATA & PATA Combo Bridge chipset,
> > USB device id 152d:2338.
The two of you should read through
http://bugzilla.kernel.org/show_bug.cgi?id=9638
which concerns this very problem.
> > - the problem occurs quite rarely, approx. once for
> > every 20 GB of transfered data during heavy load
> >
> > - it seems that only read operations are affected
> >
> > - the problem is accompanied by these messages in syslog each
> > time it occurs:
> >
> > May 17 15:06:56 kernel: sd 6:0:0:0: [sdb] Sense Key : 0x0 [current]
> > May 17 15:06:56 kernel: sd 6:0:0:0: [sdb] ASC=0x0 ASCQ=0x0
> >
> > - the bug is not detected as an error and incorrect data is returned,
> > causing insidious data corruption
> >
> > - tested with 3 external disk enclosures (Akasa Integral AK-ENP2SATA-BL)
> > with different disks on different computers, with kernel 2.6.24 and 2.6.25
> >
> > - the patch provides a crude workaround by detecting the error condition
> > and retrying the faulty transfer
> >
> >
> > The fix needs a review as I don't know much about USB and SCSI.
> > It's possible that this approach is wrong and that the problem should
> > be fixed somewhere else.
> >
> > There are other problems with this chipset that make it necessary
> > to disconnect and power off the enclosure from time to time, but at least
> > there's no data corruption anymore.
>
> I'm not sure this is a good approach. More that this code right above in
> usb_stor_invoke_transport, which your code undoes the effect of for this
> device, doesn't seem right:
>
> /* If things are really okay, then let's show that. Zero
> * out the sense buffer so the higher layers won't realize
> * we did an unsolicited auto-sense. */
> if (result == USB_STOR_TRANSPORT_GOOD &&
> /* Filemark 0, ignore EOM, ILI 0, no sense */
> (srb->sense_buffer[2] & 0xaf) == 0 &&
> /* No ASC or ASCQ */
> srb->sense_buffer[12] == 0 &&
> srb->sense_buffer[13] == 0) {
> srb->result = SAM_STAT_GOOD;
> srb->sense_buffer[0] = 0x0;
> }
>
> So if the transport initially gets a failure, but then request sense
> doesn't show any error, we just go "hmm, guess it was ok after all".
> That seems kind of dangerous, I shouldn't think we should assume a
No, no -- you have misread the code. If the transport initially got a
failure then result would be equal to USB_STOR_TRANSPORT_FAILED, not
USB_STOR_TRANSPORT_GOOD, so this code wouldn't run.
> If you just delete that code above, does the corruption go away?
Alan Stern
next prev parent reply other threads:[~2008-07-22 2:37 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.eWQqoO1e4Mdhu8SK5jzMFAI/3NU@ifi.uio.no>
2008-07-21 19:37 ` [PATCH] JMicron JM20337 USB-SATA data corruption bugfix - device 152d:2338 Robert Hancock
2008-07-22 2:37 ` Alan Stern [this message]
2008-07-22 9:03 ` Tomas Styblo
2008-07-23 2:38 ` Alan Stern
2008-07-23 23:20 ` Robert Hancock
2008-07-24 3:42 ` Alan Stern
2008-07-30 19:55 ` Robert Hancock
2008-07-30 20:00 ` [usb-storage] " Matthew Dharm
2008-07-30 20:46 ` Robert Hancock
2008-07-30 21:18 ` Alan Stern
2008-07-30 21:07 ` Alan Stern
2008-08-01 21:15 ` Alex Buell
2008-08-01 22:22 ` Alex Buell
2008-08-02 2:32 ` Robert Hancock
2008-08-02 23:49 ` Alan Stern
2008-08-03 9:07 ` Alex Buell
2008-08-04 16:48 ` Alan Stern
2008-08-04 20:17 ` Alex Buell
2008-08-04 20:45 ` Alan Stern
2008-09-02 12:10 ` Thiago Galesi
2008-09-02 15:02 ` Alan Stern
2008-09-02 16:07 ` Thiago Galesi
2008-09-02 19:19 ` Alan Stern
2008-09-02 20:16 ` Thiago Galesi
2008-09-02 21:06 ` Alan Stern
2008-09-04 12:09 ` Thiago Galesi
2008-09-04 14:03 ` Alan Stern
2008-09-04 15:17 ` Thiago Galesi
2008-09-04 15:26 ` Alan Stern
2008-07-25 8:44 ` Tomas Styblo
2008-07-25 8:54 ` Robert Hancock
2008-07-22 5:11 ` Tomas Styblo
2008-07-22 5:31 ` Robert Hancock
2008-07-22 6:11 ` Tomas Styblo
2008-07-22 8:45 ` Robert Hancock
2008-07-24 6:15 ` Alex Buell
2008-07-29 21:09 ` Alex Buell
2008-07-29 22:33 ` [usb-storage] " Matthew Dharm
2008-07-20 5:13 Tomas Styblo
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=Pine.LNX.4.44L0.0807212232001.5882-100000@netrider.rowland.org \
--to=stern@rowland.harvard.edu \
--cc=hancockr@shaw.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=tripie@cpan.org \
--cc=usb-storage@lists.one-eyed-alien.net \
/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).