RE: Recent -CURRENT panic (New interrupt code related?); backtrace included

2003-11-13 Thread Xin LI/
Yes I have device apic enabled, and after setting options NO_MIXED_MODE, the
problem persists. However, fortunatelly, the spurious.patch seemed to solved
the problem, and the system has been up for 9 hours without panic'ing as I
described before.

Do you need me to test atpic.patch as well? 

-Original Message-
From: John Baldwin [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 13, 2003 12:29 AM
To: Xin LI/
Cc: [EMAIL PROTECTED]
Subject: RE: Recent -CURRENT panic (New interrupt code related?); backtrace
included


 Do you have 'device apic' enabled?  If so, can you try using 'options
NO_MIXED_MODE'.
 Barring that, can you try
http://www.FreeBSD.org/~jhb/patches/spurious.patch and if that doesn't work
 http://www.FreeBSD.org/~jhb/patches/atpic.patch?

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


RE: Recent -CURRENT panic (New interrupt code related?); backtrace included

2003-11-13 Thread John Baldwin

On 13-Nov-2003 Xin LI/ÀîöÎ wrote:
 Yes I have device apic enabled, and after setting options NO_MIXED_MODE, the
 problem persists. However, fortunatelly, the spurious.patch seemed to solved
 the problem, and the system has been up for 9 hours without panic'ing as I
 described before.
 
 Do you need me to test atpic.patch as well? 

No, that is fine, thanks.   I will have a better patch later today that should
hopefully work both with and without mixed mode.


-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


RE: Recent -CURRENT panic (New interrupt code related?); backtrace included

2003-11-12 Thread John Baldwin

On 12-Nov-2003 Xin LI/李鑫 wrote:
 Hello,
 
 On recently compiled kernels, I often get panics which seemed to be interrupt 
 related. Among
 other things, almost all of them claims that Kernel trap 30, which seemd to be 
 strange. 
 
 The kernel I am currently running, namely,
 
 FreeBSD servers.frontfree.net 5.1-CURRENT FreeBSD 5.1-CURRENT #5: Sat Oct 25 
 22:27:05 CST 2003   
 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVERS  i386
 
 seemed to be ok, however, when I am trying the new kernels (you see, 14 compile and 
 run
 attempts:), it exhibits incredible instablity.
 
 FreeBSD 5.1-CURRENT #19: Wed Nov 12 12:17:28 CST 2003
 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVERS
 
 Here is one of the crashdumps I caught. The machine was configured with a UP kernel, 
 with
 DEVICE_POLLING enabled. There are two networking adapters attached to it, a fxp and 
 a dc, and the
 machine itself act as a NAT gateway. The network load is not very heavy. If you 
 think the
 backtrace helpful, or need any more information, please write me and I will try 
 everything I can
 to help.

Do you have 'device apic' enabled?  If so, can you try using 'options NO_MIXED_MODE'.
Barring that, can you try http://www.FreeBSD.org/~jhb/patches/spurious.patch and
if that doesn't work http://www.FreeBSD.org/~jhb/patches/atpic.patch?

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Recent -CURRENT panic (New interrupt code related?); backtrace included

2003-11-11 Thread Xin LI/
Hello,

On recently compiled kernels, I often get panics which seemed to be interrupt related. 
Among other things, almost all of them claims that Kernel trap 30, which seemd to be 
strange. 

The kernel I am currently running, namely,

FreeBSD servers.frontfree.net 5.1-CURRENT FreeBSD 5.1-CURRENT #5: Sat Oct 25 22:27:05 
CST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVERS  i386

seemed to be ok, however, when I am trying the new kernels (you see, 14 compile and 
run attempts:), it exhibits incredible instablity.

FreeBSD 5.1-CURRENT #19: Wed Nov 12 12:17:28 CST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVERS

Here is one of the crashdumps I caught. The machine was configured with a UP kernel, 
with DEVICE_POLLING enabled. There are two networking adapters attached to it, a fxp 
and a dc, and the machine itself act as a NAT gateway. The network load is not very 
heavy. If you think the backtrace helpful, or need any more information, please write 
me and I will try everything I can to help.

servers# gdb -k /usr/obj/usr/src/sys/SERVERS/kernel.debug vmcore.0 
GNU gdb 5.2.1 (FreeBSD)
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...
panic: from debugger
panic messages:
---
panic: from debugger


Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc0639654
stack pointer   = 0x10:0xc6305a98
frame pointer   = 0x10:0xc6305aa4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 11 (idle)
panic: from debugger
Uptime: 23m22s
Dumping 63 MB
 16 32 48
---
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc04e8b41 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2  0xc04e8ed7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3  0xc0464252 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4  0xc04641b2 in db_command (last_cmdp=0xc06cc440, cmd_table=0x0, 
aux_cmd_tablep=0xc069d338, 
aux_cmd_tablep_end=0xc069d33c) at /usr/src/sys/ddb/db_command.c:346
#5  0xc04642f5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6  0xc04672e5 in db_trap (type=30, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7  0xc063939c in kdb_trap (type=30, code=0, regs=0xc6305ca0) at 
/usr/src/sys/i386/i386/db_interface.c:171
#8  0xc064cda6 in trap_fatal (frame=0xc6305ca0, eva=0) at 
/usr/src/sys/i386/i386/trap.c:816
#9  0xc064c822 in trap (frame=
  {tf_fs = 24, tf_es = 1075970064, tf_ds = -1636237296, tf_edi = 0, tf_esi = 
-1059059840, tf_ebp = -969909024, tf_isp = -969909044, tf_ebx = -1059063048, tf_edx = 
0, tf_ecx = 2, tf_eax = 0, tf_trapno = 30, tf_err = 0, tf_eip = -1067175531, tf_cs = 
8, tf_eflags = 582, tf_esp = -969909016, tf_ss = -1067175489})
at /usr/src/sys/i386/i386/trap.c:618
#10 0xc063ad58 in calltrap () at {standard input}:94
#11 0xc06431bf in cpu_idle () at /usr/src/sys/i386/i386/machdep.c:1071
#12 0xc04d449c in idle_proc (dummy=0x0) at /usr/src/sys/kern/kern_idle.c:86
#13 0xc04d41d4 in fork_exit (callout=0xc04d4460 idle_proc, arg=0x0, frame=0x0)
at /usr/src/sys/kern/kern_fork.c:793
(kgdb) bt full
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
No locals.
#1  0xc04e8b41 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
No locals.
#2  0xc04e8ed7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
td = (struct thread *) 0xc0e00780
bootopt = 260
newpanic = 0
ap = 0xc6305ae0 \230[0AF2251d?
buf = from debugger, '\0' repeats 242 times
#3  0xc0464252 in db_panic () at /usr/src/sys/ddb/db_command.c:450
No locals.
#4  0xc04641b2 in db_command (last_cmdp=0xc06cc440, cmd_table=0x0, 
aux_cmd_tablep=0xc069d338, 
aux_cmd_tablep_end=0xc069d33c) at /usr/src/sys/ddb/db_command.c:346
cmd = (struct command *) 0xc06658c0
t = 0
modif = 
\0\231r?[0r\0\0\0qr\0\0\0\001\0\0\0H[0200\214qaK\0 
$rp\0\0\0l\231r[0`F\234h200^F0\0\0\0\020\0\0\0h\231rWF200\0\0\0\020\0\0
addr = -1067175531
count = -1
have_addr = 0
result = 0
#5  0xc04642f5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
No locals.
#6  0xc04672e5 in db_trap (type=30, code=0) at /usr/src/sys/ddb/db_trap.c:73
bkpt = 0
#7  0xc063939c in kdb_trap (type=30, code=0, regs=0xc6305ca0) at 
/usr/src/sys/i386/i386/db_interface.c:171
ef = 582
ddb_mode = 1
#8  0xc064cda6 in trap_fatal (frame=0xc6305ca0, eva=0) at 
/usr/src/sys/i386/i386/trap.c:816
code = 16
type = 30
ss =