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
44 matches
Mail list logo
