Bug 29412

Can you bisect?

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.

Can you give me any hints on how to do a more useful bisect? Perhaps limiting the scope to a particular source path?

(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.

Ok retesting v2.6.32-rc1 first, I had trouble building it (gcc 4.6 won't work); trouble getting the initramfs to work, and trouble getting X to start (some kind of race condition / bad failure mode in the gdm3 init script launched ~300 Xorg instances before I killed it).

However, I could reproduce the issue without X: single-user mode, no radeon module loaded: fans climbed down as they should. Single-user mode, radeon driver loaded: fans didn't climb down.

I'll check v2.6.32-rc1^ next, then I'll collect dmesg/Xorg.0.logs as appropriate.

(I confirmed this with 3.3~rc6-1~experimental.1 in the mean time)

Created attachment 72633 [details]
dmesg from v2.6.32-rc1^

Frustratingly, the issue reared its head with v2.6.32-rc1^.  This dmesg is from a single user mode session, two suspends with "modprobe radeon" in the middle.

It's getting hard to run kernels this old (even though they aren't that old!) notice the error loading the radeon firmware: no idea why it hasn't managed, other kernels do (and it's there).  Also udev refuses to start with < 2.6.32.

I may have to set up a test root with an older userspace (squeeze perhaps) to go further :(

Does this basically invalidate my previous bisect?

udev should cope fine with kernels < 2.6.32 iirc as long as CONFIG_SYSFS_DEPRECATED is not set.

The painful memories are coming back to me: udev also requires v2.6.28-rc6~45 ("reintroduce accept4") and dup3 and friends from 2.6.27.

It's just a kms issue no need to bisect. Something is not restored properly.

Created attachment 72654 [details]
possible fix

Does this patch fix the issue?

I'll have access to the machine again this Friday; I'll try it this weekend. Thanks!

Sadly, this patch doesn't seem to solve it.  I'll add a printk and re-try just to be doubly sure I'm not messing things up and loading the wrong module.

Created attachment 72731 [details]
alternate fix

After you verify the first patch does not fix the issue, you can try this one.  Can you also attach a copy of your vbios?  To get a copy of your vbios:

(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/<pci bus id>
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom

Ignore the last hunk of that patch (rv770.c).

That second patch sorts it! Thanks! I booted to single-user; modprobe radeon; pm-suspend; resumed: fine. Moved to multi-user; logged into GNOME; suspended via GNOME menu; resumed: fine again.

Would you still like the vbios?

Cheers!

Perfect.  No need for the vbios.  I'll send the patch to Dave.

A patch referencing this bug report has been merged in Linux v3.4-rc2:

commit 402976fe51b2d1a58a29ba06fa1ca5ace3a4cdcd
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Mar 29 19:04:08 2012 -0400

    drm/radeon/kms: fix fans after resume

This bug can be closed.