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] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0705301223170.5979-100000@iolanthe.rowland.org>
Date:	Wed, 30 May 2007 12:29:27 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Dan Aloni <da-x@...atomic.org>
cc:	linux-usb-devel@...ts.sourceforge.net,
	Linux Kernel List <linux-kernel@...r.kernel.org>
Subject: Re: [linux-usb-devel] Dealing with flaky USB storage devices and
 rootfs

On Wed, 30 May 2007, Dan Aloni wrote:

> On Tue, May 29, 2007 at 05:50:49PM -0400, Alan Stern wrote:
> > On Tue, 29 May 2007, Dan Aloni wrote:
> > 
> > > Hello,
> > > 
> > > We have a system where the rootfs is a partition on a USB device,
> > > and I've noticed upon a few rare cases where the USB controller 
> > > loses the connection to the USB device after some uptime (days,
> > > weeks...), and the USB device reappears a very short time later.
> > 
> > That failure mode is pretty uncommon.  More often what happens is the
> > connection remains intact but communication/protocol/firmware/???  
> > errors cause the device to stop working.  It never disappears but it
> > can't be used again without unplugging or power-cycling.
> 
> Yes this is also what I assume happening. i.e. more likely a USB 
> flash disk firmware bug than a controller bug (there are lots of 
> crappy USB flash drives out there).

The only way to tell for certain in some particular case (like yours) 
is to use a USB bus analyzer.  However you probably don't care too much 
about the cause, so long as you can fix it.  Have you tried using a 
different flash drive?

> The specific use case I refer to is with a flash drive embedded 
> inside a locked and closed chassis of a dedicated server. So, 
> anyone repluging it must know what they are doing anyway.

That's fine for you.  But once the code is in the kernel, it affects 
everybody -- including people who don't have dedicated servers with 
closed and locked chassis.

My personal opinion is that it's somewhat distasteful to add software
workarounds for problems caused by bad hardware, unless it's really
impractical to fix or replace the hardware.  But to each his own...

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ