From: James v. Z. <ja...@dv...> - 2005-12-02 11:05:02
|
--------------------------------------------------------------------- Machine #1 : Two console dual AthlonMP 2800+ server 2Gb RAM with 360Gb SATA hardware RAID5, plus 240Gb linux software array. dual e1000 gigabit LAN + onboard e100. 1000VA UPS. FC2, 2.6.13-vz4.2 kernel using faketty and patched X build from modded FC2 .srpm; text console is on vga16 framebuffer. second PCI console is GF4MX440 This machine shows (very rarely) console-switching instability mentioned earlier. Switch back and forth between the primary X server and text console all you like; not usually a problem. If it does corrupt the text console, it can be recovered by using the second X console to login as root and killing the gdm-binary that launches the primary X console. > What nvidia binary driver version are you using? 7676 > If you repeatedly alternately log in and out of two different screens > at least twenty times, one of the screens will not crash? Currently 17 days uptime; last shutdown was due to a power outage. That's about the only reason it goes down, actually. Each console gets logged into and out of once or twice a day. I just tried logging in and out repeatedly and no crashes from that. > What about > ctrl-alt-backspace zapping the screens one after another (waiting 5 > seconds in between zaps) Doing this repeatedly, without necessarily taking a 5 second pause, I'm sure I was doing it quicker than that; just zapping each console as soon as it had a login eventually caused the primary X server to fail. Recovered by [ init 4 && init 5 ] At a guess I killed each console seven times or more before this happenned; I wasn't counting. Waiting 5 secs between each zap produced the same result. ---------------------------------------------------------------------- Machine #2 : Two console P4 3.0Ghz, 2Gb RAM, 160Gb software RAID5, two TV tuner cards : a Fusion DVB-T+ and VideoMate TV gold+. e1000 gigabit. FC4 with 2.6.14-v2.1 kernel using faketty and patched X from modded FC4 .srpm; text console is vga16 framebuffer. This machine shows more frequent console switching instability. However it is worth noting that it has quirks that prevent me using more than two consoles. I feel there are possibly two problems here : the mainboard and the PCI MX4000 video in it. The MX4000 insists on being primary and will crash linux or windows if you try using it as a secondary of any kind in any machine. The mainboard BIOS has no PCI/AGP init first switch. Rarely it locks up; if it doesn't, the recovery process of using the second console to kill first gdm-binary will bring X back, but not the text console, which remains corrupted every time you try to use it until the system is reset The console switching problem may be more significant due to VGA-BIOS / mainboard BIOS failings? It is an intel chipset and I have found intel skt478 chipsets, particularly intel desktop mainboards have very poor support for configurations such as this. (This one is a gigabyte mainboard, it replaced an intel desktop - the intel board was more cantankerous still; any kind of multi-head X was difficult.) Needless to say console switching is avoided on this workstation. > What nvidia binary driver version are you using? 7676 > If you repeatedly alternately log in and out of two different screens > at least twenty times, one of the screens will not crash? Currently 8 days uptime, last shutdown by mistake. Each console gets logged in and out of five or six times a day. Repeated login/logoff does not generate a crash. > What about > ctrl-alt-backspace zapping the screens one after another (waiting 5 > seconds in between zaps) Well, this one is much more problematic with this. Taking the same approach I did with the server above, definately not waiting 5 seconds, it failed much sooner - two or three zaps and I had no primary X server. [init 4 && init 5 ] did not recover X consoles. In fact, I had to reset. uptime = 0. Counting to five between zaps meant it lasted about six or seven zaps each console. Still not recoverable. ------------------------------------------------------------------------- Machine #3 is currently out of service, but by past record, I'd expect it to behave exactly as the server does - it has proven very stable using three and four consoles. It's a more pedestrian AthlonXP 2600+ 1Gb with FX5200 and MX440 secondaries on a gigabyte nforce2 mainboard With some prior kernels, notably 2.6.9-vz11, this machine never ever corrupted the text console or caused similar issues. Neither did the server for that matter. The P4 was in a different incarnation at that time; can't recollect for comparison. J On Fri, 2005-12-02 at 14:53, Michael Pardee wrote: > Hugo and James, (and any others with non-crashing binary nvidia driver systems) > Can you help us figure out what your "secret" to non-crashing nvidia is? > What nvidia binary driver version are you using? Could you send us > the output of nvidia-bug-report? > If you repeatedly alternately log in and out of two different screens > at least twenty times, one of the screens will not crash? What about > ctrl-alt-backspace zapping the screens one after another (waiting 5 > seconds in between zaps) We have always been able to crash things > that way. (might be understandable to crash if x servers exit > abnormally) > > Our old implementation with debian 2.6.8 with ruby and nvidia 6629 > drivers worked great, but now ubuntu/evdev/nvidia 76** we have the > crashing problem on logout intermittently. It gets worse with more > than 2 users. It seems that consoles get corrupted first, then the x > servers are more prone to crashing. After one of our displays > crashes, we can't start it back up without /etc/init.d/gdm restart to > reset all the cards. > > ALSO, I ran across some info on XGI video cards today. http://www.xgitech.com/ > They already have linux drivers (with 2D open source) and may release > fully open source (3D included) in the near future. They are also > very affordable, see: > http://www.newegg.com/Product/ProductList.asp?Submit=GO&Range=1&bop=and&description=xgi&Order=price > I sent them an email asking some more detailed questions but haven't heard back. > > Thanks, > Michael Pardee > Open Sense Solutions LLC > http://opensensesolutions.com > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id865&op=click > _______________________________________________ > Linuxconsole-dev mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev > |