Summary: | [SNB] system hangs after suspend-resume | ||
---|---|---|---|
Product: | DRI | Reporter: | alanw <alanwww1> |
Component: | DRM/Intel | Assignee: | Chris Wilson <chris> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | critical | ||
Priority: | medium | CC: | hanswurst, jbarnes, yi.sun, yuanhan.liu, zhenyu.z.wang |
Version: | unspecified | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
alanw
2011-03-20 04:46:25 UTC
This doesn't immediately strike me as being i915.ko related... (In reply to comment #1) > This doesn't immediately strike me as being i915.ko related... Sorry for beening noob. You mean i reported it in a wrong place ? Can you help where i should report ? Or is it possible to move this report there ? If not can you close it ? Just that our expertise only runs as far as the gfx. Have a look to see if this is similar to bug 32539, or if any of the debugging steps there help. (In reply to comment #3) > Just that our expertise only runs as far as the gfx. Have a look to see if this > is similar to bug 32539, or if any of the debugging steps there help. Thanks. That is not helping me. Do you know where i should report this problem ? I heard from Yuanhan that this is a BIOS bug. (In reply to comment #5) > I heard from Yuanhan that this is a BIOS bug. Yes. Besides the BIOS bug, Zhenyu has found something else which may fix some case of this issue. So, alanw, would you please try to update your bios, then have another try? Thanks, Yuanhan Liu I failed to attach patches here... please try my patches at http://people.freedesktop.org/~zhen/snb_desktop_suspend/ also with one at http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git;a=commit;h=a7a75c8f70d6f6a2f16c9f627f938bbee2d32718 New BIOS update is required for fixing suspend/resume issue on my DH67 board. Patches are against upstream 2.6.38 kernel. These have passed many cycles of S3 test on my hw here. > New BIOS update is required for fixing suspend/resume issue on my DH67 board. > Patches are against upstream 2.6.38 kernel. These have passed many cycles of S3 > test on my hw here. Thank you. I have an MSI board but i see that there is an updated BIOS there with updated chipset firmware. That might be what i need. I will make a test tonight and report back. Thanks once again. The board and BIOS version. http://www.msi.com/product/mb/H67MS-E33.html#/?div=BIOS (In reply to comment #6) > (In reply to comment #5) > > I heard from Yuanhan that this is a BIOS bug. > > Yes. Besides the BIOS bug, Zhenyu has found something else which may fix some > case of this issue. > > So, alanw, would you please try to update your bios, then have another try? > > Thanks, > Yuanhan Liu I made a short test last night. I have not yet applied Zhenyu's patches. I only upgraded to the latest BIOS (chipset firmware) yet. Well i had only made a quick test yet, but suspend began to work (at least a 3-4 times i tried), but the BIOS upgrade left me without the HDMI audio device. That is really strange. I only have two devices show up with aplay -l. Previously i had a device #3 with the HDMI output. IN BIOS i don't see an potion to turn this on or off. I'll make further tests with suspend with Zhenyu's patches today. Also i will try to boot the machine into Windows to see if the HDMI audio device really disappeared. If yes there might be that the chipset upgrade is faulty. @Zhenyu: Could you please check if your HDMI audio device shows up with the new BIOS on your Mobo ? Thx sorry, no HDMI monitor by hand. New patch set uploaded to http://people.freedesktop.org/~zhen/snb_desk_suspend_0323/ I made tests with the first patch set. It was applied to 2.6.38 final kernel. Testing went good, fast suspend and resume without a problem (10-20 cycles) (In reply to comment #10) > sorry, no HDMI monitor by hand. About the HDMI audio device disappearing with new firmware, I made a test with Windows 7 x64 and yes this is definitely a firmware bug. The hdmi audio device disappeared in both linux and windows with new BIOS. Reverting back to the previous BIOS instantly gives back the HDMI audio device. I reported this to MSI, but where else should i report the problem ? It could be a BIOS or a chipset firmware problem. @Zhenyo: I think if you don't even plug the hdmi cable you should be seeing the hdmi audio device. Could you please check? With that info we could decide whether it is a BIOS or a firmware problem. Should i make a test with the new patchset? I already commented on bug #32589 about this issue (https://bugs.freedesktop.org/show_bug.cgi?id=32539#c10). I just did a BIOS update on my Intel DH67GD and I this fixed it for me as well, resume works fine now. :) I'm running kernel 2.6.38 and HDMI audio still works as well btw. ;) *** Bug 32539 has been marked as a duplicate of this bug. *** I'm affected a bug that has the exact same effects as described by alanw, however I use different hardware: Asus P8P67-m PRO, i5 2500k and an Asus GT210 Nvidia GPU. The machine seems to suspend properly, but on resume it is completely unresponsive and even does multiple reboots (telling from harddisk spinups and onboard LED flashing). If the GPU is installed, then there is no video signal on resume. With or without GPU, it does not respond to pings or ssh logins and can only be shutdown by a hard reset. As reported in Ubuntu's bugreport system, resume is also broken on the P8H67-m PRO version with internal graphics, however the standard P8P67 (PRO) is not affected. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/760842 The problem is 100% reproducible with the latest BIOS (as well as the previous versions) and all kernels tested (2.6.32-lts, 2.6.37, 2.6.38, 2.6.39). Suspend (S3) was initiated by "pm-suspend" or "echo -n mem > /sys/power/state" from terminal, without any nvidia graphics driver installed. Additionally, I tried Wang Zhenyu's patchset (http://people.freedesktop.org/~zhen/snb_desk_suspend_0323/) on a stock 2.6.38 kernel, but this is probably only targeted towards the internal Intel GPU and (not surprisingly) does not work in my case. I should mention that no overclocking is present and I tested it enabling/disabling all possible BIOS settings without success. pm-suspend.log http://pastebin.com/srfzWiC6 Using sudo sh -c "echo 'core' > /sys/power/pm_test" before suspending forces the kernel to do simulate suspend and resume without actually calling the low-level hardware commands. The results below are copy & pasted from the Ubuntu bugtracker: ------------------------------- 1. GPU present (with Nvidia driver), fans kept running and machine was stuck (no ping, no keyboard, no video signal). dmesg after reboot: http://pastebin.com/wpmxaU3C 2. No GPU present (but Nvidia driver still installed), it correctly suspended and resumed after a few seconds. dmesg: http://pastebin.com/UMt1aj2q 3. GPU present (Nvidia driver removed, nouveau driver installed), it correctly suspended and resumed after a few seconds. dmesg: http://pastebin.com/wC6VitEc ----- 4. no echo "core" GPU present, Nvidia driver removed, nouveau driver installed, regular pm-suspend ---> machine stuck and multiple reboots Hans, it sounds like you have a different problem with nvidia, please open a new bug for that (and not against drm/intel). And this bug seems to be fixed for at least one user; please open a new one if you still have issues (but please try http://lists.freedesktop.org/archives/intel-gfx/2011-June/010979.html first). |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.