On 04/13/2011 10:21 AM, Joerg Roedel wrote: > > First of all, I bisected between v2.6.37-rc2..f005fe12b90c which where > only a couple of patches and merged v2.6.38-rc4 in at every step. There > was no failure found. > Then I tried this again, but this time I merged v2.6.38-rc5 at every > step and was successful. The bad commit in this branch turned out to be > > 1a4a678b12c84db9ae5dce424e0e97f0559bb57c > > which is related to memblock. > > Then I tried to find out which change between 2.6.38-rc4 and 2.6.38-rc5 > is needed to trigger the failure, so I used f005fe12b90c as a base, > bisected between v2.6.38-rc4..v2.6.38-rc5 and merged every bisect step > into the base and tested. Here the bad commit turned out to be > > e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20 > > which is related to gart. It turned out that the gart aperture on that > box is on another position with these patches. Before it was as > 0xa4000000 and now it is at 0xa0000000. It seems like this has something > to do with the root-cause. > > Reverting commit 1a4a678b12c84db9ae5dce424e0e97f0559bb57c fixes the > problem btw. and booting with iommu=soft also works, but I have no idea > yet why the aperture at that address is a problem (with the patch > reverted the aperture lands at 0x80000000). > Does reverting e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20 solve the problem for you? 1a4a678b12c84db9ae5dce424e0e97f0559bb57c is a memory-allocation-order patch, which have a nasty tendency to unmask bugs elsewhere in the kernel. However, e6d2e2b2b1e1455df16d68a78f4a3874c7b3ad20 looks positively strange (and it doesn't exactly help that the description is written in Yinghai-ese and is therefore nearly impossible to decode, never mind tell if it is remotely correct.) -hpa _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
