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 introduces a
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
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 the Janitor's
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 things.
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]
More
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 can
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 with the
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 kind of
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
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 to just
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. Then it
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 few
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 device
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 some
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 device.
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 is
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
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 proper
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
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
Hi Tejun, Alan, Jeff,
This is open bug list for SATA subsystem. It has more items than other
subsystems, but mainly because this is such a hot technology now and
so much work is being done in this area. Needless to say It is very
well maintained and exemplary for some other areas that are not
Natalie Protasevich wrote:
Hi Tejun, Alan, Jeff,
This is open bug list for SATA subsystem. It has more items than other
...
http://bugzilla.kernel.org/show_bug.cgi?id=7693
http://bugzilla.kernel.org/show_bug.cgi?id=8738 adaptec and sata bad interaction
Hello, Natalie.
Natalie Protasevich wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=7693
This bug isn't related to libata in anyway. It's Can't use radeonfb
with dvi port on a Samsung SyncMaster 204B (1600x1200).
http://bugzilla.kernel.org/show_bug.cgi?id=8738 adaptec and sata bad
On Wed, 2007-08-08 at 15:31 -0700, Natalie Protasevich wrote:
Hi Tejun, Alan, Jeff,
This is open bug list for SATA subsystem. It has more items than other
subsystems, but mainly because this is such a hot technology now and
so much work is being done in this area. Needless to say It is very
25 matches
Mail list logo
