On Wed, 2007-05-23 at 20:38 +0100, Alan Cox wrote:
> On Wed, 23 May 2007 15:17:08 -0400
> "Salyzyn, Mark" <[EMAIL PROTECTED]> wrote:
>
> > The 31 bit limit for some of these cards is a problem, we currently only
> > do __GFP_DMA for bounce buffer sg elements allocated for user supplied
> >
On Wed, 2007-05-23 at 20:38 +0100, Alan Cox wrote:
On Wed, 23 May 2007 15:17:08 -0400
Salyzyn, Mark [EMAIL PROTECTED] wrote:
The 31 bit limit for some of these cards is a problem, we currently only
do __GFP_DMA for bounce buffer sg elements allocated for user supplied
references in
On Thu, 2007-05-24 at 10:22 -0700, Christoph Lameter wrote:
> On Thu, 24 May 2007, James Bottomley wrote:
>
> > The idea was basically to match an allocation to a device mask. I was
> > going to do a generic implementation (which would probably kmalloc,
> > check the physaddr and fall back to
On Thu, 24 May 2007, James Bottomley wrote:
> The idea was basically to match an allocation to a device mask. I was
> going to do a generic implementation (which would probably kmalloc,
> check the physaddr and fall back to GFP_DMA if we were unlucky) but
> allow the architectures to override.
On Thu, 2007-05-24 at 10:00 -0700, Christoph Lameter wrote:
> On Thu, 24 May 2007, James Bottomley wrote:
>
> > > Going to ensure that we have a 31 bit (not 32 bit) physical address?
> >
> > No, unfortunately. Implementing kmalloc_mask() and kmalloc_dev() was
> > something I said I'd do ...
On Thu, 24 May 2007, James Bottomley wrote:
> > Going to ensure that we have a 31 bit (not 32 bit) physical address?
>
> No, unfortunately. Implementing kmalloc_mask() and kmalloc_dev() was
> something I said I'd do ... about two years ago.
Tell me more about these ideas.
-
To unsubscribe
On Thu, 24 May 2007, Salyzyn, Mark wrote:
> So, is the sequence:
>
> p = kmalloc(upsg->sg[i].count,GFP_KERNEL);
> . . .
> addr = pci_map_single(dev->pdev, p, upsg->sg[i].count,
> data_dir);
>
> Going to ensure that we have a 31 bit (not 32 bit) physical address?
Only if you
On Thu, 2007-05-24 at 09:24 -0400, Salyzyn, Mark wrote:
> So, is the sequence:
>
> p = kmalloc(upsg->sg[i].count,GFP_KERNEL);
> . . .
> addr = pci_map_single(dev->pdev, p, upsg->sg[i].count,
> data_dir);
>
> Going to ensure that we have a 31 bit (not 32 bit) physical address?
Cc: Bernhard Walle; [EMAIL PROTECTED]; Andrew
> Morton; linux-kernel@vger.kernel.org; James Bottomley
> Subject: Re: [PATCH] [scsi] Remove __GFP_DMA
>
>
> On 5/23/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > On Mon, 21 May 2007, Bernhard Walle wrote:
>
> > That didn't used to work right on the AMD boards when I tried it last as
> > we ended up with a buffer that was mapped by the IOMMU for some reason
> > and that was not below 2GB.
>
> The physical address you mean? If that is still happening then it needs
> to get fixed. The allocation
That didn't used to work right on the AMD boards when I tried it last as
we ended up with a buffer that was mapped by the IOMMU for some reason
and that was not below 2GB.
The physical address you mean? If that is still happening then it needs
to get fixed. The allocation should not
PROTECTED]; Andrew
Morton; linux-kernel@vger.kernel.org; James Bottomley
Subject: Re: [PATCH] [scsi] Remove __GFP_DMA
On 5/23/07, Christoph Lameter [EMAIL PROTECTED] wrote:
On Mon, 21 May 2007, Bernhard Walle wrote:
[PATCH] [scsi] Remove __GFP_DMA
After
On Thu, 2007-05-24 at 09:24 -0400, Salyzyn, Mark wrote:
So, is the sequence:
p = kmalloc(upsg-sg[i].count,GFP_KERNEL);
. . .
addr = pci_map_single(dev-pdev, p, upsg-sg[i].count,
data_dir);
Going to ensure that we have a 31 bit (not 32 bit) physical address?
No,
On Thu, 24 May 2007, Salyzyn, Mark wrote:
So, is the sequence:
p = kmalloc(upsg-sg[i].count,GFP_KERNEL);
. . .
addr = pci_map_single(dev-pdev, p, upsg-sg[i].count,
data_dir);
Going to ensure that we have a 31 bit (not 32 bit) physical address?
Only if you have less
On Thu, 24 May 2007, James Bottomley wrote:
Going to ensure that we have a 31 bit (not 32 bit) physical address?
No, unfortunately. Implementing kmalloc_mask() and kmalloc_dev() was
something I said I'd do ... about two years ago.
Tell me more about these ideas.
-
To unsubscribe from
On Thu, 2007-05-24 at 10:00 -0700, Christoph Lameter wrote:
On Thu, 24 May 2007, James Bottomley wrote:
Going to ensure that we have a 31 bit (not 32 bit) physical address?
No, unfortunately. Implementing kmalloc_mask() and kmalloc_dev() was
something I said I'd do ... about two
On Thu, 24 May 2007, James Bottomley wrote:
The idea was basically to match an allocation to a device mask. I was
going to do a generic implementation (which would probably kmalloc,
check the physaddr and fall back to GFP_DMA if we were unlucky) but
allow the architectures to override.
On Thu, 2007-05-24 at 10:22 -0700, Christoph Lameter wrote:
On Thu, 24 May 2007, James Bottomley wrote:
The idea was basically to match an allocation to a device mask. I was
going to do a generic implementation (which would probably kmalloc,
check the physaddr and fall back to GFP_DMA if
Alan Cox wrote:
On Wed, 23 May 2007 15:17:08 -0400
"Salyzyn, Mark" <[EMAIL PROTECTED]> wrote:
The 31 bit limit for some of these cards is a problem, we currently only
do __GFP_DMA for bounce buffer sg elements allocated for user supplied
references in ioctls.
I figure we should be using
On Wed, 23 May 2007 15:17:08 -0400
"Salyzyn, Mark" <[EMAIL PROTECTED]> wrote:
> The 31 bit limit for some of these cards is a problem, we currently only
> do __GFP_DMA for bounce buffer sg elements allocated for user supplied
> references in ioctls.
>
> I figure we should be using
; Bernhard Walle; [EMAIL PROTECTED];
Andrew Morton; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [scsi] Remove __GFP_DMA
On Wed, 2007-05-23 at 10:41 +0800, Aubrey Li wrote:
> On 5/23/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > On Mon, 21 May 2007, Bernhard Walle wrote:
&
On Wed, 2007-05-23 at 11:55 -0400, Robert P. J. Day wrote:
> On Wed, 23 May 2007, James Bottomley wrote:
>
> > I'll defer to Mark on this one. However, please remember that you
> > can't just blindly remove GFP_DMA ... there are some cards which
> > require it.
> >
> > Aacraid is one example ...
On Wed, 23 May 2007, James Bottomley wrote:
> I'll defer to Mark on this one. However, please remember that you
> can't just blindly remove GFP_DMA ... there are some cards which
> require it.
>
> Aacraid is one example ... it has a set of cards that can only DMA
> to 31 bits. For them, the
On Wed, 2007-05-23 at 10:41 +0800, Aubrey Li wrote:
> On 5/23/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > On Mon, 21 May 2007, Bernhard Walle wrote:
> >
> > > [PATCH] [scsi] Remove __GFP_DMA
> > >
> > > After 821de3a27bf33f11ec878562577c58
On Wed, 2007-05-23 at 10:41 +0800, Aubrey Li wrote:
On 5/23/07, Christoph Lameter [EMAIL PROTECTED] wrote:
On Mon, 21 May 2007, Bernhard Walle wrote:
[PATCH] [scsi] Remove __GFP_DMA
After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to
alloate a
DMA buffer any
On Wed, 23 May 2007, James Bottomley wrote:
I'll defer to Mark on this one. However, please remember that you
can't just blindly remove GFP_DMA ... there are some cards which
require it.
Aacraid is one example ... it has a set of cards that can only DMA
to 31 bits. For them, the GFP_DMA
On Wed, 2007-05-23 at 11:55 -0400, Robert P. J. Day wrote:
On Wed, 23 May 2007, James Bottomley wrote:
I'll defer to Mark on this one. However, please remember that you
can't just blindly remove GFP_DMA ... there are some cards which
require it.
Aacraid is one example ... it has a
; Bernhard Walle; [EMAIL PROTECTED];
Andrew Morton; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [scsi] Remove __GFP_DMA
On Wed, 2007-05-23 at 10:41 +0800, Aubrey Li wrote:
On 5/23/07, Christoph Lameter [EMAIL PROTECTED] wrote:
On Mon, 21 May 2007, Bernhard Walle wrote:
[PATCH] [scsi
On Wed, 23 May 2007 15:17:08 -0400
Salyzyn, Mark [EMAIL PROTECTED] wrote:
The 31 bit limit for some of these cards is a problem, we currently only
do __GFP_DMA for bounce buffer sg elements allocated for user supplied
references in ioctls.
I figure we should be using pci_alloc_consistent
Alan Cox wrote:
On Wed, 23 May 2007 15:17:08 -0400
Salyzyn, Mark [EMAIL PROTECTED] wrote:
The 31 bit limit for some of these cards is a problem, we currently only
do __GFP_DMA for bounce buffer sg elements allocated for user supplied
references in ioctls.
I figure we should be using
On 5/23/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
On Mon, 21 May 2007, Bernhard Walle wrote:
> [PATCH] [scsi] Remove __GFP_DMA
>
> After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate
a
> DMA buffer any more in sd.c.
>
> Signed-off-by
On Mon, 21 May 2007, Bernhard Walle wrote:
> [PATCH] [scsi] Remove __GFP_DMA
>
> After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate
> a
> DMA buffer any more in sd.c.
>
> Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
Great that avo
On Mon, 21 May 2007, Bernhard Walle wrote:
[PATCH] [scsi] Remove __GFP_DMA
After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate
a
DMA buffer any more in sd.c.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
Great that avoids a DMA kmalloc slab. Any other
On 5/23/07, Christoph Lameter [EMAIL PROTECTED] wrote:
On Mon, 21 May 2007, Bernhard Walle wrote:
[PATCH] [scsi] Remove __GFP_DMA
After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate
a
DMA buffer any more in sd.c.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED
[PATCH] [scsi] Remove __GFP_DMA
After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate a
DMA buffer any more in sd.c.
Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
---
drivers/scsi/sd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scs
[PATCH] [scsi] Remove __GFP_DMA
After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate a
DMA buffer any more in sd.c.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
---
drivers/scsi/sd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/sd.c
36 matches
Mail list logo
