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.
Created attachment 109451 [details]
dmesg output when booting rc2 kernel with radeon.agpmode=-1
Created attachment 109461 [details]
dmesg output when booting rc2 without using radeon.agpmode=-1
Created attachment 109471 [details]
lspci -vv output
The problem is still occurring with kernel-PAE-3.12.0-0.rc2.git0.1.fc21.i686.
Created attachment 109481 [details]
Xorg.0.log file so you can see the reported error message
Can you bisect?
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.
(In reply to Alex Deucher from comment #6)
> Can you bisect?
I'll try 'cause I get the same with clean 3.12-rc2 +
radeon.agpmode=8 works as before, but
[ 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) +
works like a charm.
Any point to start without git-tree?
Created attachment 109551 [details]
(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 +
> 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
> 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.
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.
(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
> > 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...
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.
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.
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).
Someone who has the necessary powers please reassign according to https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-September/111758.html .
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.
I'll be able to try it tonight or tomorrow.
I tested the referenced patch on top of vanilla 3.12-rc2 and things work correctly.
(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 ;-)
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.
(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.
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?
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.