On Thu, Jun 28, 2001 at 08:21:15PM -0700, Heather wrote: > > On Thu, Jun 28, 2001 at 10:59:28AM -0700, Heather wrote: > > > > and the slightest variation can result in a black screen when your > > > > start > > > > the X server. > > > > > > I recommend having your net connection live and be ssh'd in from another > > > box. > > > That keeps you a visible text session. > > > > > > You can sometimes use a different GUI utility (e.g. SVGAlib app, or > > > vga_reset > > > or something) to reinit the video and keep working without having to > > > reboot > > > to yank its chain. > > > > CTRL+ALT+backspace or CTRL+ALT+F1 still work even when the display > > doesn't want to show you anything. > > Not necessarily. The X server is also responsible for input focus - one might > argue that's its primary job - and if it's *really* unhappy, it won't get > around > to your useful keystroke.
Hmm, good point. That makes sense, given my past experience with X... > Too busy dealing with a crying vidcard. Maybe next > week sometime. > > Meanwhile your monitor is squealing at you :( :( :( The X server doesn't know that the monitor isn't syncing, since the vid card doesn't act any differently whether the monitor handles the video output or not. (I think it can detect whether or not a monitor is connected, though.) I don't know if this is the case for most LCD displays in laptops, or if the video controller will stop working if the vid mode is out of range. That wouldn't make much sense though, because that would make it hard to get back to a working range... > > > If the X server locks up, you can > > always use alt+sysrq+u, alt+sysrq+b > > Magic sysrq's might only work at a console prompt. cf above, your keyboard > may be inoperable. No, they always work, since it's all in the kernel, before it goes through the "keyboard mode" stuff that kbdmode messes with. That being the case, it doesn't matter if X is running and has your keyboard in raw mode. You obviously don't see the output from your keystrokes, but they show up in the kernel log messages, even alt+sysrq+?. Err, one other thing that can bring down alt+sysrq: The system could deadlock with interrupts disabled, in which case you lose, and nothing will ever get through, not ethernet, not mouse, not keyboard, not serial. I don't think X can disable interrupts, though, so as long as the kernel isn't buggy, you're fine (he says optimistically... :) Anyway, we both agree that logging in remotely is the way to go. I was just pointing out that, especially for this problem, you can get away with not doing that if you can deal with the system when it's having problems. (For the display-won't-sync problem, nothing is going to happen that overwrites the kernel in memory or whatever, so it's unlikely that the system will hang and require a reboot.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
