linux-kernel - Re: READ SCSI cmd seems to fail on SATA optical devices...

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: <455B3D99.8040705@cfl.rr.com>
Date:	Wed, 15 Nov 2006 11:17:29 -0500
From:	Phillip Susi <psusi@....rr.com>
To:	Tejun Heo <htejun@...il.com>
CC:	Mathieu Fluhr <mfluhr@...o.com>,
	Arjan van de Ven <arjan@...radead.org>, 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...

Tejun Heo wrote:
>> The patch _seems_ to solve my problem. I am just really astonished when
>> I read the diff file :D. Can I expect that it will be merged to the
>> official kernel sources ?
> 
> It seems that some devices choke when the bytes after CDB contain 
> garbage.  I seem to recall that I read somewhere ATAPI device require 
> left command bytes cleared to zero but I can't find it anywhere now. 
> Maybe I'm just imagining.  Anyways, yeah, I'll push it to upstream.
> 

The original patch memsets the entire buffer only to copy over most of 
it right after.  Could you amend the patch so that it memcpys first, 
then memsets only the remainder of the buffer?  No sense wasting cpu 
cycles.

-
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/