| Message ID | 65a6ef750910252203s58af446fv268c857191e698d3@mail.gmail.com |
|---|---|
| State | Not Applicable |
| Delegated to: | David Miller |
| Headers | show |
Hello, Mark Nelson wrote: > Like the Asus M2A-VM, MSI's K9A2 Platinum (MS-7376) can also support 64bit > DMA. According to MSI tech support, 64bit DMA is known to work with BIOS > versions 1.7 and later. Have you verified it? I'd really like for someone to actually verify it works before committing the patch as it's pretty nasty when it doesn't work. Thanks.
Adding back linux-ide and Jeff (accidentally dropped them off on my first reply) On Wed, Oct 28, 2009 at 5:13 AM, Tejun Heo <tj@kernel.org> wrote: > Hello, Mark. > > Mark Nelson wrote: >>>From reading this bug report: >> http://bugzilla.kernel.org/show_bug.cgi?id=14275 >> it sounds like when the SB600 can't do 64bit DMA the machine can fail to boot. >> >> I've been using the system with a patch that removes the AHCI_HFLAG_32BIT_ONLY >> from board_ahci_sb600 for a few months now, but the system only has 4GB of RAM, >> with some of it hoisted over the 32bit mark: >> >> Memory: 4048052k/4980736k available (2010k kernel code, 145176k >> reserved, 922k data, 228k init) >> >> This probably isn't a rigorous enough test though... What is the best way to >> verify it (and that way I can check more BIOS versions)? > > The surest way would be to put one time printk which prints out the > physical dma address if it's above 4G in the issue path. Something > like the following (completely untested). > > diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c > index b1a2577..08b987d 100644 > --- a/drivers/ata/ahci.c > +++ b/drivers/ata/ahci.c > @@ -2019,6 +2019,11 @@ static unsigned int ahci_fill_sg(struct ata_queued_cmd *qc, void *cmd_tbl) > for_each_sg(qc->sg, sg, qc->n_elem, si) { > dma_addr_t addr = sg_dma_address(sg); > u32 sg_len = sg_dma_len(sg); > + static int cnt; > + > + if (addr > 0xffffffffULL && !(cnt++ % 500)) > + printk("ahci: dma'ing to address 0x%llx\n", > + (unsigned long long)addr); > > ahci_sg[si].addr = cpu_to_le32(addr & 0xffffffff); > ahci_sg[si].addr_hi = cpu_to_le32((addr >> 16) >> 16); > That looks good. I'll have a play with it and see what I get. Thanks! Mark -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Oct 28, 2009 at 9:51 AM, Mark Nelson <mdnelson8@gmail.com> wrote: > Adding back linux-ide and Jeff (accidentally dropped them off on my first reply) > > On Wed, Oct 28, 2009 at 5:13 AM, Tejun Heo <tj@kernel.org> wrote: >> Hello, Mark. >> >> Mark Nelson wrote: >>>>From reading this bug report: >>> http://bugzilla.kernel.org/show_bug.cgi?id=14275 >>> it sounds like when the SB600 can't do 64bit DMA the machine can fail to boot. >>> >>> I've been using the system with a patch that removes the AHCI_HFLAG_32BIT_ONLY >>> from board_ahci_sb600 for a few months now, but the system only has 4GB of RAM, >>> with some of it hoisted over the 32bit mark: >>> >>> Memory: 4048052k/4980736k available (2010k kernel code, 145176k >>> reserved, 922k data, 228k init) >>> >>> This probably isn't a rigorous enough test though... What is the best way to >>> verify it (and that way I can check more BIOS versions)? >> >> The surest way would be to put one time printk which prints out the >> physical dma address if it's above 4G in the issue path. Something >> like the following (completely untested). >> >> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c >> index b1a2577..08b987d 100644 >> --- a/drivers/ata/ahci.c >> +++ b/drivers/ata/ahci.c >> @@ -2019,6 +2019,11 @@ static unsigned int ahci_fill_sg(struct ata_queued_cmd *qc, void *cmd_tbl) >> for_each_sg(qc->sg, sg, qc->n_elem, si) { >> dma_addr_t addr = sg_dma_address(sg); >> u32 sg_len = sg_dma_len(sg); >> + static int cnt; >> + >> + if (addr > 0xffffffffULL && !(cnt++ % 500)) >> + printk("ahci: dma'ing to address 0x%llx\n", >> + (unsigned long long)addr); >> >> ahci_sg[si].addr = cpu_to_le32(addr & 0xffffffff); >> ahci_sg[si].addr_hi = cpu_to_le32((addr >> 16) >> 16); >> > > That looks good. I'll have a play with it and see what I get. > Things look promising so far with lots of DMAs above 4GB (snippets from syslog): ahci 0000:00:12.0: version 3.0 ahci 0000:00:12.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 ahci 0000:00:12.0: MSI K9A2 Platinum: enabling 64bit DMA ahci 0000:00:12.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode ahci 0000:00:12.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ccc scsi0 : ahci scsi1 : ahci scsi2 : ahci scsi3 : ahci ata1: SATA max UDMA/133 irq_stat 0x00400000, PHY RDY changed irq 22 ata2: SATA max UDMA/133 abar m1024@0xfbcff800 port 0xfbcff980 irq 22 ata3: SATA max UDMA/133 abar m1024@0xfbcff800 port 0xfbcffa00 irq 22 ata4: SATA max UDMA/133 abar m1024@0xfbcff800 port 0xfbcffa80 irq 22 pata_atiixp 0000:00:14.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16 pata_atiixp 0000:00:14.1: setting latency timer to 64 scsi4 : pata_atiixp scsi5 : pata_atiixp ata5: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xff00 irq 14 ata6: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xff08 irq 15 ata5.00: ATAPI: PIONEER DVD-RW DVR-111D, 1.29, max UDMA/66 ata5.01: ATAPI: HL-DT-ST GCE-8520B, 1.02, max UDMA/33 ata5.00: configured for UDMA/66 ata5.01: configured for UDMA/33 ata3: SATA link down (SStatus 0 SControl 300) ata4: SATA link down (SStatus 0 SControl 300) ata2: SATA link down (SStatus 0 SControl 300) ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ahci: dma'ing to address 0x12ee49ed8 ata1.00: ATA-7: ST3320620AS, 3.AAD, max UDMA/133 ata1.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 31/32) ata1.00: SB600 AHCI: limiting to 255 sectors per cmd ata1.00: SB600 AHCI: limiting to 255 sectors per cmd ata1.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA ST3320620AS 3.AA PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 625142448 512-byte logical blocks: (320 GB/298 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: scsi 4:0:0:0: CD-ROM PIONEER DVD-RW DVR-111D 1.29 PQ: 0 ANSI: 5 sr0: scsi3-mmc drive: 62x/62x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 4:0:0:0: Attached scsi CD-ROM sr0 scsi 4:0:1:0: CD-ROM HL-DT-ST CD-RW GCE-8520B 1.02 PQ: 0 ANSI: 5 sr1: scsi3-mmc drive: 40x/52x writer cd/rw xa/form2 cdda tray sr 4:0:1:0: Attached scsi CD-ROM sr1 sda1 sda2 sda3 sda4 < sda5 sda6 > sd 0:0:0:0: [sda] Attached SCSI disk EXT4-fs (sda5): mounted filesystem with ordered data mode VFS: Mounted root (ext4 filesystem) readonly on device 8:5. Freeing unused kernel memory: 392k freed ahci: dma'ing to address 0x12e9a8000 ahci: dma'ing to address 0x12e57a000 ahci: dma'ing to address 0x12d455000 sd 0:0:0:0: Attached scsi generic sg0 type 0 sr 4:0:0:0: Attached scsi generic sg1 type 5 sr 4:0:1:0: Attached scsi generic sg2 type 5 ahci: dma'ing to address 0x12e13f000 ahci: dma'ing to address 0x12dd65000 ahci: dma'ing to address 0x12e594000 ahci: dma'ing to address 0x12e29a000 ahci: dma'ing to address 0x12df02000 ahci: dma'ing to address 0x12cf0d200 Adding 4939948k swap on /dev/sda6. Priority:-1 extents:1 across:4939948k ahci: dma'ing to address 0x12d774000 ahci: dma'ing to address 0x12c40c000 ahci: dma'ing to address 0x12c01a000 ahci: dma'ing to address 0x12c3ac000 ahci: dma'ing to address 0x12beca000 ahci: dma'ing to address 0x12b25a000 ahci: dma'ing to address 0x1294b5000 ahci: dma'ing to address 0x12905d000 ahci: dma'ing to address 0x12934a000 ahci: dma'ing to address 0x1287df000 ahci: dma'ing to address 0x1289c2000 ahci: dma'ing to address 0x1264f0000 ahci: dma'ing to address 0x1268a7000 ahci: dma'ing to address 0x1262ab000 ahci: dma'ing to address 0x12501b000 ahci: dma'ing to address 0x124162000 ahci: dma'ing to address 0x1261a1000 ahci: dma'ing to address 0x12362c000 ahci: dma'ing to address 0x122b1a000 ahci: dma'ing to address 0x121887000 ahci: dma'ing to address 0x12101c000 ahci: dma'ing to address 0x120b4b000 ahci: dma'ing to address 0x11f56b000 ahci: dma'ing to address 0x11ef71000 ahci: dma'ing to address 0x120314000 ahci: dma'ing to address 0x1274e9000 ahci: dma'ing to address 0x11e129000 ahci: dma'ing to address 0x11d065000 ahci: dma'ing to address 0x11cefe000 ahci: dma'ing to address 0x11c607000 ahci: dma'ing to address 0x11c384000 ahci: dma'ing to address 0x1194bb000 ahci: dma'ing to address 0x11881e000 ahci: dma'ing to address 0x118669000 ahci: dma'ing to address 0x1178e7000 ahci: dma'ing to address 0x116c0c000 ahci: dma'ing to address 0x116b1b000 ahci: dma'ing to address 0x1167fe000 ahci: dma'ing to address 0x11550f000 ahci: dma'ing to address 0x114cd3000 ahci: dma'ing to address 0x1147c9000 ahci: dma'ing to address 0x12464a000 ahci: dma'ing to address 0x11cf76000 ahci: dma'ing to address 0x111970000 ahci: dma'ing to address 0x110bbf000 This was running with BIOS version 1.8. I'll try to test more BIOS revisions to work out exactly which ones work with 64bit DMA. Thanks! Mark -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Mark Nelson wrote: > Things look promising so far with lots of DMAs above 4GB (snippets > from syslog): It's probably working okay but a good test would be to repeat to copy a large file and checksum it and verify checksums actually match. Thanks.
On Wed, Oct 28, 2009 at 11:14 PM, Tejun Heo <tj@kernel.org> wrote: > Mark Nelson wrote: >> Things look promising so far with lots of DMAs above 4GB (snippets >> from syslog): > > It's probably working okay but a good test would be to repeat to copy > a large file and checksum it and verify checksums actually match. > Okay, that sounds like a good test. I'll give it a go tonight. Thanks for your help on this! Mark -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Oct 28, 2009 at 11:14 PM, Tejun Heo <tj@kernel.org> wrote: > Mark Nelson wrote: >> Things look promising so far with lots of DMAs above 4GB (snippets >> from syslog): > > It's probably working okay but a good test would be to repeat to copy > a large file and checksum it and verify checksums actually match. > Okay, I copied the following file: -rw-r--r-- 1 mark mark 8715024384 Oct 29 18:42 /home/mark/Test1.mpg and both the original and the copy came out with the same md5sum of c83d8da8fb1aa6843a3b94005278e8a7 This is with BIOS version 1.8 though - I'll go back a few more versions and repeat these tests and see if I can find any that don't work with 64bit DMA. Thanks! Mark -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 29, 2009 at 7:32 PM, Mark Nelson <mdnelson8@gmail.com> wrote: > On Wed, Oct 28, 2009 at 11:14 PM, Tejun Heo <tj@kernel.org> wrote: >> Mark Nelson wrote: >>> Things look promising so far with lots of DMAs above 4GB (snippets >>> from syslog): >> >> It's probably working okay but a good test would be to repeat to copy >> a large file and checksum it and verify checksums actually match. >> > Okay, I copied the following file: > > -rw-r--r-- 1 mark mark 8715024384 Oct 29 18:42 /home/mark/Test1.mpg > > and both the original and the copy came out with the same md5sum of > c83d8da8fb1aa6843a3b94005278e8a7 > > This is with BIOS version 1.8 though - I'll go back a few more versions and > repeat these tests and see if I can find any that don't work with 64bit DMA. > I got some time to do the testing on more BIOSs and I found that all the released BIOS versions worked correctly with 64bit DMA enabled, going all the way back to version 1.0 (thankfully my CPU is old enough to work with BIOS releases that old). I guess this makes sense as version 1.0 is dated 2007-10-29, which is around the time that the first correctly working Asus M2A-VM BIOS was released. Or maybe it's just a coincidence... In any case, it looks like we can enable 64bit DMA on this board regardless of BIOS version. So, I've prepared a new patch that I'll send separately. Thanks! Mark -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: upstream/drivers/ata/ahci.c =================================================================== --- upstream.orig/drivers/ata/ahci.c +++ upstream/drivers/ata/ahci.c @@ -2718,6 +2718,20 @@ static bool ahci_sb600_enable_64bit(stru }, .driver_data = "20071026", /* yyyymmdd */ }, + /* + * BIOS version 1.7 and up are known to support 64bit DMA + * 1.7 was released on 2009-01-13. + * Enable 64bit DMA on 1.7 and anything newer. + */ + { + .ident = "MSI K9A2 Platinum", + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, + "MICRO-STAR INTERNATIONAL CO.,LTD"), + DMI_MATCH(DMI_BOARD_NAME, "MS-7376"), + }, + .driver_data = "20090113", /* yyyymmdd */ + }, { } }; const struct dmi_system_id *match;
Like the Asus M2A-VM, MSI's K9A2 Platinum (MS-7376) can also support 64bit DMA. According to MSI tech support, 64bit DMA is known to work with BIOS versions 1.7 and later. Earlier BIOSs most likey work also, but we'll be safe here and just enable 64bit DMA on 1.7 and newer. Signed-off-by: Mark Nelson <mdnelson8@gmail.com> --- drivers/ata/ahci.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html