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?
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?
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?
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?
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]"
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]"
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 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 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]"
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 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, 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?
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?
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 OpenPGP: http://www.orchid.homeunix.org/carlos/gpg/0x06E09309.asc signature.asc Description: OpenPGP digital signature
Re: 6.2-PRE: Fatal Trap?
On Sat, 30 Dec 2006 15:08:30 + (GMT), "Robert Watson" ... > > 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 > > ... 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?
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, 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? 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: 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=0x383fbff AMD Features=0xc0400800 real memory = 503250944 (479 MB) avail memory = 483074048 (460 MB) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: 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: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: 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: 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: 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: port 0xe400-0xe41f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: 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: port 0xe000-0xe01f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] usb1: 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: port 0xdc00-0xdc1f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] usb2: 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 removable, self powered ehci0: mem 0xde00-0xdeff irq 21 at device 16.3 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0
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?
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 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?
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 OpenPGP: http://www.orchid.homeunix.org/carlos/gpg/0x06E09309.asc 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?
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?
-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 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]"
6.2-PRE: Fatal Trap?
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 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: 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=0x383fbff AMD Features=0xc0400800 real memory = 503250944 (479 MB) avail memory = 483074048 (460 MB) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: 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: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: 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: 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: 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: port 0xe400-0xe41f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: 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: port 0xe000-0xe01f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] usb1: 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: port 0xdc00-0xdc1f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] usb2: 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 removable, self powered ehci0: mem 0xde00-0xdeff irq 21 at device 16.3 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 17.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 17.5 (no driver attached) rl0: port 0xd400-0xd4ff mem 0xdd00-0xddff irq 18 at device 19.0 on pci0 miibus2: on rl0 rlphy0: on miibus2 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:20:ed:8d:3e:13 acpi_button1: on acpi0 fdc0: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: at iomem 0xc-0xcbfff,0xcc000-0xccfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter "TSC" frequency 1807314700 Hz quality 800 Timecounters tick every 1.000 msec ad0: DMA limited to UDMA33, device found non-ATA66 cable ad0: 76319MB at ata0-master UDMA33 Trying to mount root from ufs:/dev/ad0s1a IP Filter: v4.1.8 initialized. Default = pass all, Logging = enabled $ sudo pciconf -lv Password: [EMAIL PROTECTED]:0:0: class=0x06 card=0x31161106 chip=0x31161106 rev=0x00 hdr=0x00 vendor = 'VIA Technol
