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]
Message-Id: <1163498891.3005.11.camel@de-c-l-110.nero-de.internal>
Date:	Tue, 14 Nov 2006 11:08:11 +0100
From:	Mathieu Fluhr <mfluhr@...o.com>
To:	Tejun Heo <htejun@...il.com>
Cc:	jgarzik@...ox.com, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: READ SCSI cmd seems to fail on SATA optical devices...

On Tue, 2006-11-14 at 11:02 +0900, Tejun Heo wrote:
> Hello, Mattieu Fluhr.
> 
> Mathieu Fluhr wrote:
> > The problem is that, on SATA devices controlled by libata, on some big
> > files (like for example a 600 MB file) the READ command seems to fail
> > and outputs garbage (not 1 or 2 bytes diff, but the whole buffer).
> >  -> This problem does not come out everytime, and each time on    
> >     different sectors.
> > 
> > Please note that:
> > - it is not chipset dependant (tested on nforce4 and sii3114)
> > - it is not medium or device dependant
> 
> Hmmm... Interesting.  So, you're reading the media by directly issuing 
> commands through the sg interface, right?  Can you please try the 
> followings?
> 
> * Try using /dev/srX or /dev/scdX device instead of /dev/sgX.  You can 
> use the command SG_IO but the code path is different, so it will help us 
> rule out sg bug.
> 
> * Perform rounds of read-verify test using standard block interface (ie. 
> simply opening /dev/srX and reading it).
I will try this and report the results.

> 
> [--snip--]
> > - When I force the bus type to be IDE, our software will then send ATA
> > commands. In this case, everything works like a charm. No errors at all.
> 
> What do you mean by 'sending ATA commands'?  libata exports all devices 
> as SCSI devices.  For ATA devices, you can use ATA passthrough but you 
> send CDBs to ATAPI devices anyway.
Inside our code, we first guess which the bus type of every device using
an INQUIRY cmd (0x12). 
- If the device appears to be a SCSI one, then we send "pure" SCSI CDBs
- For an IDE device, we do, as described in the Annex A of the MMC-5
spec, and pad each CDBs to 12 bytes.

So in the case of a READ CDB, we send 10 bytes if the device is a SCSI
one and 12 for IDE one.


> 
> Thanks.
> 

-
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