Re: xserver-xorg-video-intel does sometimes not resume
Julien,
many thanks for the quick and useful reply.
Am Tuesday, 20. September 2011 schrieb Julien Cristau:
> On Tue, Sep 20, 2011 at 12:32:46 +0200, Rainer Dorsch wrote:
> > Hello,
> >
> > I have occasionally (maybe once a week) the problem, that my system does
> > not resume after a suspend. To be precise: the screen has no signal, but
> > the system itself is up an running (and re-suspends after 10 minutes of
> > inactivity as configured). When I resume the re-suspend, that usually
> > works. I.e. here the complete sequence:
> >
> > 1. System suspends
> > 2. Resume, but occasionally no video signal available
> > 3. System re-suspends automatically after 10 minutes of inactivity
> > 4. Resume usually works (or sampling rate too small to hit the problem)
> >
> > I am wondering what I could do to figure out the root cause of the
> > problem. I forgot to try, but I assume, that I could ssh into the
> > machine and do some diagnosis, when the problem occurs. Are there logs
> > which could help? I attach the syslog below...
>
> Boot with drm.debug=6 and compare dmesg from a successful vs failed
> resume.
I booted with drm.debug=6 and found that there is an intermittent detection
problem with the monitor ("CRT not detected via hotplug"):
rd@blackbox:~/tmp.nobackup$ diff -u syslog-intel.drm-1303.part syslog-
intel.drm-1340.part
--- syslog-intel.drm-1303.part 2011-09-21 13:52:26.103280388 +0200
+++ syslog-intel.drm-1340.part 2011-09-21 13:54:31.949381096 +0200
@@ -9,14 +9,6 @@
[drm:drm_crtc_helper_set_config],
[drm:drm_crtc_helper_set_config], [CRTC:3] [FB:17] #connectors=1 (x y) (0 0)
[drm:drm_crtc_helper_set_config], [CONNECTOR:8:HDMI-A-1] to [CRTC:3]
-[drm:intel_crt_detect], CRT not detected via hotplug
-[drm:output_poll_execute], [CONNECTOR:5:VGA-1] status updated from 2 to 2
-[drm:intel_sdvo_debug_write], SDVOB: W: 0B
(SDVO_CMD_GET_ATTACHED_DISPLAYS)
-[drm:intel_sdvo_read_response], SDVOB: R: (Success) 01 00
-[drm:intel_sdvo_detect], SDVO response 1 0 [1]
-[drm:intel_sdvo_debug_write], SDVOB: W: 7A 02
(SDVO_CMD_SET_CONTROL_BUS_SWITCH)
-[drm:intel_sdvo_debug_write], SDVOB: W: 7A 02
(SDVO_CMD_SET_CONTROL_BUS_SWITCH)
-[drm:output_poll_execute], [CONNECTOR:8:HDMI-A-1] status updated from 1 to 1
[drm:i915_get_vblank_counter], trying to get vblank count for disabled pipe B
[drm:intel_opregion_setup], graphic opregion physical addr: 0xcf78e0f4
[drm:intel_opregion_setup], Public ACPI methods supported
@@ -97,10 +89,8 @@
[drm:drm_mode_debug_printmodeline], Modeline 13:"640x480" 60 25200 640 656
752 800 480 490 492 525 0x40 0xa
[drm:drm_mode_debug_printmodeline], Modeline 14:"720x400" 70 28320 720 738
846 900 400 412 414 449 0x40 0x6
[drm:drm_mode_getconnector], [CONNECTOR:8:?]
-[drm:drm_mode_addfb], [FB:24]
[drm:intel_crtc_cursor_set],
-[drm:drm_mode_addfb], [FB:21]
-[drm:drm_mode_addfb], [FB:24]
+[drm:drm_mode_addfb], [FB:25]
[drm:intel_crt_detect], CRT not detected via hotplug
[drm:output_poll_execute], [CONNECTOR:5:VGA-1] status updated from 2 to 2
[drm:intel_sdvo_debug_write], SDVOB: W: 0B
(SDVO_CMD_GET_ATTACHED_DISPLAYS)
rd@blackbox:~/tmp.nobackup$
Monitor is an EIZO FlexScan L767
Full log is here
http://bokomoko.de/~rd/syslog-drm.6
around 13:03 the resume was not detecting the monitor, around 13:40 the resume
was detecting the monitor.
Does anybody have an idea what could go wrong?
Does anybody have an idea what I could do as a workaround? E.g. can I ask the
driver to retry three times, when the CRT is not detected? Can I enforce that
the monitor is driven (it is a desktop and never changed)? Other ideas?
Thanks,
Rainer
--
Rainer Dorsch
http://bokomoko.de/
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201109211412.01145...@bokomoko.de
Bug#642374: xauth: Doesn't seem to handle concurrency [SEC=UNCLASSIFIED]
Package: xauth Version: 1:1.0.6-1 Severity: normal for run in `seq 1 10` do ssh -X -l "xload" & done /usr/bin/xauth: error in locking authority file /home//.Xauthority X11 connection rejected because of wrong authentication. A sleep 0.1 though lets it through (most of the time, but like all race conditions, this is a deeply evil hack). One suspects xauth shouldn't just fail immediately if it can't hardlink the lockfile. Act more like procmail's lockfile utility, and back off a bit while retrying. -- System Information: Debian Release: wheezy/sid APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'stable'), (5, 'testing'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xauth depends on: ii libc6 2.13-7 Embedded GNU C Library: Shared lib ii libx11-6 2:1.4.3-2 X11 client-side library ii libxau6 1:1.0.6-3 X11 authorisation library ii libxext6 2:1.3.0-3 X11 miscellaneous extension librar ii libxmuu1 2:1.1.0-2 X11 miscellaneous micro-utility li xauth recommends no packages. xauth suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110922003828.27034.23637.report...@weinberg.bom.gov.au
Bug#642387: libx11-6: Leak found under valgrind in XGetVisualInfo (VisUtil.c:135)
Package: libx11-6 Version: 2:1.4.4-1 Severity: minor Dear Maintainer, Found while valgrinding wine (wine-1.3.28-451-ge2cc32d / git-sha1sum: e2cc32d252c01f3b00ef02a2084a810a082ff0a9): ==17495== 2,800 bytes in 1 blocks are definitely lost in loss record 849 of 883 ==17495==at 0x4025D22: realloc (vg_replace_malloc.c:488) ==17495==by 0x577238C: XGetVisualInfo (VisUtil.c:135) ==17495==by 0x7BC34932: interlocked_inc (critsection.c:45) ==17495==by 0x7BC3535B: RtlEnterCriticalSection (critsection.c:546) ==17495==by 0x594185B: glXGetFBConfigs (glxapi.c:552) ==17495==by 0x56CB9E4: X11DRV_ChoosePixelFormat (opengl.c:1227) ==17495==by 0x4DED422: ChoosePixelFormat (painting.c:551) ==17495==by 0x4F7D525: WineD3D_CreateFakeGLContext (directx.c:324) ==17495==by 0x4F9757F: InitAdapters (directx.c:5257) ==17495==by 0x4F982A8: wined3d_init (directx.c:5480) ==17495==by 0x503AFE1: wined3d_create (wined3d_main.c:105) ==17495==by 0x4EED127: Direct3DCreate9 (d3d9_main.c:43) ==17495==by 0x4930831: test_setting_constants (shader.c:637) ==17495==by 0x49313C9: func_shader (shader.c:855) ==17495==by 0x493D179: run_test (test.h:556) ==17495==by 0x493D569: main (test.h:624) ==17495== script used: export LD_LIBRARY_PATH="/home/austin/src/mesa/lib" export LIBGL_DRIVERS_PATH="/home/austin/src/mesa/lib/gallium" export VALGRIND_OPTS="-q --trace-children=yes --track-origins=yes --gen-suppressions=all --suppressions=$HOME/wine-git/tools/valgrind/valgrind-suppressions --leak-check=full --num-callers=20 --workaround-gcc296-bugs=yes --vex-iropt-precise-memory-exns=yes" export WINETEST_WRAPPER='valgrind' export WINE_HEAP_TAIL_REDZONE=32 cd $HOME/wine-git/dlls/d3dx9_36/tests make shader.ok Expected outcome: no leaks outside of Wine Actual outcome: Leak from X11. *** End of the template - remove these lines *** -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libx11-6 depends on: ii libc6 2.13-18 ii libx11-data2:1.4.4-1 ii libxcb11.7-3 ii multiarch-support 2.13-18 libx11-6 recommends no packages. libx11-6 suggests no packages. -- no debconf information -- -Austin -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACC5Q1c6EniHXZ_i1v6+xqZnKS-8Tjz0bhPjYDJyQWo61=o...@mail.gmail.com
