Bug 46161
| Summary: | [BISECTED]divide error on radeon modprobe | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Brad Jackson (bjackson0971) |
| Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
| Status: | CLOSED CODE_FIX | ||
| Severity: | high | CC: | airlied, alan, alexdeucher |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.6 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: | Trace from message log | ||
(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*? 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. 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 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. Can you try a newer kernel, I believe this should be fixed. It was fixed in one of the releases shortly after I reported it. |
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.