On 2/20/2011 9:33 AM, Andrey Smagin wrote: > On week -current I have same problem, my box paniced every 2-15 min. I resolve problem by next steps - unplug network connectors from 2 intel em (82574L) cards. I think last time that mpd5 related panic, but mpd5 work with another re interface interated on MB. I think it may be em related panic, or em+mpd5. The latest panic I saw didnt have anything to do with em. Are you sure your crashes are because of the nic drive ? The latest I saw was on Friday. # kgdb /usr/obj/usr/src/sys/router/kernel.debug vmcore.11 (kgdb) bt #0 doadump () at pcpu.h:231 #1 0xc04a51f9 in db_fncall (dummy1=1, dummy2=0, dummy3=-1063333856, dummy4=0xc6b9696c "") at /usr/src/sys/ddb/db_command.c:548 #2 0xc04a55f1 in db_command (last_cmdp=0xc096f73c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04a574a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc04a764d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc068ba7e in kdb_trap (type=12, code=0, tf=0xc6b96b94) at /usr/src/sys/kern/subr_kdb.c:546 #6 0xc088056f in trap_fatal (frame=0xc6b96b94, eva=52) at /usr/src/sys/i386/i386/trap.c:937 #7 0xc0880830 in trap_pfault (frame=0xc6b96b94, usermode=0, eva=52) at /usr/src/sys/i386/i386/trap.c:859 #8 0xc0880d4a in trap (frame=0xc6b96b94) at /usr/src/sys/i386/i386/trap.c:532 #9 0xc086716c in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #10 0xc0657a16 in uihold (uip=0x0) at /usr/src/sys/kern/kern_resource.c:1248 #11 0xc0654ec9 in crcopy (dest=0xce3ee800, src=0xce3ee600) at /usr/src/sys/kern/kern_prot.c:1873 #12 0xc0654fd1 in crcopysafe (p=0xc90cc810, cr=0xce3ee800) at /usr/src/sys/kern/kern_prot.c:1950 #13 0xc0656d7f in seteuid (td=0xc9196b80, uap=0xc6b96cec) at /usr/src/sys/kern/kern_prot.c:615 #14 0xc06985ff in syscallenter (td=0xc9196b80, sa=0xc6b96ce4) at /usr/src/sys/kern/subr_trap.c:315 #15 0xc0880884 in syscall (frame=0xc6b96d28) at /usr/src/sys/i386/i386/trap.c:1061 #16 0xc08671d1 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:264 #17 0x00000033 in ?? () (kgdb) frame 10 #10 0xc0657a16 in uihold (uip=0x0) at /usr/src/sys/kern/kern_resource.c:1248 1248 { (kgdb) list 1243 * Place another refcount on a uidinfo struct. 1244 */ 1245 void 1246 uihold(uip) 1247 struct uidinfo *uip; 1248 { 1249 1250 refcount_acquire(&uip->ui_ref); 1251 } 1252 (kgdb) p *uip Cannot access memory at address 0x0 (kgdb) p uip $1 = (struct uidinfo *) 0x0 (kgdb) > > > Wed, 16 Feb 2011 12:08:30 -0500 письмо от Andrew Boyer <aboyer_at_averesystems.com>: > >> Moving this to -current and -stable and following up... >> >> Something is broken with coredumps on stable/8 amd64. I tried a vanilla >> 8.2-RC3 and yesterday's csup of stable/8; neither can dump a core with 'sysctl >> debug.kdb.panic=1'. >> >> For the 8.2-RC3 / amd64 / GENERIC install, I used the memstick image, >> installed on ad7 (a 250GB SATA drive), used the default partition map, and set >> dumpdev to AUTO. >> >> I added enough tracing to show that the second panic is due to the syncer >> process flushing buffers to the other filesystems in parallel with the dump. >> I've seen this panic and a similar one 'buffer not locked' coming from >> ffs_write(). One time out of about 30 the core ran to completion, but slowly >> (~1MB/sec). Other times the dump just locks up completely with no other >> output. >> >> Does anyone know what might have changed to expose this problem? >> >> I don't ever see it under 7.1. >> >> Thanks, >> Andrew >> >> On Feb 3, 2011, at 12:11 AM, Eugene Grosbein wrote: >> >>> On 02.02.2011 00:50, Gleb Smirnoff wrote: >>> >>>> E> Uptime: 8h3m51s >>>> E> Dumping 4087 MB (3 chunks) >>>> E> chunk 0: 1MB (150 pages) ... ok >>>> E> chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not >> busy??? >>>> E> cpuid = 3 >>>> E> Uptime: 8h3m52s >>>> E> Automatic reboot in 15 seconds - press a key on the console to abort >>>> Can you add KDB_TRACE option to kernel? Your boxes for some reason can't >>>> dump core, but with this option we will have at least trace. >>> >>> I see Mike Tancsa's box has "bufwrite: buffer is not busy???" problem too. >>> Has anyone a thought how to fix generation of crashdumps? >>> >>> Eugene Grosbein >>> >>> >>> _______________________________________________ >>> freebsd-net_at_freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe_at_freebsd.org" >> >> -------------------------------------------------- >> Andrew Boyer aboyer_at_averesystems.com >> >> >> >> >> _______________________________________________ >> freebsd-current_at_freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike_at_sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/Received on Sun Feb 20 2011 - 14:31:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:11 UTC