Bug 61811 - kms mode breaks when using radeon.agpmode=-1
Summary: kms mode breaks when using radeon.agpmode=-1
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-21 16:39 UTC by Bruno Wolff III
Modified: 2013-10-15 01:52 UTC (History)
5 users (show)

See Also:
Kernel Version: 3.12
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
dmesg output when booting rc2 kernel with radeon.agpmode=-1 (45.92 KB, text/plain)
2013-09-24 09:24 UTC, Bruno Wolff III
Details
dmesg output when booting rc2 without using radeon.agpmode=-1 (49.02 KB, text/plain)
2013-09-24 09:25 UTC, Bruno Wolff III
Details
lspci -vv output (12.17 KB, text/plain)
2013-09-24 09:26 UTC, Bruno Wolff III
Details
Xorg.0.log file so you can see the reported error message (18.78 KB, text/plain)
2013-09-24 09:34 UTC, Bruno Wolff III
Details
dmesg-3.12-rc2-agpmode-1.log (43.41 KB, text/plain)
2013-09-24 20:29 UTC, Dieter Nützel
Details

Description Bruno Wolff III 2013-09-21 16:39:21 UTC
I need to use radeon.agpmode=-1 with my rv280 based graphics card due to a long (2+ years) standing bug with the driver. Recently I was no longer able to start X because modesetting is no longer working. At boot I no longer see the resolution change and I got log entries later in Xor.0.log saying "[KMS] drm report modesetting isn't supported."
If I boot without radeon.agpmode=-1 X starts, though becomes unusable shortly due to the pre-existing but. kernel-PAE-3.12.0-0.rc0.git22.2.fc21.i686 works for me. kernel-PAE-3.12.0-0.rc0.git24.1.fc21.i686 doesn't work. (git23's build failed so I didn't test that one.)
I did a git whatchanged d5d04bb..3711d86 which I think should have showed me the commits that were in git24 and not git22 and I didn't see any specifically directed at the radeon driver. I did see some PCI related commits.
Comment 1 Bruno Wolff III 2013-09-24 09:24:07 UTC
Created attachment 109451 [details]
dmesg output when booting rc2 kernel with radeon.agpmode=-1
Comment 2 Bruno Wolff III 2013-09-24 09:25:23 UTC
Created attachment 109461 [details]
dmesg output when booting rc2 without using radeon.agpmode=-1
Comment 3 Bruno Wolff III 2013-09-24 09:26:57 UTC
Created attachment 109471 [details]
lspci -vv output
Comment 4 Bruno Wolff III 2013-09-24 09:28:33 UTC
The problem is still occurring with kernel-PAE-3.12.0-0.rc2.git0.1.fc21.i686.
Comment 5 Bruno Wolff III 2013-09-24 09:34:46 UTC
Created attachment 109481 [details]
Xorg.0.log file so you can see the reported error message
Comment 6 Alex Deucher 2013-09-24 19:07:26 UTC
Can you bisect?
Comment 7 Bruno Wolff III 2013-09-24 19:24:50 UTC
It will go slow, as I'll only be able to do about one build a day as I have pretty old hardware. It will also be slow getting started as I haven't tried it before and I'll need to figure out the workflow. On the plus side the number of commits isn't huge, so I can probably get it done in a few weeks.
Comment 8 Dieter Nützel 2013-09-24 20:27:03 UTC
(In reply to Alex Deucher from comment #6)
> Can you bisect?

Hello Alex,

I'll try 'cause I get the same with clean 3.12-rc2 +
0001-drm-radeon-avoid-UVD-corruption-on-AGP-cards-using-G.patch

radeon.agpmode=8 works as before, but
radeon.agpmode=-1 gave

[-]
[   10.958649] radeon: `-1' invalid for parameter `agpmode'
[   11.515274] radeon: `-1' invalid for parameter `agpmode'
FATAL: Error inserting radeon (/lib/modules/3.12.0-rc2-1-desktop/kernel/drivers/gpu/drm/radeon/radeon.ko): Invalid argument

Welcome to openSUSE 12.3 "Dartmouth" - Kernel 3.12.0-rc2-1-desktop (tty1).
[-]

Your drm-fixes-3.12 (3.11.0-rc7 in reality) +
0001-drm-radeon-avoid-UVD-corruption-on-AGP-cards-using-G.patch
works like a charm.

Any point to start without git-tree?
Comment 9 Dieter Nützel 2013-09-24 20:29:50 UTC
Created attachment 109551 [details]
dmesg-3.12-rc2-agpmode-1.log
Comment 10 Alex Deucher 2013-09-24 20:40:35 UTC
(In reply to Dieter Nützel from comment #8)
> (In reply to Alex Deucher from comment #6)
> > Can you bisect?
> 
> Hello Alex,
> 
> I'll try 'cause I get the same with clean 3.12-rc2 +
> 0001-drm-radeon-avoid-UVD-corruption-on-AGP-cards-using-G.patch
> 
> radeon.agpmode=8 works as before, but
> radeon.agpmode=-1 gave
> 
> [-]
> [   10.958649] radeon: `-1' invalid for parameter `agpmode'
> [   11.515274] radeon: `-1' invalid for parameter `agpmode'
> FATAL: Error inserting radeon
> (/lib/modules/3.12.0-rc2-1-desktop/kernel/drivers/gpu/drm/radeon/radeon.ko):
> Invalid argument
> 

We haven't touched anything AGP related in radeon in years.  Maybe some general kernel module parsing change?

> 
> Any point to start without git-tree?

You really need a git tree to bisect.
Comment 11 Bruno Wolff III 2013-09-24 20:52:15 UTC
I believe it was after d5d04bb and up to 3711d86. There weren't any radeon changes in that range that I noticed when I read through the git whatchanged output. It's possible that some patch was added or removed in there, but there wasn't a comment in the spec changelog for the rpms. I can check more carefully to make sure. There were some intel changes and maybe there is some common code.
Comment 12 Dieter Nützel 2013-09-24 20:58:27 UTC
(In reply to Alex Deucher from comment #10)
> (In reply to Dieter Nützel from comment #8)
> > (In reply to Alex Deucher from comment #6)
> > > Can you bisect?
> > 
> > Hello Alex,
> > 
> > I'll try 'cause I get the same with clean 3.12-rc2 +
> > 0001-drm-radeon-avoid-UVD-corruption-on-AGP-cards-using-G.patch
> > 
> > radeon.agpmode=8 works as before, but
> > radeon.agpmode=-1 gave
> > 
> > [-]
> > [   10.958649] radeon: `-1' invalid for parameter `agpmode'
> > [   11.515274] radeon: `-1' invalid for parameter `agpmode'
> > FATAL: Error inserting radeon
> >
> (/lib/modules/3.12.0-rc2-1-desktop/kernel/drivers/gpu/drm/radeon/radeon.ko):
> > Invalid argument
> > 
> 
> We haven't touched anything AGP related in radeon in years.

I know. ;-)

>  Maybe some general kernel module parsing change?

That was my thought, too.

> > 
> > Any point to start without git-tree?
> 
> You really need a git tree to bisect.

I know, second time, but...
...I'll see what I can find in Linus 3.12-rc1 (maybe before) patch file(s) (logs).
For several git trees this system is to small...
Comment 13 Bruno Wolff III 2013-09-24 21:14:15 UTC
Kernel kernel-PAE-3.12.0-0.rc0.git22.2.fc21.i686 which worked for me was based off commit d5d04bb. The next kernel which didn;t work (kernel-PAE-3.12.0-0.rc0.git24.1.fc21.i686) was based on commit 3711d86.
Comment 14 Bruno Wolff III 2013-09-26 12:25:32 UTC
After a bit of learning, I believe I am on my way to bisecting for the problem commit. I can only do 2 tests a day (maybe 3 on weekends) and will probably finish on Monday.
Comment 15 Bruno Wolff III 2013-09-27 12:38:25 UTC
So far I have 26935fb06ee88f1188789807687c03041f3c70d9 as the last known good commit and 48efe453e6b29561f78a1df55c7f58375259cb8c as the first known bad commit.
Of the commits there, the most suspicious ones have to do with the strict_strto*() to kstrto*() change as it looks like that might affect parameter parsing. This would be commits 6072ddc8520b86adfac6939ca32fb6e6c4de017a and 57103d7fe1833857cf542a482c1eb8da0bf86e5d.
I still expect to have the bisect done by sometime on Monday (or maybe late Sunday).
Comment 16 Michel Dänzer 2013-09-27 15:07:48 UTC
Someone who has the necessary powers please reassign according to https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-September/111758.html .
Comment 17 Bjorn Helgaas 2013-09-27 15:44:10 UTC
Bruno or Dieter, can you try Jean's patch from the email mentioned in comment #16?  If v3.12-rc2 + Jean's patch solves the problem, it might save you a lot of bisect time.
Comment 18 Bruno Wolff III 2013-09-27 17:53:22 UTC
I'll be able to try it tonight or tomorrow.
Comment 19 Bruno Wolff III 2013-09-28 00:00:06 UTC
I tested the referenced patch on top of vanilla 3.12-rc2 and things work correctly.
Comment 20 Dieter Nützel 2013-09-28 00:23:28 UTC
(In reply to Bjorn Helgaas from comment #17)
> Bruno or Dieter, can you try Jean's patch from the email mentioned in
> comment #16?  If v3.12-rc2 + Jean's patch solves the problem, it might save
> you a lot of bisect time.

3.12-rc2 + Jean's patch

Running with radeon.agpmode=-1.
Direct way to 3.12-rc3, please ;-)

Tested-by Dieter@nuetzel-hh.de
Comment 21 Bruno Wolff III 2013-09-30 03:14:54 UTC
This is fixed by commit 3a126f85e015701e56240884f27f97543580d5f7 which is in Linus' tree. It is also in Fedora kernel-PAE-3.12.0-0.rc2.git4.1.fc21.i686 which I tested and confirmed the fix again.
Comment 22 Dieter Nützel 2013-10-14 22:01:13 UTC
(In reply to Bruno Wolff III from comment #0)
> I need to use radeon.agpmode=-1 with my rv280 based graphics card due to a
> long (2+ years) standing bug with the driver.

Hello Bruno,

isn't it then time to writing a bug report on bugs.freedesktop.org, that Christian König or Alex Deucher from AMD can look at it?

Greetings,
   Dieter
Comment 23 Bruno Wolff III 2013-10-15 01:52:17 UTC
I have a Fedora bug for that issue. I'm starting to work on bisecting some older kernel bugs and may bring it back to the kernel when I'm done. But I'm starting on a sound / network / probable locking bug from 3 years ago. It will probably take me a couple of weeks to get that one bisected.

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