On Tue, 16 Jan 2007 17:45:56 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Alan wrote:
> >> The other oddity I've been seeing is that I am getting zero length
> >> commands,
> >> such as TEST_UNIT_READY with a dma_dir of DMA_FROM_DEVICE. Shouldn't this
> >> be
> >> DMA_NONE? I'm still tracking
Brian King wrote:
> James Bottomley wrote:
>> On Tue, 2007-01-16 at 17:45 -0500, Jeff Garzik wrote:
>>> Tejun recently updated the CDB length areas of the code. I bet it's
>>> either a bug somewhere in there, or the SCSI layer isn't passing us
>>> proper command lengths in a case or two.
>>>
>>> A
On Tue, 2007-01-16 at 17:17 -0600, Brian King wrote:
> I think we are OK here since atapi_xlate is only ever called by
> ata_scsi_translate.
True. But can you tell me where it gets set in ata_scsi_translate if
sc_data_direction is DMA_NONE ...
James
-
To unsubscribe from this list: send the li
> The other oddity I've been seeing is that I am getting zero length commands,
> such as TEST_UNIT_READY with a dma_dir of DMA_FROM_DEVICE. Shouldn't this be
> DMA_NONE? I'm still tracking this down.
I was looking at a PATA trace that was looking the same 2 days ago and
couldn't figure what was go
James Bottomley wrote:
> On Tue, 2007-01-16 at 17:45 -0500, Jeff Garzik wrote:
>> Tejun recently updated the CDB length areas of the code. I bet it's
>> either a bug somewhere in there, or the SCSI layer isn't passing us
>> proper command lengths in a case or two.
>>
>> Additional traces (starting
On Tue, 2007-01-16 at 17:45 -0500, Jeff Garzik wrote:
> Tejun recently updated the CDB length areas of the code. I bet it's
> either a bug somewhere in there, or the SCSI layer isn't passing us
> proper command lengths in a case or two.
>
> Additional traces (starting with SCSI command, before
Alan wrote:
The other oddity I've been seeing is that I am getting zero length commands,
such as TEST_UNIT_READY with a dma_dir of DMA_FROM_DEVICE. Shouldn't this be
DMA_NONE? I'm still tracking this down.
I was looking at a PATA trace that was looking the same 2 days ago and
couldn't figure wh
I'm currently debugging some problems with SATA on ipr and figured I would
give a heads up. The problems include overlength errors and data corruption.
Basically SATA on ipr is completely broken in its current state.
>From what I have found so far, it looks like due to some libata changes
made rece
8 matches
Mail list logo
