Created attachment 37929 [details] before suspend logs CRB board info: PBA E73564-202 BIOS date 05/05/2010 (core version 4.6.3.2) IGFX VBIOS version 2024. Description: The suggested change mentioned in the bug#29567 fixed the problem for us (your CRB has that odd device ID - without adding that to the drive you won’t get video). Huron River X comes up after video=LVDS-1:d is added. But after sleep and resume X is not coming back. Attached are the logs for the suspend / resume screen corruption issue. These are after a cold boot with the video=LVDS-1:d added. Before-suspend Cold boot, from telnet run dmesg then echo mem to sys/power/state After-resume After resume - screen is corrupted, from telnet run dmesg then xrandr –s 1024x768 After-xrandr After randr - screen is ok (on 1 of 5 or 6 tests I did see corruption in an xterm window but the rest of the screen was ok.
Created attachment 37930 [details] after xrandr logs attached
Created attachment 37931 [details] after resume logs attached
Could you attach 'lspci -nvv' output?
I tested hibernate and suspend on my huron river, that works fine. Manjeet, could you try latest linux-2.6 git tree?
Created attachment 37985 [details] lspci output attached
Created attachment 37986 [details] oxorg logs attachd lspci and xorg logs attached.
Created attachment 38145 [details] attached 2.6.32 rc2 logs. I am attaching the dmesg and X log of my trial with latest kernel files.
Hi Wang Zhenyu , We tried resume after patching linux-2.6.36-RC2 kernel with next-20100825 patch(latest on git) on CRB. Corruption still exists after resume. Also it disappears after I do xrandr –s 1280x1024 (basically, mode switch to any other resolution seems to work here). Can we get the dmesg and X logs from your system? so that we can compare and see if there is a difference in the configuration . I am attaching the dmesg and X log of my trial with latest kernel files.
oh, it looks I can't produce on my old 1024x768 monitor, but produce on another bigger one. Looks we failed to restore some state correctly after resume. cc: Yuanhan who owns the machine now.
When I tried to test my huron river with new bios, it failed to boot after upgrade. I need sometime to bring it back. Could you attach intel_reg_dump output before and after suspend?
Created attachment 38337 [details] intel_reg_dump output before suspend attached
Created attachment 38338 [details] intel_reg_dump output after resume Hi, I have atatched the requested attach intel_reg_dump output before and after suspend
Hi Wang Zhenyu, Any update on this? This is very critical for us and is currently a blocker. Please keep me updated with latest progress. Thanks, Manjeet
We find this's tiling related. Disable tiling could workaround the problem for now, and in consider we haven't done 2D accel on sandybridge yet. So this workaround has no impact. Yuanhan is looking into the tiling buffer restore issue.
Hi Wang Zhenyu, We tried the tiling workaround but the screen is still showing up partially distored after resume. See attached snapshot.
Created attachment 38615 [details] resume after tiling workaround snapshot attached.
Hi Manjeet Singh, Would you please attach xorg.log after the tiling mode is disabled? BTW, the screen shot you attached looks a little different from the one we saw here. The screen is completely corrupted here. While, from that attachment, we saw that the middle part looks quite OK. So, is there any difference after tiling mode disabled? Thanks.
Disable tiling does workaround this issue for me on LVDS panel. You should have a xorg.conf file, and its 'Device' section should like below: Section "Device" Identifier "Configured Video Device" Driver "intel" Option "Tiling" "false" EndSection
(In reply to comment #19) > Disable tiling does workaround this issue for me on LVDS panel. I'd confirm disable tiling also makes S3 working on my Huron River (with pci id 0126).
Hi Wang Zhenyu, The tiling workaround has reduced the resume corruption but we are still seeing 10% to 50% screen coming distored after resume. I tried resume 10 times and there is not a single case when screen was 100% correct after resume. I am attaching somoe more after resume screenshot in zip file. First resume - Middle part came up OK but distorted from side Seconds resume- 90% of the scree was OK, but bottom panel and top icons were distorted. Third resume- same as first resume. Middle part ok, sides were distored. See snapshots.
Created attachment 38675 [details] latest after resume snapshots attached
Created attachment 38676 [details] xorg.log file attached Attaching the xorg.conf file I used. also attached xorg.log files after resume.
Please note that our kernel version is 2.6.35 (not 2.6.36).
Please confirm you're testing VGA output or LVDS panel? Is it possible to test 2.6.36-rc4? We and QA are mostly using development tip. And if it could be better we will identify patches for backport to stable kernel.
We are testing with LVDS panel. It is not possible for us to move from 2.6.35 to 2.6.36 right now. Is 2.6.36-rc4 + tiling workaround working 100% properly for you? if yes then please provide the backport patch for 2.6.35 and I can test that. Thanks, Manjeet
Current 36-rc kernel works for me if disable tiling. Could you attach 'dmidecode' output? Yuanhan suspect we might not have seen the same bug... Could you test my backport branch at http://cgit.freedesktop.org/~zhen/drm-intel/log/?h=snb-35-backport-hp? I picked up more kms fixes into that branch. And I'll test .35 kernel too.
2.6.35 kernel tested, and it works fine here after disabling tiling mode. FYI, I also tested kernel 2.6.33 from Fedora 13 with the same result. And that's why I guess we might meet a diferrent bug. Anyway, I was wondering does disableing tiling mode OR NOT make difference you there? Thanks.
I'm fil(In reply to comment #28) > 2.6.35 kernel tested, and it works fine here after disabling tiling mode. FYI, > I also tested kernel 2.6.33 from Fedora 13 with the same result. And that's why > I guess we might meet a diferrent bug. I just filed bug#30199. Let's track the tiling bug (the issue met by Yuanhan and me) there.
(In reply to comment #29) > I'm fil(In reply to comment #28) > > 2.6.35 kernel tested, and it works fine here after disabling tiling mode. FYI, > > I also tested kernel 2.6.33 from Fedora 13 with the same result. And that's why > > I guess we might meet a diferrent bug. > I just filed bug#30199. Let's track the tiling bug (the issue met by Yuanhan > and me) there. Hi Manjeet, I made a patch for bug#30199, and it solved that issue. Although I guess we met a different problem, please apply that patch, and do test again. If you still get problem, please comment it here. Thanks.
(lower priority to not appear in our Q3 blocker list...) Manjeet, any news by testing Yuanhan's patch?
Hi Wang, Yuanhan's patch worked for us. We are not seeing any corrption now after resume. You can go ahead and mark this bug as fixed. Thanks for your support. -Manjeet
Thankyou for your testing and your feedback. I have patches in -fixes ready to go upstream, so closing.
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.