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
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
Robert Hancock wrote:
>@@ -1153,6 +1164,15 @@
> pp->notifier_clear_block = pp->gen_block +
> NV_ADMA_NOTIFIER_CLEAR + (4 * ap->port_no);
>
>+ /* Now that the legacy PRD and padding buffer are allocated we can
>+ safely raise the DMA mask to allocate the CPB/APRD
Robert Hancock wrote:
@@ -1153,6 +1164,15 @@
pp-notifier_clear_block = pp-gen_block +
NV_ADMA_NOTIFIER_CLEAR + (4 * ap-port_no);
+ /* Now that the legacy PRD and padding buffer are allocated we can
+ safely raise the DMA mask to allocate the CPB/APRD table.
+
>ata1.00: XXX DMA address 202275000 is above 32bit
Tejun-I find the allocation always above 32bit with the following tests
-
1) kernel-2.6.24-rc5 + the 32 bit limiting patch that you provided in a
previous posting.
2) vanilla-2.6.24-rc5.
But I don't find the DMA allocation above 32bit in the
The dmesg snippet with the patched kernel. This does not contain my
patch.
Linux version 2.6.24-rc5-default ([EMAIL PROTECTED]) (gcc version 4.1.2
20070115 (prerelease) (SUSE Linux)) #2 SMP Thu Dec 13 15:38:25 IST 2007
Command line:
The dmesg snippet with the patched kernel. This does not contain my
patch.
Linux version 2.6.24-rc5-default ([EMAIL PROTECTED]) (gcc version 4.1.2
20070115 (prerelease) (SUSE Linux)) #2 SMP Thu Dec 13 15:38:25 IST 2007
Command line:
ata1.00: XXX DMA address 202275000 is above 32bit
Tejun-I find the allocation always above 32bit with the following tests
-
1) kernel-2.6.24-rc5 + the 32 bit limiting patch that you provided in a
previous posting.
2) vanilla-2.6.24-rc5.
But I don't find the DMA allocation above 32bit in the
Please apply the attached patch and try to use cdrom w/o specifying any
parameter and report kernel log.
Thanks.
--
tejun
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4753a18..acaa8b8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4537,6
Hello,
[EMAIL PROTECTED] wrote:
> --- sata_nv.c.orig2007-12-17 21:08:12.0 +0530
> +++ sata_nv.c 2007-12-17 21:08:25.0 +0530
> @@ -2407,6 +2407,12 @@
> type = GENERIC;
> }
>
> + /* set 64bit dma masks, may fail */
> + if (type == ADMA) {
>
I found that the patch Robert has provided hasn't gone into 2.6.24-rc5 so maybe
it is not working.
At the same time I did apply a small patch to 2.6.24-rc5 that seems to fix the
issue.
I feel this could just be added to 2.6.24-rc5 without Robert's patch because of
Jeff Garzik's" sata_nv:
Hello,
I am seeing that this doesn't fix a Dell PowerEdge T105 which has the CK804
chipset.
This system has a "HL-DT-ST" DVD-ROM (See dmesg with this posting) attached to
the sata ports and has 8Gb physical memory.
The SATA DVD rom gets detected but any I/O like dd or mount is not successful.
Hello,
I am seeing that this doesn't fix a Dell PowerEdge T105 which has the CK804
chipset.
This system has a "HL-DT-ST" DVD-ROM (See dmesg with this posting) attached to
the sata ports and has 8Gb physical memory.
The SATA DVD rom gets detected but any I/O like dd or mount is not successful.
Hello,
I am seeing that this doesn't fix a Dell PowerEdge T105 which has the CK804
chipset.
This system has a HL-DT-ST DVD-ROM (See dmesg with this posting) attached to
the sata ports and has 8Gb physical memory.
The SATA DVD rom gets detected but any I/O like dd or mount is not successful.
Hello,
I am seeing that this doesn't fix a Dell PowerEdge T105 which has the CK804
chipset.
This system has a HL-DT-ST DVD-ROM (See dmesg with this posting) attached to
the sata ports and has 8Gb physical memory.
The SATA DVD rom gets detected but any I/O like dd or mount is not successful.
I found that the patch Robert has provided hasn't gone into 2.6.24-rc5 so maybe
it is not working.
At the same time I did apply a small patch to 2.6.24-rc5 that seems to fix the
issue.
I feel this could just be added to 2.6.24-rc5 without Robert's patch because of
Jeff Garzik's sata_nv: don't
Hello,
[EMAIL PROTECTED] wrote:
--- sata_nv.c.orig2007-12-17 21:08:12.0 +0530
+++ sata_nv.c 2007-12-17 21:08:25.0 +0530
@@ -2407,6 +2407,12 @@
type = GENERIC;
}
+ /* set 64bit dma masks, may fail */
+ if (type == ADMA) {
+
Please apply the attached patch and try to use cdrom w/o specifying any
parameter and report kernel log.
Thanks.
--
tejun
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4753a18..acaa8b8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4537,6
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
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
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
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
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
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:
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
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
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
Sent: 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 ex
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
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 controll
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
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
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
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
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
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
: 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
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
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
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
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,
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
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
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
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
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
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:
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
Mark Lord wrote:
> 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
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:
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
Mark Lord wrote:
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
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
Robert Hancock wrote:
> Tejun Heo wrote:
>> How about always initialize DMA mask to ATA_DMA_MASK regardless of ADMA
>> mode such that PRD and PAD buffers are always accessible by register
>> mode and just raising PCI dma mask and queue bounce limit if ADMA mode
>> is active?
>
> Could be done..
Tejun Heo wrote:
How about always initialize DMA mask to ATA_DMA_MASK regardless of ADMA
mode such that PRD and PAD buffers are always accessible by register
mode and just raising PCI dma mask and queue bounce limit if ADMA mode
is active?
Could be done.. but, I don't want to constrain the
Hello, Robert.
Robert Hancock wrote:
> @@ -747,11 +748,29 @@
> on the port. */
> adma_enable = 0;
> nv_adma_register_mode(ap);
> + if (!(pp->flags & NV_ADMA_ATAPI_SETUP_COMPLETE)) {
> + /* Transitioning to legacy mode.
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA mode
on systems with memory located above 4GB. We need to make sure that the legacy
PRD table and padding buffer are appropriately allocated according to the
DMA mask requirements of the current operating mode (ADMA or
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA mode
on systems with memory located above 4GB. We need to make sure that the legacy
PRD table and padding buffer are appropriately allocated according to the
DMA mask requirements of the current operating mode (ADMA or
Hello, Robert.
Robert Hancock wrote:
@@ -747,11 +748,29 @@
on the port. */
adma_enable = 0;
nv_adma_register_mode(ap);
+ if (!(pp-flags NV_ADMA_ATAPI_SETUP_COMPLETE)) {
+ /* Transitioning to legacy mode. Free the
Tejun Heo wrote:
How about always initialize DMA mask to ATA_DMA_MASK regardless of ADMA
mode such that PRD and PAD buffers are always accessible by register
mode and just raising PCI dma mask and queue bounce limit if ADMA mode
is active?
Could be done.. but, I don't want to constrain the
Robert Hancock wrote:
Tejun Heo wrote:
How about always initialize DMA mask to ATA_DMA_MASK regardless of ADMA
mode such that PRD and PAD buffers are always accessible by register
mode and just raising PCI dma mask and queue bounce limit if ADMA mode
is active?
Could be done.. but, I don't
70 matches
Mail list logo
