From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 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): How reproducible: Sometimes Steps to Reproduce: 1.Switch between virtual consoles on IA64 71sbe and 7.2 2. 3. Actual Results: Machine sometimes locks up. Expected Results: Machine shouldn't lockup. Additional info:
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 unplugging it. 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% deal. 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 differnt hardware.
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