Bug#252895: /usr/X11R6/bin/xfontsel: [xfontsel] crash
I can reproduce this bug, both for xfontsel and emacs. Removing msttcorefonts doesn't seem to make a difference. xlsfonts reports 7258 fonts, xfontsel reports 9930 names. One potentially interesting data point is that, for me, this only happens for locales other than C or en_US (i.e. "LC_ALL=C xfontsel" works, but "LC_ALL=el_GR xfontsel" does not). Vassilis.
Bug#261251: xserver-xfree86: [ati/radeon+crusoe] Xclients are crashing at start
On Sat, 2004-07-24 at 20:04, Michel Dänzer wrote: > > It's still the same bug though, why are you reporting it as a new one? > Merging with the existing bugs about this problem... The first bug was reported to be a bug of the xlibs and I though that it was changing a bit to relate it to the xserver package now. (Moreover, I lost the reference to the last mail I sent...) Sorry for this. > It's certainly not the graphics chip, as the code which generates the > error isn't even near the driver, let alone the hardware, and people are > seeing the problem with a variety of graphics chips, but only with > Transmeta CPUs. Ok. I might have been too fast to draw hypothesis on this. But I am now sure that we have to go deeper (i.e. in the Xserver). I don't know where it will stop. > Interesting. So it sounds like the optimized code either contains some > instruction(s) that work slightly differently on Transmeta CPUs than on > other x86 CPUs, and/or it triggers a bug in the code morphing. Hum, does it means that the XFree86-debug does not contain any optimization ? If so, I have to tell you that I actually tried to compile one Xserver with debug and no optimization (I removed all the -O2 from the Makefiles). And it was working. In fact, when debug is activated it seems to work. If somebody knows what are the differences between a normal binary and a binary with debug options, I would like to know. And if one of these differences can explain such behavior, then I really would like to know. :) > Can others seeing the problem confirm that it doesn't happen with the > XFree86-debug server from xserver-xfree86-dbg? Just to make it more clear where is the breaking point, here are some hints: - start the Xserver and the Xserver only - run gdb on xlogo - put a break on the function _XReply in the file XlibInt.c - after 9 times through this break you should encounter the bug. The size of the 9th message sent by xlogo is 476 and the wrong reply from the Xserver is 32. Regards -- Emmanuel Fleury Computer Science Department, | Office: B1-201 Aalborg University, | Phone: +45 96 35 72 23 Fredriks Bajersvej 7E, | Fax:+45 98 15 98 89 9220 Aalborg East, Denmark | Email: [EMAIL PROTECTED]
Bug#216933: Bug#261251: xserver-xfree86: [ati/radeon+crusoe] Xclients are crashing at start
priority 261251 normal merge 261251 216933 thanks On Sat, 2004-07-24 at 17:17 +0200, Emmanuel Fleury wrote: > > I am hunting a very strange bug (probably hardware related). This bug > has been reported by several people in bug #234556 as a bug of the > xlibs package but I think I managed to push it down to the xserver > package now (at least I believe so). It's still the same bug though, why are you reporting it as a new one? Merging with the existing bugs about this problem... > This bug seems to appear only on architectures which contain a > processor Transmeta Crusoe and/or a graphic card ATI Radeon Mobility > (mine is a Radeon Mobility M6 LY). I should emphase the fact that we > don't know which one from the Crusoe or the Radeon is responsible of > this problem (in fact, I don't even know if it is hardware). It's certainly not the graphics chip, as the code which generates the error isn't even near the driver, let alone the hardware, and people are seeing the problem with a variety of graphics chips, but only with Transmeta CPUs. > I compiled an Xserver with the debug options in order to follow what > was going on inside the Xserver. I reached the specific mode where the > bug was occurring and ran the Xserver with debug and... it worked. I > mean the Xclient connected normally to the Xserver with debug. Of > course, I checked that I was still into the specific mode by using a > non-debug Xserver and the problem was still here. > > At first, I really though I did something wrong while the compilation, > so I took the Xserver package with debug options and it was the exact > same behavior (i.e. once in the specific mode the XFree86 was crashing > all the Xclients and the XFree86-debug was allowing the Xclients to > connect). Interesting. So it sounds like the optimized code either contains some instruction(s) that work slightly differently on Transmeta CPUs than on other x86 CPUs, and/or it triggers a bug in the code morphing. Can others seeing the problem confirm that it doesn't happen with the XFree86-debug server from xserver-xfree86-dbg? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Processed: Re: Bug#261251: xserver-xfree86: [ati/radeon+crusoe] Xclients are crashing at start
Processing commands for [EMAIL PROTECTED]: > priority 261251 normal Bug#261251: xserver-xfree86: [ati/radeon+crusoe] Xclients are crashing at start Severity set to `normal'. > merge 261251 216933 Bug#216933: libx11-6: many clients get BadLength error from X_ChangeProperty request (Transmeta Crusoe smoking gun) Bug#261251: xserver-xfree86: [ati/radeon+crusoe] Xclients are crashing at start Mismatch - only Bugs in same state can be merged: Values for `package' don't match: #216933 has `libx11-6'; #261251 has `xserver-xfree86' > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#261251: xserver-xfree86: [ati/radeon+crusoe] Xclients are crashing at start
Package: xserver-xfree86 Version: 4.3.0.dfsg.1-6 Severity: important Hi all, I am hunting a very strange bug (probably hardware related). This bug has been reported by several people in bug #234556 as a bug of the xlibs package but I think I managed to push it down to the xserver package now (at least I believe so). This bug seems to appear only on architectures which contain a processor Transmeta Crusoe and/or a graphic card ATI Radeon Mobility (mine is a Radeon Mobility M6 LY). I should emphase the fact that we don't know which one from the Crusoe or the Radeon is responsible of this problem (in fact, I don't even know if it is hardware). The problem is the following, from time to time at boot the laptop enter in a specific mode where the bug occurs. Since this mode has been reached the bug is fully reproducible, but I don't know yet what are the conditions to enter in this mode. So the only way to reach the bug is to reboot several time until you reach this mode. The bug itself is that the Xserver does not accept any connection from any Xclient. Each time a Xclient is trying to connect the Xserver we get the following message (exemple using xlogo): [EMAIL PROTECTED] xlogo]$ ./xlogo X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 18 (X_ChangeProperty) Serial number of failed request: 16 Current serial number in output stream: 19 You can perfectly stop and start again the Xserver but only the Xserver (using xinit will fail because of the attempt to start the xconsole, but using only /usr/bin/X11/X or /usr/bin/X11/XFree86 will work). I started to debug from one Xclient (xlogo) compiled with debug option and no optimization (it was misleading gdb) and the xlib compiled also with debug and no optimization. I appeared that the Xclient makes an attempt to connect to the Xserver and send 9 messages to the Xserver. But when getting the 9th answer from the Xserver, the size of the message (or the message itself, I don't know) seems to be unexpected from the Xclient and makes it terminate. So, the bug is probably deeper in the Xserver (the behavior of the Xclient seems to be as expected). This is here that things are starting to be strange... I compiled an Xserver with the debug options in order to follow what was going on inside the Xserver. I reached the specific mode where the bug was occurring and ran the Xserver with debug and... it worked. I mean the Xclient connected normally to the Xserver with debug. Of course, I checked that I was still into the specific mode by using a non-debug Xserver and the problem was still here. At first, I really though I did something wrong while the compilation, so I took the Xserver package with debug options and it was the exact same behavior (i.e. once in the specific mode the XFree86 was crashing all the Xclients and the XFree86-debug was allowing the Xclients to connect). Then I tried to do the following: - run XFree86 (no debug) - run gdb on xlogo and stop just before send the 9th message - run gdb on XFree86 (no debug) and attach to the first XFree86 My hope was to be able to disassemble the functions and follow what was going on. The problem was that while attaching the process XFree86 was suddenly taking all the cpu time and nothing was happening (an interesting point is that when not in this specific mode where the bug is happening, this operation is possible). So, now I'm stuck. I really don't know how to go deeper in XFree86. My theory is that there is a problem with the driver of the Radeon Mobility (maybe combined with some specific feature of the motherboard for the Crusoe). Does anybody have an idea ? Regards -- Emmanuel -- Package-specific info: Contents of /var/lib/xfree86/X.roster: xserver-xfree86 xserver-xfree86-dbg /var/lib/xfree86/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 20 Aug 23 2003 /etc/X11/X -> /usr/bin/X11/XFree86 -rwxr-xr-x 1 root root 1745388 Jul 7 17:07 /usr/bin/X11/XFree86 Contents of /var/lib/xfree86/XF86Config-4.roster: xserver-xfree86 xserver-xfree86-dbg VGA-compatible devices on PCI bus: :00:0c.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY /etc/X11/XF86Config-4 does not match checksum in /var/lib/xfree86/XF86Config-4.md5sum. XFree86 X server configuration file status: -rw-r--r-- 1 root root 15888 Jul 16 17:42 /etc/X11/XF86Config-4 Contents of /etc/X11/XF86Config-4: # # XFree86 4.x configuration for Sony PCG-C1MZX # Version: 1.0 # # Author: Emmanuel Fleury <[EMAIL PROTECTED]> # # 28-aug-2003: First version based on the file of # Felix Groebert <[EMAIL PROTECTED]> # # # Copyright (c) 1999 by The XFree86 Project, Inc. # # Permission is hereby granted, free of charge, to any person obtaining a # copy of this software and associated documentation files (the "Software"), # to deal in the Software without restriction, including without limitation # the rig
Bug#261239: xfree86: [INTL:de] German l10n: updating Debconf template
Florian Ernst wrote: PS: Last-Translator is X-Debbugs-CCed so he can comment / veto on this. Those changes make sense and are fine with me ;-) Alwin Meschede
Bug#230787: xterm: dies when XIM is killed
On Sat, Jul 24, 2004 at 05:25:03AM +0300, Rauli Ruohonen wrote: > This was harder to reproduce than I expected. I thought it'd always > happen, but that's not true (I just tried xterm briefly, noticed a > problem, and went back to using gnome-terminal). I haven't checked how XIM > works, but apparently you need to have sent some request to kinput2, > after which kinput2 has to die before responding, and *then* the client > application freezes. When I said xterm "dies", I was being unclear.. It > doesn't exit. yes - when I tried it, I wasn't in the middle of a request, but only had verified that XIM was talking to xterm. > A way to reproduce this for all X apps I tested: thanks (there's lots of details here - seems enough for me to do the same) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpwR9npRsHUN.pgp Description: PGP signature
Bug#216933: XFree86 bug only seen on transmeta processors (BadLength from X_ChangeProperty request)
Hi Transmeta, the X bug and Joey, I'm contacting you as I'm not quite sure where to turn next. I'm hoping you'll pass this on to a Transmeta developer for me. Somehow with the X packages for Debian, several laptops with Crusoe chips appear to occasionally refuse to run X. Once the bug occurs it refuses to start until you reboot the laptop though occasionally even then it will reoccur (does code morphing caching persist over reboots?). The symptoms are very bizarre but include X crashing for certain calls yet the only reports of this are on Crusoe chips so people are wondering if it is your code morphing that is breaking X some how. You can see the report at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=216933 Joey Hess's comments in this bug and the similarity between all the users having your chips have made me contact you. The merged bug is at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=234556 There's one that was reported to the freedesktop.org bugzilla at: http://freedesktop.org/bugzilla/show_bug.cgi?id=455 I guess I'm asking if there are any known bugs in the revision of the chip that I have (see below[0]) that I can fix with firmware upgrades or if you have any idea what is causing this bug. Is it possible there is a bug in your code morphing which is causing this? People have seen the bug on 2.4.x and 2.6.x and on a variety of graphic chips. I guess I'm clutching at straws really. Do you have any idea what may cause this? Simon [0] My laptop is a UK version of the Sharp MM10 which is called the Sharp MM1110. It has a Silicon Motion, Inc. SM720 Lynx3DM (rev c1) as its graphics card. My /proc/cpuinfo gives: processor : 0 vendor_id : GenuineTMx86 cpu family : 6 model : 4 model name : Transmeta(tm) Crusoe(tm) Processor TM5800 stepping: 3 cpu MHz : 993.333 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr cx8 sep cmov mmx longrun lrti bogomips: 1966.08 -- ... "No manner of public opinion is likely to make me do what I do not think is right. Attempts at chastisement shall be met with flames that make your eyebrows curl." -- Manoj Srivastava on d-d
Bug#261239: xfree86: [INTL:de] German l10n: updating Debconf template
Package: xfree86 Severity: wishlist Tags: patch l10n Dear members of the X Strike Force, please consider updating the German Denconf template using the attached patch. Cheers, Flo PS: Last-Translator is X-Debbugs-CCed so he can comment / veto on this. --- xfree86_4.3.0.dfsg.1-6_de.po.orig 2004-07-24 13:39:19.0 +0200 +++ xfree86_4.3.0.dfsg.1-6_de.po2004-07-24 15:05:42.0 +0200 @@ -35,7 +35,7 @@ "Project-Id-Version: de\n" "Report-Msgid-Bugs-To: [EMAIL PROTECTED]" "POT-Creation-Date: 2004-06-06 10:41-0500\n" -"PO-Revision-Date: 2004-01-21 20:29+0100\n" +"PO-Revision-Date: 2004-07-24 15:03+0200\n" "Last-Translator: Alwin Meschede <[EMAIL PROTECTED]>\n" "Language-Team: \n" "MIME-Version: 1.0\n" @@ -56,7 +56,7 @@ "A display manager is a program that provides graphical login capabilities " "for the X Window System." msgstr "" -"Ein Display Manager ist ein Programm welches grafische Anmeldemöglichkeiten " +"Ein Display Manager ist ein Programm, welches grafische Anmeldemöglichkeiten " "für das X Window System zur Verfügung stellt." #. Type: select @@ -68,7 +68,7 @@ "run by default." msgstr "" "Ein Display Manager kann nur einen vorgegebenen X Server benutzen, doch es " -"können mehrere Display Manager installiert sein. Bitte wählen Sie welcher " +"können mehrere Display Manager installiert sein. Bitte wählen Sie, welcher " "Display Manager als Standard benutzt werden soll." #. Type: select @@ -102,10 +102,10 @@ "Otherwise you may leave xdm running, and the new version will take effect " "the next time the daemon is restarted." msgstr "" -"Der X Display Manager (xdm) Daemon wird meist beim Upgraden oder entfernen " +"Der X Display Manager (xdm) Daemon wird meist beim Upgraden oder Entfernen " "eines Pakets gestoppt, aber er scheint mindestens eine laufende X-Session zu " -"managen. Wenn xdm jetzt gestoppt wird, werden alle Sessions beendet, die er " -"gerade managt. Alternativ können Sie xdm weiter laufen lassen, die neue " +"verwalten. Wenn xdm jetzt gestoppt wird, werden alle Sessions beendet, die er " +"gerade verwaltet. Alternativ können Sie xdm weiter laufen lassen, die neue " "Version wird dann aktiv, sobald der Daemon das nächste Mal gestartet wird." #. Type: note @@ -183,7 +183,7 @@ #. Description #: ../xserver-common.templates:5 msgid "Select what type of user has permission to start the X server." -msgstr "Wähle aus, welcher Benutzertyp den X-Server starten darf." +msgstr "Wählen Sie aus, welcher Benutzertyp den X-Server starten darf." #. Type: select #. Description @@ -208,7 +208,7 @@ #. Description #: ../xserver-common.templates:20 msgid "Enter the desired nice value for the X server to use." -msgstr "Gib den gewünschten \"nice\"-Wert für den X-Server an." +msgstr "Geben Sie den gewünschten »nice«-Wert für den X-Server an." #. Type: string #. Description @@ -224,11 +224,11 @@ "other than interacting with the console user (such as a web server)." msgstr "" "Es wurde festgestellt, dass sich die Geschwindigkeit des X-Servers " -"verbessert, wenn er mit einer höheren Prozeßpriorität als normal läuft; Die " -"Prozeßpriorität wird als \"nice\" (nett)-Wert bezeichnet. Dieser reicht von " -"-20 (extrem hohe Priorität bzw. \"nicht nett\" zu anderen Prozessen) bis 19 " -"(extrem niedrige Priorität). Der Standartwert für normale Prozesse ist 0. -" -"10 ist eine gute Standarteinstellung für einen Einbenutzerrechner; 0 ein " +"verbessert, wenn er mit einer höheren Prozesspriorität als normal läuft; Die " +"Prozesspriorität wird als »nice« (nett)-Wert bezeichnet. Dieser reicht von " +"-20 (extrem hohe Priorität bzw. »nicht nett« zu anderen Prozessen) bis 19 " +"(extrem niedrige Priorität). Der Standardwert für normale Prozesse ist 0. -" +"10 ist eine gute Standardeinstellung für einen Einbenutzerrechner; 0 ein " "guter Standard für Rechner mit zusätzlichen Aufgaben neben der Interaktion " "mit dem Benutzer (wie zum Beispiel ein WWW-Server)." @@ -241,7 +241,7 @@ "of the X server should be set to 0." msgstr "" "Obiges gilt nicht für die Linux-Kernelversion 2.6 (und auch nicht für die " -"2.5er Serie, nachdem der \"O(1)-Scheduler\" integriert wurde; auf solchen " +"2.5er Serie, nachdem der »O(1)-Scheduler« integriert wurde); auf solchen " "Systemen sollte der nice-Wert des X-Servers auf 0 gesetzt werden." #. Type: string @@ -260,7 +260,7 @@ #. Description #: ../xserver-common.templates:41 msgid "Please enter an integer between -20 and 19." -msgstr "Geben Sie eine Ganzzahl zwischen -20 und 19 ein." +msgstr "Bitte geben Sie eine Ganzzahl zwischen -20 und 19 ein." #. Type: boolean #. Description @@ -278,7 +278,7 @@ "or driver module. If autodetection succeeds, further debconf questions " "about your video hardware will be pre-answered." msgstr "" -"Antworten sie mit Ja, wenn Sie versuchen möchten, den empfohlenen X-Server " +"Antworten Sie mit »Ja«, wenn Sie versuchen möchten, den empfohlenen X-Server " "und/oder das
Bug#261173: xset: print screen resolution
On 2004-07-24 Dan Jacobson <[EMAIL PROTECTED]> wrote: [...] > $ xset q > could print screen resolution parameters, e.g., 800x600. As xset cannot modify the resolution and xset is not a "show information"-tool (but one to change preferences) I disagree. I think xdpyinfo would make you happy. ci andreas
