From: <bug...@an...> - 2006-12-10 00:03:16
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=7697 ------- Additional Comments From sr...@tu... 2006-12-09 16:03 ------- (In reply to comment #13) > While trying to get the hex output, I noticed that I had to do a lot of casting > to get correct (long enough) values printed out. Next I noticed that actually > the check should be returning ok according to the debug output (see previous > attachment), but it did not... so doing similar casts in the check itself, like > with the patch attached, the problem goes away and 3D works! So there is a problem if the fb gets exactly mapped at the end of the 32bit address space. Couldn't this happen on 32bit systems too? And with the gart area? The same bug is certainly present in radeon_state.c too, and radeon_cp.c uses the same calculation. Just storing fb_size -1 instead of fb_size (and change the comparisons accordingly) might work too instead of the casts all over the place, just need to make sure the fb_size wasn't 0 before (which shouldn't really happen)... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |