Robert Hancock wrote:
Jeff Garzik wrote:
Robert Hancock wrote:
This fixes some problems with ATAPI devices on nForce4 controllers in
ADMA mode
on systems with memory located above 4GB. We need to delay setting
the 64-bit
DMA mask until the PRD table and padding buffer are allocated so that
Jeff Garzik wrote:
Robert Hancock wrote:
This fixes some problems with ATAPI devices on nForce4 controllers in
ADMA mode
on systems with memory located above 4GB. We need to delay setting the
64-bit
DMA mask until the PRD table and padding buffer are allocated so that
they don't
get
Robert Hancock wrote:
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA mode
on systems with memory located above 4GB. We need to delay setting the 64-bit
DMA mask until the PRD table and padding buffer are allocated so that they don't
get allocated above 4GB and break
Jeff Garzik wrote:
Robert Hancock wrote:
This fixes some problems with ATAPI devices on nForce4 controllers in
ADMA mode
on systems with memory located above 4GB. We need to delay setting the
64-bit
DMA mask until the PRD table and padding buffer are allocated so that
they don't
get
Robert Hancock wrote:
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA mode
on systems with memory located above 4GB. We need to delay setting the 64-bit
DMA mask until the PRD table and padding buffer are allocated so that they don't
get allocated above 4GB and break
Mark Lord wrote:
Morrison, Tom wrote:
I am hopeful that the sata_mv has this bug (I proved that the
problem I was experiencing was due to the sata_mv driver with 3.75Gig
or more of memory)...
I am on vacation for a week or more ...or I'd tell you today
if it did have this bug!
..
Yeah, I
Jeff Garzik wrote:
Robert Hancock wrote:
Based on a quick look at sata_mv it appears it sets a 64-bit DMA mask
unconditionally, but for non-ATA_PROT_DMA commands (which includes all
ATAPI), it just falls back to ata_qc_issue_prot which issues via the
legacy SFF interface and can only handle
Robert Hancock wrote:
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA
mode
on systems with memory located above 4GB. We need to delay setting the 64-bit
DMA mask until the PRD table and padding buffer are allocated so that they
don't
get allocated above 4GB and
Robert Hancock wrote:
Based on a quick look at sata_mv it appears it sets a 64-bit DMA mask
unconditionally, but for non-ATA_PROT_DMA commands (which includes all
ATAPI), it just falls back to ata_qc_issue_prot which issues via the
legacy SFF interface and can only handle 32-bit addressing. So
Morrison, Tom wrote:
I am hopeful that the sata_mv has this bug (I proved that the
problem I was experiencing was due to the sata_mv driver
with 3.75Gig or more of memory)...
I am on vacation for a week or more ...or I'd tell you today
if it did have this bug!
..
Yeah, I kind of had your
Jeff Garzik wrote:
Robert Hancock wrote:
Based on a quick look at sata_mv it appears it sets a 64-bit DMA mask
unconditionally, but for non-ATA_PROT_DMA commands (which includes all
ATAPI), it just falls back to ata_qc_issue_prot which issues via the
legacy SFF interface and can only handle
PROTECTED] on behalf of Mark Lord
Sent: Fri 11/23/2007 10:22 AM
To: Robert Hancock
Cc: linux-kernel; ide; Jeff Garzik; Tejun Heo
Subject: Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Robert Hancock wrote:
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA
: Fri 11/23/2007 12:46 PM
To: Morrison, Tom
Cc: Robert Hancock; linux-kernel; ide; Jeff Garzik; Tejun Heo
Subject: Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Morrison, Tom wrote:
I am hopeful that the sata_mv has this bug (I proved that the
problem I was experiencing
Mark wrote:
Yeah, I kind of had your reports in mind when I asked that. :)
On a related note, I now have lots of Marvell (sata_mv) hardware here,
and an Intel CPU/chipset box with physical RAM above the 4GB boundary.
Morrison, Tom wrote:
Yes, I believe that - otherwise, this problem would
Tejun Heo wrote:
Hello, Robert.
Robert Hancock wrote:
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA
mode on systems with memory located above 4GB. We need to delay setting the
64-bit DMA mask until the PRD table and padding buffer are allocated so that
they don't
Robert Hancock wrote:
+/* Ensure DMA mask is set to 32-bit before allocating legacy PRD
and
+ pad buffers */
+pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
+pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32));
[--snip--]
+pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
+
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA mode
on systems with memory located above 4GB. We need to delay setting the 64-bit
DMA mask until the PRD table and padding buffer are allocated so that they don't
get allocated above 4GB and break legacy mode (which is
Le mardi 20 novembre 2007 à 18:56 -0600, Robert Hancock a écrit :
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA
mode on systems with memory located above 4GB. We need to delay setting the
64-bit DMA mask until the PRD table and padding buffer are allocated so that
Vincent Fortier wrote:
Le mardi 20 novembre 2007 à 18:56 -0600, Robert Hancock a écrit :
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA
mode on systems with memory located above 4GB. We need to delay setting the
64-bit DMA mask until the PRD table and padding buffer
Hello, Robert.
Robert Hancock wrote:
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA
mode on systems with memory located above 4GB. We need to delay setting the
64-bit DMA mask until the PRD table and padding buffer are allocated so that
they don't get allocated
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA
mode on systems with memory located above 4GB. We need to delay setting the
64-bit DMA mask until the PRD table and padding buffer are allocated so that
they don't get allocated above 4GB and break legacy mode (which is
Tejun Heo wrote:
Robert Hancock wrote:
Tejun Heo wrote:
..
Yes, it should likely do something with these return values. Though
theoretically it shouldn't fail, since the DMA mask is either 32-bit,
which shouldn't fail, or one that was successfully set before. Also I
don't think the SCSI layer
Tejun Heo wrote:
Could be done.. but, I don't want to constrain the ADMA APRD/CPB area in
that way (there are some dual-socket Opteron boxes with this controller,
forcing an allocation below 4GB for this could force a non-optimal node
allocation I think..) To do this I'd have to raise the mask
23 matches
Mail list logo
