About "panic: bufwrite: buffer is not busy???"

Sun Feb 20 16:55:02 UTC 2011

Sun, 20 Feb 2011 10:30:52 -0500 письмо от Mike Tancsa <mike at sentex.net>:

> 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 ?

I not shure crash because nic driver, I say only because my box after unplug 2 em nic's
have uptime from moment of unplug to right now  moment.  About all last week I tried 
understand source of panic. My box :
Phenom x4
12GB
2 re nic
2 em nic 
through re0 em1 em2 work mpd5
re0 pptp client
em0 pppoe client
em1 l2tp client

> 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/