Bug 46161 - [BISECTED]divide error on radeon modprobe
Summary: [BISECTED]divide error on radeon modprobe
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 high
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-18 16:32 UTC by Brad Jackson
Modified: 2013-11-20 16:13 UTC (History)
3 users (show)

See Also:
Kernel Version: 3.6
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Trace from message log (9.21 KB, text/plain)
2012-08-18 16:32 UTC, Brad Jackson
Details

Description Brad Jackson 2012-08-18 16:32:01 UTC
Created attachment 77901 [details]
Trace from message log

I have a script that is run by rc.local that runs modprobe radeon, then disables vgaswitcheroo and unloads the radeon module. Excerpt from message log with trace is attached.

This started happening in 3.6-rc1 and is still in rc2. It does happen on 3.5.1 and 3.5.2 if the radeon module is manually loaded a second time after boot. Other kernels were not tested.
Comment 1 Michel Dänzer 2012-09-03 14:04:11 UTC
(In reply to comment #0)
> This started happening in 3.6-rc1 and is still in rc2. It does happen on
> 3.5.1
> and 3.5.2 if the radeon module is manually loaded a second time after boot.
So, do I understand this correctly: With 3.5.x it only happens after the radeon kernel module was loaded a second time, but with 3.6-rc* it even happens after it was loaded for the first time? If so, can you bisect what introduced the change in behaviour for 3.6-rc*?
Comment 2 Brad Jackson 2012-09-03 19:37:57 UTC
You are correct. I just tested 3.4.3 that I still had built and there is no error with repeated modprobes. I'm trying 3.4.10 to see if the problem started in 3.4. If it started in 3.5, I will do a few test builds of 3.5-RCx to find when it started. Then I can maybe try manually reverting any patches that looks like good candidates before I start a small bisect.
Comment 3 Brad Jackson 2012-09-03 21:58:07 UTC
I had to bisect between 3.4.0 and 3.5-rc1 and this was the result.

416a2bd274566a6f607a271f524b2dc0b84d9106 is the first bad commit
commit 416a2bd274566a6f607a271f524b2dc0b84d9106
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu May 31 19:00:25 2012 -0400

    drm/radeon: fixup tiling group size and backendmap on r6xx-r9xx (v4)
    
    Tiling group size is always 256bits on r6xx/r7xx/r8xx/9xx. Also fix and
    simplify render backend map. This now properly sets up the backend map
    on r6xx-9xx which should improve 3D performance.
    
    Vadim benchmarked also:
    Some benchmarks on juniper (5750), fullscreen 1920x1080,
    first result - kernel 3.4.0+ (fb21affa), second - with these patches:
    
    Lightsmark:   91 fps => 123 fps    +35%
    Doom3:        74 fps => 101 fps    +36%
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

:040000 040000 897f0745cc0845c549d44d172c2949cc92b4777c 4c08505d2b214813be5c65e4b87bb809ff027ce2 M	drivers
Comment 4 Brad Jackson 2012-09-03 22:26:31 UTC
I tried backing the patch out of 3.6-rc4 (got minor offset and fuzz warnings) and the problem is gone there too.

If a developer needs help narrowing down a fix to a specific file or line of code, I can do test builds if I can get patches to apply.
Comment 5 Alex Deucher 2013-11-20 14:24:28 UTC
Can you try a newer kernel, I believe this should be fixed.
Comment 6 Brad Jackson 2013-11-20 14:28:58 UTC
It was fixed in one of the releases shortly after I reported it.

Note You need to log in before you can comment on or make changes to this bug.