> It's not the fact that I have an extra, unused on-board video > (checked). > Also, when the video output stops, the console still works > fine for input > (keyboard never stops working normally). Also, I can > successfully start X > just fine. It's just the vty's output that is stopped (all > vtys, alt-Fn > has no effect on output, only input). It's not wiped, just no further > changes. I tried issuing a vidcontrol; before lockup, color > change works > fine, after, no effect. > > It's acting as if the mapping in memory to the video buffer > has changed. >
The problem is that the syscons driver stops updating the display because it's timeout call to scrn_timeout() gets lost and/or never re-armed. The causes could be one or more of the following: 1) a race in the syscons code that determines whether or not to re-arm the periodic timeout. 2) a race in the callout code that results in random timeouts getting lost. Since syscons timeout happens 10 times a second, it has a high chance of being affected. 3) breakage in softclock, resulting in timeouts not being triggered at all. I highly doubt this one since the rest of the machine works fine. Note that while it happens easily on SMP machines, I was able to trigger it last night on a UP box in the form of the syscons bell getting turned on but not off. My SMP box died while trying to debug this and I haven't been able to get access to another one yet. If anyone is interested in looking at it, /sys/dev/syscons/syscons.c:scrn_timeout() is a good place to start. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
