All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artur Skawina <art.08.09@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: "Lev A. Melnikovsky" <melnikovsky@mail.ru>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	linux-usb@vger.kernel.org
Subject: Re: reading errors on JMicron JM20337 USB-SATA
Date: Mon, 03 Aug 2009 17:33:48 +0200	[thread overview]
Message-ID: <4A77035C.5090906@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0908031021370.16132-100000@iolanthe.rowland.org>

Alan Stern wrote:
> On Mon, 3 Aug 2009, Lev A. Melnikovsky wrote:
>> AS> yes, jmicron bridges do not report errors properly and just stall pretty
>> AS> much indefinitely; found out the hard way, when a disk started to develop
>> My interpretation was different - the bridge firmware does not crash but 
>> remains alive (it does not report the error properly but "zis iz probably 
>> perfectly normal behaviour for a Vogon"). This is the Linux kernel that 
>> indefinitely tries to re-read. Am I wrong?

No, but that's arguably the right thing to do -- the device didn't
report an error, so why should the kernel fail?..

> You are correct except for the term "indefinitely".  The retries _will_
> stop if you wait long enough.  Unfortunately, because of all the nested
> retry loops in the SCSI drivers and at the application level, you may
> have to wait as long as half an hour.

iirc, i had stalls _way_ longer than that, probably because the reads
eventually succeeded, only to stall on the next ones.

> I agree that this should be fixed.  But it is a SCSI issue, not a USB 
> issue.  You could try bringing it up on the linux-scsi mailing list.

actually, the number of retries should probably be configurable, but i
wouldn't lower them by default; losing data because of recoverable errors
is bad. In this case the bridge may be at fault (by not passing along the
error), but to make a significant difference you'd have to reduce the number
of retries to something like zero, maybe one at most, and that's just too
low for a default. 

artur

  reply	other threads:[~2009-08-03 15:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-01 22:23 reading errors on JMicron JM20337 USB-SATA Lev A. Melnikovsky
2009-08-02 14:03 ` Artur Skawina
2009-08-03  7:19   ` Lev A. Melnikovsky
2009-08-03 14:25     ` Alan Stern
2009-08-03 15:33       ` Artur Skawina [this message]
2009-08-03 15:45         ` Alan Stern
2009-08-03 19:24       ` Lev A. Melnikovsky
2009-08-03 19:52         ` Alan Stern
     [not found]           ` <Pine.LNX.4.44L0.0908031539161.2888-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2009-08-04 18:11             ` Lev A. Melnikovsky
2009-08-04 18:43               ` 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=4A77035C.5090906@gmail.com \
    --to=art.08.09@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=melnikovsky@mail.ru \
    --cc=stern@rowland.harvard.edu \
    /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.