Bug#660464: KMS is not working for Radeon 9250

[Jonathan Nieder <jrnieder@gmail.com>]

Mirek Jezbera wrote:
> On Po 20.úno, Jonathan Nieder wrote:
>> Mirek Jezbera wrote:

>>> I have recompiled kernel 3.2.6 (from unstable kernel sources 3.2.6-1) to have
>>> same options as working 3.3.0-rc1 kernel. From 5 boots I have gui three times
>>> and black screen twice.
>>> With linux kernel 3.3.0-rc1 I have always booted into gui. 
[...]
> It seems, that there is some race condition issue in kernel.

Yeah.

A lot happened between v3.2 and v3.3-rc1, unfortunately.  Would you be
able to bisect to narrow down the search for the fix?

It works like this:

 0. Prerequisites:
	apt-get install git build-essential

 1. Get the kernel, if you don't already have it.

	git clone \
	  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

 2. Try v3.2.  Hopefully it does not contain the fix.

	git checkout v3.2
	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>
	reboot until the gdm flicker happens (giving up after a few
	 times if it doesn't happen)

      git checkout v3.3-rc1
	git bisect start -- drivers/gpu/drm
	git bisect good v3.2; # reproduces the bug

 3. If that reproduced the bug, try v3.3-rc1.

	make silentoldconfig; # reuse configuration
	make deb-pkg; # maybe with -j4
	dpkg -i ../<name of package>
	reboot until the gdm flicker happens (giving up after 10 or so
	 trials if it doesn't happen, which we would hope)

	git bisect good; # if gdm flickers
	git bisect bad; # if you cannot get it to flicker
	git bisect skip; # if some other bug makes it hard to test

    Hopefully it does contain the fix, so you can run "git bisect bad".

 4. Git checks out a version half-way between to test; repeat
    until it finds the "first bad commit", which will be the fix.
    If the gitk package is installed, you can run "git bisect
    visualize" to watch the search space for the fix narrowing.
    If you get bored before it finishes, the partial result shown
    by "git bisect log" will already be useful.

To recap: a few rounds of bisecting would be very useful.  It is
fussy because the bug is not 100% reproducible and a little
counterintuitive because since we are searching for the patch that
introduced a fix rather than a bug, our values are backwards:

	good = buggy
	bad = fixed

Hope that helps,
Jonathan