[issue774] mp_lock related panic (it seems)

Matthew Dillon dillon at apollo.backplane.com
Fri Sep 7 12:30:27 PDT 2007

:Rumko <rumcic at gmail.com> added the comment:
:Finally was able to get a usable core dump (when forcing the core dump I al=
:got a 0B vmcore) with latest -HEAD ... it's at leaf:~rumko/crash/dumps/*.6
:priority:  -> bug

    It died while running FAH504-Linux.exe.  The only place in the trap
    code that asserts the MP lock is being held is if in_vm86call is set.

    I think what may be happening here is that a VM86 call is blocking
    somewhere and causing a thread switch to occur.  Then some other 
    possibly unrelated process takes an AST fault and hits that assertion,
    which is made BEFORE the trap code checks whether the frame is in an
    emualted VM context or not.

        if (in_vm86call) {				<<<<< This is a global
                ASSERT_MP_LOCK_HELD(curthread);		<<<<< check made too
                if (frame->tf_eflags & PSL_VM &&
                    (type == T_PROTFLT || type == T_STKFLT)) {

							<<<<< check should be
							      made down here
							      (and it is)


    I think the assertion is bogus and the solution is to just remove it.
    I will commit this right now and have also included the patch below.

					Matthew Dillon 
					<dillon at backplane.com>

Index: i386/trap.c
RCS file: /cvs/src/sys/platform/pc32/i386/trap.c,v
retrieving revision 1.107
diff -u -p -r1.107 trap.c
--- i386/trap.c	25 Jul 2007 18:21:35 -0000	1.107
+++ i386/trap.c	7 Sep 2007 19:27:50 -0000
@@ -464,7 +464,6 @@ 	type = frame->tf_trapno;
 	code = frame->tf_err;
 	if (in_vm86call) {
-		ASSERT_MP_LOCK_HELD(curthread);
 		if (frame->tf_eflags & PSL_VM &&
 		    (type == T_PROTFLT || type == T_STKFLT)) {
 #ifdef SMP

More information about the Bugs mailing list