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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 23 Nov 2009 19:54:50 +0100
From:	Jan Kara <jack@...e.cz>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Jan Kara <jack@...e.cz>, tmhikaru@...il.com,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
	Jens Axboe <axboe@...nel.dk>, linux-scsi@...r.kernel.org,
	linux-ext4@...r.kernel.org
Subject: Re: Weird I/O errors with USB hard drive not remounting filesystem
 readonly

On Mon 23-11-09 13:20:26, Alan Stern wrote:
> On Mon, 23 Nov 2009, Jan Kara wrote:
> 
> > On Mon 23-11-09 10:06:03, Alan Stern wrote:
> > > On Mon, 23 Nov 2009, Jan Kara wrote:
> > > 
> > > >   Yeah, from what you write, it looks like USB enclosure is at fault (or it
> > > > could still be your USB controller but I doubt it).  It's still a bit
> > > > bothering that the error reported by the drive was not properly propagated
> > > > up to VFS. Either it's some block layer retry/ignore magic that I missed or
> > > > we ignore errors from block layer in some place.
> > > 
> > > Is there any interest in tracking this down?  It's not hard to find out
> > > what low-level errors are being reported and to generate them on demand
> > > with an emulated USB disk drive.
> >   Well, if you could provide me with the patch, I could try to track down
> > why the errors aren't propagated... It would be interesting because if it's
> > not some retry logic in block layer, it's a bug in VFS ;).
> 
> I can't provide a patch without first knowing what the errors are.  The 
> way to find out is to use usbmon.  See Documentation/usb/usbmon.txt for 
> instructions.
  Ah, OK. The problem manifests itself as an error in SATA communication
(which in fact somehow happens over USB, but I don't really know the
details of mass storage over USB) so debugging USB would become actual only
if we found out it's really some bug in an usb stack. But so far the most
probable is just an error somewhere between the USB controller in the
enclosure and the drive itself. BTW: Is the data transferred over USB
checksummed?

									Honza
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ