Bug#884829: Still present in Debian 11
A small update: I managed to rebuild the xserver-xorg-core package with the patch applied, but the leak persists. So while it manifests the same way and can be triggered by the same application, my problem seems to have a different cause. On a second thought, it makes sense: if I understand it correctly, XAA, EXA, UXA etc. were replaced by Glamor in recent years. And from the Xorg log it seems that that's what my laptop uses (Intel HD 5500), so I should not experience any issues coming from the EXA code, right? I'm not very experienced with Valgrind, but I'll send an update if I manage to set it up and find anything of interest. Martin P.S. I had no clue about this transition to Glamor; Debian now generally works well out of the box, so I'm not learning about new stuff by constantly fixing stuff. :))
Bug#884829: Still present in Debian 11
Hi, I can confirm this bug still exists in xserver-xorg-core 2:1.20.11-1+deb11u1; I have been suffering from it ever since I upgraded from Debian 10 to Debian 11 a few months ago. The memory usage of Xorg process keeps growing until eventually the laptop becomes unresponsive and OOM killer starts reaping random processes and everything comes crashing down. In my case, I tracked the problem mainly to xfdesktop4 and xfce4-panel (leaking about 5 MB per hour when the machine is idle). Only when I kill both of them the increase in memory consumption stops, although the already consumed memory is not released. Using the machine makes the rate of leaking worse, so clearly there are many other sources that can trigger the leak. I can also confirm that if I install audacious and play it with the visualization on, the leak increases to about 57 MB per hour, so the problem I experience is very likely the same one as reported here. I'm really happy to finally learn I'm not crazy and someone else noticed the issue as well (although I did not expect it to go all the way back to 2017). Is there anything I can do to help move this along? Should I try testing the patch? Or open a bug report upstream? Thanks, Martin
Bug#680514: xserver-xorg-video-intel: freezes also occuring in Jessie
Package: xserver-xorg-video-intel Version: 2:2.21.15-2+b2 Followup-For: Bug #680514 Hi there, I'm experiencing this issue over one month now and I'm running an up to date jessie system (kernel 3.16.0-4-amd64, xserver-xorg-video-intel 2:2.21.15-2+b2, xserver-xorg-core 2:1.16.1.901-1). I'm not able to find any trigger for the lock-up, the bug just randomly appears "out of the blue". Once I also found my laptop "frozen" this way in the morning; the system was idle for at least several hours when the lock-up occured. As reported earlier, it is still possible to SSH into the machine; what I think was not reported is that it is _sometimes_ possible to revive the system by executing pm-suspend via SSH - the screen goes off for a while, turns immediately back on and everything works perfectly again. Sometimes, however, the pm-suspend succeeds and xserver remains frozen even after waking up, no matter how many times I try executing pm-suspend. In the latter case I also noticed that it takes more time than usual to finish suspending. Any idea what should I look for when it happens again? I'm running into this bug few times a week so I could try to learn more, but the logs do not seem to reveal anything useful.. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Oct 4 2013 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 2397280 Nov 3 22:52 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) Xorg X server configuration file status: -rw-r--r-- 1 root root 152 May 22 2014 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: --- Section "Device" Identifier "Intel Graphics" Driver "intel" Option "AccelMethod" "sna" Option "TearFree" "true" EndSection /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-13) ) #1 SMP Debian 3.16.7-2 (2014-11-06) Xorg X server log files on system: -- -rw-r--r-- 1 root root 20725 Dec 11 18:23 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [ 3.985] X.Org X Server 1.16.1.901 (1.16.2 RC 1) Release Date: 2014-11-02 [ 3.985] X Protocol Version 11, Revision 0 [ 3.985] Build Operating System: Linux 3.2.0-4-amd64 x86_64 Debian [ 3.985] Current Operating System: Linux hx31 3.16.0-4-amd64 #1 SMP Debian 3.16.7-2 (2014-11-06) x86_64 [ 3.985] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=0d377c28-a14d-4365-ab55-3d9f001fb7b5 ro quiet pcie_aspm=force drm.vblankoffdelay=1 i915.semaphores=1 nmi_watchdog=0 acpi_osi= [ 3.985] Build Date: 03 November 2014 09:44:08PM [ 3.985] xorg-server 2:1.16.1.901-1 (http://www.debian.org/support) [ 3.985] Current version of pixman: 0.32.6 [ 3.985]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 3.985] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 3.985] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Dec 11 18:21:02 2014 [ 3.987] (==) Using config file: "/etc/X11/xorg.conf" [ 3.987] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 3.994] (==) No Layout section. Using the first Screen section. [ 3.994] (==) No screen section available. Using defaults. [ 3.994] (**) |-->Screen "Default Screen Section" (0) [ 3.994] (**) | |-->Monitor "" [ 3.994] (==) No device specified for screen "Default Screen Section". Using the first device section listed. [ 3.994] (**) | |-->Device "Intel Graphics" [ 3.994] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 3.994] (==) Automatically adding devices [ 3.994] (==) Automatically enabling devices [ 3.994] (==) Automatically adding GPU devices [ 3.997] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 3.997]Entry deleted from font path. [ 4.025] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 4.025] (==) ModulePath set to "/usr/lib/xorg/modu
Bug#595189: xserver-xorg-input-all: no support for WALTOP tablets
Package: xserver-xorg-input-all Version: 1:7.5+6 Severity: normal After xorg has switched to direct udev-based hardware detection instead of using HAL, I've been unable to get my tablet working. I've been using patched waltop driver and since I don't really understand the udev rules system, I can't prevent evdev driver (which is not working) from taking it over. Anyway, this doesn't change the fact, that WALTOP tablets don't work in Debian without self-help and good knowledge about udev etc. (virtually every how-to found on the web still refers to getting it working using HAL). There are three possible ways, how to get it working: 1) Patched version of xserver-xorg-input-wacom driver with disabled vendor-ID check. linuxacom driver was working well with WALTOP tablets until the vendor- ID check blocked any devices other than Wacom. More information for example at https://bugs.launchpad.net/ubuntu/+source/xf86 -input-wacom/+bug/392825 2) There are several reports in Ubuntu bug tracking system, that some people succeeded by installing the wizardpen driver (now available from https://launchpad.net/~doctormo/+archive/xorg-wizardpen, it was dead project for several years). 3) Fixing the xserver-xorg-input-evdev driver. At this moment, when I plug in the tablet (Genius G-pen F350), evdev is loaded to handle it. It appears to be working at first, but as soon as I "click" at the surface (or push any button at the pen) the cursor stops moving. It moves only when i hold some button, the tip is in contact with the tablet, or if the pen is taken out of range and back again. By loading a evbug module I've found out, that even though the cursor doesn't move anymore, the events are generated as usual, so the problem is most likely somewhere in the xorg evdev driver, not in the kernel support. ( 4) there's also the official driver from Wacom, but it doesn't work with new kernel and xorg and as far as I know, it's probably based on the linuxwacom driver) The best solution would be using the Wacom driver because it includes tools for testing and setting some advanced options. The same goes for wizardpen, but one can't be sure, if the development won't stop again... -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.36-rc3 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20100901204554.24838.65735.report...@hackup
