VectorLinux
October 25, 2014, 04:30:31 am *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Visit our home page for VL info. To search the old message board go to http://vectorlinux.com/forum1. The first VL forum is temporarily offline until we can find a host for it. Thanks for your patience.
 
Now powered by KnowledgeDex.
   Home   Help Search Login Register  
Please support VectorLinux!
Pages: [1]
  Print  
Author Topic: Vector locks when using KVM switch ?? [SOLVED]  (Read 2829 times)
Hiero2
Member
*
Posts: 57


« on: August 07, 2009, 11:36:23 am »

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  Huh, 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?
« Last Edit: August 16, 2009, 12:14:32 pm by Hiero2 » Logged
M0E-lnx
Administrator
Vectorian
*****
Posts: 3185



« Reply #1 on: August 07, 2009, 11:53:36 am »

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

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
FULL URL: http://en.wikipedia.org/wiki/KVM_switch

This might explain why your problems
« Last Edit: August 07, 2009, 12:17:01 pm by M0E-lnx » Logged

Hiero2
Member
*
Posts: 57


« Reply #2 on: August 07, 2009, 06:23:07 pm »

Remember the short fat guy on Car 54? Ooo, ooo, ooo! [I mean, how can you represent that in print?!]

Well, dude, sure sounds good! It fits the happenings and circumstances. I'll be checking it out, 4 sure.

xorg.conf has no string DCC. So how do I tell xorg to include noDCC?

Logged
uelsk8s
Administrator
Vectorian
*****
Posts: 2504



« Reply #3 on: August 09, 2009, 08:13:15 am »

try
Option "NoDCC"   "true"
in the DEVICE section
Logged
Hiero2
Member
*
Posts: 57


« Reply #4 on: August 10, 2009, 05:41:00 am »

 Undecided  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:

From xorg.conf:
Section "Monitor"
 DisplaySize 336 269 # 96 DPI @ 1280x1024 (non 4:3 aspect)
  Option "UseEdidFreqs" "1"
#DisplaySize     380   300   # mm
Identifier   "Monitor0"
VendorName   "HSD"
ModelName    "HC194D"
### Comment all HorizSync and VertRefresh values to use DDC:   Huh
HorizSync    31.0 - 81.0
VertRefresh  56.0 - 75.0
Option       "DPMS"
EndSection

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.

Mark
Logged
uelsk8s
Administrator
Vectorian
*****
Posts: 2504



« Reply #5 on: August 10, 2009, 06:18:45 am »

Quote
### Comment all HorizSync and VertRefresh values to use DDC: 
the comment means if you comment out the following HorizSync and VertRefresh lines they will not be used and xorg will use DCC instead.

the NoDCC line goes in the Device section for your video card
Logged
Hiero2
Member
*
Posts: 57


« Reply #6 on: August 10, 2009, 06:35:19 am »

Ahh! Interesting - I didn't think of it that way "Comment all . . .".

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??

Ok - new data.
First, I found this Wikipedia page - VERY useful.  
http://en.wikipedia.org/wiki/VGA_connector

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 . . .).

From xorg.0.log
(II) NVIDIA(0): NVIDIA GPU GeForce 6600 (NV43) at PCI:1:0:0 (GPU-0)
(--) NVIDIA(0): Memory: 262144 kBytes
(--) NVIDIA(0): VideoBIOS: 05.43.02.46.01
(--) NVIDIA(0): Interlaced video modes are supported on this GPU
(--) NVIDIA(0): Connected display device(s) on GeForce 6600 at PCI:1:0:0:
(--) NVIDIA(0):     HSD HC194D (CRT-0)
(--) NVIDIA(0): HSD HC194D (CRT-0): 400.0 MHz maximum pixel clock
(WW) NVIDIA(0): The EDID for HSD HC194D (CRT-0) contradicts itself: mode
(WW) NVIDIA(0):     "640x360" is specified in the EDID; however, the EDID's
(WW) NVIDIA(0):     valid HorizSync range (31.000-81.000 kHz) would exclude
(WW) NVIDIA(0):     this mode's HorizSync (26.2 kHz); ignoring HorizSync check
(WW) NVIDIA(0):     for mode "640x360".
(II) NVIDIA(0): Assigned Display Device: CRT-0
(II) NVIDIA(0): Validated modes:
(II) NVIDIA(0):     "1280x1024"
(II) NVIDIA(0):     "1024x768"
(II) NVIDIA(0):     "800x600"
(II) NVIDIA(0):     "640x480"
(II) NVIDIA(0): Virtual screen size determined to be 1280 x 1024
(**) NVIDIA(0): DPI set to (96, 96); computed from "DPI" X config option
(**) NVIDIA(0): Enabling 32-bit ARGB GLX visuals.

However, the process the wiki pages uses to reset the xorg.conf using the vid card drivers sounds like less risky alternative than me editing the xorg.conf myself (ignorant noob that I am).

Thanks;
Mark
Logged
M0E-lnx
Administrator
Vectorian
*****
Posts: 3185



« Reply #7 on: August 10, 2009, 06:50:55 am »

Wow... it's amazing how the use of a really "dump" device can escalate to such a big deal. At this point, I would have just gotten rid of the thing Wink
Logged

Hiero2
Member
*
Posts: 57


« Reply #8 on: August 10, 2009, 10:42:57 am »

 Grin - 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.

 Cool
Logged
uelsk8s
Administrator
Vectorian
*****
Posts: 2504



« Reply #9 on: August 10, 2009, 01:51:36 pm »

Ahh! Interesting - I didn't think of it that way "Comment all . . .".

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,
Logged
Hiero2
Member
*
Posts: 57


« Reply #10 on: August 16, 2009, 12:14:09 pm »

uelsk8s;

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.

So thanks, and I'll mark the thread solved.
Mark, aka Hiero2
Logged
GrannyGeek
Packager
Vectorian
****
Posts: 2567


« Reply #11 on: August 16, 2009, 04:30:49 pm »

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 type
startx
at 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
Logged

Registered Linux User #397786

Happily running VL 7 Gold on  a Sempron LE-1300 desktop (2.3 GHz), 4 G RAM,  GeForce 6150 SE onboard graphics and on an HP Pavilion dv7 i7, 6 gigs, Intel 2nd Generation Integrated Graphics Controller
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!