Originally reported against the wrong product, here:
I have an ATI Radeon X850XT PCIE card plugged into an Intel DG35EC motherboard.
With kernels since 2.6.32-rc1 and most recently tested with mainline commit 2a324ce7b79a3a90cc2d4ade5d5f960a99000caa (2.6.38-rc5+), if I attempt a suspend-to-ram, upon resume, the fan on my ATI card remains at full speed (loud), and does not throttle back to quiet (normal behaviour).
Booting with 'radeon.modeset=0' prevents this.
Please let me know what further information is needed.
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
> I suspect some user space component is only enabling KMS if the kernel
> equals or exceeds this tag and that's why it is only triggered from that
Thanks. Odd. The test the radeon driver uses is
if (info->dri->pKernelDRMVersion->version_minor >= 5)
ginfo.request = RADEON_INFO_ACCEL_WORKING2;
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:
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
... test test test ...
git checkout HEAD^
make deb-pkg; # maybe with -j4
dpkg -i ../<name of package>
... 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
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]
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]
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:
(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?
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:
Author: Alex Deucher <firstname.lastname@example.org>
Date: Thu Mar 29 19:04:08 2012 -0400
drm/radeon/kms: fix fans after resume
This bug can be closed.