Hi,
I have a A4-3400 CPU that I bought half a year ago. I've tried once month, but Fedora has never succeeded in booting in graphical mode.
Some time ago a finally built some custom kernels to figure out why. I created a bug to Fedora bug, but it has not progressed.I have a A4-3400 CPU that I bought half a year ago. I've tried once month, but Fedora has never succeeded in booting in graphical mode.
Analysis:
The radeon module startup fails with division by zero in r6xx_remap_render_backend because the first RB is not enabled and the code assuming that enabled RBs must be all the first ones of the valid range.
The radeon module startup fails with division by zero in r6xx_remap_render_backend because the first RB is not enabled and the code assuming that enabled RBs must be all the first ones of the valid range.
Longer version:
In r600.c:r6xx_remap_render_backend
The function contains only one divide:
u32 r6xx_remap_render_backend(struct radeon_device *rdev,
u32 tiling_pipe_num,
u32 max_rb_num,
u32 total_max_rb_num,
u32 disabled_rb_mask)
{
u32 rendering_pipe_num, rb_num_width, req_rb_num;
...
/* mask out the RBs that don't exist on that asic */
disabled_rb_mask |= (0xff << max_rb_num) & 0xff;
rendering_pipe_num = 1 << tiling_pipe_num;
req_rb_num = total_max_rb_num - r600_count_pipe_bits(disabled_rb_mask);
BUG_ON(rendering_pipe_num < req_rb_num);
pipe_rb_ratio = rendering_pipe_num / req_rb_num;
I added a printk to see what actual parameters are passed in:
tiling_pipe_num=2, max_rb_num=1, total_max_rb_num=8, disabled_rb_mask=253
Using those to calculate the divide by zero comes from:
disabled_rb_mask |= 254; -> 255
req_rb_num = 8 - 8;
Quick fix for stable kernel series:
The attached fix activates only in the division by zero case and instead of failing uses the given disabled_rb_mask. This is guaranteed to be regression free and actually allows me to load the radeon driver successfully. It does help with cards that currently work, but for which some usable RBs are disabled due to the eager masking.
Proper fix would propably be to find out think why the disabled_rb_mask is masked the way it is, were there bugs in other places for which it is a workaround. I can see two possible modifictions:
1) only mask bits exceeding total_max_rb_num instead of the max_rb_num since the one enabled RB on A4-3400 can propably be any one of the 8 possible values.
1) only mask bits exceeding total_max_rb_num instead of the max_rb_num since the one enabled RB on A4-3400 can propably be any one of the 8 possible values.
2) or activate the current code only if there are more than max_rb_num zero bits in the given disabled_rb_mask
-Mikko
Attachment:
r600-division-by-zero.patch
Description: Binary data
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
