Jeff Garzik wrote:
quoted text
> Ping...  sata_nv status is still a bit open for 2.6.24, and I would like 
> to move us forward a bit.
> 
> * Kuan's patch...  it has been confirmed (and is needed), correct?  can 
> someone work up a good patch for 2.6.24?  The only one I ever received 
> was badly word-wrapped, and at the time, Robert seemed uncertain of it, 
> so I waited.

I can get you one later today hopefully.

quoted text
> 
> * ADMA ATAPI 4GB issues...  playing tricks with the ordering of 
> allocations and DMA masks is just way too fragile.  We just cannot 
> guarantee that all allocators work that way.  The obvious solution to me 
> seems to be hardcoding the consistent DMA mask to 32-bit, but using 
> 64-bit for regular dma mask if-and-only-if ADMA is enabled.

That's not enough to fix the problem since there's issues with actual 
transfer data being allocated above 4GB as well, not just the consistent 
  allocations (it appears that blk_queue_bounce_limit setting to 32-bit 
doesn't prevent this on x86_64). Either we play some funky games with 
changing the DMA mask of the entire device to 32-bit if either port is 
in ATAPI mode (which blew up when I tried it) or we add the ability to 
set the DMA mask independently on each port (like by setting the mask on 
the SCSI device and using that for DMA mapping instead) which requires 
core changes.

quoted text
> 
> * it sure seems like there are other open sata_nv ADMA issues -- can we 
> hard-confirm or deny this?  bugzilla wasn't very helpful for me.  It 
> doesn't seem like we can disable ADMA (to solve those issues) and get 
> enough test time in (which is what I said a week (or more?) ago too...)

The NCQ/non-NCQ command switching issue is still hitting some people 
(last I heard Kuan was looking into this), also there's a hotplug issue 
that Tejun reported..

quoted text
> 
> It seems like we should be able to tackle the first two issues promptly, 
> at least.
> 
>     Jeff
> 
> 
> 
> 
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/