Bug#363559: xserver-xorg-video-ati: system freezes on Thinkpad T42
Ah, great. I was wondering how something like this could slip through the cracks. Still, at some point maybe we should back up the ATI driver to the older version, if that is even possible? Or, maybe there is a manual workaround that is not much trouble? Backing up via snapshot.debian.net is a real chore in this case. -Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363559: xserver-xorg-video-ati: system freezes on Thinkpad T42
Package: xserver-xorg-video-ati Version: 1:6.5.7.3-3 Severity: important The current version of the ati driver causes my Thinkpad T42 to freeze a few minutes after X is started. Changing to the vesa driver causes the freezes to stop. Commenting out all loaded modules from the Module section of xorg.conf causes the freeze to take longer to happen, but it does not prevent it. Likewise, turning off hardware acceleration with the NoAccel option does not prevent the freezes (though I do not recall whether NoAccel made the freeze take longer to happen). The chipset is: (--) RADEON(0): Chipset: ATI FireGL Mobility T2 (M10) NT (AGP) (ChipID = 0x4e54) For now I have used snapshot.debian.net to downgrade to 6.8.2.dfsg.1-6 and all is well again. I have been having this problem for much or all of 2006. I believe 6.9.x already had the problem, and no update through 1:6.5.7.3-3 has fixed it. The following thread describes the same problem I am seeing, but unfortunately with no resolution reached: http://hardware.mcse.ms/archive42-2006-1-276052.html Here is my xorg.conf: # xorg.conf.dpkg-new (Xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf.dpkg-new manual page. # (Type man xorg.conf.dpkg-new at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/xorg.conf.dpkg-new /etc/X11/xorg.conf.dpkg-new.custom # md5sum /etc/X11/xorg.conf.dpkg-new /var/lib/xfree86/xorg.conf.dpkg-new.md5sum # dpkg-reconfigure xserver-xorg Section Files FontPathunix/:7101 FontPathunix/:7100 # if the local font server has problems, we can fall back on these FontPath/usr/lib/X11/fonts/misc FontPath/usr/lib/X11/fonts/cyrillic FontPath/usr/lib/X11/fonts/100dpi/:unscaled FontPath/usr/lib/X11/fonts/75dpi/:unscaled FontPath/usr/lib/X11/fonts/Type1 FontPath/usr/lib/X11/fonts/CID FontPath/usr/lib/X11/fonts/100dpi FontPath/usr/lib/X11/fonts/75dpi EndSection Section Module Loadbitmap Loaddbe Loadddc Loaddri Loadextmod Loadfreetype Loadglx Loadint10 Loadrecord Loadtype1 Loadv4l Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xorg Option XkbModel pc105 Option XkbLayout dvorak EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/input/mice Option Protocol ExplorerPS/2 Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section InputDevice Identifier Synaptics Touchpad Driver synaptics Option SendCoreEventstrue Option Device/dev/psaux Option Protocol auto-dev Option HorizScrollDelta 0 EndSection Section Device Identifier ATI Driver ati BusID PCI:1:0:0 Option DynamicClocks on Option UseFBDev false Option MonitorLayout LVDS, CRT #Option NoAccel true # reasonable guesses at limits Option CRT2HSync15-92 # Option CRT2VRefresh 50-85 # the Dell LCD I am using at EPFL can only handle 1600x1200 at 60 Hz Option CRT2VRefresh 50-60 Option MergedFB on EndSection Section Device Identifier Framebuffer Driver fbdev EndSection Section Device Identifier VESA Driver vesa Option ModeSetClearScreen off EndSection Section Monitor Identifier Generic Monitor Option DPMS DisplaySize 305 229 EndSection Section Screen Identifier Default Screen Device ATI # Device Framebuffer # Device VESA Monitor Generic Monitor DefaultDepth24 SubSection Display Depth 1 Modes 1600x1200 1024x768 800x600 640x480 EndSubSection
Bug#347680: Xorg breaks acpid
Marcus's analysis looks right to me: But who can tell which is the grand-piece-of-sw that has the exclusive right to open /proc/acpi/event? The one which has been designed to multiplex the events to make them available to other programs, and it's acpid. The standard Debian setup is to use acpid to multiplex the event stream. Even if it is possible to run with acpid, that should be a different, non-standard option. There are lots of reasons to multiplex in userspace instead of in the kernel. Among these is that a userspace multiplexer can filter and modify the stream as it goes by, and a userspace multiplexer can pull events from multiple sources including virtual events injected by other sources than the raw hardware. The earlier comments that obviously the kernel should multiplex just aren't right. Doing it in userspace makes sense, and if it is done in userspace, then additionally doing it in the kernel would be a bad thing. At any rate, the current strategy isn't right. If the system is using acpid--the most common configuration--then it is a bug for X to get in the way of acpid. It is laudable that Xorg currently tries to support ACPI even when acpid is not running. However, this is an unusual and only marginally useful configuration, isn't it? Thus, if nothing else, it would seem to make sense to simply remove the non-acpid ACPI support when compiling for Debian. In that case, the party line would be, if you want to use ACPI, then you install acpid and programs talk to that. If it is still desirable to make X work without acpid around, then that should surely be a non-standard configuration which requires an *explicit* configuration option on the X server. This does not appear worthwhile for Debian, since we do have acpid easily installable, but maybe it is sufficiently worthwhile for other Linux distributions that it is worth including. -Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
