| Summary: | Xfree freeze on a website using latest nvidia drivers | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Brice Arnould (un_brice) <brice.arnould> |
| Component: | [OLD] Library | Assignee: | Gentoo X packagers <x11> |
| Status: | VERIFIED NEEDINFO | ||
| Severity: | critical | CC: | azarah, gcadieux, kde, squeeze |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | A webpage that (sometimes) show the bug when viewed with Konqueror | ||
|
Description
Brice Arnould (un_brice)
2003-04-21 12:24:51 UTC
Yes, That page crashes for me with Nvidia 4349 / xfree4.3.0-r2 and konqueror. It works in mozilla on the same setup. It works in mozilla and konqueror on a radeon. It might be worth seeing if a smaller html snippet from that page will trigger the bug. (As I'm not only having this problem, and because it can be considired as an remote vunlnerablity affecting often used softwares (NVdrivers+Konqueror), I've increased the severity of this bug.) I've tried to save the file which make X freeze and open it with Konqueror, nothing happen. At the opposite I've tried to disable "preemptible kernel" and "low latency sheduling" and to disable all plugins in Konqueror... still crash. Also I've noticed that I have the same problem with www.netraverse.com/gentoo.html . ... so I'll try others combinaisons, but the help of someone wich know XFree/KDE or know how to use gdb in such case would be greet (as it is for the moment, NVidia won't even read this bug repport). So its a KDE problem ... checked yet if they know about this, or maybe have a possible fix ? Also, have you tried to disable Hardware rendering ? I use the stable nvidia drivers, and it works for me. I guess it is a problem in the nvidia drivers triggered by konqueror/kde/qt. Also most things except drivers should not be able to put your system in such a state. What happens if you use other nvidia drivers? >So its a KDE problem ... checked yet if they know about this, or maybe have a possible fix ? No, it's an bug of the driver because changing it make the system work. So this bug can appear in almost any graphical application. >I use the stable nvidia drivers, and it works for me. I use the 2.4.20-r2 kernel with an KT400 motherboard. >I guess it is a problem in the nvidia drivers triggered by konqueror/kde/qt. Yes, I think too, but I can't contact nvidia to tell them what function fail, because I don't know how to find it. This is why I post here. All that I can tell is that problem occcure during the loading of an image by the javascript of this page (i'll put the html file, js script and gif in a tar.bz2 file). This is why I'm asking for people which know how to use gdb to find precisely what make the system hang. >Also most things except drivers should not be able to put your system in such a state. What happens if you use other nvidia drivers? I've said it, that work only with 1.0.3x drivers. But they are slow, and if we don't say anything to nvidia, this bug will stay (and, in function of the bug, can be used as a security hole). To end, I have noticed that an utility called tsl_test in the GLX package segfault. But : *this a test and the Makefile continue *ldd say me that it don't handle tsl files when i use it with them Created attachment 11090 [details]
A webpage that (sometimes) show the bug when viewed with Konqueror
Could you post: $ ls -l /usr/lib/opengl/nvidia/lib/ The TLS stuff *should* be harmless. Seems the tls_test utility from nvidia segfault if you do not have glibc with TLS ... I just have not gotten to quiet the thing down. Did you try to disable hardware rendering ? This can be done by adding to the "Device" section in XF86Config: ------------------------------------------------------------- Option "RenderAccel" "off" ------------------------------------------------------------- Just another 2 Just another 2ยข, I've not experienced a crash, what I should have said is that I saw X using 100% cpu. Evidently looping somewhere and not processing events, hence it looks like it has crashed because the desktop had stop painting, processing keyboard events etc. But I could ssh in from another machine and run apps, shutdown cleanly etc. So I wouldn't expect its a kernel or hardware issue. I thought 4349 were marked as stable on x86? I'll try a debug build of stuff later and the nv driver / nvidia driver without acccel to see if I can track this down further... Works here with RenderAccel "off" Right, so its back to the new render code introduced in 4191. From comments it seems like 4349 is better than 4191, but still have issues ... right? Somebody who have KDE wants to file a bug with nvidia ? ^_^
Disabling the RenderAccel had "solved" the problem.
Thanks all ! (especialy Martin, his workaround will help me to wait for an action from
nvidia -_^)
>Somebody who have KDE wants to file a bug with nvidia ?
If those wich knows how to do don't want to make, this, i'll try to contact nvidia... i'll wait
few days before.
By the way, Nvidia has just released a new driver in a "bugfixe release", but i've tested
it and it don't fix this bug -_-.
Do you still have this with 1.0.4363 ? >Do you still have this with 1.0.4363 ?
Yes, as I've (badly) said, "it don't fix the bug".
Bleh, ok missed that. i already tried to contact nvidia months ago, they just ignored me (ok months ago i didn't have brain@gentoo.org, but i think they'll not care too much), i solved disabling the hardware rendering, which is very buggy, maybe if many people send the same bugreport to nvidia they'll take a look? I have contacted nvidia about this issue. Awaiting word from them. I've encountered what I believe is the same problem. Basically, the whole screen 'freezes' periodically. The problem is definitely related to 100% CPU utilitization. I'm not completely convinced the problem is an nvidia driver problem however. It appears to be an interaction between X and nvidia. Everything was working fine until recent emerges (withing the last week. I emerged the nvidia-kernel-1.0.4363-r2.ebuild on May 26. I emerged xfree-4.3.0-r2.ebuild on June 7 and -3 on June 16. I believe I didn't encounter the problem until after the emerge of xfree-4.3.0-r3. Though it is possible that I encountered the problem earlier after June 7. I do know that I didn't encounter this problem until the last week or possibly two weeks. The problem is definitely CPU activity related. If you're are running KDE, you are _much_ more likely to suffer random freezes. These seem to occur with extra activity such as moving the mouse, opening a browser, refreshing or scrolling a broswer page. The freezes seem to be tied to any increase in CPU activity combined with changes to the screen. I also noticed that I emerged xft-2.0.1-r2 on Jun 12. Due to timing etc, I suspect that the guitly party may actually be xft. I don't have the requisite knowledge and skills to trace and debug this. I would like to go back to xfree-4.3.0-r1, but I'm not certain how to do this with the following messages These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild UD] x11-base/xfree-4.3.0-r1 [4.3.0-r3] [blocks B ] >=x11-base/xfree-4.3.0-r2 (from pkg x11-libs/xft-2.0.1-r2) [ebuild N ] x11-libs/xft-2.0.1-r2 Do I emerge unmerge xft first? Then emerge unmerge xfree and then emerge xfree-4.3.0-r1? I'd like to go back and see if the problem goes away. Portage 2.0.48-r1 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1) ================================================================= System uname: 2.4.20 i686 AMD Athlon(TM) XP 1900+ GENTOO_MIRRORS="rsync://csociety-ftp.ecn.purdue.edu/pub/gentoo/ http://csociety-ftp.ecn.purdue.edu/pub/gentoo/ ftp://csociety-ftp.ecn.purdue.edu/pub/gentoo/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="x86 oss 3dnow apm avi crypt cups encode gif jpeg gnome libg++ mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib alsa gdbm berkdb slang readline arts tetex bonobo svga java guile X sdl gpm tcpd pam libwww ssl perl python esd imlib oggvorbis gtk qt kde motif opengl mozilla cdr" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -Os -pipe" CXXFLAGS="-march=athlon-xp -Os -pipe" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache" yes you shouldn't have xft installed anyway, because it is built as part of xfree Hi Seemant, Several points / observations. 1) I did not separately install xft. It was installed as part of a 'emerge -u --deep world'. 2) When I 'emerge unmerged xft' , it also unmerged xfree 4.3.0. From you comment, I assumed that this was supposed to happen. 3) When I 'emerge -p /usr/portage/x11-base/xfree/xfree-4.3.0-r1.ebuild', it displayed that it would emerge: xfree-4.3.0-r1 xfree-4.3.0-r3 xft-2.0.1-r2 In other words, it's not possible to go back to 4.3.0-r1. 4) When I emerge xfree-4.3.0.-r1, I ended up with the following in my /usr/portage/distfiles for the X430 series: ls -l /usr/portage/distfiles/X430* -rw-r--r-- 1 root root 10993622 May 3 06:49 /usr/portage/distfiles/X430src-1.tgz -rw-r--r-- 1 root root 7962239 May 3 06:49 /usr/portage/distfiles/X430src-2.tgz -rw-r--r-- 1 root root 12366363 May 3 06:49 /usr/portage/distfiles/X430src-3.tgz -rw-r--r-- 1 root root 12906091 May 3 06:49 /usr/portage/distfiles/X430src-4.tgz -rw-r--r-- 1 root root 4388018 May 3 06:49 /usr/portage/distfiles/X430src-5.tgz -rw-r--r-- 1 root root 8074919 Jun 20 21:32 /usr/portage/distfiles/X430src-6.tgz -rw-r--r-- 1 root root 9317241 Jun 20 21:49 /usr/portage/distfiles/X430src-7.tgz Note that X430src-6 and X430src-7 were either added or where changed in the last 2 weeks after I was alread at xfree-4.3.0-r3. There were several other smaller .tgz files downloaded as well. This surprised me a great deal as I had expected all these files to already be on my system. Results: After unmerging xft and emergeing xfree-4.3.0-r1 (which brought it up to -r3), I am no longer experiencing the freezes. BTW, for people experiencing the 'freezes', if you upgrade your kernel to a version which supports pre-emption (and compile pre-emption in), then you'll still get keyboard and mouse responsiveness. :-) If you'ld like me to upload/post and other information on my system. I will be happy to do so. I have the same problems as Guy, so I tried his solution. Regrettably, if does not work for me. When I unmerged xft, xfree was not automatically unmerged. I unmerged xfree manually. When I emerge -p xfree, portage offers to merge: [ebuild N ] x11-base/xfree-4.3.0-r2 When I explicitly # emerge -p /usr/portage/x11-base/xfree/xfree-4.3.0-r1.ebuild These are the packages that I would merge, in order: Calculating dependencies ...done [ebuild N ] x11-base/xfree-4.3.0-r1 [ebuild N ] x11-base/xfree-4.3.0-r2 [ebuild N ] x11-libs/xft-2.0.1-r2 so this would bring me to -r2, where I was before, with the system freezing. There is a /usr/portage/x11-base/xfree/xfree-4.3.0-r3.ebuild on my system, but it seems to be ignored. I tried an explicit: # emerge -p /usr/portage/x11-base/xfree/xfree-4.3.0-r3.ebuild which appears to run to completion with no errors, but after it is done the command startx is not installed in the path. I hope this helps, and am willing to post any other information of interest. I'd be really interested in a fix, since at present I'm back to a command line interface, rather limiting these days. I'm posting this bug from my Red Hat system! Hi! I'm having the same problem. My computer freezes randomly when I press win+r (run dialog) and try to complete something and sometimes when I start a konsole and entering text before the konsole is completly ready. I don't have to use the computer more than a couple of minuters before it happens (from a freshly booted machine). One interesting part is that if I execute xterm the same way I haven't been able to freeze my machine. Is this an nvidia, X or QT/KDE problem? This is what I have installed: ------------------------------------------------------------ emerge -p gentoo-sources xfree nvidia-kernel nvidia-glx kde These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] sys-kernel/gentoo-sources-2.4.20-r5 [ebuild R ] x11-base/xfree-4.3.0-r2 [ebuild R ] media-video/nvidia-kernel-1.0.4363-r2 [ebuild R ] media-video/nvidia-glx-1.0.4363 [ebuild R ] kde-base/kde-3.1.2 ------------------------------------------------------------ I've tried the "RenderAccel" w/o success. I have switched to the nv driver from X now instead. If this works w/o problem then it must be the driver. I've been testing this and it seems to be the driver. Using the X shipped driver it seems to run ok, as soon as i switch to nvidia's it freezes. A quick and dirty fix for the frozen: ping the frozen machine from another on the network, and it unfreezes immediately. If freezes become frequent, leave a ping running and you (almost) won't notice the bug. Now if I understood why this works, I might be well on my way to understanding the problem. have you tried nvidia 4496 ? Bug 28330 seems to indicate an issue with older nvidias and random lockups ... Closing due to lack of response. Please reopen if you add more info. Actually, that seems to work for me, with the new drivers. Does i've said that i changed of MB, and that the new's chipset is a Nforce2 (instead of a KT400) ? OK, that's all then. Thanks. |
