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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
