LKML Archive on
help / color / mirror / Atom feed
From: James Bottomley <>
To: Robert Hancock <>
Cc: Alan Cox <>, Alexander <>,, ide <>,
	Jeff Garzik <>, Tejun Heo <>
Subject: Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI]	Crash	on	accessing DVD-RAM
Date: Mon, 14 Jan 2008 20:23:43 -0600	[thread overview]
Message-ID: <1200363823.3159.107.camel@localhost.localdomain> (raw)
In-Reply-To: <>

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.


  reply	other threads:[~2008-01-15  2:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2008-01-11  5:46 ` Robert Hancock
2008-01-12  8:25   ` Alexander
2008-01-12 19:25     ` Robert Hancock
2008-01-12 20:35       ` James Bottomley
2008-01-12 23:04         ` Robert Hancock
2008-01-12 23:27           ` James Bottomley
2008-01-13  1:38             ` Robert Hancock
2008-01-13  3:12               ` James Bottomley
2008-01-13 13:33               ` Alan Cox
2008-01-13 15:38                 ` James Bottomley
2008-01-13 16:29                   ` Alan Cox
2008-01-13 16:51                     ` James Bottomley
2008-01-15  1:41                       ` Robert Hancock
2008-01-15  2:23                         ` James Bottomley [this message]
2008-02-01  0:09 ` Robert Hancock
2008-02-01  9:59   ` Alexander
2008-02-04  8:29   ` Alexander
2008-01-10 13:44 Alexander

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1200363823.3159.107.camel@localhost.localdomain \ \ \ \ \ \ \ \ \
    --subject='Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI]	Crash	on	accessing DVD-RAM' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).