George Spelvin wrote: > Tejun Heo <htejun@xxxxxxxxx> wrote: > >> George Spelvin wrote: >>> ATM I'm just recompiling the kernel from -rc6 to -rc7. >>> >>> It's in single-user mode so I can't ssh over the boot messages, but >>> they definitely included "64bit" from ahci_print_info(). >> Thanks for verifying. I would love to lift the 32 restriction from >> SB600 but it's been quite a rocky ride and I still can't tell what's >> the determining factor. :-( > > H'm.... 64-bit support comes through in multiple places. > I wonder if it's just one of them? > - HBA memory-mapped registers (which are in fact limited to 32 bits) This is determined by the BIOS and I don't think it ever puts it over 32bit boundary. > - Port x command list base address > - Port x FIS base address > - Command table base address (command header, offset 8) > - Data base address (physical region descriptor, offset 0) The first three are controlled by consistent_dma_mask while the last one is controlled by dma_mask, so maybe setting only consistent_dma_mask to 32bit could help. The problem is how to verify them. You'll need to dig the list and bugzilla to look for reporters who reported failure on 64bit DMA and verify it actually fixes the problem. It can be tricky as the problem doesn't seem to appear for all users. > What we really care about is that the data physical regions can > be anywhere in 64-bit space. If any of the others were limited to > 32 bits, that would only be slightly annoying. > > But... > The base addresses are already above 4G. Aobve 8G, actually. > > Port 0 base addresses: 02 1f1e 0000, 02 1f1e 0400 > Port 1 base addresses: 02 1f1a 0000, 02 1f1a 0400 > Port 2 base addresses: 02 1f98 0000, 02 1f98 0400 > Port 3 base addresses: 02 1f9e 0000, 02 1f9e 0400 Where are these numbers from? -- tejun -- 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
