https://bugzilla.kernel.org/show_bug.cgi?id=29412 Jonathan Nieder <jrnieder@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jrnieder@xxxxxxxxx --- Comment #3 from Jonathan Nieder <jrnieder@xxxxxxxxx> 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
