Date: Fri, 29 Feb 2008 07:43:12 -0800 (PST) From: Barney Cordoba <barney_cordoba@yahoo.com> To: matthew <matthew@matthew.sk> Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 7.0 Beta, RC, RELEASE (amd64) freezes with dummynet enabled Message-ID: <506309.93775.qm@web63903.mail.re1.yahoo.com> In-Reply-To: <47C7FC8A.4050906@matthew.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
--- matthew <matthew@matthew.sk> wrote: > Kris Kennaway wrote: > > > matthew wrote: > >> I have posted before that i have a stability > issue with the 7.0 branch > >> on my servers. Tested on > BETA2,BETA4,RC1,RC2,RELEASE > >> > >> The original thread and my post with details is > at: > >> > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007-12/msg00674.html > > >> > >> > >> I was waiting for the 7.0-RELEASE, updated the > whole servers, and > >> enabled dummynet again, but it always freezes > after some minutes, 100% > >> reproducible. > >> > >> I tested it also on a HP 140 G3 1U server, where > 6.3 has absolutely no > >> problems, but the 7.0 branch keeps freezing. > >> > >> Again, if it helps to solve this bug, i can > rebuild the kernel with > >> debug symbols a take some screenshots :) > >> > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to > >> "freebsd-current-unsubscribe@freebsd.org" > >> > >> > > > > Please follow the steps at > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html > > > > > > > Kris > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" > > > I have some screenshots from debug console after the > freeze, i hade to > replace the keyboard with a working ESC key to > launch the ctrl+alt+esc:) > > You can find it on http://dummynetcrash.matthew.sk/ > > Sorry for the bad quality of some pictures. > > I have also a dump, after running panic in the debug > console: > > (gdb) > root@hanka:/usr/src/sys/amd64/compile/HANKA-debug# > kgdb > kernel.debug /var/crash/vmcore.1 > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol > "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 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 "amd64-marcel-freebsd". > > Unread portion of the kernel message buffer: > KDB: enter: manual escape to debugger > panic: from debugger > cpuid = 0 > Uptime: 19h35m58s > Physical memory: 993 MB > Dumping 392 MB: 377 361 345 329 313 297 281 265 249 > 233 217 201 185 169 > 153 137 121 105 89 73 57 41 25 9 > > #0 doadump () at pcpu.h:194 > 194 __asm __volatile("movq %%gs:0,%0" : > "=r" (td)); > (kgdb) backtrace > #0 doadump () at pcpu.h:194 > #1 0xffffffff80480f05 in boot (howto=260) at > ../../../kern/kern_shutdown.c:409 > #2 0xffffffff804813a7 in panic (fmt=Variable "fmt" > is not available. > ) at ../../../kern/kern_shutdown.c:563 > #3 0xffffffff801bad37 in db_panic (addr=Variable > "addr" is not available. > ) at ../../../ddb/db_command.c:433 > #4 0xffffffff801bb61c in db_command_loop () at > ../../../ddb/db_command.c:401 > #5 0xffffffff801bd07f in db_trap (type=Variable > "type" is not available. > ) at ../../../ddb/db_main.c:222 > #6 0xffffffff804a89c5 in kdb_trap (type=3, code=0, > tf=0xffffffff9ff2a9e0) at > ../../../kern/subr_kdb.c:502 > #7 0xffffffff8073c4c5 in trap > (frame=0xffffffff9ff2a9e0) at > ../../../amd64/amd64/trap.c:499 > #8 0xffffffff80721dfe in calltrap () at > ../../../amd64/amd64/exception.S:169 > #9 0xffffffff804a8b91 in kdb_enter > (msg=0xffffffff80e20fe0 "") at > cpufunc.h:63 > #10 0xffffffff803ae691 in scgetc > (sc=0xffffffff80b3c5a0, flags=Variable > "flags" is not available. > ) at ../../../dev/syscons/syscons.c:3378 > #11 0xffffffff803b17e4 in sckbdevent > (thiskbd=0xffffff0001154a00, > event=Variable "event" is not available. > ) at ../../../dev/syscons/syscons.c:627 > #12 0xffffffff8031be23 in kbdmux_intr > (kbd=0xffffff0001154a00, > arg=Variable "arg" is not available. > ) at ../../../dev/kbdmux/kbdmux.c:549 > #13 0xffffffff8031c3a0 in kbdmux_kbd_intr > (xkbd=Variable "xkbd" is not > available. > ) at ../../../dev/kbdmux/kbdmux.c:200 > #14 0xffffffff804b2844 in taskqueue_run > (queue=0xffffff000117a300) at > ../../../kern/subr_taskqueue.c:255 > #15 0xffffffff80465c9a in ithread_loop > (arg=0xffffff0001104180) at > ../../../kern/kern_intr.c:1036 > #16 0xffffffff8046348a in fork_exit > (callout=0xffffffff80465bc0 > <ithread_loop>, arg=0xffffff0001104180, > frame=0xffffffff9ff2ac80) > at ../../../kern/kern_fork.c:781 > #17 0xffffffff807221ce in fork_trampoline () at > ../../../amd64/amd64/exception.S:415 > #18 0x0000000000000000 in ?? () > #19 0x0000000000000000 in ?? () > #20 0x0000000000000001 in ?? () > #21 0x0000000000000000 in ?? () > #22 0x0000000000000000 in ?? () > #23 0x0000000000000000 in ?? () > #24 0x0000000000000000 in ?? () > #25 0x0000000000000000 in ?? () > #26 0x0000000000000000 in ?? () > #27 0x0000000000000000 in ?? () > #28 0x0000000000000000 in ?? () > #29 0x0000000000000000 in ?? () > #30 0x0000000000000000 in ?? () > #31 0x0000000000000000 in ?? () > #32 0x0000000000000000 in ?? () > #33 0x0000000000000000 in ?? () > #34 0x0000000000000000 in ?? () > #35 0x0000000000000000 in ?? () > #36 0x0000000000000000 in ?? () > #37 0x0000000000000000 in ?? () > #38 0x0000000000000000 in ?? () > #39 0x0000000000000000 in ?? () > #40 0x0000000000000000 in ?? () > #41 0x0000000000000000 in ?? () > #42 0x0000000000d7f000 in ?? () > #43 0xffffff00011c18d0 in ?? () > #44 0xffffffff80a846e0 in facility_initialized () > #45 0xffffff00011c18d0 in ?? () > #46 0xffffff0001084340 in ?? () > #47 0xffffffff9ff2ab70 in ?? () > #48 0xffffffff9ff2ab38 in ?? () > #49 0xffffff00011bc000 in ?? () > #50 0xffffffff8049e826 in sched_switch > (td=0xffffff0001104180, > newtd=0xffffffff80465bc0, flags=Variable "flags" is > not available. > ) at ../../../kern/sched_4bsd.c:905 > Previous frame inner to this frame (corrupt stack?) > > On http://dummynetcrash.matthew.sk you can also find > the kernel.debug > and tha crash files, for more debugging. Have you tried your setup without polling? It really doesn't make any sense to poll when using controllers that have interrupt hold offs that can be precisely programmed like the em controllers. But it will certain give insight to your problem if one works and the other doesn't. I'd also try it on a 32bit compile. Otherwise you have too many variables. Barney ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?506309.93775.qm>