Most recent kernel where this bug did not occur: ? Distribution: Debian 3.1 Hardware Environment: IBM x460, 4 dual core Xeon 3 GHz, 14 GB RAM, 2 70 GB SAS disks. Software Environment: Debian 3.1 (Sarge) with mainline kernel 2.6.18 patched with SAS and AIC94xx drivers. Can be reproduced with kernel-2.6.19-rc2 without patches (SAS and AIC94xx included in mainline) Problem Description: During the kernel boot sequence, it hangs in Calgary IOMMU init. I put some traces in the kernel to show where: -->calgary_iommu_init PCI-DMA: Using Calgary IOMMU -->calgary_init -->calgary_init_one Calgary: bus number 0 address 0xfda00000 -->calgary_setup_tar -->calgary_reserve_regions <--calgary_reserve_regions Calgary: going to set up TAR <bbar ffffc20000080000>... before calgary_reg -->calgary_reg <--calgary_reg before readq(target) It hangs at the first readq() after the calgary_req() in calgary_setup(). Steps to reproduce: Configure kernel to use calgary IOMMU and boot. You can can avoid the problem using "iommu=off". Using "acpi=noirq" changes nothing.
Summarizing: we're hanging on the first Calgary register access, the machine space address for Calgary registers (0xfda00000) and the ioremap response look correct. The only clue so far is that this machine has a rev 2 Calgary, and the code works fine on a rev 1 Calgary... I don't see anything obvious in the errata, continuing to investigate.
Turns out the BIOS is initializing Calgary's BBAR register to a different address than the one we were expecting. Laurent put together a preliminary patch to get the BBAR address out of the BIOS supplied tables rather than calculate it ourselves.
Patch submitted: http://marc.theaimsgroup.com/?l=linux-kernel&m=116250442901467&w=2 and will be included in 2.6.20.