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 6:43:27 pm
List:org.freebsd.freebsd-current

we seem pretty solid on ia32 ^Z and then fg will sometimes kill teh process instead of forgrounding it though.

(I aborted several buildworlds that way accidentally)

Andrew's panic seems SMP specific though.. you may check if there is somethign different between ia32 and alpha on whether it holds schedlock at this point:

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

I'm trying to test jeff's latest patch but got side tracked by hardware ..

On Tue, 2 Jul 2002, Matthew Dillon wrote:

:... : > > > : > > : > > This is nearly 100% for me. But only on MP boxes. On my uniprocessor : > > alpha, things work just fine. Oh.. hmm.. I'm not sure if I have : > > witless compiled in there.. : > : > which is almost 100%,? the ^Z killing the process, or ^C killing the : > machine? : :^C killing the machine. : :Drew

How are we doing on IA32? I've successfully run 9 buildworld -j 5's so far with a SMP build of -current. I'm going to run a bunch more and then I'll switch to testing signals (a buildworld only generates 4 or 5 signals over the entire build so it isn't a good test for signal-related issues).

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