Re: 6.2-PRE: Fatal Trap?
On 30/12/06, Ivan Voras [EMAIL PROTECTED] wrote: Karol Kwiatkowski wrote: This works: FreeBSD 6.2-PRERELEASE #0: Thu Dec 14 11:34:36 CET 2006 This doesn't: FreeBSD 6.2-PRERELEASE #0: Sat Dec 30 11:27:11 CET 2006 I'm not sure it that's all that matters, I can supply more information if needed. Yes, you'll need to send at least a kernel stack backtrace. See here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html Get it to start the debugger on panic and post the backtrace (bt). Is it possible to make it auto run debugger, then auto run backtrace then dump the output to disk so people who have no local access can get backtraces? Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE: Fatal Trap?
Yesterda I had also a kernel trap - process (sendmail) on a Compaq Deskpro with the 6.2 Prerelease.. I revert every option in make.conf, tried Generic kernel as well..no success... Awaiting for more info And now compiling today sources On 1/1/07, Chris [EMAIL PROTECTED] wrote: On 30/12/06, Ivan Voras [EMAIL PROTECTED] wrote: Karol Kwiatkowski wrote: This works: FreeBSD 6.2-PRERELEASE #0: Thu Dec 14 11:34:36 CET 2006 This doesn't: FreeBSD 6.2-PRERELEASE #0: Sat Dec 30 11:27:11 CET 2006 I'm not sure it that's all that matters, I can supply more information if needed. Yes, you'll need to send at least a kernel stack backtrace. See here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html Get it to start the debugger on panic and post the backtrace (bt). Is it possible to make it auto run debugger, then auto run backtrace then dump the output to disk so people who have no local access can get backtraces? Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- --- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE: Fatal Trap?
Iantcho Vassilev wrote: Yesterda I had also a kernel trap - process (sendmail) on a Compaq Deskpro with the 6.2 Prerelease.. I revert every option in make.conf, tried Generic kernel as well..no success... Awaiting for more info And now compiling today sources On 1/1/07, Chris [EMAIL PROTECTED] wrote: On 30/12/06, Ivan Voras [EMAIL PROTECTED] wrote: Karol Kwiatkowski wrote: This works: FreeBSD 6.2-PRERELEASE #0: Thu Dec 14 11:34:36 CET 2006 This doesn't: FreeBSD 6.2-PRERELEASE #0: Sat Dec 30 11:27:11 CET 2006 I'm not sure it that's all that matters, I can supply more information if needed. Yes, you'll need to send at least a kernel stack backtrace. See here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html Get it to start the debugger on panic and post the backtrace (bt). Is it possible to make it auto run debugger, then auto run backtrace then dump the output to disk so people who have no local access can get backtraces? I also ran into a trap after yesterday's cvsupdate (rpcbind traps with trap 12). Running the prvious kernel now and it works, compiling just now a new system with the today's cvsupdates (but there was no kernel stuff, so I expect no success on that). The box ist running FreeBSD fauxpas.dyn.org 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #47: Tue Dec 26 14:12:56 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/THOR amd64 The date of this uname output is the date of my last kernel build that works ... Regards, Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE: Fatal Trap?
Am 01.01.2007 um 12:31 schrieb Chris: Is it possible to make it auto run debugger, then auto run backtrace then dump the output to disk so people who have no local access can get backtraces? No, but you can enable crashdumps and run the debugger on the dump afterwards. Add dumpdev=AUTO to /etc/rc.conf, then run /etc/rc.d/dumpon start. When the next panic occurs, the kernel will write the dump to the configured swap space, and the system will save the dump to /var/crash on rebooting. See http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ kerneldebug-gdb.html on how to get a backtrace from that dump. If you're short on space in /var, and/or you have a large amount of RAM, you can set the sysctl debug.minidump to 1 to have the kernel only dump relevant portions of memory, instead of everything. This, however, is experimental in -stable, afaik. Stefan -- Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE: Fatal Trap?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [resending to list, cleared kernel logs] Larry Rosenman wrote: I had to on an emergency basis replace my aging P-1 Firewall. The guys at my hosting company gave me an AthlonXP 2200+, and with 6.1 (all the way up to today's RELENG_6_1), it works fine. I tried(!) to put 6.2-PRE (RELENG_6) on it, but no matter what I do, it panics when either NTPD or SSHD starts (depending on whats first). Unfortunately, I don't have the exact panic (it's a page not present, and if I understood my remote eyes/hands right, a NULL de-reference). The box is 300+ miles away (Distance from Austin, TX to Dallas, TX). Anyone got ideas? Here's a me too message. AMD Athlon / FreeBSD 6.2-PRERELEASE i386 This works: FreeBSD 6.2-PRERELEASE #0: Thu Dec 14 11:34:36 CET 2006 This doesn't: FreeBSD 6.2-PRERELEASE #0: Sat Dec 30 11:27:11 CET 2006 Between those all that has changed is the source (via cvsup) Panic messages: (Dec 30 11:44:31) % syslogd: kernel boot file is /boot/kernel/kernel % kernel: kernel trap 12 with interrupts disabled % kernel: % kernel: % kernel: Fatal trap 12: page fault while in kernel mode % kernel: fault virtual address = 0x74 % kernel: fault code= supervisor read, page not present % kernel: instruction pointer = 0x20:0xc055598d % kernel: stack pointer = 0x28:0xe9894bbc % kernel: frame pointer = 0x28:0xe9894bc0 % kernel: code segment = base 0x0, limit 0xf, type 0x1b % kernel: = DPL 0, pres 1, def32 1, gran 1 % kernel: processor eflags = resume, IOPL = 0 % kernel: current process = 602 (smbd) % kernel: trap number = 12 % kernel: panic: page fault % kernel: Uptime: 14s with samba disabled it happens with ntpd: (Dec 30 11:59:12) % syslogd: kernel boot file is /boot/kernel/kernel % kernel: kernel trap 12 with interrupts disabled % kernel: % kernel: % kernel: Fatal trap 12: page fault while in kernel mode % kernel: fault virtual address = 0x74 % kernel: fault code= supervisor read, page not present % kernel: instruction pointer = 0x20:0xc055598d % kernel: stack pointer = 0x28:0xe98b8bbc % kernel: frame pointer = 0x28:0xe98b8bc0 % kernel: code segment = base 0x0, limit 0xf, type 0x1b % kernel: = DPL 0, pres 1, def32 1, gran 1 % kernel: processor eflags = resume, IOPL = 0 % kernel: current process = 661 (ntpd) % kernel: trap number = 12 % kernel: panic: page fault % kernel: Uptime: 5m21s I'm not sure it that's all that matters, I can supply more information if needed. Regards, Karol - -- Karol Kwiatkowski freebsd at orchid dot homeunix dot org OpenPGP: http://www.orchid.homeunix.org/carlos/gpg/0x06E09309.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFllQ9ezeoPAwGIYsRAh5YAJ9VugCJ9hX47NrFZRM53onJU1bgfACfefmS DgJOqvP4rsvgjekwF6OYc+A= =Il28 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE: Fatal Trap?
Karol Kwiatkowski wrote: This works: FreeBSD 6.2-PRERELEASE #0: Thu Dec 14 11:34:36 CET 2006 This doesn't: FreeBSD 6.2-PRERELEASE #0: Sat Dec 30 11:27:11 CET 2006 I'm not sure it that's all that matters, I can supply more information if needed. Yes, you'll need to send at least a kernel stack backtrace. See here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html Get it to start the debugger on panic and post the backtrace (bt). signature.asc Description: OpenPGP digital signature
Re: 6.2-PRE: Fatal Trap?
i think this is related: panic: mtx_lock() of spin mutex (null) @ /r+d/6.2/src/sys/netinet/in_pcb.c:217 cpuid = 0 KDB: enter: panic [thread pid 715 tid 100055 ] Stopped at kdb_enter+0x2b: nop db ps pid ppid pgrp uid state wmesg wchancmd 715 71043 0 R+ CPU 0 rpcbind 7104343 0 S+ wait 0xc4bff648 sh 695 1 695 0 Ss select 0xc0a3ca04 syslogd 649 1 649 0 Ss select 0xc0a3ca04 devd ... db bt Tracing pid 715 tid 100055 td 0xc4e4bd80 kdb_enter(c0903edb) at kdb_enter+0x2b panic(c090318e,0,c0912361,d9,c4fda000,...) at panic+0x127 _mtx_lock_flags(c4fda090,0,c0912361,d9,38,...) at _mtx_lock_flags+0x65 in_pcballoc(c4f1f590,c0a3ef80) at in_pcballoc+0xec tcp_attach(c4f1f590) at tcp_attach+0x94 tcp_usr_attach(c4f1f590,6,c4e4bd80) at tcp_usr_attach+0x2f socreate(1c,e8ed6cc4,1,6,c4a38780,...) at socreate+0x122 socket(c4e4bd80,e8ed6d04) at socket+0x71 syscall(3b,3b,3b,bfbfeec8,8053030,...) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (97, FreeBSD ELF32, socket), eip = 0x28134feb, esp = 0xbfbfeccc, ebp = 0xbfbfecf8 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE: Fatal Trap?
Ivan Voras wrote: Karol Kwiatkowski wrote: This works: FreeBSD 6.2-PRERELEASE #0: Thu Dec 14 11:34:36 CET 2006 This doesn't: FreeBSD 6.2-PRERELEASE #0: Sat Dec 30 11:27:11 CET 2006 I'm not sure it that's all that matters, I can supply more information if needed. Yes, you'll need to send at least a kernel stack backtrace. See here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html Get it to start the debugger on panic and post the backtrace (bt). Thanks for the link, I hope I've done it right. Here it is: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x74 fault code = supervisor read, page not present instruction pointer = 0x20:0xc055d18d stack pointer = 0x28:0xe989dbbc frame pointer = 0x28:0xe989dbc0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 637 (ntpd) [thread pid 637 tid 100059 ] Stopped at turnstile_setowner+0xd: movl0x74(%ecx),%eax db bt Tracing pid 637 tid 100059 td 0xc4de2780 turnstile_setowner(c4de9240,0,c4dc9240,c07201e0,c5102090,...) at turnstile_setowner+0xd turnstile_wait(c5101090,0,c5101000,c07234e0,e989dc24,...) at turnstile_wait+0xca _mtx_lock_sleep(c5102090,c4de2780,0,0,0,...) at _mtx_lock_sleep+0xb4 in_pcballoc(c4e892c8,c07234e0,1,c06c8de5,38,...) at in_pcballoc+0xbe tcp_attach(c4e892c8,c4e8933c,c06c8de5,0,c4e892c8,...) at tcp_attach+0x58 tcp_usr_attach(c4e892c8,0,c4de2780,0,0,...) at tcp_usr_attach+0x63 socreate(2,e989dcb8,1,0,c4ab1c90,...) at socreate+0x167 socket(c4de2780,e989dd04,c,c4de2780,80d3000,...) at socket+0xb3 syscall(3b,3b,3b,0,7,...) at syscall+0x380 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (97, FreeBSD ELF32, socket), eip = 0x282939d3, esp = 0xbfbfeb1c, ebp = 0xbfbfebf8 --- db HTH, Karol -- Karol Kwiatkowski freebsd at orchid dot homeunix dot org OpenPGP: http://www.orchid.homeunix.org/carlos/gpg/0x06E09309.asc signature.asc Description: OpenPGP digital signature
Re: 6.2-PRE: Fatal Trap?
On Saturday 30 December 2006 15:11, Karol Kwiatkowski wrote:
Ivan Voras wrote:
Karol Kwiatkowski wrote:
This works: FreeBSD 6.2-PRERELEASE #0: Thu Dec 14 11:34:36 CET 2006
This doesn't: FreeBSD 6.2-PRERELEASE #0: Sat Dec 30 11:27:11 CET
2006
I'm not sure it that's all that matters, I can supply more
information if needed.
Yes, you'll need to send at least a kernel stack backtrace. See here:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/
kerneldebug-online-ddb.html
Get it to start the debugger on panic and post the backtrace (bt).
Thanks for the link, I hope I've done it right. Here it is:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x74
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc055d18d
stack pointer = 0x28:0xe989dbbc
frame pointer = 0x28:0xe989dbc0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 637 (ntpd)
[thread pid 637 tid 100059 ]
Stopped at turnstile_setowner+0xd: movl0x74(%ecx),%eax
db bt
Tracing pid 637 tid 100059 td 0xc4de2780
turnstile_setowner(c4de9240,0,c4dc9240,c07201e0,c5102090,...) at
turnstile_setowner+0xd
turnstile_wait(c5101090,0,c5101000,c07234e0,e989dc24,...) at
turnstile_wait+0xca
_mtx_lock_sleep(c5102090,c4de2780,0,0,0,...) at _mtx_lock_sleep+0xb4
in_pcballoc(c4e892c8,c07234e0,1,c06c8de5,38,...) at
in_pcballoc+0xbe tcp_attach(c4e892c8,c4e8933c,c06c8de5,0,c4e892c8,...)
at tcp_attach+0x58 tcp_usr_attach(c4e892c8,0,c4de2780,0,0,...) at
tcp_usr_attach+0x63 socreate(2,e989dcb8,1,0,c4ab1c90,...) at
socreate+0x167
socket(c4de2780,e989dd04,c,c4de2780,80d3000,...) at socket+0xb3
syscall(3b,3b,3b,0,7,...) at syscall+0x380
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (97, FreeBSD ELF32, socket), eip = 0x282939d3, esp =
0xbfbfeb1c, ebp = 0xbfbfebf8 ---
db
Something like the attached should fix it. Seems tcp was forgotten in a
recent change to INP locking.
--
/\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: tcp_subr.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/netinet/tcp_subr.c,v
retrieving revision 1.228.2.12
diff -u -r1.228.2.12 tcp_subr.c
--- tcp_subr.c 1 Oct 2006 05:33:50 - 1.228.2.12
+++ tcp_subr.c 30 Dec 2006 15:06:45 -
@@ -300,6 +300,15 @@
uma_zone_set_max(tcptw_zone, tcptw_auto_size());
}
+static int
+tcp_inpcb_init(void *mem, int size, int flags)
+{
+ struct inpcb *inp = mem;
+
+ INP_LOCK_INIT(inp, inp, tcpinp);
+ return (0);
+}
+
void
tcp_init()
{
@@ -328,7 +337,7 @@
tcbinfo.porthashbase = hashinit(hashsize, M_PCB,
tcbinfo.porthashmask);
tcbinfo.ipi_zone = uma_zcreate(inpcb, sizeof(struct inpcb),
- NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_NOFREE);
+ NULL, NULL, tcp_inpcb_init, NULL, UMA_ALIGN_PTR, UMA_ZONE_NOFREE);
uma_zone_set_max(tcbinfo.ipi_zone, maxsockets);
#ifdef INET6
#define TCP_MINPROTOHDR (sizeof(struct ip6_hdr) + sizeof(struct tcphdr))
pgpTdZroeH8uw.pgp
Description: PGP signature
Re: 6.2-PRE: Fatal Trap?
On Sat, 30 Dec 2006, Larry Rosenman wrote:
I had to on an emergency basis replace my aging P-1 Firewall. The guys at
my hosting company gave me an AthlonXP 2200+, and with 6.1 (all the way up
to today's RELENG_6_1), it works fine.
I tried(!) to put 6.2-PRE (RELENG_6) on it, but no matter what I do, it
panics when either NTPD or SSHD starts (depending on whats first).
Unfortunately, I don't have the exact panic (it's a page not present, and if
I understood my remote eyes/hands right, a NULL de-reference).
The box is 300+ miles away (Distance from Austin, TX to Dallas, TX).
Anyone got ideas?
It looks like the attached patch was missed in the MFC I just pointed at.
Could you try applying it?
You can also fetch it from:
http://www.watson.org/~robert/freebsd/20061230-20061230-tcp_pcb_fix.diff
Robert N M Watson
Computer Laboratory
University of Cambridge
Index: tcp_subr.c
===
RCS file: /zoo/cvsup/FreeBSD-CVS/src/sys/netinet/tcp_subr.c,v
retrieving revision 1.228.2.12
diff -u -r1.228.2.12 tcp_subr.c
--- tcp_subr.c 1 Oct 2006 05:33:50 - 1.228.2.12
+++ tcp_subr.c 30 Dec 2006 15:18:25 -
@@ -300,6 +300,14 @@
uma_zone_set_max(tcptw_zone, tcptw_auto_size());
}
+static int
+tcp_inpcb_init(void *mem, int size, int flags)
+{
+ struct inpcb *inp = (struct inpcb *) mem;
+ INP_LOCK_INIT(inp, inp, tcpinp);
+ return (0);
+}
+
void
tcp_init()
{
@@ -328,7 +336,7 @@
tcbinfo.porthashbase = hashinit(hashsize, M_PCB,
tcbinfo.porthashmask);
tcbinfo.ipi_zone = uma_zcreate(inpcb, sizeof(struct inpcb),
- NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_NOFREE);
+ NULL, NULL, tcp_inpcb_init, NULL, UMA_ALIGN_PTR, UMA_ZONE_NOFREE);
uma_zone_set_max(tcbinfo.ipi_zone, maxsockets);
#ifdef INET6
#define TCP_MINPROTOHDR (sizeof(struct ip6_hdr) + sizeof(struct tcphdr))
@@ -1005,6 +1013,7 @@
error = 0;
for (i = 0; i n; i++) {
inp = inp_list[i];
+ INP_LOCK(inp);
if (inp-inp_gencnt = gencnt) {
struct xtcpcb xt;
caddr_t inp_ppcb;
@@ -1028,8 +1037,11 @@
xt.xt_socket.xso_protocol = IPPROTO_TCP;
}
xt.xt_inp.inp_gencnt = inp-inp_gencnt;
+ INP_UNLOCK(inp);
error = SYSCTL_OUT(req, xt, sizeof xt);
- }
+ } else
+ INP_UNLOCK(inp);
+
}
if (!error) {
/*
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE: Fatal Trap?
On Sat, 30 Dec 2006 12:57:49 +0100 Karol Kwiatkowski [EMAIL PROTECTED] wrote: Here's a me too message. AMD Athlon / FreeBSD 6.2-PRERELEASE i386 My box uses FreeBSD / amd64, cvsupped today, and I also got stuck with a panic. Looks familiar, except it panics whenenver I go to multiuser, I even tried disabling samba and ntp, still it panics. Ok, that was sendmail. Hmm, seems it panics on any process that tries to use the network... Hmm, I just realized that I don't need the machine multiuser to make a debug kernel. Man, the holdays sure can take a tbite out of a man. Currently compiling a debug kernel... -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE: Fatal Trap?
On Sat, 30 Dec 2006, Larry Rosenman wrote: I had to on an emergency basis replace my aging P-1 Firewall. The guys at my hosting company gave me an AthlonXP 2200+, and with 6.1 (all the way up to today's RELENG_6_1), it works fine. I tried(!) to put 6.2-PRE (RELENG_6) on it, but no matter what I do, it panics when either NTPD or SSHD starts (depending on whats first). Unfortunately, I don't have the exact panic (it's a page not present, and if I understood my remote eyes/hands right, a NULL de-reference). The box is 300+ miles away (Distance from Austin, TX to Dallas, TX). Anyone got ideas? Here's the 6.1 dmesg, and a pciconf -lv to see if anyone knows of wonkity hardware The following commit went into RELENG_6 yesterday; could you check and see if it's present in the version that panics, and if you move to a revision slightly before this (i.e., from the 28th) the panic goes away? It could be there's a problem with these changes and it needs to be backed out until fixed... Date: Fri, 29 Dec 2006 19:25:49 + (UTC) From: John Baldwin [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], cvs-all@FreeBSD.org Subject: cvs commit: src/sys/netinet in_pcb.c in_pcb.h ip_divert.c raw_ip.c tcp_usrreq.c udp_usrreq.c src/sys/netinet6 in6_pcb.c raw_ip6.c udp6_usrreq.c jhb 2006-12-29 19:25:49 UTC FreeBSD src repository Modified files:(Branch: RELENG_6) sys/netinet in_pcb.c in_pcb.h ip_divert.c raw_ip.c tcp_usrreq.c udp_usrreq.c sys/netinet6 in6_pcb.c raw_ip6.c udp6_usrreq.c Log: MFC: Close some races between enumerating inpcb's and tearing them down by making the mutex portion of struct inpcb type-stable and never destroying it. Revision ChangesPath 1.165.2.6 +9 -5 src/sys/netinet/in_pcb.c 1.80.2.5 +2 -1 src/sys/netinet/in_pcb.h 1.113.2.3 +24 -4 src/sys/netinet/ip_divert.c 1.150.2.6 +15 -4 src/sys/netinet/raw_ip.c 1.124.2.5 +2 -2 src/sys/netinet/tcp_usrreq.c 1.175.2.9 +15 -4 src/sys/netinet/udp_usrreq.c 1.62.2.5 +1 -1 src/sys/netinet6/in6_pcb.c 1.50.2.8 +1 -2 src/sys/netinet6/raw_ip6.c 1.54.2.3 +1 -2 src/sys/netinet6/udp6_usrreq.c thanks all! Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-RELEASE-p11 #0: Sat Dec 30 03:11:48 CST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC ACPI APIC Table: AMIINT AMIINI09 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 2200+ (1807.31-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x681 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc0400800SYSCALL,MMX+,3DNow+,3DNow real memory = 503250944 (479 MB) avail memory = 483074048 (460 MB) ioapic0 Version 0.3 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: AMIINT AMIINI09 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA XM266 (PM266/KM266) host to PCI bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xec00-0xec7f mem 0xdf80-0xdfff irq 17 at device 9.0 on pci0 miibus0: MII bus on xl0 xlphy0: 3Com internal media interface on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:01:02:2a:67:e4 xl1: 3Com 3c905B-TX Fast Etherlink XL port 0xe800-0xe87f mem 0xdf00-0xdf7f irq 18 at device 10.0 on pci0 miibus1: MII bus on xl1 xlphy1: 3Com internal media interface on miibus1 xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl1: Ethernet address: 00:10:5a:11:7c:ec uhci0: VIA 83C572 USB controller port 0xe400-0xe41f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xe000-0xe01f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: VIA 83C572 USB controller port 0xdc00-0xdc1f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] usb2: VIA 83C572 USB controller on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2
Re: 6.2-PRE: Fatal Trap?
On Sat, 30 Dec 2006, Robert Watson wrote: On Sat, 30 Dec 2006, Larry Rosenman wrote: I had to on an emergency basis replace my aging P-1 Firewall. The guys at my hosting company gave me an AthlonXP 2200+, and with 6.1 (all the way up to today's RELENG_6_1), it works fine. I tried(!) to put 6.2-PRE (RELENG_6) on it, but no matter what I do, it panics when either NTPD or SSHD starts (depending on whats first). Unfortunately, I don't have the exact panic (it's a page not present, and if I understood my remote eyes/hands right, a NULL de-reference). The box is 300+ miles away (Distance from Austin, TX to Dallas, TX). Anyone got ideas? It looks like the attached patch was missed in the MFC I just pointed at. Could you try applying it? You can also fetch it from: http://www.watson.org/~robert/freebsd/20061230-20061230-tcp_pcb_fix.diff Robert N M Watson Computer Laboratory University of Cambridge Normally, I'd be more than happy to, but, given: 1) the box is 300+ miles away 2) I do NOT have access to remote hands again till Tuesday (Holiday) 3) this is my firewall between all my services and the rest of the world and if down, I'm off the air :( I wish I could, but can't afford to be down for the 5 days :( Thanks for the diagnosis, however, as I was going nuts. Thanks, Larry Rosenman -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE: Fatal Trap?
On Sat, 30 Dec 2006, Larry Rosenman wrote: I had to on an emergency basis replace my aging P-1 Firewall. The guys at my hosting company gave me an AthlonXP 2200+, and with 6.1 (all the way up to today's RELENG_6_1), it works fine. I tried(!) to put 6.2-PRE (RELENG_6) on it, but no matter what I do, it panics when either NTPD or SSHD starts (depending on whats first). Unfortunately, I don't have the exact panic (it's a page not present, and if I understood my remote eyes/hands right, a NULL de-reference). The box is 300+ miles away (Distance from Austin, TX to Dallas, TX). Anyone got ideas? It looks like the attached patch was missed in the MFC I just pointed at. Could you try applying it? You can also fetch it from: http://www.watson.org/~robert/freebsd/20061230-20061230-tcp_pcb_fix.diff Normally, I'd be more than happy to, but, given: 1) the box is 300+ miles away 2) I do NOT have access to remote hands again till Tuesday (Holiday) 3) this is my firewall between all my services and the rest of the world and if down, I'm off the air :( I wish I could, but can't afford to be down for the 5 days :( Thanks for the diagnosis, however, as I was going nuts. I've gone ahead and MFC'd the missing tcp_subr.c patch and the change now appears stable on by 6-STABLE test box. I'd appreciate it if other people experiencing the panic could slide forward to confirm (or perhaps less ideally, not confirm) that this fixes the problem for them also. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE: Fatal Trap?
On Sat, 30 Dec 2006 15:08:30 + (GMT), Robert Watson snip... The following commit went into RELENG_6 yesterday; could you check and see if it's present in the version that panics, and if you move to a revision slightly before this (i.e., from the 28th) the panic goes away? It could be there's a problem with these changes and it needs to be backed out until fixed... Date: Fri, 29 Dec 2006 19:25:49 + (UTC) From: John Baldwin [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], cvs-all@FreeBSD.org Subject: cvs commit: src/sys/netinet in_pcb.c in_pcb.h ip_divert.c raw_ip.c tcp_usrreq.c udp_usrreq.c src/sys/netinet6 in6_pcb.c raw_ip6.c udp6_usrreq.c jhb 2006-12-29 19:25:49 UTC FreeBSD src repository Modified files:(Branch: RELENG_6) sys/netinet in_pcb.c in_pcb.h ip_divert.c raw_ip.c tcp_usrreq.c udp_usrreq.c sys/netinet6 in6_pcb.c raw_ip6.c udp6_usrreq.c Log: MFC: Close some races between enumerating inpcb's and tearing them down by making the mutex portion of struct inpcb type-stable and never destroying it. Revision ChangesPath 1.165.2.6 +9 -5 src/sys/netinet/in_pcb.c 1.80.2.5 +2 -1 src/sys/netinet/in_pcb.h 1.113.2.3 +24 -4 src/sys/netinet/ip_divert.c 1.150.2.6 +15 -4 src/sys/netinet/raw_ip.c 1.124.2.5 +2 -2 src/sys/netinet/tcp_usrreq.c 1.175.2.9 +15 -4 src/sys/netinet/udp_usrreq.c 1.62.2.5 +1 -1 src/sys/netinet6/in6_pcb.c 1.50.2.8 +1 -2 src/sys/netinet6/raw_ip6.c 1.54.2.3 +1 -2 src/sys/netinet6/udp6_usrreq.c /snip... Me too, on the panic. All of those revisions are in the sources I csup'd on the 30th. Patrick -- Patrick Bowen [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE: Fatal Trap?
Robert Watson wrote: On Sat, 30 Dec 2006, Larry Rosenman wrote: I had to on an emergency basis replace my aging P-1 Firewall. The guys at my hosting company gave me an AthlonXP 2200+, and with 6.1 (all the way up to today's RELENG_6_1), it works fine. I tried(!) to put 6.2-PRE (RELENG_6) on it, but no matter what I do, it panics when either NTPD or SSHD starts (depending on whats first). Unfortunately, I don't have the exact panic (it's a page not present, and if I understood my remote eyes/hands right, a NULL de-reference). The box is 300+ miles away (Distance from Austin, TX to Dallas, TX). Anyone got ideas? It looks like the attached patch was missed in the MFC I just pointed at. Could you try applying it? You can also fetch it from: http://www.watson.org/~robert/freebsd/20061230-20061230-tcp_pcb_fix.diff Normally, I'd be more than happy to, but, given: 1) the box is 300+ miles away 2) I do NOT have access to remote hands again till Tuesday (Holiday) 3) this is my firewall between all my services and the rest of the world and if down, I'm off the air :( I wish I could, but can't afford to be down for the 5 days :( Thanks for the diagnosis, however, as I was going nuts. I've gone ahead and MFC'd the missing tcp_subr.c patch and the change now appears stable on by 6-STABLE test box. I'd appreciate it if other people experiencing the panic could slide forward to confirm (or perhaps less ideally, not confirm) that this fixes the problem for them also. The link is slightly broken, I've found the patch here: http://www.watson.org/~robert/freebsd/20061230-tcp_pcb_fix.diff Applied, recompiled the kernel - no more panic :) Thanks Robert nad Max. If there's anything else needed let me know. Karol P.S. out of curiosity - now that I have configured kernel with DDB and KDB options, is there any performance penalty of running such kernel? -- Karol Kwiatkowski freebsd at orchid dot homeunix dot org OpenPGP: http://www.orchid.homeunix.org/carlos/gpg/0x06E09309.asc signature.asc Description: OpenPGP digital signature
Re: 6.2-PRE: Fatal Trap?
patch applied and panic gone! nice quick work!! Happy New Year danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE: Fatal Trap?
On Sat, 30 Dec 2006 15:24:25 + (GMT) Robert Watson [EMAIL PROTECTED] wrote: It looks like the attached patch was missed in the MFC I just pointed at. Could you try applying it? Ok, with that patch applied an a new kernel built, I'm upp and running again. That was quick - thanks to all involved! -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE: Fatal Trap?
On Sat, 30 Dec 2006, Karol Kwiatkowski wrote: It looks like the attached patch was missed in the MFC I just pointed at. Could you try applying it? You can also fetch it from: http://www.watson.org/~robert/freebsd/20061230-20061230-tcp_pcb_fix.diff Normally, I'd be more than happy to, but, given: 1) the box is 300+ miles away 2) I do NOT have access to remote hands again till Tuesday (Holiday) 3) this is my firewall between all my services and the rest of the world and if down, I'm off the air :( I wish I could, but can't afford to be down for the 5 days :( Thanks for the diagnosis, however, as I was going nuts. I've gone ahead and MFC'd the missing tcp_subr.c patch and the change now appears stable on by 6-STABLE test box. I'd appreciate it if other people experiencing the panic could slide forward to confirm (or perhaps less ideally, not confirm) that this fixes the problem for them also. The link is slightly broken, I've found the patch here: http://www.watson.org/~robert/freebsd/20061230-tcp_pcb_fix.diff Thanks, sorry about that! Applied, recompiled the kernel - no more panic :) Thanks Robert nad Max. If there's anything else needed let me know. I've committed the fix, so with any luck life will be better. P.S. out of curiosity - now that I have configured kernel with DDB and KDB options, is there any performance penalty of running such kernel? No, it shouldn't really have any effect on performance. The one thing to watch out for is that your system will no longer reboot automatically on a panic, as it will drop to the debugger, by default. You can change this by setting debug.debugger_on_panic to 0, in which case you will likely want to set debug.trace_on_panic to 1 so it prints a stack trace before rebooting (which is often sufficient, combined with the trap frame and panic message to debug the problem). Right now these are sysctls, not tunables, but you can change the default using options KDB_UNATTENDED (which flips the default to not entering the debugger and rebooting) and options KDB_TRACE (which causes a trace to be printed on panic by default). Probably they should also be tunables so that loader.conf entries will work. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE: Fatal Trap?
On Sat, Dec 30, 2006 at 04:04:50PM +, Robert Watson wrote: ... I've gone ahead and MFC'd the missing tcp_subr.c patch and the change now appears stable on by 6-STABLE test box. I'd appreciate it if other people experiencing the panic could slide forward to confirm (or perhaps less ideally, not confirm) that this fixes the problem for them also. Confirmed no panic after patch applied; running: g1-18(6.2-P)[1] uname -a FreeBSD g1-18.catwhisker.org. 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #270: Sat Dec 30 08:28:21 PST 2006 [EMAIL PROTECTED]:/common/S1/obj/usr/src/sys/LAPTOP_30W i386 1-18(6.2-P)[2] (The panic prior to applying the patch was quite a surprise; first one I've seen inn STABLE for some time.) Peace, david -- David H. Wolfskill [EMAIL PROTECTED] Believe SORBS at your own risk: 63.193.123.122 has been static since Aug 1999. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpGS1dKQzQ4p.pgp Description: PGP signature
Re: 6.2-PRE: Fatal Trap?
On Saturday 30 December 2006 10:24, Robert Watson wrote: On Sat, 30 Dec 2006, Larry Rosenman wrote: I had to on an emergency basis replace my aging P-1 Firewall. The guys at my hosting company gave me an AthlonXP 2200+, and with 6.1 (all the way up to today's RELENG_6_1), it works fine. I tried(!) to put 6.2-PRE (RELENG_6) on it, but no matter what I do, it panics when either NTPD or SSHD starts (depending on whats first). Unfortunately, I don't have the exact panic (it's a page not present, and if I understood my remote eyes/hands right, a NULL de-reference). The box is 300+ miles away (Distance from Austin, TX to Dallas, TX). Anyone got ideas? It looks like the attached patch was missed in the MFC I just pointed at. Could you try applying it? You can also fetch it from: http://www.watson.org/~robert/freebsd/20061230-20061230-tcp_pcb_fix.diff Sorry, it was lost in the noise as we have lots of other local changes to tcp_subr.c at work so I missed this hunk. :( -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
debugging kernel options (was: Re: 6.2-PRE: Fatal Trap?)
Robert Watson wrote: P.S. out of curiosity - now that I have configured kernel with DDB and KDB options, is there any performance penalty of running such kernel? No, it shouldn't really have any effect on performance. The one thing to watch out for is that your system will no longer reboot automatically on a panic, as it will drop to the debugger, by default. You can change this by setting debug.debugger_on_panic to 0, in which case you will likely want to set debug.trace_on_panic to 1 so it prints a stack trace before rebooting (which is often sufficient, combined with the trap frame and panic message to debug the problem). Right now these are sysctls, not tunables, but you can change the default using options KDB_UNATTENDED (which flips the default to not entering the debugger and rebooting) and options KDB_TRACE (which causes a trace to be printed on panic by default). Probably they should also be tunables so that loader.conf entries will work. Great explanation, thank you. I turned on debugging on my desktop computer which, apart from normal every day use, is 'testing' STABLE by running it :) I'm perfectly fine with the defaults, at least for now. Cheers and thanks again, Karol -- Karol Kwiatkowski freebsd at orchid dot homeunix dot org OpenPGP: http://www.orchid.homeunix.org/carlos/gpg/0x06E09309.asc signature.asc Description: OpenPGP digital signature
Re: debugging kernel options (was: Re: 6.2-PRE: Fatal Trap?)
On Sat, 30 Dec 2006, Karol Kwiatkowski wrote: Robert Watson wrote: P.S. out of curiosity - now that I have configured kernel with DDB and KDB options, is there any performance penalty of running such kernel? No, it shouldn't really have any effect on performance. The one thing to watch out for is that your system will no longer reboot automatically on a panic, as it will drop to the debugger, by default. You can change this by setting debug.debugger_on_panic to 0, in which case you will likely want to set debug.trace_on_panic to 1 so it prints a stack trace before rebooting (which is often sufficient, combined with the trap frame and panic message to debug the problem). Right now these are sysctls, not tunables, but you can change the default using options KDB_UNATTENDED (which flips the default to not entering the debugger and rebooting) and options KDB_TRACE (which causes a trace to be printed on panic by default). Probably they should also be tunables so that loader.conf entries will work. Great explanation, thank you. I turned on debugging on my desktop computer which, apart from normal every day use, is 'testing' STABLE by running it :) I'm perfectly fine with the defaults, at least for now. BTW, if you're running X on your desktop, be aware that it's X that does all the video mode management. If your box enters the debugger while in X, the debugger doesn't know how to switch back to text mode (and X isn't running, obviously), so while you'll be talking to the debugger, the chances you'll see anything comprehensible are actually quite low. For this reason, I normally also use a serial console when debugging desktop boxes: I can always plug my notebook in with a serial cable to see why it's entered the debugger. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE: Fatal Trap?
On Sat, 30 Dec 2006, Robert Watson wrote: On Sat, 30 Dec 2006, Karol Kwiatkowski wrote: It looks like the attached patch was missed in the MFC I just pointed at. Could you try applying it? You can also fetch it from: http://www.watson.org/~robert/freebsd/20061230-20061230-tcp_pcb_fix.diff Normally, I'd be more than happy to, but, given: 1) the box is 300+ miles away 2) I do NOT have access to remote hands again till Tuesday (Holiday) 3) this is my firewall between all my services and the rest of the world and if down, I'm off the air :( I wish I could, but can't afford to be down for the 5 days :( Thanks for the diagnosis, however, as I was going nuts. I've gone ahead and MFC'd the missing tcp_subr.c patch and the change now appears stable on by 6-STABLE test box. I'd appreciate it if other people experiencing the panic could slide forward to confirm (or perhaps less ideally, not confirm) that this fixes the problem for them also. [snip] I can confirm (now that I saw other confirmations), that the fix is the correct one (I'm up on: FreeBSD fw.lerctr.org 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Sat Dec 30 17:14:04 CST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Thanks Robert and all for the very quick work with a really sparse bug report. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
