> > http://bugzilla.kernel.org/show_bug.cgi?id=8424 - patch review
> This one is on Alan.
I think not - something horrible is happening in dma_alloc_coherent when
called from dmam_* with a non PCI device
Seems to be some kind of AMD64 specific DMA mapping bug ?
-
To unsubscribe from this list: s
On Thu, Aug 09, 2007 at 02:53:36PM +0100, Alan Cox wrote:
> > > http://bugzilla.kernel.org/show_bug.cgi?id=8424 - patch review
> > This one is on Alan.
>
> I think not - something horrible is happening in dma_alloc_coherent when
> called from dmam_* with a non PCI device
>
>
> Seems to be some k
> > Seems to be some kind of AMD64 specific DMA mapping bug ?
>
> I think it's dev->dma_mask == NULL. Clearly you're passing a non DMA
> able device to dma_alloc_coherent(). Which seems like a caller bug.
Ok - other archs seem to just return NULL in this case. If its your view
that dma_alloc_cohe
On Thu, Aug 09, 2007 at 06:21:01PM +0100, Alan Cox wrote:
> > > Seems to be some kind of AMD64 specific DMA mapping bug ?
> >
> > I think it's dev->dma_mask == NULL. Clearly you're passing a non DMA
> > able device to dma_alloc_coherent(). Which seems like a caller bug.
>
> Ok - other archs seem
> Someone must ask that caller library to DMA to/from that device
> in the first place. Whoever it is it is wrong.
No I disagree.
> Or perhaps you got the wrong device here? For ISA devices we
> traditionally used NULL. Or if you set up your own ISA devices
> (which I can't see a reason for but
On Thu, Aug 09, 2007 at 06:53:10PM +0100, Alan Cox wrote:
> > Or perhaps you got the wrong device here? For ISA devices we
> > traditionally used NULL. Or if you set up your own ISA devices
> > (which I can't see a reason for but there might be one I'm missing)
> > at least give them a dma mask.
On Thu, 2007-08-09 at 18:53 +0100, Alan Cox wrote:
> > Someone must ask that caller library to DMA to/from that device
> > in the first place. Whoever it is it is wrong.
>
> No I disagree.
I'm with Andi here ... you're fortunate that parisc has no working
IDE/SATA interface (or rather we have so
> Where does the device come from? What device is it?
At the higher level someone passed us a device and some mappings and
function methods and said "this is an IDE controller"
> Is that known already?
The core code has no idea or interest in where it came from.
> But at least on x86-64 the dev
> You cannot allocate a dma_coherent buffer without passing in the correct
> underlying device ... on parisc we'd explode trying to find the iommu to
> map through (some of our hw has more than one).
We do pass the correct underlying device. Then dma_alloc_coherent oopses
on x86_64 if you pass som
On Thu, 2007-08-09 at 23:37 +0100, Alan Cox wrote:
> > You cannot allocate a dma_coherent buffer without passing in the correct
> > underlying device ... on parisc we'd explode trying to find the iommu to
> > map through (some of our hw has more than one).
>
> We do pass the correct underlying dev
On Thu, Aug 09, 2007 at 11:34:58PM +0100, Alan Cox wrote:
> > Where does the device come from? What device is it?
>
> At the higher level someone passed us a device and some mappings and
> function methods and said "this is an IDE controller"
Ok you're stabbing in the dark. I guess more debugging
On Fri, 2007-08-10 at 00:17 +0100, Alan Cox wrote:
> > If the device you're passing has a NULL dma_mask pointer that means the
> > platform hasn't set it up correctly for dma ... and that's the
>
> Well it may not do DMA.
Unfortunately, I don't think we've considered that possibility in the
inte
> If the device you're passing has a NULL dma_mask pointer that means the
> platform hasn't set it up correctly for dma ... and that's the
Well it may not do DMA.
> underlying problem (although it's not necessarily a libata problem): you
> can't call dma_ operations on a device that hasn't been
I'll submit a patch to check this in my next batch.
But as James pointed out you'll likely need similar patches on other
architectures.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.k
> > At the higher level someone passed us a device and some mappings and
> > function methods and said "this is an IDE controller"
>
> Ok you're stabbing in the dark. I guess more debugging is needed.
Huh ?
> > > But at least on x86-64 the device is likely DMA capable. At least
> > > PCMCIA usua
> BTW unless I'm misreading the i386 code it'll not fail here, but
> allocate memory. Surely that will cause failures later if you
> rely on it failing? If you don't rely on it then changing x86-64
> will also not help you.
Eww that'll do strange things.
Ok so we do in fact need some kind of prop
BTW unless I'm misreading the i386 code it'll not fail here, but
allocate memory. Surely that will cause failures later if you
rely on it failing? If you don't rely on it then changing x86-64
will also not help you.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
t
> Not in non platform code, please ... somewhere on the Janitor's list is
> moving the dma_mask from the bus specific devices into the generic
> device ... when that happens this quantity will become u64 and they
> won't know what to do with the NULL check.
Ok filed for "kernel summit"
-
To unsub
On Fri, 2007-08-10 at 14:54 +0100, Alan Cox wrote:
> > > Ok so we do in fact need some kind of proper way to ask if a device is
> > > DMA capable ?
> >
> > Right now it seems to be (dev->dma_mask != NULL)
>
> I'll follow that path for now then
Not in non platform code, please ... somewhere on t
Alan Cox <[EMAIL PROTECTED]> writes:
> > BTW unless I'm misreading the i386 code it'll not fail here, but
> > allocate memory. Surely that will cause failures later if you
> > rely on it failing? If you don't rely on it then changing x86-64
> > will also not help you.
>
> Eww that'll do strange t
> > Ok so we do in fact need some kind of proper way to ask if a device is
> > DMA capable ?
>
> Right now it seems to be (dev->dma_mask != NULL)
I'll follow that path for now then
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED
> Surely we don't need to wait until then? This is the correct fix, isn't
> it? (Obviously I'll split it into a generic and a pcmcia specific piece
> if it looks OK to everyone).
>
> It sets the PCMCIA dma_mask up correctly and introduces a DMA_MASK_NONE
> (I prefer that to DMA_0BIT_MASK but I c
On Fri, 2007-08-10 at 17:58 +0100, Alan Cox wrote:
> > Not in non platform code, please ... somewhere on the Janitor's list is
> > moving the dma_mask from the bus specific devices into the generic
> > device ... when that happens this quantity will become u64 and they
> > won't know what to do wit
On Fri, 2007-08-10 at 22:27 +0200, Andi Kleen wrote:
> > Surely we don't need to wait until then? This is the correct fix, isn't
> > it? (Obviously I'll split it into a generic and a pcmcia specific piece
> > if it looks OK to everyone).
> >
> > It sets the PCMCIA dma_mask up correctly and intro
24 matches
Mail list logo
