Re: PROBLEM REMAINS: [sata_nv ADMA breaksATAPI] Crash on accessing DVD-RAM

[James Bottomley]

On Mon, 2008-01-14 at 19:41 -0600, Robert Hancock wrote:
> James Bottomley wrote:
> > On Sun, 2008-01-13 at 16:29 +0000, Alan Cox wrote:
> >>> Yes, I concur for the short term.  The other two possible courses of
> >>> action either involve long discussions (the different device one) or
> >>> you'll never quite be sure you got all the paths (the GFP_DMA32 one).
> >>> At least with this one, you know everything will work.
> >> The different device one is tricky because the PCI layer is involved in
> >> mapping on some systems so you can't just magic up a platform device for
> >> it. Putting a mask on the block queue might perhaps work as a model
> >> which avoids breaking stuff by suprise, with the device left at 32bit
> >> masking.
> > 
> > Actually, you might be able to ... that's why I'm suggesting it.  There
> > are two pieces of information the arch layer needs to know:  what is the
> > dma_mask and where is the iommu/bridge/whatever.  When we went to the
> > generic dma_map_ API on parisc, we found you simply get the one from
> > struct device and for the other you walk up the device tree until you
> > find what you're looking for.
> > 
> > I'm not suggesting we invent a dummy pci_device ... I'm suggesting we
> > dma_map on the existing scsi_device, which is properly parented to the
> > pci_device.  The problem with this approach will be any architecture
> > which blindly expects dma_map converts to pci_dma_map; however, I'm not
> > sure we have any of those left.
> 
> I've tried the dumb solution of setting the mask on the PCI device (for 
> both ports) whenever an ATAPI device is detected, and ran into problems 
> with that. If we really need to keep the block queue bounce limit and 
> DMA mask the same, then we then have to set the bounce limit on both 
> ports as well. If you blindly do that from slave_config, though, then 
> you blow up since on the first port's initial slave_config the block 
> queue for the second port isn't allocated yet, so you'd have to detect 
> that case somehow. And if it's done via hotplug after the other port is 
> already in use, it'll be changing the limits on a port that's in active 
> use, which seems like it could be a bit racy.
> 
> So, any ideas? Maybe using the separate struct device is the easiest 
> solution, if it'll work..

Right, and the separate struct device exists already in the
scsi_device ... the problem currently is that this isn't the device we
map with, but it could easily become so ... provided the architectures
support it.

This isn't a quick fix solution ... it will involve quite a bit of
device use rethreading through both scsi and ata, so it might be wise to
get linux-arch buy in first.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/