atom feed30 messages in org.freebsd.freebsd-currentRe: KSE signal problems still
FromSent OnAttachments
Andrew GallatinJul 2, 2002 2:12 pm 
Julian ElischerJul 2, 2002 3:54 pm 
Andrew GallatinJul 2, 2002 4:10 pm 
Julian ElischerJul 2, 2002 5:48 pm 
Andrew GallatinJul 2, 2002 6:02 pm 
Matthew DillonJul 2, 2002 6:11 pm 
Julian ElischerJul 2, 2002 6:38 pm 
Andrew GallatinJul 2, 2002 6:42 pm 
Julian ElischerJul 2, 2002 6:43 pm 
Julian ElischerJul 2, 2002 6:45 pm 
Andrew GallatinJul 2, 2002 6:57 pm 
Julian ElischerJul 2, 2002 7:30 pm 
Julian ElischerJul 2, 2002 7:31 pm 
Andrew GallatinJul 2, 2002 7:56 pm 
John BaldwinJul 2, 2002 9:17 pm 
Julian ElischerJul 2, 2002 9:42 pm 
David XuJul 2, 2002 10:34 pm 
Matthew DillonJul 2, 2002 10:35 pm 
Julian ElischerJul 2, 2002 10:55 pm 
Matthew DillonJul 2, 2002 11:02 pm 
Bruce EvansJul 3, 2002 12:32 am 
Bruce EvansJul 3, 2002 12:44 am 
Julian ElischerJul 3, 2002 1:37 am 
John BaldwinJul 3, 2002 1:40 am 
Terry LambertJul 3, 2002 1:52 am 
Julian ElischerJul 3, 2002 2:13 am 
Julian ElischerJul 3, 2002 2:25 am 
John BaldwinJul 3, 2002 2:47 am 
Julian ElischerJul 3, 2002 9:30 am 
John BaldwinJul 3, 2002 9:57 am 
Subject:Re: KSE signal problems still
From:Julian Elischer (jul@elischer.org)
Date:Jul 2, 2002 3:54:17 pm
List:org.freebsd.freebsd-current

On Tue, 2 Jul 2002, Andrew Gallatin wrote:

An easy way to induce a panic w/a post KSE -current is to ^C gdb as it starts on an SMP machine:

A possibly related breakage is:

type ^Z while doing "make buiildworld" (or something similar).

when you type 'fg' there is a high change the build will abort..

# gdb -k /var/crash/kernel.1 /var/crash/vmcore.1 GNU gdb 5.2.0 (FreeBSD) 20020627 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-undermydesk-freebsd"... ^C

panic: mutex sched lock not owned at ../../../kern/subr_smp.c:126 cpuid = 1; lapic.id = 01000000 Debugger("panic") Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0 db> where No such command db> tr Debugger(c02dbf5a) at Debugger+0x46 panic(c02db1a8,c02db318,c02df736,7e,c4445540) at panic+0xd6 _mtx_assert(c0315440,1,c02df736,7e) at _mtx_assert+0xa8 forward_signal(c4445540) at forward_signal+0x1a tdsignal(c4445540,2,2) at tdsignal+0x182 psignal(c443d558,2) at psignal+0x3c8 pgsignal(c441ad00,2,1,c441ad1c,0) at pgsignal+0x63 ttyinput(3,c41e8e30,c41e8e00,0,c0347903) at ttyinput+0x316 ptcwrite(c4307a00,d7d5ec88,7f0011,1,d7d5ebc4) at ptcwrite+0x17f spec_write(d7d5ebf0,d7d5ec3c,c0204cc8,d7d5ebf0,7f0011) at spec_write+0x5a spec_vnoperate(d7d5ebf0) at spec_vnoperate+0x13 vn_write(c41ded5c,d7d5ec88,c440cd80,0,c409e780) at vn_write+0x1c8 dofilewrite(c409e780,c41ded5c,5,8088000,1) at dofilewrite+0xaf write(c409e780,d7d5ed14,3,b,282) at write+0x39 syscall(2f,2f,2f,1,8073410) at syscall+0x23c syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (4, FreeBSD ELF, write), eip = 0x281fb3a3, esp = 0xbfbff37c, ebp = 0xbfbff3e8 ---

hummmmm

so, the question is: where should we get the sched lock?

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message