Red Hat Bugzilla – Bug 52919
Switching back and forth between virtual consoles can lock up machine
Last modified: 2005-10-31 17:00:50 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1)
Description of problem:
On a bordeaux running fairfax or 7.1sbe, switching between virtual consoles
can lock up machine
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Switch between virtual consoles on IA64 71sbe and 7.2
Actual Results: Machine sometimes locks up.
Expected Results: Machine shouldn't lockup.
Was X involved at all?
Yes, switching back to X windows from a text console after having switched from
X windows is usually when the lockup occurs.
Is an error recorded in the system logs?
(i.e., BIOS system event logs.)
*** Bug 52928 has been marked as a duplicate of this bug. ***
Where is this log located?
In the firmware.
Also, I'm idly curious what happens if you downgrade the firmware to something
in the 79-83 range or so.
Created attachment 33584 [details]
Critical interrupts in bordeaux system event viewer after virtual console switching locup
Not fixed in Pensacola IA64 RC2.
I've got a fix for this that will be ready for testing soon.
A potential fix I should say...
Please attach patch when it's available.
Potential fix didn't help, in testing here. Still waiting on info from Intel.
mharris: just FYI, HW info:
any ia64 system.
video cards observed: nvidia (using XFree86 drivers) ATI Rage 128 (PCI and AGP).
Matrox G400 AGP. S3 Trio64 PCI (using basic VGA drivers.) ATI Mach64 (onboard).
Created attachment 34262 [details]
VTswitch patch from VMware..
The above patch is what I integrated into XFree86-4.1.0-4 for testing,
and it has aparently fixed the problem for a few people, but not for
others, and in most cases made the problem worse. This is not limited
to ia64 testing, but also x86 testing.
I've informed Mark at VMware of the results, and hope he contacts me
back. In the mean time, I'm going to see if I can figure out the logic,
and try and find a solution.
BTW, thanks for the hardware list Bill.
Ok, this could be potentially a crucial help... Can someone
experiencing these hangs on ia64 test the following for me and
report what occurs.
1) Run X
2) Take your mouse, put it upside down, making sure no buttons are pressed
3) Place the mouse somewhere stable and out of the way, where it wont move
(upside down) or be affected by desk vibrations, etc.. possibly even
4) Exercise slowly the VTswitch. See if you can switch VC's ok without
X hanging, first starting slowly, waiting a few seconds, trying again,
and then try to do it as fast as possible, as soon as the switch
triggers, hit it again.
I'm trying to see if there are multiple problems. One is known, at least
on x86 where VT switching _while_ the mouse is moving, can increase the
likelyhood of a hang dramatically, and in some test cases, it is a 100%
I can reproduce the latter on one of my machines with various video
hardware. This very much hints toward a race condition in the generic
VT switch code WRT the mouse being enabled/disabled, which is what the
above patch from VMware attempts to fix but fails..
Now back to trying to figure out why...
the mouse thing doesn't appear to have much to do with it, AFAICT.
Interestingly, if you run with a framebuffer console, it doesn't appear to
hang the machine.
Installed XFree86-4.1.0-4 on system with ATI Mach64 video. Switching terminals
no longer hangs system, system now reboots.
I believe this bug might have something to do with bug #50732
Bill/Arjan, could this be kernel console code issue as above?
The various VT switch issues, seem to be more than one bug on
50732 is a xfree bug not kernel bug.
Also here it is XFree that is doing the mode switch....
the fact that it works with fbcon enabled shows that only certain mode switches
are defective... it doesn't make things easier though ;(
Fixed in 2.4.9-9.1.
Just to clarify the closure... the bug was a bug in the kernel, fixed with
the new kernel version bill has indicated above. This should solve the
problem for ia64 VT switching.
Just for others that are monitoring bugzilla reported VT switch bugs,
this new kernel will likely fix some of those problems also. I
believe that XFree86 still has some VT switch bugs however, and will
be testing the problems that are still open in bugzilla to see which
ones are still relevant. It will probably be easier to fix the remaining
problems now that the kernel issue is fixed.
By way of further notes. There is a kernel console switch race on SMP too. A
patch for that is testing in the current -ac tree