Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-28 Thread Robert Hancock 

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 
they don't

get allocated above 4GB and break legacy mode (which is needed for ATAPI
devices).

Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>


This is a bit nasty :/

I would consider setting the consistent DMA mask to 32-bit, and 
setting the overall mask to 64-bit.


Seems like that would solve the problem?


The issue with that is that it would also constrain the ADMA CPB/PRD 
table allocation to 32-bit, which I'd rather avoid having to do. There 
are dual-socket Opteron boxes like HP xw9300 that use this controller, 
and limiting the allocation to 32-bit could force a non-optimal node 
allocation for the table memory.


These type of devices really want a version of dma_alloc_coherent that 
allows overriding the DMA mask for specific allocations to make this 
cleaner. I'm sure this isn't the only device that has different DMA mask 
requirements for different consistent memory allocations..


This patch does has the advantage of being confirmed to fix the 
reporter's problem (https://bugzilla.redhat.com/show_bug.cgi?id=351451) 
which there's something to be said for this late in the .24-rc series..




Also, does this need to be rebased on top of what I just pushed upstream?


It don't think so.. this change is independent from the "sata_nv: don't 
use legacy DMA in ADMA mode (v3)" patch you just merged.


This bug fix is still outstanding. I haven't heard any more comments on 
this one recently..


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-28 Thread Robert Hancock 

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 
they don't

get allocated above 4GB and break legacy mode (which is needed for ATAPI
devices).

Signed-off-by: Robert Hancock [EMAIL PROTECTED]


This is a bit nasty :/

I would consider setting the consistent DMA mask to 32-bit, and 
setting the overall mask to 64-bit.


Seems like that would solve the problem?


The issue with that is that it would also constrain the ADMA CPB/PRD 
table allocation to 32-bit, which I'd rather avoid having to do. There 
are dual-socket Opteron boxes like HP xw9300 that use this controller, 
and limiting the allocation to 32-bit could force a non-optimal node 
allocation for the table memory.


These type of devices really want a version of dma_alloc_coherent that 
allows overriding the DMA mask for specific allocations to make this 
cleaner. I'm sure this isn't the only device that has different DMA mask 
requirements for different consistent memory allocations..


This patch does has the advantage of being confirmed to fix the 
reporter's problem (https://bugzilla.redhat.com/show_bug.cgi?id=351451) 
which there's something to be said for this late in the .24-rc series..




Also, does this need to be rebased on top of what I just pushed upstream?


It don't think so.. this change is independent from the sata_nv: don't 
use legacy DMA in ADMA mode (v3) patch you just merged.


This bug fix is still outstanding. I haven't heard any more comments on 
this one recently..


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-20 Thread shyam_iyer 
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.
>+ These are allowed to fail since we store the value that ends up
>+ being used to set as the bounce limit in slave_config later if
>+ needed. */
>+  pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
>+  pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
>+  pp->adma_dma_mask = *dev->dma_mask;
>+
>   mem = dmam_alloc_coherent(dev, NV_ADMA_PORT_PRIV_DMA_SZ,
> _dma, GFP_KERNEL);


This causes my DMA memory to always be above 4GB no matter how much I delay the 
setting of the 64bit DMA mask. I find that if I set the DMA mask as 32bit and 
not increase it to 64 bit at all then all my I/O to the DVD rom are fine. 

Jeff Garzik wrote:
>I would consider setting the consistent DMA mask to 32-bit, and setting 
>the overall mask to 64-bit.

>Seems like that would solve the problem?

I agree and I have tested that it is working.

-Shyam Iyer

--
This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com
http://www.opensubscriber.com/message/linux-kernel@vger.kernel.org/8218887.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-20 Thread shyam_iyer 
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.
+ These are allowed to fail since we store the value that ends up
+ being used to set as the bounce limit in slave_config later if
+ needed. */
+  pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
+  pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
+  pp-adma_dma_mask = *dev-dma_mask;
+
   mem = dmam_alloc_coherent(dev, NV_ADMA_PORT_PRIV_DMA_SZ,
 mem_dma, GFP_KERNEL);


This causes my DMA memory to always be above 4GB no matter how much I delay the 
setting of the 64bit DMA mask. I find that if I set the DMA mask as 32bit and 
not increase it to 64 bit at all then all my I/O to the DVD rom are fine. 

Jeff Garzik wrote:
I would consider setting the consistent DMA mask to 32-bit, and setting 
the overall mask to 64-bit.

Seems like that would solve the problem?

I agree and I have tested that it is working.

-Shyam Iyer

--
This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com
http://www.opensubscriber.com/message/linux-kernel@vger.kernel.org/8218887.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-18 Thread Shyam_Iyer 
>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 kernel logs when
I apply my patch on the vanilla-2.6.24-rc5 kernel.

-Shyam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-18 Thread Shyam_Iyer 
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:
root=/dev/disk/by-id/scsi-3600508e03ad8e2c732a09d08-part3
vga=0x31a resume=/dev/sda2 splash=verbose showopts 1
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009cc00 (usable)
 BIOS-e820: 0009cc00 - 000a (reserved)
 BIOS-e820: 000cc000 - 0010 (reserved)
 BIOS-e820: 0010 - 7fff (usable)
 BIOS-e820: 7fff - 8000 (reserved)
 BIOS-e820: 8000 - cff0 (usable)
 BIOS-e820: cff0 - cff0a000 (ACPI data)
 BIOS-e820: cff0a000 - cff8 (ACPI NVS)
 BIOS-e820: cff8 - d000 (reserved)
 BIOS-e820: e000 - f000 (reserved)
 BIOS-e820: fec0 - fec1 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: fff8 - 0001 (reserved)
 BIOS-e820: 0001 - 00023000 (usable)
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
Entering add_active_range(0, 256, 524272) 1 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used
Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used
end_pfn_map = 2293760
DMI present.
ACPI: RSDP 000F7AE0, 0014 (r0 PTLTD )
ACPI: RSDT CFF064D5, 004C (r1 DELL   PE_SC3604 DELL0)
ACPI: FACP CFF09906, 0074 (r1 DELL   PE_SC3604 DELLF4240)
ACPI: DSDT CFF06521, 33E5 (r1 DELL   PE_SC3604 MSFT  10E)
ACPI: FACS CFF0AFC0, 0040
ACPI: TCPA CFF0997A, 0032 (r1 Phoeni  x604  TL 0)
ACPI: SLIC CFF099AC, 0176 (r1 DELL   PE_SC3604 PTL 1)
ACPI: SPCR CFF09B22, 0050 (r1 DELL   PE_SC3604 PTL 1)
ACPI: SRAT CFF09B72, 00C8 (r1 AMDHAMMER604 AMD 1)
ACPI: SSDT CFF09C3A, 02CC (r1 AMDPOWERNOW  604 AMD 1)
ACPI: MCFG CFF09F06, 003C (r1 PTLTDMCFG604  LTP0)
ACPI: HPET CFF09F42, 0038 (r1 PTLTD  HPETTBL   604  LTP1)
ACPI: APIC CFF09F7A, 005E (r1 PTLTD  APIC604  LTP0)
ACPI: BOOT CFF09FD8, 0028 (r1 PTLTD  $SBFTBL$  604  LTP1)
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 0 -> APIC 1 -> Node 0
SRAT: Node 0 PXM 0 0-a
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
SRAT: Node 0 PXM 0 0-d000
Entering add_active_range(0, 0, 156) 1 entries of 3200 used
Entering add_active_range(0, 256, 524272) 1 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used
SRAT: Node 0 PXM 0 0-23000
Entering add_active_range(0, 0, 156) 3 entries of 3200 used
Entering add_active_range(0, 256, 524272) 3 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 3 entries of 3200 used
Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used
NUMA: Using 63 for the hash shift.
Bootmem setup node 0 -00023000
Zone PFN ranges:
  DMA 0 -> 4096
  DMA324096 ->  1048576
  Normal1048576 ->  2293760
Movable zone start PFN for each node
early_node_map[4] active PFN ranges
0:0 ->  156
0:  256 ->   524272
0:   524288 ->   851712
0:  1048576 ->  2293760
On node 0 totalpages: 2096780
  DMA zone: 96 pages used for memmap
  DMA zone: 2540 pages reserved
  DMA zone: 1360 pages, LIFO batch:0
  DMA32 zone: 24480 pages used for memmap
  DMA32 zone: 823120 pages, LIFO batch:31
  Normal zone: 29184 pages used for memmap
  Normal zone: 1216000 pages, LIFO batch:31
  Movable zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x8008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x10de8201 base: 0xfed0
Using ACPI (MADT) for SMP configuration information
swsusp: Registered nosave memory region: 0009c000 -
0009d000
swsusp: Registered nosave memory region: 0009d000 -
000a
swsusp: Registered nosave memory region: 000a -
000cc000
swsusp: Registered nosave memory region: 000cc000 -
0010
swsusp: Registered nosave memory region: 7fff -
8000
swsusp: Registered nosave memory region: cff0 -
cff0a000
swsusp: Registered nosave memory

RE: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-18 Thread Shyam_Iyer 
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:
root=/dev/disk/by-id/scsi-3600508e03ad8e2c732a09d08-part3
vga=0x31a resume=/dev/sda2 splash=verbose showopts 1
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009cc00 (usable)
 BIOS-e820: 0009cc00 - 000a (reserved)
 BIOS-e820: 000cc000 - 0010 (reserved)
 BIOS-e820: 0010 - 7fff (usable)
 BIOS-e820: 7fff - 8000 (reserved)
 BIOS-e820: 8000 - cff0 (usable)
 BIOS-e820: cff0 - cff0a000 (ACPI data)
 BIOS-e820: cff0a000 - cff8 (ACPI NVS)
 BIOS-e820: cff8 - d000 (reserved)
 BIOS-e820: e000 - f000 (reserved)
 BIOS-e820: fec0 - fec1 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: fff8 - 0001 (reserved)
 BIOS-e820: 0001 - 00023000 (usable)
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
Entering add_active_range(0, 256, 524272) 1 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used
Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used
end_pfn_map = 2293760
DMI present.
ACPI: RSDP 000F7AE0, 0014 (r0 PTLTD )
ACPI: RSDT CFF064D5, 004C (r1 DELL   PE_SC3604 DELL0)
ACPI: FACP CFF09906, 0074 (r1 DELL   PE_SC3604 DELLF4240)
ACPI: DSDT CFF06521, 33E5 (r1 DELL   PE_SC3604 MSFT  10E)
ACPI: FACS CFF0AFC0, 0040
ACPI: TCPA CFF0997A, 0032 (r1 Phoeni  x604  TL 0)
ACPI: SLIC CFF099AC, 0176 (r1 DELL   PE_SC3604 PTL 1)
ACPI: SPCR CFF09B22, 0050 (r1 DELL   PE_SC3604 PTL 1)
ACPI: SRAT CFF09B72, 00C8 (r1 AMDHAMMER604 AMD 1)
ACPI: SSDT CFF09C3A, 02CC (r1 AMDPOWERNOW  604 AMD 1)
ACPI: MCFG CFF09F06, 003C (r1 PTLTDMCFG604  LTP0)
ACPI: HPET CFF09F42, 0038 (r1 PTLTD  HPETTBL   604  LTP1)
ACPI: APIC CFF09F7A, 005E (r1 PTLTD  APIC604  LTP0)
ACPI: BOOT CFF09FD8, 0028 (r1 PTLTD  $SBFTBL$  604  LTP1)
SRAT: PXM 0 - APIC 0 - Node 0
SRAT: PXM 0 - APIC 1 - Node 0
SRAT: Node 0 PXM 0 0-a
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
SRAT: Node 0 PXM 0 0-d000
Entering add_active_range(0, 0, 156) 1 entries of 3200 used
Entering add_active_range(0, 256, 524272) 1 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used
SRAT: Node 0 PXM 0 0-23000
Entering add_active_range(0, 0, 156) 3 entries of 3200 used
Entering add_active_range(0, 256, 524272) 3 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 3 entries of 3200 used
Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used
NUMA: Using 63 for the hash shift.
Bootmem setup node 0 -00023000
Zone PFN ranges:
  DMA 0 - 4096
  DMA324096 -  1048576
  Normal1048576 -  2293760
Movable zone start PFN for each node
early_node_map[4] active PFN ranges
0:0 -  156
0:  256 -   524272
0:   524288 -   851712
0:  1048576 -  2293760
On node 0 totalpages: 2096780
  DMA zone: 96 pages used for memmap
  DMA zone: 2540 pages reserved
  DMA zone: 1360 pages, LIFO batch:0
  DMA32 zone: 24480 pages used for memmap
  DMA32 zone: 823120 pages, LIFO batch:31
  Normal zone: 29184 pages used for memmap
  Normal zone: 1216000 pages, LIFO batch:31
  Movable zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x8008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x10de8201 base: 0xfed0
Using ACPI (MADT) for SMP configuration information
swsusp: Registered nosave memory region: 0009c000 -
0009d000
swsusp: Registered nosave memory region: 0009d000 -
000a
swsusp: Registered nosave memory region: 000a -
000cc000
swsusp: Registered nosave memory region: 000cc000 -
0010
swsusp: Registered nosave memory region: 7fff -
8000
swsusp: Registered nosave memory region: cff0 -
cff0a000
swsusp: Registered nosave memory region:

RE: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-18 Thread Shyam_Iyer 
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 kernel logs when
I apply my patch on the vanilla-2.6.24-rc5 kernel.

-Shyam
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-17 Thread Tejun Heo 
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 +4537,10 @@ static void ata_fill_sg(struct ata_queued_cmd *qc)
 * Note h/w doesn't support 64-bit, so we unconditionally
 * truncate dma_addr_t to u32.
 */
+   if (sg_dma_address(sg) & ~DMA_BIT_MASK(32))
+   ata_dev_printk(qc->dev, KERN_WARNING,
+  "XXX DMA address %llx is above 32bit\n",
+  sg_dma_address(sg));
addr = (u32) sg_dma_address(sg);
sg_len = sg_dma_len(sg);
 
@@ -6628,6 +6632,10 @@ int ata_port_start(struct ata_port *ap)
if (rc)
return rc;
 
+   ata_port_printk(ap, KERN_INFO, "XXX: prd %p/%llx pad %p/%llx\n",
+   ap->prd, (unsigned long long)ap->prd_dma,
+   ap->pad, (unsigned long long)ap->pad_dma);
+
DPRINTK("prd alloc, virt %p, dma %llx\n", ap->prd,
(unsigned long long)ap->prd_dma);
return 0;
diff --git a/drivers/ata/sata_nv.c b/drivers/ata/sata_nv.c
index ed5dc7c..c55d2ae 100644
--- a/drivers/ata/sata_nv.c
+++ b/drivers/ata/sata_nv.c
@@ -247,6 +247,7 @@ struct nv_adma_port_priv {
void __iomem*ctl_block;
void __iomem*gen_block;
void __iomem*notifier_clear_block;
+   u64 adma_dma_mask;
u8  flags;
int last_issue_ncq;
 };
@@ -748,7 +749,7 @@ static int nv_adma_slave_config(struct scsi_device *sdev)
adma_enable = 0;
nv_adma_register_mode(ap);
} else {
-   bounce_limit = *ap->dev->dma_mask;
+   bounce_limit = pp->adma_dma_mask;
segment_boundary = NV_ADMA_DMA_BOUNDARY;
sg_tablesize = NV_ADMA_SGTBL_TOTAL_LEN;
adma_enable = 1;
@@ -1134,10 +1135,20 @@ static int nv_adma_port_start(struct ata_port *ap)
void *mem;
dma_addr_t mem_dma;
void __iomem *mmio;
+   struct pci_dev *pdev = to_pci_dev(dev);
u16 tmp;
 
VPRINTK("ENTER\n");
 
+   /* Ensure DMA mask is set to 32-bit before allocating legacy PRD and
+  pad buffers */
+   rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
+   if (rc)
+   return rc;
+   rc = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32));
+   if (rc)
+   return rc;
+
rc = ata_port_start(ap);
if (rc)
return rc;
@@ -1153,6 +1164,15 @@ static int nv_adma_port_start(struct ata_port *ap)
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.
+  These are allowed to fail since we store the value that ends up
+  being used to set as the bounce limit in slave_config later if
+  needed. */
+   pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
+   pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
+   pp->adma_dma_mask = *dev->dma_mask;
+
mem = dmam_alloc_coherent(dev, NV_ADMA_PORT_PRIV_DMA_SZ,
  _dma, GFP_KERNEL);
if (!mem)
@@ -2418,12 +2438,6 @@ static int nv_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
hpriv->type = type;
host->private_data = hpriv;
 
-   /* set 64bit dma masks, may fail */
-   if (type == ADMA) {
-   if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
-   pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
-   }
-
/* request and iomap NV_MMIO_BAR */
rc = pcim_iomap_regions(pdev, 1 << NV_MMIO_BAR, DRV_NAME);
if (rc)
diff --git a/include/linux/libata.h b/include/linux/libata.h

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-17 Thread Tejun Heo 
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) {
> + if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
> + pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
> + }
> +
>   ppi[0] = _port_info[type];
>   rc = ata_pci_prepare_sff_host(pdev, ppi, );
>   if (rc)
> @@ -2418,12 +2424,6 @@
>   hpriv->type = type;
>   host->private_data = hpriv;
>  
> - /* set 64bit dma masks, may fail */
> - if (type == ADMA) {
> - if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
> - pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
> - }
> -

This is weird.  IIRC, the problem is caused by allocating consistent
memory for legacy DMA over 32bit limit.  Your patch moves setting 64bit
DMA mask upward but it doesn't affect anything because
ata_pci_prepare_sff_host() and hpriv allocation are not DMA memory
allocations and thus unaffected by DMA mask.

Robert's last patch seems correct to me.  I have no idea why it doesn't
work for you tho.  Another interesting point is that you are reporting
data corruption instead of time out or HSM violation, which indicates
that the PRD table is accessible but what it contains is incorrect.

I guess it's time to print out some memory addresses.  I'll prep a debug
patch soon.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-17 Thread shyam_iyer 
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 use legacy DMA in ADMA mode (v3)" patch.

It doesn't work without this patch because there is an allocation of memory 
from  hpriv before the mask can be set.

Please review.

Signed-off-by: Shyam Iyer

--- sata_nv.c.orig  2007-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) {
+   if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
+   pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
+   }
+
ppi[0] = _port_info[type];
rc = ata_pci_prepare_sff_host(pdev, ppi, );
if (rc)
@@ -2418,12 +2424,6 @@
hpriv->type = type;
host->private_data = hpriv;
 
-   /* set 64bit dma masks, may fail */
-   if (type == ADMA) {
-   if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
-   pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
-   }
-
/* request and iomap NV_MMIO_BAR */
rc = pcim_iomap_regions(pdev, 1 << NV_MMIO_BAR, DRV_NAME);
if (rc)


--
This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com
http://www.opensubscriber.com/message/linux-kernel@vger.kernel.org/8211470.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-17 Thread shyam_iyer 
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.

If I reduce the memory with mem=<4Gb or disable the adma mode by passing 
adma=0, I am able to mount the media or do I/O.

Dmesg output -

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: root=/dev/disk/by-id/scsi-3600508e03ad8e2c732a09d08-part3 
vga=0x31a resume=/dev/sda2 splash=verbose showopts
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009cc00 (usable)
 BIOS-e820: 0009cc00 - 000a (reserved)
 BIOS-e820: 000cc000 - 0010 (reserved)
 BIOS-e820: 0010 - 7fff (usable)
 BIOS-e820: 7fff - 8000 (reserved)
 BIOS-e820: 8000 - cff0 (usable)
 BIOS-e820: cff0 - cff0a000 (ACPI data)
 BIOS-e820: cff0a000 - cff8 (ACPI NVS)
 BIOS-e820: cff8 - d000 (reserved)
 BIOS-e820: e000 - f000 (reserved)
 BIOS-e820: fec0 - fec1 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: fff8 - 0001 (reserved)
 BIOS-e820: 0001 - 00023000 (usable)
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
Entering add_active_range(0, 256, 524272) 1 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used
Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used
end_pfn_map = 2293760
DMI present.
ACPI: RSDP 000F7AE0, 0014 (r0 PTLTD )
ACPI: RSDT CFF064D5, 004C (r1 DELL   PE_SC3604 DELL0)
ACPI: FACP CFF09906, 0074 (r1 DELL   PE_SC3604 DELLF4240)
ACPI: DSDT CFF06521, 33E5 (r1 DELL   PE_SC3604 MSFT  10E)
ACPI: FACS CFF0AFC0, 0040
ACPI: TCPA CFF0997A, 0032 (r1 Phoeni  x604  TL 0)
ACPI: SLIC CFF099AC, 0176 (r1 DELL   PE_SC3604 PTL 1)
ACPI: SPCR CFF09B22, 0050 (r1 DELL   PE_SC3604 PTL 1)
ACPI: SRAT CFF09B72, 00C8 (r1 AMDHAMMER604 AMD 1)
ACPI: SSDT CFF09C3A, 02CC (r1 AMDPOWERNOW  604 AMD 1)
ACPI: MCFG CFF09F06, 003C (r1 PTLTDMCFG604  LTP0)
ACPI: HPET CFF09F42, 0038 (r1 PTLTD  HPETTBL   604  LTP1)
ACPI: APIC CFF09F7A, 005E (r1 PTLTD  APIC604  LTP0)
ACPI: BOOT CFF09FD8, 0028 (r1 PTLTD  $SBFTBL$  604  LTP1)
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 0 -> APIC 1 -> Node 0
SRAT: Node 0 PXM 0 0-a
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
SRAT: Node 0 PXM 0 0-d000
Entering add_active_range(0, 0, 156) 1 entries of 3200 used
Entering add_active_range(0, 256, 524272) 1 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used
SRAT: Node 0 PXM 0 0-23000
Entering add_active_range(0, 0, 156) 3 entries of 3200 used
Entering add_active_range(0, 256, 524272) 3 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 3 entries of 3200 used
Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used
NUMA: Using 63 for the hash shift.
Bootmem setup node 0 -00023000
Zone PFN ranges:
  DMA 0 -> 4096
  DMA324096 ->  1048576
  Normal1048576 ->  2293760
Movable zone start PFN for each node
early_node_map[4] active PFN ranges
0:0 ->  156
0:  256 ->   524272
0:   524288 ->   851712
0:  1048576 ->  2293760
On node 0 totalpages: 2096780
  DMA zone: 96 pages used for memmap
  DMA zone: 2540 pages reserved
  DMA zone: 1360 pages, LIFO batch:0
  DMA32 zone: 24480 pages used for memmap
  DMA32 zone: 823120 pages, LIFO batch:31
  Normal zone: 29184 pages used for memmap
  Normal zone: 1216000 pages, LIFO batch:31
  Movable zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x8008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x10de8201 base: 0xfed0
Using ACPI (MADT) for SMP configuration information
swsusp: Registered nosave memory region: 0009c000 - 0009d000
swsusp: Registered nosave memory region: 0009d000

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-17 Thread shyam_iyer 
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.

If I reduce the memory with mem=<4Gb or disable the adma mode by passing 
adma=0, I am able to mount the media or do I/O.

Dmesg output -

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: root=/dev/disk/by-id/scsi-3600508e03ad8e2c732a09d08-part3 
vga=0x31a resume=/dev/sda2 splash=verbose showopts
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009cc00 (usable)
 BIOS-e820: 0009cc00 - 000a (reserved)
 BIOS-e820: 000cc000 - 0010 (reserved)
 BIOS-e820: 0010 - 7fff (usable)
 BIOS-e820: 7fff - 8000 (reserved)
 BIOS-e820: 8000 - cff0 (usable)
 BIOS-e820: cff0 - cff0a000 (ACPI data)
 BIOS-e820: cff0a000 - cff8 (ACPI NVS)
 BIOS-e820: cff8 - d000 (reserved)
 BIOS-e820: e000 - f000 (reserved)
 BIOS-e820: fec0 - fec1 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: fff8 - 0001 (reserved)
 BIOS-e820: 0001 - 00023000 (usable)
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
Entering add_active_range(0, 256, 524272) 1 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used
Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used
end_pfn_map = 2293760
DMI present.
ACPI: RSDP 000F7AE0, 0014 (r0 PTLTD )
ACPI: RSDT CFF064D5, 004C (r1 DELL   PE_SC3604 DELL0)
ACPI: FACP CFF09906, 0074 (r1 DELL   PE_SC3604 DELLF4240)
ACPI: DSDT CFF06521, 33E5 (r1 DELL   PE_SC3604 MSFT  10E)
ACPI: FACS CFF0AFC0, 0040
ACPI: TCPA CFF0997A, 0032 (r1 Phoeni  x604  TL 0)
ACPI: SLIC CFF099AC, 0176 (r1 DELL   PE_SC3604 PTL 1)
ACPI: SPCR CFF09B22, 0050 (r1 DELL   PE_SC3604 PTL 1)
ACPI: SRAT CFF09B72, 00C8 (r1 AMDHAMMER604 AMD 1)
ACPI: SSDT CFF09C3A, 02CC (r1 AMDPOWERNOW  604 AMD 1)
ACPI: MCFG CFF09F06, 003C (r1 PTLTDMCFG604  LTP0)
ACPI: HPET CFF09F42, 0038 (r1 PTLTD  HPETTBL   604  LTP1)
ACPI: APIC CFF09F7A, 005E (r1 PTLTD  APIC604  LTP0)
ACPI: BOOT CFF09FD8, 0028 (r1 PTLTD  $SBFTBL$  604  LTP1)
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 0 -> APIC 1 -> Node 0
SRAT: Node 0 PXM 0 0-a
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
SRAT: Node 0 PXM 0 0-d000
Entering add_active_range(0, 0, 156) 1 entries of 3200 used
Entering add_active_range(0, 256, 524272) 1 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used
SRAT: Node 0 PXM 0 0-23000
Entering add_active_range(0, 0, 156) 3 entries of 3200 used
Entering add_active_range(0, 256, 524272) 3 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 3 entries of 3200 used
Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used
NUMA: Using 63 for the hash shift.
Bootmem setup node 0 -00023000
Zone PFN ranges:
  DMA 0 -> 4096
  DMA324096 ->  1048576
  Normal1048576 ->  2293760
Movable zone start PFN for each node
early_node_map[4] active PFN ranges
0:0 ->  156
0:  256 ->   524272
0:   524288 ->   851712
0:  1048576 ->  2293760
On node 0 totalpages: 2096780
  DMA zone: 96 pages used for memmap
  DMA zone: 2540 pages reserved
  DMA zone: 1360 pages, LIFO batch:0
  DMA32 zone: 24480 pages used for memmap
  DMA32 zone: 823120 pages, LIFO batch:31
  Normal zone: 29184 pages used for memmap
  Normal zone: 1216000 pages, LIFO batch:31
  Movable zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x8008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x10de8201 base: 0xfed0
Using ACPI (MADT) for SMP configuration information
swsusp: Registered nosave memory region: 0009c000 - 0009d000
swsusp: Registered nosave memory region: 0009d000

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-17 Thread shyam_iyer 
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.

If I reduce the memory with mem=4Gb or disable the adma mode by passing 
adma=0, I am able to mount the media or do I/O.

Dmesg output -

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: root=/dev/disk/by-id/scsi-3600508e03ad8e2c732a09d08-part3 
vga=0x31a resume=/dev/sda2 splash=verbose showopts
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009cc00 (usable)
 BIOS-e820: 0009cc00 - 000a (reserved)
 BIOS-e820: 000cc000 - 0010 (reserved)
 BIOS-e820: 0010 - 7fff (usable)
 BIOS-e820: 7fff - 8000 (reserved)
 BIOS-e820: 8000 - cff0 (usable)
 BIOS-e820: cff0 - cff0a000 (ACPI data)
 BIOS-e820: cff0a000 - cff8 (ACPI NVS)
 BIOS-e820: cff8 - d000 (reserved)
 BIOS-e820: e000 - f000 (reserved)
 BIOS-e820: fec0 - fec1 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: fff8 - 0001 (reserved)
 BIOS-e820: 0001 - 00023000 (usable)
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
Entering add_active_range(0, 256, 524272) 1 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used
Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used
end_pfn_map = 2293760
DMI present.
ACPI: RSDP 000F7AE0, 0014 (r0 PTLTD )
ACPI: RSDT CFF064D5, 004C (r1 DELL   PE_SC3604 DELL0)
ACPI: FACP CFF09906, 0074 (r1 DELL   PE_SC3604 DELLF4240)
ACPI: DSDT CFF06521, 33E5 (r1 DELL   PE_SC3604 MSFT  10E)
ACPI: FACS CFF0AFC0, 0040
ACPI: TCPA CFF0997A, 0032 (r1 Phoeni  x604  TL 0)
ACPI: SLIC CFF099AC, 0176 (r1 DELL   PE_SC3604 PTL 1)
ACPI: SPCR CFF09B22, 0050 (r1 DELL   PE_SC3604 PTL 1)
ACPI: SRAT CFF09B72, 00C8 (r1 AMDHAMMER604 AMD 1)
ACPI: SSDT CFF09C3A, 02CC (r1 AMDPOWERNOW  604 AMD 1)
ACPI: MCFG CFF09F06, 003C (r1 PTLTDMCFG604  LTP0)
ACPI: HPET CFF09F42, 0038 (r1 PTLTD  HPETTBL   604  LTP1)
ACPI: APIC CFF09F7A, 005E (r1 PTLTD  APIC604  LTP0)
ACPI: BOOT CFF09FD8, 0028 (r1 PTLTD  $SBFTBL$  604  LTP1)
SRAT: PXM 0 - APIC 0 - Node 0
SRAT: PXM 0 - APIC 1 - Node 0
SRAT: Node 0 PXM 0 0-a
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
SRAT: Node 0 PXM 0 0-d000
Entering add_active_range(0, 0, 156) 1 entries of 3200 used
Entering add_active_range(0, 256, 524272) 1 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used
SRAT: Node 0 PXM 0 0-23000
Entering add_active_range(0, 0, 156) 3 entries of 3200 used
Entering add_active_range(0, 256, 524272) 3 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 3 entries of 3200 used
Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used
NUMA: Using 63 for the hash shift.
Bootmem setup node 0 -00023000
Zone PFN ranges:
  DMA 0 - 4096
  DMA324096 -  1048576
  Normal1048576 -  2293760
Movable zone start PFN for each node
early_node_map[4] active PFN ranges
0:0 -  156
0:  256 -   524272
0:   524288 -   851712
0:  1048576 -  2293760
On node 0 totalpages: 2096780
  DMA zone: 96 pages used for memmap
  DMA zone: 2540 pages reserved
  DMA zone: 1360 pages, LIFO batch:0
  DMA32 zone: 24480 pages used for memmap
  DMA32 zone: 823120 pages, LIFO batch:31
  Normal zone: 29184 pages used for memmap
  Normal zone: 1216000 pages, LIFO batch:31
  Movable zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x8008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x10de8201 base: 0xfed0
Using ACPI (MADT) for SMP configuration information
swsusp: Registered nosave memory region: 0009c000 - 0009d000
swsusp: Registered nosave memory region: 0009d000 -

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-17 Thread shyam_iyer 
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.

If I reduce the memory with mem=4Gb or disable the adma mode by passing 
adma=0, I am able to mount the media or do I/O.

Dmesg output -

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: root=/dev/disk/by-id/scsi-3600508e03ad8e2c732a09d08-part3 
vga=0x31a resume=/dev/sda2 splash=verbose showopts
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009cc00 (usable)
 BIOS-e820: 0009cc00 - 000a (reserved)
 BIOS-e820: 000cc000 - 0010 (reserved)
 BIOS-e820: 0010 - 7fff (usable)
 BIOS-e820: 7fff - 8000 (reserved)
 BIOS-e820: 8000 - cff0 (usable)
 BIOS-e820: cff0 - cff0a000 (ACPI data)
 BIOS-e820: cff0a000 - cff8 (ACPI NVS)
 BIOS-e820: cff8 - d000 (reserved)
 BIOS-e820: e000 - f000 (reserved)
 BIOS-e820: fec0 - fec1 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: fff8 - 0001 (reserved)
 BIOS-e820: 0001 - 00023000 (usable)
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
Entering add_active_range(0, 256, 524272) 1 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used
Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used
end_pfn_map = 2293760
DMI present.
ACPI: RSDP 000F7AE0, 0014 (r0 PTLTD )
ACPI: RSDT CFF064D5, 004C (r1 DELL   PE_SC3604 DELL0)
ACPI: FACP CFF09906, 0074 (r1 DELL   PE_SC3604 DELLF4240)
ACPI: DSDT CFF06521, 33E5 (r1 DELL   PE_SC3604 MSFT  10E)
ACPI: FACS CFF0AFC0, 0040
ACPI: TCPA CFF0997A, 0032 (r1 Phoeni  x604  TL 0)
ACPI: SLIC CFF099AC, 0176 (r1 DELL   PE_SC3604 PTL 1)
ACPI: SPCR CFF09B22, 0050 (r1 DELL   PE_SC3604 PTL 1)
ACPI: SRAT CFF09B72, 00C8 (r1 AMDHAMMER604 AMD 1)
ACPI: SSDT CFF09C3A, 02CC (r1 AMDPOWERNOW  604 AMD 1)
ACPI: MCFG CFF09F06, 003C (r1 PTLTDMCFG604  LTP0)
ACPI: HPET CFF09F42, 0038 (r1 PTLTD  HPETTBL   604  LTP1)
ACPI: APIC CFF09F7A, 005E (r1 PTLTD  APIC604  LTP0)
ACPI: BOOT CFF09FD8, 0028 (r1 PTLTD  $SBFTBL$  604  LTP1)
SRAT: PXM 0 - APIC 0 - Node 0
SRAT: PXM 0 - APIC 1 - Node 0
SRAT: Node 0 PXM 0 0-a
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
SRAT: Node 0 PXM 0 0-d000
Entering add_active_range(0, 0, 156) 1 entries of 3200 used
Entering add_active_range(0, 256, 524272) 1 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used
SRAT: Node 0 PXM 0 0-23000
Entering add_active_range(0, 0, 156) 3 entries of 3200 used
Entering add_active_range(0, 256, 524272) 3 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 3 entries of 3200 used
Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used
NUMA: Using 63 for the hash shift.
Bootmem setup node 0 -00023000
Zone PFN ranges:
  DMA 0 - 4096
  DMA324096 -  1048576
  Normal1048576 -  2293760
Movable zone start PFN for each node
early_node_map[4] active PFN ranges
0:0 -  156
0:  256 -   524272
0:   524288 -   851712
0:  1048576 -  2293760
On node 0 totalpages: 2096780
  DMA zone: 96 pages used for memmap
  DMA zone: 2540 pages reserved
  DMA zone: 1360 pages, LIFO batch:0
  DMA32 zone: 24480 pages used for memmap
  DMA32 zone: 823120 pages, LIFO batch:31
  Normal zone: 29184 pages used for memmap
  Normal zone: 1216000 pages, LIFO batch:31
  Movable zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x8008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x10de8201 base: 0xfed0
Using ACPI (MADT) for SMP configuration information
swsusp: Registered nosave memory region: 0009c000 - 0009d000
swsusp: Registered nosave memory region: 0009d000 -

Re: Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-17 Thread shyam_iyer 
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 use legacy DMA in ADMA mode (v3) patch.

It doesn't work without this patch because there is an allocation of memory 
from  hpriv before the mask can be set.

Please review.

Signed-off-by: Shyam Iyer

--- sata_nv.c.orig  2007-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) {
+   if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
+   pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
+   }
+
ppi[0] = nv_port_info[type];
rc = ata_pci_prepare_sff_host(pdev, ppi, host);
if (rc)
@@ -2418,12 +2424,6 @@
hpriv-type = type;
host-private_data = hpriv;
 
-   /* set 64bit dma masks, may fail */
-   if (type == ADMA) {
-   if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
-   pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
-   }
-
/* request and iomap NV_MMIO_BAR */
rc = pcim_iomap_regions(pdev, 1  NV_MMIO_BAR, DRV_NAME);
if (rc)


--
This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com
http://www.opensubscriber.com/message/linux-kernel@vger.kernel.org/8211470.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-17 Thread Tejun Heo 
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) {
 + if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
 + pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
 + }
 +
   ppi[0] = nv_port_info[type];
   rc = ata_pci_prepare_sff_host(pdev, ppi, host);
   if (rc)
 @@ -2418,12 +2424,6 @@
   hpriv-type = type;
   host-private_data = hpriv;
  
 - /* set 64bit dma masks, may fail */
 - if (type == ADMA) {
 - if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
 - pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
 - }
 -

This is weird.  IIRC, the problem is caused by allocating consistent
memory for legacy DMA over 32bit limit.  Your patch moves setting 64bit
DMA mask upward but it doesn't affect anything because
ata_pci_prepare_sff_host() and hpriv allocation are not DMA memory
allocations and thus unaffected by DMA mask.

Robert's last patch seems correct to me.  I have no idea why it doesn't
work for you tho.  Another interesting point is that you are reporting
data corruption instead of time out or HSM violation, which indicates
that the PRD table is accessible but what it contains is incorrect.

I guess it's time to print out some memory addresses.  I'll prep a debug
patch soon.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-17 Thread Tejun Heo 
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 +4537,10 @@ static void ata_fill_sg(struct ata_queued_cmd *qc)
 * Note h/w doesn't support 64-bit, so we unconditionally
 * truncate dma_addr_t to u32.
 */
+   if (sg_dma_address(sg)  ~DMA_BIT_MASK(32))
+   ata_dev_printk(qc-dev, KERN_WARNING,
+  XXX DMA address %llx is above 32bit\n,
+  sg_dma_address(sg));
addr = (u32) sg_dma_address(sg);
sg_len = sg_dma_len(sg);
 
@@ -6628,6 +6632,10 @@ int ata_port_start(struct ata_port *ap)
if (rc)
return rc;
 
+   ata_port_printk(ap, KERN_INFO, XXX: prd %p/%llx pad %p/%llx\n,
+   ap-prd, (unsigned long long)ap-prd_dma,
+   ap-pad, (unsigned long long)ap-pad_dma);
+
DPRINTK(prd alloc, virt %p, dma %llx\n, ap-prd,
(unsigned long long)ap-prd_dma);
return 0;
diff --git a/drivers/ata/sata_nv.c b/drivers/ata/sata_nv.c
index ed5dc7c..c55d2ae 100644
--- a/drivers/ata/sata_nv.c
+++ b/drivers/ata/sata_nv.c
@@ -247,6 +247,7 @@ struct nv_adma_port_priv {
void __iomem*ctl_block;
void __iomem*gen_block;
void __iomem*notifier_clear_block;
+   u64 adma_dma_mask;
u8  flags;
int last_issue_ncq;
 };
@@ -748,7 +749,7 @@ static int nv_adma_slave_config(struct scsi_device *sdev)
adma_enable = 0;
nv_adma_register_mode(ap);
} else {
-   bounce_limit = *ap-dev-dma_mask;
+   bounce_limit = pp-adma_dma_mask;
segment_boundary = NV_ADMA_DMA_BOUNDARY;
sg_tablesize = NV_ADMA_SGTBL_TOTAL_LEN;
adma_enable = 1;
@@ -1134,10 +1135,20 @@ static int nv_adma_port_start(struct ata_port *ap)
void *mem;
dma_addr_t mem_dma;
void __iomem *mmio;
+   struct pci_dev *pdev = to_pci_dev(dev);
u16 tmp;
 
VPRINTK(ENTER\n);
 
+   /* Ensure DMA mask is set to 32-bit before allocating legacy PRD and
+  pad buffers */
+   rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
+   if (rc)
+   return rc;
+   rc = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32));
+   if (rc)
+   return rc;
+
rc = ata_port_start(ap);
if (rc)
return rc;
@@ -1153,6 +1164,15 @@ static int nv_adma_port_start(struct ata_port *ap)
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.
+  These are allowed to fail since we store the value that ends up
+  being used to set as the bounce limit in slave_config later if
+  needed. */
+   pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
+   pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
+   pp-adma_dma_mask = *dev-dma_mask;
+
mem = dmam_alloc_coherent(dev, NV_ADMA_PORT_PRIV_DMA_SZ,
  mem_dma, GFP_KERNEL);
if (!mem)
@@ -2418,12 +2438,6 @@ static int nv_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
hpriv-type = type;
host-private_data = hpriv;
 
-   /* set 64bit dma masks, may fail */
-   if (type == ADMA) {
-   if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) == 0)
-   pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
-   }
-
/* request and iomap NV_MMIO_BAR */
rc = pcim_iomap_regions(pdev, 1  NV_MMIO_BAR, DRV_NAME);
if (rc)
diff --git a/include/linux/libata.h b/include/linux/libata.h

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-08 Thread Robert Hancock 

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 allocated above 4GB and break legacy mode (which is needed for ATAPI
devices).

Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>


This is a bit nasty :/

I would consider setting the consistent DMA mask to 32-bit, and setting 
the overall mask to 64-bit.


Seems like that would solve the problem?

Also, does this need to be rebased on top of what I just pushed upstream?

Jeff


Jeff, ping on this one? This (or, one like it) really should make it 
into 2.6.24..


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-08 Thread Robert Hancock 

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 allocated above 4GB and break legacy mode (which is needed for ATAPI
devices).

Signed-off-by: Robert Hancock [EMAIL PROTECTED]


This is a bit nasty :/

I would consider setting the consistent DMA mask to 32-bit, and setting 
the overall mask to 64-bit.


Seems like that would solve the problem?

Also, does this need to be rebased on top of what I just pushed upstream?

Jeff


Jeff, ping on this one? This (or, one like it) really should make it 
into 2.6.24..


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-04 Thread Robert Hancock 

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 allocated above 4GB and break legacy mode (which is needed for ATAPI
devices).

Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>


This is a bit nasty :/

I would consider setting the consistent DMA mask to 32-bit, and setting 
the overall mask to 64-bit.


Seems like that would solve the problem?


The issue with that is that it would also constrain the ADMA CPB/PRD 
table allocation to 32-bit, which I'd rather avoid having to do. There 
are dual-socket Opteron boxes like HP xw9300 that use this controller, 
and limiting the allocation to 32-bit could force a non-optimal node 
allocation for the table memory.


These type of devices really want a version of dma_alloc_coherent that 
allows overriding the DMA mask for specific allocations to make this 
cleaner. I'm sure this isn't the only device that has different DMA mask 
requirements for different consistent memory allocations..


This patch does has the advantage of being confirmed to fix the 
reporter's problem (https://bugzilla.redhat.com/show_bug.cgi?id=351451) 
which there's something to be said for this late in the .24-rc series..




Also, does this need to be rebased on top of what I just pushed upstream?


It don't think so.. this change is independent from the "sata_nv: don't 
use legacy DMA in ADMA mode (v3)" patch you just merged.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-04 Thread Jeff Garzik 

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 legacy mode (which is needed for ATAPI
devices).

Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>


This is a bit nasty :/

I would consider setting the consistent DMA mask to 32-bit, and setting 
the overall mask to 64-bit.


Seems like that would solve the problem?

Also, does this need to be rebased on top of what I just pushed upstream?

Jeff



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-04 Thread Jeff Garzik 

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 legacy mode (which is needed for ATAPI
devices).

Signed-off-by: Robert Hancock [EMAIL PROTECTED]


This is a bit nasty :/

I would consider setting the consistent DMA mask to 32-bit, and setting 
the overall mask to 64-bit.


Seems like that would solve the problem?

Also, does this need to be rebased on top of what I just pushed upstream?

Jeff



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-04 Thread Robert Hancock 

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 allocated above 4GB and break legacy mode (which is needed for ATAPI
devices).

Signed-off-by: Robert Hancock [EMAIL PROTECTED]


This is a bit nasty :/

I would consider setting the consistent DMA mask to 32-bit, and setting 
the overall mask to 64-bit.


Seems like that would solve the problem?


The issue with that is that it would also constrain the ADMA CPB/PRD 
table allocation to 32-bit, which I'd rather avoid having to do. There 
are dual-socket Opteron boxes like HP xw9300 that use this controller, 
and limiting the allocation to 32-bit could force a non-optimal node 
allocation for the table memory.


These type of devices really want a version of dma_alloc_coherent that 
allows overriding the DMA mask for specific allocations to make this 
cleaner. I'm sure this isn't the only device that has different DMA mask 
requirements for different consistent memory allocations..


This patch does has the advantage of being confirmed to fix the 
reporter's problem (https://bugzilla.redhat.com/show_bug.cgi?id=351451) 
which there's something to be said for this late in the .24-rc series..




Also, does this need to be rebased on top of what I just pushed upstream?


It don't think so.. this change is independent from the sata_nv: don't 
use legacy DMA in ADMA mode (v3) patch you just merged.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Tejun Heo 
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 legacy mode (which is needed for ATAPI
> devices).
> 
> Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>

Acked-by: Tejun Heo <[EMAIL PROTECTED]>

Thanks.

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Mark Lord 

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 32-bit addressing. So yes, it 
appears to have a similar bug as sata_nv had.



sata_mv doesn't do ATAPI at all...

..

Not yet, anyway.  Stay tuned..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Robert Hancock 

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 32-bit addressing. So yes, it 
appears to have a similar bug as sata_nv had.



sata_mv doesn't do ATAPI at all...


Right.. missed that ATA_FLAG_NO_ATAPI. So these issues Tom is reporting 
are just with a normal SATA hard drive?


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Jeff Garzik 

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 yes, it 
appears to have a similar bug as sata_nv had.



sata_mv doesn't do ATAPI at all...

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Robert Hancock 

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 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.


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 yes, it 
appears to have a similar bug as sata_nv had.


Likely it needs a similar slave_config trick to change bounce limit 
depending on the connected device, unless there is really a way to issue 
ATAPI commands with this EDMA interface, as the TODO list in sata_mv.c 
suggests may be possible..


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Mark Lord 

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 have
been a crisis a LONG time ago...:-)
 
But I do have some more questions in relationship to how 
things are mapped in your environment. I have a flat memory 
map (i.e.: the full 0x0 -- 0x1__ is passed to the 32bit 
Linux kernel without any 'holes' and/or reserved areas).
 
Does your Intel memory map have this same type of flat memory 
model (and thus allow use of the FULL lower 4Gig) - or does it 
reserve areas of lower 4Gig for devices and such - if not - where 
are these reserved areas - and how do the relate to the I/O memory

map for the device?
 
In other words, I would be very interested in seeing the memory 
map & the PCI memory mapping to see if any overlap/correspond 
to reserve areas of lower 4 Gig (in a linux 32bit mode)...

...

I believe that only 2GB or so of the 4GB RAM appears below the 4GB boundary.
The rest is accessed above 4GB, using Intel's 36-bit PAE functionality.

I think what you want to see is /proc/mtrr, annotated below by me:

reg00: base=0x08000 (2048MB), size=2048MB: uncachable, count=1  I/O space
reg01: base=0x0 (   0MB), size=4096MB: write-back, count=1  first 2GB 
of RAM + I/O space
reg02: base=0x1 (4096MB), size=1024MB: write-back, count=1  third GB of 
RAM
reg03: base=0x14000 (5120MB), size= 512MB: write-back, count=1  portion of 
4th GB of RAM
reg04: base=0x16000 (5632MB), size= 256MB: write-back, count=1  portion of 
4th GB of RAM
reg05: base=0x17000 (5888MB), size= 128MB: write-back, count=1  portion of 
4th GB of RAM
reg06: base=0x17800 (6016MB), size=  64MB: write-back, count=1  portion of 
4th GB of RAM
reg07: base=0x0af80 (2808MB), size=   8MB: uncachable, count=1  (?) dunno


From that, the visible RAM should be 2048 + 1024 + 512 + 256 + 128 + 64 = 
3968MB.

In /proc/meminfo, it reports MemTotal of 4067260kB, which divided by 1024 gives 
3971MB.

The BIOS reports 4024MB.

But the MTRR values above do make it rather clear that nearly half the RAM
requires 33-bit physical addressing for access.

Cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Morrison, Tom 
Yes, I believe that - otherwise, this problem would have
been a crisis a LONG time ago...:-)
 
But I do have some more questions in relationship to how 
things are mapped in your environment. I have a flat memory 
map (i.e.: the full 0x0 -- 0x1__ is passed to the 32bit 
Linux kernel without any 'holes' and/or reserved areas).
 
Does your Intel memory map have this same type of flat memory 
model (and thus allow use of the FULL lower 4Gig) - or does it 
reserve areas of lower 4Gig for devices and such - if not - where 
are these reserved areas - and how do the relate to the I/O memory
map for the device?
 
In other words, I would be very interested in seeing the memory 
map & the PCI memory mapping to see if any overlap/correspond 
to reserve areas of lower 4 Gig (in a linux 32bit mode)...
 
Tom



From: Mark Lord [mailto:[EMAIL PROTECTED]
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 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 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.

Cheers


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Mark Lord 

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 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.

Cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Morrison, Tom 
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!



From: [EMAIL 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 
> 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 needed for ATAPI
> devices).
...

Mmm.. I wonder how many other libata drivers have this exact same bug,
whether noticed yet or not ?

Cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Mark Lord 

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 legacy mode (which is needed for ATAPI
devices).

...

Mmm.. I wonder how many other libata drivers have this exact same bug,
whether noticed yet or not ?

Cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Mark Lord 

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 legacy mode (which is needed for ATAPI
devices).

...

Mmm.. I wonder how many other libata drivers have this exact same bug,
whether noticed yet or not ?

Cheers
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Tejun Heo 
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 legacy mode (which is needed for ATAPI
 devices).
 
 Signed-off-by: Robert Hancock [EMAIL PROTECTED]

Acked-by: Tejun Heo [EMAIL PROTECTED]

Thanks.

-- 
tejun
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Jeff Garzik 

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 yes, it 
appears to have a similar bug as sata_nv had.



sata_mv doesn't do ATAPI at all...

Jeff


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Robert Hancock 

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 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.


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 yes, it 
appears to have a similar bug as sata_nv had.


Likely it needs a similar slave_config trick to change bounce limit 
depending on the connected device, unless there is really a way to issue 
ATAPI commands with this EDMA interface, as the TODO list in sata_mv.c 
suggests may be possible..


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Morrison, Tom 
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!



From: [EMAIL 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 
 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 needed for ATAPI
 devices).
...

Mmm.. I wonder how many other libata drivers have this exact same bug,
whether noticed yet or not ?

Cheers
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Mark Lord 

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 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.

Cheers
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Morrison, Tom 
Yes, I believe that - otherwise, this problem would have
been a crisis a LONG time ago...:-)
 
But I do have some more questions in relationship to how 
things are mapped in your environment. I have a flat memory 
map (i.e.: the full 0x0 -- 0x1__ is passed to the 32bit 
Linux kernel without any 'holes' and/or reserved areas).
 
Does your Intel memory map have this same type of flat memory 
model (and thus allow use of the FULL lower 4Gig) - or does it 
reserve areas of lower 4Gig for devices and such - if not - where 
are these reserved areas - and how do the relate to the I/O memory
map for the device?
 
In other words, I would be very interested in seeing the memory 
map  the PCI memory mapping to see if any overlap/correspond 
to reserve areas of lower 4 Gig (in a linux 32bit mode)...
 
Tom



From: Mark Lord [mailto:[EMAIL PROTECTED]
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 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 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.

Cheers


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Mark Lord 

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 have
been a crisis a LONG time ago...:-)
 
But I do have some more questions in relationship to how 
things are mapped in your environment. I have a flat memory 
map (i.e.: the full 0x0 -- 0x1__ is passed to the 32bit 
Linux kernel without any 'holes' and/or reserved areas).
 
Does your Intel memory map have this same type of flat memory 
model (and thus allow use of the FULL lower 4Gig) - or does it 
reserve areas of lower 4Gig for devices and such - if not - where 
are these reserved areas - and how do the relate to the I/O memory

map for the device?
 
In other words, I would be very interested in seeing the memory 
map  the PCI memory mapping to see if any overlap/correspond 
to reserve areas of lower 4 Gig (in a linux 32bit mode)...

...

I believe that only 2GB or so of the 4GB RAM appears below the 4GB boundary.
The rest is accessed above 4GB, using Intel's 36-bit PAE functionality.

I think what you want to see is /proc/mtrr, annotated below by me:

reg00: base=0x08000 (2048MB), size=2048MB: uncachable, count=1  I/O space
reg01: base=0x0 (   0MB), size=4096MB: write-back, count=1  first 2GB 
of RAM + I/O space
reg02: base=0x1 (4096MB), size=1024MB: write-back, count=1  third GB of 
RAM
reg03: base=0x14000 (5120MB), size= 512MB: write-back, count=1  portion of 
4th GB of RAM
reg04: base=0x16000 (5632MB), size= 256MB: write-back, count=1  portion of 
4th GB of RAM
reg05: base=0x17000 (5888MB), size= 128MB: write-back, count=1  portion of 
4th GB of RAM
reg06: base=0x17800 (6016MB), size=  64MB: write-back, count=1  portion of 
4th GB of RAM
reg07: base=0x0af80 (2808MB), size=   8MB: uncachable, count=1  (?) dunno


From that, the visible RAM should be 2048 + 1024 + 512 + 256 + 128 + 64 = 
3968MB.

In /proc/meminfo, it reports MemTotal of 4067260kB, which divided by 1024 gives 
3971MB.

The BIOS reports 4024MB.

But the MTRR values above do make it rather clear that nearly half the RAM
requires 33-bit physical addressing for access.

Cheers
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Robert Hancock 

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 32-bit addressing. So yes, it 
appears to have a similar bug as sata_nv had.



sata_mv doesn't do ATAPI at all...


Right.. missed that ATA_FLAG_NO_ATAPI. So these issues Tom is reporting 
are just with a normal SATA hard drive?


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-11-23 Thread Mark Lord 

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 32-bit addressing. So yes, it 
appears to have a similar bug as sata_nv had.



sata_mv doesn't do ATAPI at all...

..

Not yet, anyway.  Stay tuned..
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/