There is a S3 resume issue that affects HP Mini Atom N270 with Intel Mobile 945GSE on Linux 3.9.0 upwards. Device: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller [8086:27ae] (rev 03) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device [103c:361a] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at fe980000 (32-bit, non-prefetchable) [size=512K] Region 1: I/O ports at dc80 [size=8] Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M] Region 3: Memory at fe940000 (32-bit, non-prefetchable) [size=256K] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: i915 Issue: On S3 resume screen is blank. I've tracked this down to 2 patches: 1. 24576d23976746cb52e7700c4cadbf4bc1bc3472 drm/i915: enable VT switchless resume v3 This commit stops the screen from turning back on. Without the patch the screen resumes back to on, however it is filled with random vertical lines. 2. fa55583797d12b10928a1813f3dcf066637caf5e drm/i915: fixup the plane->pipe fixup code I have to manually revert this. If I don't I get the random vertical lines on resume.
Start off with a drm.debug=6 dmesg just so we can get a feel for the hardware and what is going on. If you revert the switchless resume patch, then grab intel_reg_dumper output before and after resume, that will highlight what the bios touched. In fact, if you grab intel_reg_dumper after resume with each patch reverted (none, only switchless patch reverted, both patches reverted) that is likely to have sufficient information to figure out both bugs.
Created attachment 90873 [details] dmesg log
I ran intel_reg_dumper, but I am seeing: Gen2/3 Ranges are not supported. Please use unsafe access.
(In reply to comment #3) > I ran intel_reg_dumper, but I am seeing: > > Gen2/3 Ranges are not supported. Please use unsafe access. BEN! You will need to build intel-gpu-tools from git (or a recent stable release).
Created attachment 90886 [details] 3.9.0, no reverts, before S3
Created attachment 90887 [details] 3.9.0, no reverts, after S3
Created attachment 90888 [details] 3.9.0, reverted commit fa55583, before s3
Created attachment 90889 [details] 3.9.0, reverted commit fa55583, built at head b5644d0, before s3
Created attachment 90890 [details] 3.9.0, reverted commit fa55583, built at head b5644d0, after s3
Attached are the requested register dumps. Could not resume on the revert of fa55583, so no "after S3" results for that. Apoligies it took so long, had issues getting build of the latest intel-gpu-tools sorted (other dependancy issues).
Hmm, the BIOS sets DSPCLK_GATE_D DPLUNIT which we don't restore, that may result in some instability on your machine, and it may be generally applicable to gen3 devices.
OK, that's interesting to know. I know for sure that HP aren't doing any BIOS updates on that unit (as I worked on enabling it several years ago).
Out of curiosity more than anything else, can you try diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 27300d6b583b..eb2fa4b89219 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5548,6 +5548,8 @@ static void gen3_init_clock_gating(struct drm_device *dev) if (IS_PINEVIEW(dev)) I915_WRITE(ECOSKPD, _MASKED_BIT_ENABLE(ECO_GATING_CX_ONLY)); + I915_WRITE(DSPCLK_GATE_D, I915_READ(DSPCLK_GATE_D) | DPLUNIT_CLOCK_GATE_DISABLE); + /* IIR "flip pending" means done if this bit is set */ I915_WRITE(ECOSKPD, _MASKED_BIT_DISABLE(ECO_FLIP_DONE)); } and see if that cures the random lines?
Chris, unfortunately that patch does not fix the random vertical lines.
..although I discovered today that the machine later blanks the screen after several of idle and then unblanks it in a fully working state. Not sure if that is a helpful data point to consider.
Colin, just to clarify, do you mean that after an xrandr (or dpms) off/on, everything is back to normal? No random vertical lines? That's more or less what we expected due to "enable VT switchless resume" and userspace missing its hotplug notifications, but I was still expecting the garbage. If you try 3.12/3.13 do we get any more warnings about inconsistent hw state?
so I believe xrandr is sorting this out, running it manually: king@hpmini:~$ xrandr --output LVDS1 --off king@hpmini:~$ xrandr --output LVDS1 --auto seems to get rid of the vertical lines. "If you try 3.12/3.13 do we get any more warnings about inconsistent hw state?" .. I can test with 3.13 later today, but how do I check for inconsistent hw state?
(In reply to comment #17) > so I believe xrandr is sorting this out, running it manually: > > king@hpmini:~$ xrandr --output LVDS1 --off > king@hpmini:~$ xrandr --output LVDS1 --auto > > seems to get rid of the vertical lines. Ok, that just confirms that the hotplug uevent that we send upon resume is just vanishing. I think. > "If you try 3.12/3.13 do we get any more warnings about inconsistent hw > state?" > .. I can test with 3.13 later today, but how do I check for inconsistent hw > state? The kernel has more checks and will print an OOPS report if it finds the hardware in an inconsistent state.
Colin, will it possible to try with drm-intel-nightly (or latest mainline) to see if the state checker catches anything? Also it would be interesting to read an --enable-debug=full Xorg.0.log to see what happened to that uevent.
Today's mainline kernel (top commit 85ce70fdf48aa290b4845311c2dd815d7f8d1fa5) [ 241.352344] INFO: task systemd-udevd:381 blocked for more than 120 seconds. [ 241.352420] Tainted: PF O 3.13.0-3-generic #18-Ubuntu [ 241.352474] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 241.352532] systemd-udevd D f4fd7a24 0 381 270 0x00000004 [ 241.352552] f4fd7a4c 00000086 c12f0573 f4fd7a24 c18294f8 c1a7c780 00000001 00000001 [ 241.352582] c1a7c780 f5858000 f68a0d00 0003d1d6 00000000 f4fd7a1c f86e97df 1b762573 [ 241.352608] f86e97e1 f86e97e1 f86ee998 f4fd7a60 c12f29dc 00000001 00000000 0000ff02 [ 241.352635] Call Trace: [ 241.352663] [<c12f0573>] ? format_decode+0x323/0x390 [ 241.352708] [<c12f29dc>] ? vsnprintf+0x2cc/0x3d0 [ 241.352728] [<c12f0001>] ? put_dec_trunc8+0x61/0xa0 [ 241.352750] [<c16415a3>] schedule_preempt_disabled+0x23/0x60 [ 241.352766] [<c1642eed>] __mutex_lock_slowpath+0x10d/0x171 [ 241.352782] [<c164241c>] mutex_lock+0x1c/0x28 [ 241.352910] [<f8d93aa2>] intel_get_load_detect_pipe+0x152/0x3a0 [i915] [ 241.353059] [<f8dc3142>] ? gen4_read32+0x32/0xb0 [i915] [ 241.353075] [<c12f2b6a>] ? snprintf+0x1a/0x20 [ 241.353195] [<f8d9516d>] intel_modeset_setup_hw_state+0xa7d/0xae0 [i915] [ 241.353273] [<f86cffd8>] ? drm_mode_config_reset+0x98/0xb0 [drm] [ 241.353392] [<f8d951fe>] intel_modeset_gem_init+0x2e/0x40 [i915] [ 241.353490] [<f8d5abfb>] i915_driver_load+0xb3b/0xdc0 [i915] [ 241.353586] [<f8d57e10>] ? i915_switcheroo_set_state+0xa0/0xa0 [i915] [ 241.353706] [<f86cbcab>] drm_dev_register+0x8b/0x1a0 [drm] [ 241.353768] [<f86cd78e>] drm_get_pci_dev+0x7e/0x120 [drm] [ 241.353797] [<c11d8e37>] ? sysfs_do_create_link_sd.isra.2+0xa7/0x1c0 [ 241.353897] [<f8d575ea>] i915_pci_probe+0x3a/0x80 [i915] [ 241.353918] [<c132870f>] pci_device_probe+0x6f/0xc0 [ 241.353934] [<c11d8f75>] ? sysfs_create_link+0x25/0x40 [ 241.353956] [<c13faf65>] driver_probe_device+0x105/0x380 [ 241.353972] [<c1328662>] ? pci_match_device+0xb2/0xc0 [ 241.353992] [<c13fb291>] __driver_attach+0x71/0x80 [ 241.354008] [<c13fb220>] ? __device_attach+0x40/0x40 [ 241.354026] [<c13f93c7>] bus_for_each_dev+0x47/0x80 [ 241.354043] [<c13fa9ce>] driver_attach+0x1e/0x20 [ 241.354057] [<c13fb220>] ? __device_attach+0x40/0x40 [ 241.354072] [<c13fa627>] bus_add_driver+0x157/0x230 [ 241.354093] [<c13fb859>] driver_register+0x59/0xe0 [ 241.354111] [<c10487a0>] ? __set_pmd_pte+0xa0/0xa0 [ 241.354130] [<c1327142>] __pci_register_driver+0x32/0x40 [ 241.354191] [<f86cd925>] drm_pci_init+0xf5/0x100 [drm] [ 241.354223] [<f8655000>] ? 0xf8654fff [ 241.354316] [<f865505e>] i915_init+0x5e/0x60 [i915] [ 241.354333] [<c1002122>] do_one_initcall+0xd2/0x190 [ 241.354352] [<c10e94f8>] ? tracepoint_module_notify+0x118/0x180 [ 241.354372] [<f8655000>] ? 0xf8654fff [ 241.354389] [<c1049daf>] ? set_memory_nx+0x5f/0x70 [ 241.354411] [<c16393ee>] ? set_section_ro_nx+0x54/0x59 [ 241.354432] [<c10c210a>] load_module+0x111a/0x18e0 [ 241.354464] [<c10c2a35>] SyS_finit_module+0x75/0xc0 [ 241.354481] [<c11374cb>] ? vm_mmap_pgoff+0x7b/0xa0 [ 241.354513] [<c164b90d>] sysenter_do_call+0x12/0x28 I'll test the drm-intel-nightly next
(In reply to comment #20) > Today's mainline kernel (top commit 85ce70fdf48aa290b4845311c2dd815d7f8d1fa5) > > [ 241.352344] INFO: task systemd-udevd:381 blocked for more than 120 > seconds. > [ 241.352420] Tainted: PF O 3.13.0-3-generic #18-Ubuntu > [ 241.352474] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 241.352532] systemd-udevd D f4fd7a24 0 381 270 0x00000004 > [ 241.352552] f4fd7a4c 00000086 c12f0573 f4fd7a24 c18294f8 c1a7c780 > 00000001 00000001 > [ 241.352582] c1a7c780 f5858000 f68a0d00 0003d1d6 00000000 f4fd7a1c > f86e97df 1b762573 > [ 241.352608] f86e97e1 f86e97e1 f86ee998 f4fd7a60 c12f29dc 00000001 > 00000000 0000ff02 > [ 241.352635] Call Trace: > [ 241.352663] [<c12f0573>] ? format_decode+0x323/0x390 > [ 241.352708] [<c12f29dc>] ? vsnprintf+0x2cc/0x3d0 > [ 241.352728] [<c12f0001>] ? put_dec_trunc8+0x61/0xa0 > [ 241.352750] [<c16415a3>] schedule_preempt_disabled+0x23/0x60 > [ 241.352766] [<c1642eed>] __mutex_lock_slowpath+0x10d/0x171 > [ 241.352782] [<c164241c>] mutex_lock+0x1c/0x28 > [ 241.352910] [<f8d93aa2>] intel_get_load_detect_pipe+0x152/0x3a0 [i915] > [ 241.353059] [<f8dc3142>] ? gen4_read32+0x32/0xb0 [i915] > [ 241.353075] [<c12f2b6a>] ? snprintf+0x1a/0x20 > [ 241.353195] [<f8d9516d>] intel_modeset_setup_hw_state+0xa7d/0xae0 [i915] > [ 241.353273] [<f86cffd8>] ? drm_mode_config_reset+0x98/0xb0 [drm] > [ 241.353392] [<f8d951fe>] intel_modeset_gem_init+0x2e/0x40 [i915] > [ 241.353490] [<f8d5abfb>] i915_driver_load+0xb3b/0xdc0 [i915] > [ 241.353586] [<f8d57e10>] ? i915_switcheroo_set_state+0xa0/0xa0 [i915] > [ 241.353706] [<f86cbcab>] drm_dev_register+0x8b/0x1a0 [drm] > [ 241.353768] [<f86cd78e>] drm_get_pci_dev+0x7e/0x120 [drm] > [ 241.353797] [<c11d8e37>] ? sysfs_do_create_link_sd.isra.2+0xa7/0x1c0 > [ 241.353897] [<f8d575ea>] i915_pci_probe+0x3a/0x80 [i915] > [ 241.353918] [<c132870f>] pci_device_probe+0x6f/0xc0 > [ 241.353934] [<c11d8f75>] ? sysfs_create_link+0x25/0x40 > [ 241.353956] [<c13faf65>] driver_probe_device+0x105/0x380 > [ 241.353972] [<c1328662>] ? pci_match_device+0xb2/0xc0 > [ 241.353992] [<c13fb291>] __driver_attach+0x71/0x80 > [ 241.354008] [<c13fb220>] ? __device_attach+0x40/0x40 > [ 241.354026] [<c13f93c7>] bus_for_each_dev+0x47/0x80 > [ 241.354043] [<c13fa9ce>] driver_attach+0x1e/0x20 > [ 241.354057] [<c13fb220>] ? __device_attach+0x40/0x40 > [ 241.354072] [<c13fa627>] bus_add_driver+0x157/0x230 > [ 241.354093] [<c13fb859>] driver_register+0x59/0xe0 > [ 241.354111] [<c10487a0>] ? __set_pmd_pte+0xa0/0xa0 > [ 241.354130] [<c1327142>] __pci_register_driver+0x32/0x40 > [ 241.354191] [<f86cd925>] drm_pci_init+0xf5/0x100 [drm] > [ 241.354223] [<f8655000>] ? 0xf8654fff > [ 241.354316] [<f865505e>] i915_init+0x5e/0x60 [i915] > [ 241.354333] [<c1002122>] do_one_initcall+0xd2/0x190 > [ 241.354352] [<c10e94f8>] ? tracepoint_module_notify+0x118/0x180 > [ 241.354372] [<f8655000>] ? 0xf8654fff > [ 241.354389] [<c1049daf>] ? set_memory_nx+0x5f/0x70 > [ 241.354411] [<c16393ee>] ? set_section_ro_nx+0x54/0x59 > [ 241.354432] [<c10c210a>] load_module+0x111a/0x18e0 > [ 241.354464] [<c10c2a35>] SyS_finit_module+0x75/0xc0 > [ 241.354481] [<c11374cb>] ? vm_mmap_pgoff+0x7b/0xa0 > [ 241.354513] [<c164b90d>] sysenter_do_call+0x12/0x28 > > I'll test the drm-intel-nightly next For reference that looks to be fixed with commit 7ad228b11ec26a820291c9f5a1168d6176580dc1 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Jan 7 16:15:36 2014 +0200 drm/i915: Don't grab crtc mutexes in intel_modeset_gem_init() When the pipe A force quirk is applied the code will attempt to grab a crtc mutex during intel_modeset_setup_hw_state(). If we're already holding all crtc mutexes this will obviously deadlock every time. So instead of using drm_modeset_lock_all() just grab the mode_config.mutex. This is enough to avoid the unlocked mutex warnings from certain lower level functions. The regression was introduced in: commit 027476642811f8559cbe00ef6cc54db230e48a20 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Dec 2 11:08:06 2013 +0200 drm/i915: Take modeset locks around intel_modeset_setup_hw_state() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org [danvet: Add cc: stable since the offending commit has that, too.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I tried today's drm-intel-nightly and all I get is a black screen, spinning CPU and I can't ssh in to see what's happening.
(In reply to comment #22) > I tried today's drm-intel-nightly and all I get is a black screen, > spinning CPU and I can't ssh in to see what's happening. Ville went right away and created another regression in the load detect code ;-) Patch should get merged soon.
(In reply to comment #19) > Colin, will it possible to try with drm-intel-nightly (or latest mainline) > to see if the state checker catches anything? > > Also it would be interesting to read an --enable-debug=full Xorg.0.log to > see what happened to that uevent. Time to retry. Hopefully.
Colin can you please also attach your Xorg.0.log? I just want to check that it is setup to receive hotplug events - but having it available should help any future queries.
Created attachment 93360 [details] tarball of dmesg output and Xorg.0.log Attached is dmesg.log and Xorg.0.log tarball using today's drm-intel-nightly. S3 resume still results in a blank screen.
For the record, X has hotplug (uevents) enabled.
Timeout, please re-test on current drm-intel-nightly.
Bug reporter seems to have disappeared, so closing. If this is still an issue please reopen.
I'm still experiencing this issue. I'll be happy to do whatever is needed and provide any information that will help resolve it.
Can you confirm it still happens with the latest drm-intel-nightly? Please provide dmesg with the kernel running with drm.debug=6 in its command line, and also you Xorg.0.log.
Created attachment 110965 [details] New Xorg.0 and dmesg logs Based on intel-drm-nightly, 12/16/14
Comment on attachment 93360 [details] tarball of dmesg output and Xorg.0.log With new intel-drm-nightly, blank screen / cpu spinning happens at boot. If I run in recovery mode I can get to the desktop, and then the same behavior occurs on suspend/resume. These logs reflect the first case.
(In reply to Peter Rimshnick from comment #33) > Comment on attachment 93360 [details] > tarball of dmesg output and Xorg.0.log Did you set drm.debug=6 in the kernel command line? The dmesg output is missing debugging information.
(In reply to Ander Conselvan de Oliveira from comment #34) > (In reply to Peter Rimshnick from comment #33) > > Comment on attachment 93360 [details] > > tarball of dmesg output and Xorg.0.log > > Did you set drm.debug=6 in the kernel command line? The dmesg output is > missing debugging information. I think I accidentally commented on the wrong attachment. My logs are attachment 110965 [details]. If you grep dmesg for "drm" you can see my command line. Please let me know if it is incorrect. Thanks!
Created attachment 111040 [details] [review] Fix warn on pipe disabled assertion (In reply to Peter Rimshnick from comment #35) > (In reply to Ander Conselvan de Oliveira from comment #34) > > Did you set drm.debug=6 in the kernel command line? The dmesg output is > > missing debugging information. > > I think I accidentally commented on the wrong attachment. My logs are > attachment 110965 [details]. If you grep dmesg for "drm" you can see my > command line. Please let me know if it is incorrect. Thanks! Ah, I was looking at the wrong thing. Can you apply this patch and run it again. It probably won't fix the problem, but it moves the first reported error out of the way, so it might help with debugging the real issue.
Created attachment 111183 [details] Dmesg and Xorg logs with new patch I've attached output with new logs. Same result (black screen) as last time, but the dmesg does look slightly different.
Are the latest logs I posted helpful? Let me know if you think I messed up somehow or need any other info. Thanks.
Looks like a crash (on resume?), I'll take a look.
(In reply to Jesse Barnes from comment #39) > Looks like a crash (on resume?), I'll take a look. Yes this is the drm_mm fumble I think. It's fixed in latest kernels, so unfortunately you need to retest. Relevant patch commit 046d669c62f37323ef0329c41d83a03c06b2087d Author: Krzysztof Kolasa <kkolasa@winsoft.pl> Date: Sun Mar 15 20:22:36 2015 +0100 [PATCH] drm/mm: Fix support 4 GiB and larger ranges
Created attachment 114972 [details] Logs using generic-4.0.0-994_4.0.0-994.201504072205 Using mainline kernel drm-intel-nightly--2015-04-09
(In reply to Peter Rimshnick from comment #41) > Created attachment 114972 [details] > Logs using generic-4.0.0-994_4.0.0-994.201504072205 > > Using mainline kernel drm-intel-nightly--2015-04-09 Unfortunately, same as before - does not even boot into desktop, let alone resume from suspend. Let me know if I'm not using the right kernel. Thanks!
I don't think Jesse will be working on this anymore... Have you tried more recent kernels?
Haven't tried more recent kernels.. Will try to get around to that soon.
Peter - could we close this bug or is this still valid?
(In reply to Jari Tahvanainen from comment #45) > Peter - could we close this bug or is this still valid? Hi Jari, You can close. I can't confirm whether it's still valid since I no longer have that machine. Best, Peter
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.