Bug#278724: xserver-xfree86: [nv] system hang when using gv, xmms, or lopster at depth 24 on NV5 [Aladdin TNT2] rev 32 [depth 16 works]
* Brice Goglin <[EMAIL PROTECTED]> [130107, 00:34]: > Hi Ennio, > > About 2 years ago, you reported a bug to the Debian BTS regarding a > system hang when using various programs on a TNT2 board. Did you > reproduce this problem recently? If not, I will close this bug in the > next weeks. > > Thanks, > Brice Hi Brice, I think you can close the bug, as I already wrote on 24th november 2004: quote -- From [EMAIL PROTECTED] Wed Nov 24 11:57:51 2004 To: [EMAIL PROTECTED] Subject: Re: Bug#278724: Info received (was Bug#278724: [nv] system hang when using gv, xmms, or lopster on NV5 [Aladdin TNT2] rev 0x20) Message-ID: <[EMAIL PROTECTED](Sr)@WouldBe-ei.hnet> I'm glad to inform you that changing the Section "Screen" DefaultDepth from 24 to 16 the problem seems to have disappeared: at least I could run my famous test (i.e. gv foo.txt) many times without locking the system :-) Although I think you could reasonably close the bug, one question ^^ (*) remains: I had not set that value to 24 and, if I recall well, when I configured X in old Woody and tried to run it with the wrong value, some 'goblin' would come out [better: should have come out](*) from within the X Window System and tell me that depth 24 was not supported by my video card! (*) added now for clarity sake. --- unquote - no hanging was occurring after changing the Screen DefaultDepth to 16, so I could regularly use my TNT2 for a couple of years with no problem whatsoever. A few months ago I upgraded my Mb and Video card. Best regards and always thanks for your nice work, Ennio. -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ](°|°) [Why use Win$ozz (I say) if ... "even a fool can do that. )=( Do something you aren't good at!" (as Henry Miller used to say) ]
Bug#402286: [(fwd): Re: Bug#402286: xserver-xorg 7.1.0-7 fails to load libGLcore ... (further info)]
- Forwarded message from Michel Dänzer <[EMAIL PROTECTED]> - Subject: Re: Bug#402286: xserver-xorg 7.1.0-7 fails to load libGLcore ... (further info) From: Michel Dänzer <[EMAIL PROTECTED]> Date: Mon, 11 Dec 2006 15:13:53 +0100 To: [EMAIL PROTECTED], [EMAIL PROTECTED] [For the benefit of future onlookers] >On Sat, 2006-12-09 at 18:26 +0100, Ennio-Sr wrote: >> ... >> but there is no better graphic quality and, indeed, no acceleration >> seems to be available. > The kernel you're running is too old for 3D acceleration with the > current upstream version of xserver-xorg-video-ati. You need a 2.6 > kernel to use the DRI. As reported in my initial post on the subject, problems started with kernel 2.6.17 ... (whereas 2.4.27 was good enough with Sarge). >> Still worse, if I try to run ppracer (which tested ok under Xfree86), I get: >> ... >> *** ppracer error: Couldn't initialize video: No video mode large enough for >> 1280x960 (Success) > That's a ppracer issue. It doesn't automatically fall back to a > different video resolution if the one set up in its config file doesn't > work. AAMOF, changing a few values in /etc/X11/xorg.conf made X work as nice as with XFree86. And the test for 3D with the ppracer was good also. > As there's no X bug above, I'm closing this report. If there are other > issues that haven't been reported yet, please reopen this report or file > new ones, one per problem, with specific descriptions. Agreed. Thanks for your quick answer. Regards, Ennio. -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ](°|°) [Why use Win$ozz (I say) if ... "even a fool can do that. )=( Do something you aren't good at!" (as Henry Miller used to say) ]
Bug#402286: xserver-xorg 7.1.0-7 fails to load libGLcore ... (further info)
Referring to captioned bug, I noticed this line in the Xorg.0.log: dlopen: /usr/lib/xorg/modules/extensions/libGLcore.so: undefined symbol: _glapi_Dispatch so I searched Google with that key and found bugs #391505, #377287, 378058 dealing with similar problems. Commenting the "Load GLcore" line in /etc/X11/xorg.conf the log error disappears, but there is no better graphic quality and, indeed, no acceleration seems to be available. Still worse, if I try to run ppracer (which tested ok under Xfree86), I get: PPRacer 0.3.1 -- http://racer.planetpenguin.de (c) 2004-2005 The PPRacer team (c) 1999-2001 Jasmin F. Patry<[EMAIL PROTECTED]> PPRacer comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See http://www.gnu.org/copyleft/gpl.html for details. *** ppracer error: Couldn't initialize video: No video mode large enough for 1280x960 (Success) Regards, Ennio -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ](°|°) [Why use Win$ozz (I say) if ... "even a fool can do that. )=( Do something you aren't good at!" (as Henry Miller used to say) ]
Bug#278724: Info received (was Bug#278724: [nv] system hang when using gv, xmms, or lopster on NV5 [Aladdin TNT2] rev 0x20)
Hi! in my last mesage relating to the captioned bug I wrote (Nov. 24, 2004): -- I'm glad to inform you that changing the Section "Screen" DefaultDepth from 24 to 16 the problem seems to have disappeared: at least I could run my famous test (i.e. gv foo.txt) many times without locking the system :-) Although I think you could reasonably close the bug, one question remains: I had not set that value to 24 and, if I recall well, when I configured X in old Woody and tried to run it with the wrong value, some 'goblin' would come out from within the X Window System and tell me that depth 24 was not supported by my video card! -- Despite that I did experiment many other hanging-up, but still I had no clue as to what was happening, so I didn't report them. To-day, after my PC froze again, I took different steps which may possibly throw some light on the subject. I had all six consoles opened as follows: F1 - root (idle) F2 - user (idle) F3 - user (idle) F6 - user -->start x --> running lopster (on F7) F5 - user -->startx -- :1 --> running speedy (on F8) then I opened F4 - user -->startx -- :2 --> running mplayer -vo xv -autosync 1 file.mpg (on F9) after half minute watching on F9, the screen (and the PC) froze. I ssh-ed in with my laptop and run top, which showed an XFree86 abosrbing from 60 to 94,6% of CPU! Instead of rebooting (as in past occasions) I killed the above high absorbing XFree86 process and nothing changed; killed .xinitrc running on tty4 (running mplayer on F9, the screen the PC had frozen on) and nothing happened; killed .xinitrc on tty5 (running speedy on F8) and saw a black line across my F9 screen: something had happened! While trying all the CTRL-ALT+F1 through F6 I could see part of the F9 screen progressively full of garbage blacking-out the window ... finally, CTRL-ALT+F7 showed me the window where lopster was running and after that I could re-gain control of my PC! While still having the laptop connected via ssh I tried to reproduce the hanging-up doing again the same steps and watching from top running on the laptop what went on on the PC: the speedy-preloader took almost 45% CPU and about 49% was taken by XFree86 when I launched mplayer ...; after a while (i.e. whan F9 window froze), XFree86 was absorbing up to 96,5% CPU. What I can conclude from my un-technical point of view is that it's the CPU's lack of resources to cause the freezing and wonder whether there could be a sort of pre-warning as to avoid it. Thanks for your attention and for your wonderful work. Regards, Ennio -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ](°|°) [Why use Win$ozz (I say) if ... "even a fool can do that. )=( Do something you aren't good at!" (as Henry Miller used to say) ]
Bug#278724: [(fwd): Bug#278724: [Sarge]: xserver-xfree86 freeze on errors from gv|xmms|lopster]
* Branden Robinson <[EMAIL PROTECTED]> [101204, 03:13]: > On Fri, Nov 05, 2004 at 09:27:56PM +0100, Ennio-Sr wrote: > > 2) Can you reproduce the problem with xserver-xfree86-dbg? > > > > ## Yes, I can, but no core file is created, despite following step by > > ## step the instructions listed in the 'form letter'. > > ## The only core file I could see is the /proc/kcore, which I think > > ## you're not intered in. [read more at the bottom] > > Correct; we're not interested in /proc/kcore. :) > > I apologize for the boilerplate not being precisely applicable to your > case. > > It's remotely possible you could have caused a core dump yourself by simply > signalling the process. > > That is, identify the process ID of the X server and then use "kill -QUIT" > or "kill -ABRT" on it. > > However, I suspect in this case that wouldn't have worked, because your > display adapter had things hosed at the bus level. > > On the other hand, if that *does* work, it would be useful to know, because > the core dump (once parsed by GDB) would tell us what function the X server > was in when it locked up the display adapter. And that in turn might point > in the direction of a fix. > > -- > G. Branden Robinson|My first priority in any attack is Hi Branden! I'm following up after some time to my previous answer on your last message. Finally I was again in a position to try again what you suggested, but to no avail: whatever I did from my note book, the screen on my PC remained well fixed on that frozen page showing the error I reported before. PC's keyboard was of course completely frozen and the only command which would be felt through the ssh connection was 'reboot' ! For what is worth I'm reporting the commands I gave: On my PC's XF86Config-4 I put again the value 'DefaultDepth 24' then I gave the command from root: # startx $/which x-terminal-emulator) and when X came on I gave the fatal # gv pippo The error window came out and the PC was frozen. I connected from a notebook and killed one after another all the processes relating to the gv command, i.e.: # kill -QUIT proc.no. ## gv pippo # kill -ABRT" ## xterm -class UxTerm -title uxterm -u8 # kill -ABRT" ## usr/bin/X11*X -dpi 100 -nolisten tcp # kill -QUIT" ## bash (which will not disappear from ps aux ## list as the previous processes did) This is the full list of what I did from my notebook: 1132 ps aux |grep root 1133 kill -QUIT 2231 1134 kill -ABRT 2231 (not found) 1135 ps aux |grep root 1136 kill -ABRT 2225 1137 ps aux |grep root 1138 kill -ABRT 1139 ps aux |grep root 1140 kill -QUIT 1616 1141 ps aux |grep root 1142 ps aux |grep tty1 1143 kill -QUIT 1616 1144 ps aux |grep tty1 1145 ps aux |grep tty1 |less 1146 kill -QUIT 4616 1147 kill -QUIT 1836 1148 ps aux |grep tty1 1149 kill -ABRT 1616 1150 ps aux |grep tty1 1151 ps aux | less 1154 ps aux | grep xinit 1155 reboot Of course, no core was produced. Sorry I cannot be more helpful ;( Best regards, Ennio. -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ](°|°) [Why use Win$ozz (I say) if ... "even a fool can do that. )=( Do something you aren't good at!" (as Henry Miller used to say) ]
Bug#278724: Info received (was Bug#278724: [nv] system hang when using gv, xmms, or lopster on NV5 [Aladdin TNT2] rev 0x20)
I'm glad to inform you that changing the Section "Screen" DefaultDepth from 24 to 16 the problem seems to have disappeared: at least I could run my famous test (i.e. gv foo.txt) many times without locking the system :-) Although I think you could reasonably close the bug, one question remains: I had not set that value to 24 and, if I recall well, when I configured X in old Woody and tried to run it with the wrong value, some 'goblin' would come out from within the X Window System and tell me that depth 24 was not supported by my video card! Regards, Ennio. -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ](°|°) [Why use Win$ozz (I say) if ... "even a fool can do that. )=( Do something you aren't good at!" (as Henry Miller used to say) ]
Bug#278724: Info received (was Bug#278724: [nv] system hang when using gv, xmms, or lopster on NV5 [Aladdin TNT2] rev 0x20)
As I was tired of suffering continuous system blocks - reminding me of bad 'old times' when I used another OS - I downgraded xserver-common, xserver-xfree86 and xfree86-common to 4.1.01 woody4 and all the reported problems disappeared :-) May be you can get some comparison info from the following XFree86.0.log, taken after the downgrade. I notice that it's loading GLcore now (provided it does mean something): --- quote This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to XFree86@XFree86.Org and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.1.0.1 / X Window System (protocol Version 11, revision 0, vendor release 6510) Release Date: 21 December 2001 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/FAQ) Build Operating System: Linux 2.6.9-rc1 i686 [ELF] Module Loader present (==) Log file: "/var/log/XFree86.0.log", Time: Sat Nov 20 21:15:31 2004 (==) Using config file: "/etc/X11/XF86Config-4" Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) ServerLayout "Default Layout" (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "Philips 107 Sx" (**) | |-->Device "NVIDIA Corporation NV5 [Aladdin TNT2]" (**) |-->Input Device "Generic Keyboard" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc104" (**) XKB: model: "pc104" (**) Option "XkbLayout" "it" (**) XKB: layout: "it" (==) Keyboard: CustomKeycode disabled (**) |-->Input Device "Configured Mouse" (WW) The directory "/usr/lib/X11/fonts/cyrillic" does not exist. Entry deleted from font path. (WW) The directory "/usr/lib/X11/fonts/CID" does not exist. Entry deleted from font path. (**) FontPath set to "unix/:7101,unix/:7100,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/100dpi/:unscaled,/usr/lib/X11/fonts/75dpi/:unscaled,/usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/Speedo,/usr/lib/X11/fonts/100dpi,/usr/lib/X11/fonts/75dpi,/usr/lib/X11/fonts/truetype" (==) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (--) using VT number 7 (WW) Open APM failed (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.4 XFree86 XInput driver : 0.2 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.2 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.1.0.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.2 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor="The XFree86 Project" compiled for 4.1.0.1, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.4 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 10b9,1621 card , rev 04 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 10b9,5247 card , rev 01 class 06,04,00 hdr 01 (II) PCI: 00:02:0: chip 10b9,5237 card , rev 03 class 0c,03,10 hdr 00 (II) PCI: 00:07:0: chip 10b9,1533 card , rev c3 class 06,01,00 hdr 00 (II) PCI: 00:0c:0: chip 13f6,0111 card 13f6,0111 rev 10 class 04,01,00 hdr 80 (II) PCI: 00:0c:1: chip 13f6,0211 card 13f6,0211 rev 10 class 07,80,00 hdr 00 (II) PCI: 00:0e:0: chip 1039,0900 card , rev 02 class 02,00,00 hdr 00 (II) PCI: 00:0f:0: chip 10b9,5229 card 10b9,5229 rev c2 class 01,01,fa hdr 00 (II) PCI: 00:14:0: chip 10ec,8139 card 10ec,8139 rev 10 class 02,00,00 hdr 00 (II) PCI: 01:00:0: chip 10de,00a0 card , rev 20 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) LoadModule: "scanpci" (II) Loading /usr/X11R6/lib/modules/libscanpci.a (II) Module scanpci: vendor="The XFree86 Project" compiled for 4.1.0.1, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.4 (II) UnloadModule: "scanpci" (II) Unloading /usr/X11R6/lib/modules/libscanpci.a (II) Host-to-PCI bridge: (II) PCI-to-ISA bridge: (II) PCI-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 00x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 00x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range:
Bug#278724: [nv] system hang when using gv, xmms, or lopster on NV5 [Aladdin TNT2] rev 0x20
As a further contribution to my initial report I'm forwarding a copy of *ps aux* taken running Woody and Sarge on the same box: there is one particular line coming out in Sarge (where the hanging occurs) which might signal something to you. Other behaviours I found out are: Running xmms or lopster on an x-terminal-emulator (either as root or user) I can stretch any of the windows and no freezing occurs; if I do the same using WMaker the PC hangs at the first attempt to stretch, whether if BlackBox is in use, the stretching can go ahead a few times with no hang at all. Whathever I did I could not get a core file. Could you please tell me whether you think it may be related to my configuration or not? Could you reproduce this behaviour? Thanks for your attention. Regards, Ennio. This is a *ps aux* taken running gv on Woody (kernel 2.2.22) gv warns there is an error, but doesn't hang. USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 1.0 0.0 1220 484 ?SNov13 0:04 init root 2 0.0 0.0 00 ?SW Nov13 0:00 [kflushd] root 3 0.0 0.0 00 ?SW Nov13 0:00 [kupdate] root 4 0.0 0.0 00 ?SW Nov13 0:00 [kswapd] root 5 0.0 0.0 00 ?SW Nov13 0:00 [keventd] root48 0.0 0.0 00 ?SW Nov13 0:00 [khubd] root 148 0.0 0.0 00 ?SW Nov13 0:00 [eth0] daemon 305 0.0 0.0 1316 400 ?SNov13 0:00 /sbin/portmap root 393 0.0 0.0 1288 544 ?S00:00 0:00 /sbin/syslogd root 437 0.0 0.1 1572 844 ?S00:00 0:00 /sbin/klogd -c 4 root 442 32.9 1.5 10480 9532 ?S00:00 2:27 /usr/sbin/named root 446 0.0 0.1 1372 664 ?S00:00 0:00 /sbin/rpc.statd root 463 0.0 0.0 1384 564 ?S00:00 0:00 /usr/sbin/dhcrelay3 -q -i eth0 deby.ei.hnet root 472 0.0 0.0 1236 484 ?S00:00 0:00 /usr/sbin/inetd daemon 484 0.0 0.1 1888 840 ?S00:00 0:00 lpd Waiting root 584 0.0 0.1 2396 1028 ?S00:00 0:00 /usr/lib/postfix/master postfix 1468 0.0 0.1 2348 928 ?S00:07 0:00 \_ pickup -l -t fifo -u -c postfix 1469 0.2 0.1 3680 1160 ?S00:07 0:00 \_ qmgr -l -t fifo -u -c rwhod 590 0.0 0.0 1348 552 ?S00:00 0:00 /usr/sbin/rwhod -b rwhod 592 0.0 0.1 1364 668 ?S00:00 0:00 \_ /usr/sbin/rwhod -b root 608 0.0 0.1 2708 1188 ?S00:00 0:00 /usr/sbin/sshd proxy 626 0.0 0.1 2084 924 ?S00:00 0:00 /usr/sbin/wwwoffled -c /etc/wwwoffle/wwwoffle.conf root 633 0.2 0.6 5216 4160 ?S00:00 0:01 /usr/bin/X11/xfs -daemon nobody 636 0.1 2.7 18452 16888 ? S00:00 0:00 /usr/bin/X11/xfs-xtt -daemon -user nobody -port 7110 root 639 0.0 0.1 1616 652 ?S00:00 0:00 /usr/sbin/rpc.nfsd root 641 0.0 0.1 1612 660 ?S00:00 0:00 /usr/sbin/rpc.mountd daemon 648 0.0 0.0 1320 556 ?S00:00 0:00 /usr/sbin/atd root 651 0.0 0.1 1576 676 ?S00:00 0:00 /usr/sbin/cron root 659 0.1 0.2 2184 1280 tty1 S00:00 0:00 -bash root 1476 0.0 0.1 3008 1148 tty1 R00:07 0:00 \_ ps auxfwww aux ennio 660 0.1 0.2 3616 1744 tty2 S00:00 0:00 -bash ennio 746 0.0 0.1 2960 1104 tty2 S00:01 0:00 \_ sh /usr/bin/X11/startx ennio 753 0.0 0.1 2124 616 tty2 S00:01 0:00 \_ xinit /home/ennio/.xinitrc -- /usr/X11R6/lib/X11/xinit/xserverrc root 754 3.8 2.8 61904 17780 ? S< 00:01 0:14 \_ /usr/bin/X11/X -dpi 100 -nolisten tcp ennio 757 0.0 0.1 2956 1088 tty2 S00:01 0:00 \_ sh /home/ennio/.xinitrc ennio 758 0.0 0.3 5156 2340 tty2 S00:01 0:00 \_ xterm -bg black -fg green -ls ennio 762 0.0 0.2 3628 1764 ttyp2S00:01 0:00 | \_ -bash ennio 1132 0.2 0.3 3716 2232 ttyp2S00:04 0:00 | \_ gv ennio 760 0.5 0.2 4096 1832 tty2 S00:01 0:01 \_ /usr/bin/blackbox root 661 0.0 0.0 1200 448 tty3 S00:00 0:00 /sbin/getty 38400 tty3 root 662 0.0 0.0 1200 448 tty4 S00:00 0:00 /sbin/getty 38400 tty4 root 663 0.0 0.0 1200 448 tty5 S00:00 0:00 /sbin/getty 38400 tty5 root 664 0.0 0.0 1200 448 tty6 S00:00 0:00 /sbin/getty 38400 tty6 root 665 0.0 0.1 2136 1092 ?S00:00 0:00 sh /usr/sbin/secvpnmon root 1332 0.0 0.0 1708 468 ?S00:07 0:00 \_ sleep 30 This is a *ps aux* taken running gv on Sarge (kernel 2.4.27) ---
Bug#278724: [(fwd): Bug#278724: [Sarge]: xserver-xfree86 freeze on errors from gv|xmms|lopster]
- Forwarded message from Branden Robinson <[EMAIL PROTECTED]> - Subject: Bug#278724: [Sarge]: xserver-xfree86 freeze on errors from gv|xmms|lopster From: Branden Robinson <[EMAIL PROTECTED]> Reply-To: Branden Robinson <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Date: Thu, 4 Nov 2004 11:55:08 -0500 To: [EMAIL PROTECTED], [EMAIL PROTECTED] retitle 278724 xserver-xfree86: [nv] system hang when using gv, xmms, or lopster on NV5 [Aladdin TNT2] rev 0x20 severity 278724 important tag 278724 + moreinfo upstream thanks On Fri, Oct 29, 2004 at 12:58:09AM +0200, [EMAIL PROTECTED] wrote: > While testing a few packages running under X I experienced a total > freeze of by box: as this happened with xmms, lopster and - today - with > gv, the doubt is coming out that it might depend on the X Window System, > although I cannot tell for sure. [...] Thanks for your report. ## -> Ennio's comments ## It's me that thank you for your attention and for the nice work you ## do at Debian's. We appreciate you sending along your XF86Config-4 file, but we need a little more information. 1) Can you please mail <[EMAIL PROTECTED]> the contents of your /var/log/XFree86.0.log file? A copy of the log file after the lockup has occurred (but before the X server has started again) would be most valuable. ## Ok, it's enclosed If you run a display manager like gdm, or xdm, this may be most easily obtained by rebooting into single-user mode after the box locks, and copying /var/log/XFree86.0.log to a safe location while in single-user mode. ## I don't run any gdm/xdm. Anyway I took copies of /var/log/XFree.0.log ## soon after the PC locked, ssh-ing from another box. 2) Can you reproduce the problem with xserver-xfree86-dbg? ## Yes, I can, but no core file is created, despite following step by ## step the instructions listed in the 'form letter'. ## The only core file I could see is the /proc/kcore, which I think ## you're not intered in. [read more at the bottom] [cut] [The following is a form letter.] [cut] manager. Run the client that provokes the crash from the terminal prompt. If the X server crashes, it should leave a core dump in /etc/X11. ## As I said, no core dump is produced (I even run a find / |grep core ## with no success :-(... ) [cut] In the example above, you can see I used "bt full -7" to get the "outermost" seven stack frames, complete with local variable information, where available. If you could send us something smiliar, that would be very helpful. ## As things stand, I could only do a: ## strace -o err_gv 2>&1 gv ## provided it would be of any utlity, which I fear not [I have a copy ## of the strace I took when it failed with xmms, but could not trace ## of the symbols which are in your 'form letter' gdb example] -- G. Branden Robinson| Organized religion is a sham and a Debian GNU/Linux | crutch for weak-minded people who [EMAIL PROTECTED] | need strength in numbers. http://people.debian.org/~branden/ | -- Jesse Ventura - End forwarded message - -- I have already told you in the upper part of this message that I wasn't able to get a core dump. Hereunder follow all the information I could gather. May be I'm missing some basic configuration? (The system is 'virgin' I'have not reconfigured the kernel). As you are asking me to get a core dump, does that mean that you are unable to reproduce at your end? Here, I'm getting locks no matter which file I give as gv argument on the terminal :- What I did: --- - Downloaded xserver-xfree-dbg (debconf proposed it as default server: ok) - rebooted my PC with no fbdev (no vga=788 option) - Ran startx $(which-terminal-emulator) and when the terminal appeared gave: gv err_pg and the box froze. - connected my iBook (Debian/GNU/Linux on it, too) to the frozen box and saved a copy of /var/log/XFree86.0.log (see below). *** It's worth noting that when I gave the 'gv err_pg' command, a window appeared upon the gv window-screen, with these messages: Error: /undefinedGPL Ghostscript 8.01: unrecoverable error, exit code 1 in Stopping Operand stack: Execution stack %interp_exit .runexec2 --nostringval-- idem idem --dict:1048/1123(ro) (G) There a was a bar at the bottom of this window, with the captio "DISMISS":. I clicked on it and the on-window closed leaving the full gv-screen, so that I could try: File/Open/a.different.plain.ascii.txt.file Again the on-window appeared but this time it only said: Error: /undefined in Stopping Operand stack: Execution stack However, when I clicked on the dismiss bar everything was locked. -- #dpg -l | grep core ii coreutils 5.2.1-2The GNU core utilities ii x-window-syste 4.3.0.dfsg.1-8 X Window System core components # ulimit -c unlimited # ulimit -a core file size(blocks, -c) unlimited data s
