Two new pieces of hardware - Nvidia graphics card, and a KVM switch. Installed the nvidia yesterday, got all running ok, and no problems.

Today I hook up a KVM switch. I reboot and get VL up and going. 5 minutes later she locks up, and I mean 100%. Ctrl-Alt-backspace/F1, etc - no effect. No keyboard, no mouse, screen is frozen. I plug a mouse into a USB port on the machine - no response. I am forced to reboot. Ok, done, restart, all is good - for 10 minutes or so, and then - bam, lockup. Repeat process, same result. Disconnect KVM, reboot, run for half hour/45 minutes, no problem. Reconnect KVM, ran for a half hour or so, then locked up.

A KVM switch is a dumb machine. I mean literally dumb - it is mechanical, or at least so I believe. So how could a KVM switch cause a lockup , or is it coincidental? I don't think it is, and if I'm right, what could I possibly set that would help? Or do I just have to loose all my desktop space for a second monitor?

Maybe you've been wrong all along.Maybe the KVM switch is not so dumb after all

Seriously... I dunno why this would happen.

[Edit]FROM WIKIPEDIA:

Quote

The problem is that Xorg on startup tries to ask the monitor settings passing trough DCC. Some KVM switches don't have the capabilities to transmit correclty the DCC signal, so you have to specify noDCC in xorg.conf

Ok - I went into xorg.conf to look around and scope things before I started making changes. I'm not going to add the noDCC yet. I think there may be a risk of damaging the monitor doing that. Here is what makes me think that might be the case:

Notice the comment, and the refresh rates. The comment is specifying that the refresh rates will be looking for the DDC connect with the monitor to determine the correct rates. The refresh range mentioned, I think, goes high enough to damage the LCD flat monitor I'm using. Aarrgh.

Hmmm. I'll have to look into this further. No fix yet.

BTW, I'm assuming that DDC was what you meant - it seems to be "Direct Data Channel", or basically what makes the monitor PnP. DDC and DCC are new to me, but that was the definition I found that made the most sense.

BTW, you got me started down this road at least, getting me looking for DDC - I'd never heard of that, and my google-fu didn't turn up anything useful until I started including that phrase in the search. And you DO mean "DDC", not "DCC", right??

On that page, they have a possible solution offered - IF the problem is actually the video. They mention to check the xorg log file for errors. I didn't have any errors (EE), but I did find a warning (WW). (I don't think this is causing the issue, but . . .).

- ya! Ya kno, it was too much stuff like this that always kiboshed my previous attempts to get a linux box up and running. This time I have two running distros, and this is more like fine-tuning - but almost "the straw on the camel's back" fine-tuning. Sheeesh.

Further update, and trail for those who will follow. KVM switches ain't dumb devices any more. Haven't been for some years, and most of you wouldn't want one if it was. That's because all "plug and play" relies on a "conversation" with the OS. Keyboard, mouse, monitor, other externals - they talk back.

Now, that said, this VL box has been running, using the KVM switch, all morning. I did make an edit to xorg.conf, but I'm not sure that is actually what made the difference. That's because I may have made an unintentional change this morning from when the machine bugged out on me last week - I booted the VL6 with the monitor up, and the KVM switch turned ONLY to the VL machine. Turns out this is at least one very important time when using a KVM switch. If the starting OS doesn't get feedback from the I/O devices, it does the best it can with default settings. Which may be pretty screwed for your real settings. I also used the nvidia setting gui to rewrite the xorg settings towards a more manual control of the refresh, as per the Wikipedia link (for VGA Connector) that I posted earlier in this thread. http://en.wikipedia.org/wiki/VGA_connector AND, dummy me, I finally got out the KVM user's manual, and read that, too. Turns out there is a keyboard reset hot key combination. Might have helped last week, might. Maybe not, too, can't really tell at this point, without recreating the initial lockup, which I don't care to do, thank you very much.

So, what I've learned: * If it's a critical application, there are expensive (+$150-$1,000) KVM switches that are designed to work cross-platform and with multiple hardware formats (eg PS/2, USB), maintaining dummy video signal etc. * Normal (i.e. cheap - $20-60) KVM switches, that are ~ 4 yr old or less, will do the needed communication, but may have issues that need to be learned about to manage. This is not just a Linux thing - I've got a cheap PS/2 KVM from a good mfr, whose stuff I have had a lot of good experience with - and that KVM won't work with my Windows box. * If there are issues, look to the startup. When attached through the KVM, startup the box with the monitor, keyboard, and mouse attached (KVM switch turned on to the starting machine). * Do new hardware without the kvm. Get it running then, with the machine OFF, put the KVM back in the loop. The Wikipedia entry above tells you how to use Nvidia's gui settings to rewrite the xorg.conf to help prevent the startup issues. If you've got different hardware, at least you are looking in the right area for answers. Any one of 4 components could have caused my symptoms: the monitor, the vid card, the keyboard, and the mouse. That's right - the keyboard or the mouse could have also caused my issues. But if it's the keyboard or mouse, the KMV mfrs just recommend you try a different one. * When all else fails, read the user's manual again.

BTW, you got me started down this road at least, getting me looking for DDC - I'd never heard of that, and my google-fu didn't turn up anything useful until I started including that phrase in the search. And you DO mean "DDC", not "DCC", right??

Thanks;Mark

I meant "NoDCC" and that is all I had to do when I had the same thing happen with my VL and KVM switch.Sorry I could not communicate this better,

You communicated fine. Your information was helpful. VL is up and running with the kvm switch, although it did lock today, for the first time in a week. IDK!?

I haven't used the noDCC switch, because when I googled that, every source I found was telling me DDC is associated with video. Looking for DCC only came up with stuff for train controls or something from the oil and gas industry.

I'm learning this stuff fast - but I'm still new enough I don't want to edit xorg.conf when I don't know what the edit will do. If I were sure that it wouldn't hurt, I would add the noDCC just coz you say it works for you.

But, the slightly longer method that your information led me to seems to be working, except the once this morning.

I'm learning this stuff fast - but I'm still new enough I don't want to edit xorg.conf when I don't know what the edit will do. If I were sure that it wouldn't hurt, I would add the noDCC just coz you say it works for you.

PMJI, but I think I can put your mind at ease as far as editing xorg.conf goes. /etc/X11/xorg.conf has no effect until the X server is started. The X server is what underlies the graphical interface and desktop, such as IceWM, XFce, or KDE. By default, LILO sets up as an option a plain-text login (linux-tui) that does not start the X server. Once you have logged in through linux-tui, you can start your graphical interface by typing startx at a prompt (you can do this as user).

If you want to edit /etc/X11/xorg.conf and are not sure of the effects of what you're doing, first copy /etc/X11/xorg.conf to something like /etc/X11/xorg.conf_bak. You must be root to do this. Then, as root, edit /etc/X11/xorg.conf as desired and save it. Then as user typestartxat the console prompt. Your edit will take place as soon as X is started. You don't need to reboot.

If X and your desktop don't start, you will probably see some error messages at the console prompt. If your desktop starts but has some problem and you can't exit normally, you can do Control+Alt+Backspace, which will kill the X server. If you had typed startx at a console prompt, you will be back in text mode with no X server running.

To go back to your original /etc/X11/xorg.conf, as root delete the xorg.conf that didn't work and rename xorg.conf_bak to xorg.conf. The next time you startx your original xorg.conf file will be in effect.

You see the wonderful power of having the linux-tui option available in LILO. Any time you are having problems with the GUI, you can boot with linux-tui and be at a text console, from which you can run experiments and test them out without having to reboot. --GrannyGeek