radeon modeset crashes on A4-3400 HD6410D

Alex Deucher alexdeucher at gmail.com
Wed Jan 30 11:14:16 PST 2013


On Tue, Jan 29, 2013 at 1:09 PM, Mikko Tiihonen <mikko.tiihonen at iki.fi> wrote:
> 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.
>
> 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.
>
>
> 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.
> 2) or activate the current code only if there are more than max_rb_num zero
> bits in the given disabled_rb_mask

Looks good.  I've gone ahead and applied your patch for safety sake
and I also added a patch to set up the RBs correctly on your board.
Please test the attached patches.

Thanks!

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-drm-radeon-protect-against-div-by-0-in-backend-setup.patch
Type: text/x-patch
Size: 1480 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/a3d49f5b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-fix-backend-map-setup-on-1-RB-sumo-boards.patch
Type: text/x-patch
Size: 1682 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/a3d49f5b/attachment-0001.bin>


More information about the dri-devel mailing list