Bug 52919 - Switching back and forth between virtual consoles can lock up machine
Summary: Switching back and forth between virtual consoles can lock up machine
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 7.3
Hardware: ia64
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: Brock Organ
: 52928 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-30 21:02 UTC by Clay Cooper
Modified: 2005-10-31 22:00 UTC (History)
13 users (show)

Clone Of:
Last Closed: 2001-10-21 21:26:41 UTC

Attachments (Terms of Use)
Critical interrupts in bordeaux system event viewer after virtual console switching locup (6.14 KB, text/plain)
2001-10-08 18:30 UTC, Clay Cooper
no flags Details
VTswitch patch from VMware.. (1.28 KB, patch)
2001-10-17 06:47 UTC, Mike A. Harris
no flags Details | Diff

Description Clay Cooper 2001-08-30 21:02:06 UTC
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:

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.

Additional info:

Comment 1 Bill Nottingham 2001-09-03 03:25:17 UTC
Was X involved at all?

Comment 2 Clay Cooper 2001-09-04 12:46:38 UTC
Yes, switching back to X windows from a text console after having switched from
X windows is usually when the lockup occurs.

Comment 3 Bill Nottingham 2001-10-01 18:25:39 UTC
Is an error recorded in the system logs?

Comment 4 Bill Nottingham 2001-10-01 18:25:59 UTC
(i.e., BIOS system event logs.)

Comment 5 Bill Nottingham 2001-10-01 18:31:03 UTC
*** Bug 52928 has been marked as a duplicate of this bug. ***

Comment 6 Clay Cooper 2001-10-01 19:23:57 UTC
Where is this log located?

Comment 7 Bill Nottingham 2001-10-01 19:26:23 UTC
In the firmware.

Comment 8 Bill Nottingham 2001-10-02 21:19:16 UTC
Also, I'm idly curious what happens if you downgrade the firmware to something
in the 79-83 range or so.

Comment 9 Clay Cooper 2001-10-08 18:30:48 UTC
Created attachment 33584 [details]
Critical interrupts in bordeaux system event viewer after virtual console switching locup

Comment 10 Wendy Hung 2001-10-11 17:24:21 UTC
Not fixed in Pensacola IA64 RC2.

Comment 11 Mike A. Harris 2001-10-15 09:33:44 UTC
I've got a fix for this that will be ready for testing soon.

Comment 12 Mike A. Harris 2001-10-15 09:37:39 UTC
A potential fix I should say...

Comment 13 Bill Nottingham 2001-10-15 14:17:24 UTC
Please attach patch when it's available.

Comment 14 Bill Nottingham 2001-10-16 15:56:30 UTC
Potential fix didn't help, in testing here. Still waiting on info from Intel.

Comment 15 Bill Nottingham 2001-10-16 16:26:15 UTC
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).

Comment 16 Mike A. Harris 2001-10-17 06:47:22 UTC
Created attachment 34262 [details]
VTswitch patch from VMware..

Comment 17 Mike A. Harris 2001-10-17 06:50:03 UTC
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.

Comment 18 Mike A. Harris 2001-10-17 06:50:49 UTC
BTW, thanks for the hardware list Bill.

Comment 19 Mike A. Harris 2001-10-17 07:45:15 UTC
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%

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

Comment 20 Bill Nottingham 2001-10-18 18:32:10 UTC
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.

Comment 21 Wendy Hung 2001-10-19 18:21:16 UTC
Installed XFree86-4.1.0-4 on system with ATI Mach64 video.  Switching terminals 
no longer hangs system, system now reboots.

Comment 22 Mike A. Harris 2001-10-20 23:05:54 UTC
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.

Comment 23 Arjan van de Ven 2001-10-20 23:11:10 UTC
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 ;(

Comment 24 Bill Nottingham 2001-10-29 17:02:10 UTC
Fixed in 2.4.9-9.1.

Comment 25 Mike A. Harris 2001-10-30 02:51:23 UTC
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.

Comment 26 Alan Cox 2001-10-30 08:44:04 UTC
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

Note You need to log in before you can comment on or make changes to this bug.