https://bugzilla.kernel.org/show_bug.cgi?id=29412
Jonathan Nieder <jrnieder at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jrnieder at gmail.com
--- Comment #3 from Jonathan Nieder <jrnieder at gmail.com> 2012-03-16
19:05:06 ---
(In reply to comment #2)
> I did bisect to identify the first bad commit as
> 17d857be649a21ca90008c6dc425d849fa83db5c , which is merely tagging 2.6.32-rc1.
> I suspect some user space component is only enabling KMS if the kernel version
> equals or exceeds this tag and that's why it is only triggered from that
> commit.
Thanks. Odd. The test the radeon driver uses is
if (info->dri->pKernelDRMVersion->version_minor >= 5)
ginfo.request = RADEON_INFO_ACCEL_WORKING2;
else
ginfo.request = RADEON_INFO_ACCEL_WORKING;
which wouldn't be affected by utsversion. So, questions:
1) Is that bisection result reproducible? I.e., if you do:
cd linux
git checkout v2.6.32-rc1
cp /boot/config-$(uname -r) .config; # current configuration
make localmodconfig; # optional: minimize configuration
make deb-pkg; # optionally with -j<num> for parallel build
dpkg -i ../<name of package>; # as root
reboot
... test test test ...
cd linux
git checkout HEAD^
make deb-pkg; # maybe with -j4
dpkg -i ../<name of package>
reboot
... test some more ...
does the first package produced reproduce the misbehavior and
the second one not?
2) Can you reproduce this without X? What happens if you boot
in recovery mode, run "modprobe radeon" to make sure the driver
is loaded, and suspend?
3) An attachment with "dmesg" output (and /var/log/Xorg.0.log if
X seems to be involved) from a non-working kernel would also be
interesting.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
