linux-kernel - Re: reading errors on JMicron JM20337 USB-SATA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 3 Aug 2009 10:25:02 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Lev A. Melnikovsky" <melnikovsky@...l.ru>
cc:	Artur Skawina <art.08.09@...il.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	<linux-usb@...r.kernel.org>
Subject: Re: reading errors on JMicron JM20337 USB-SATA

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?

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.

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.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/