From owner-freebsd-stable@FreeBSD.ORG Sun Feb 20 16:55:02 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E781106566B; Sun, 20 Feb 2011 16:55:02 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from f23.mail.ru (f23.mail.ru [217.69.129.89]) by mx1.freebsd.org (Postfix) with ESMTP id 62A588FC12; Sun, 20 Feb 2011 16:55:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:Reply-To:In-Reply-To:References:Date:Mime-Version:Subject:Cc:To:From; bh=njS6zTgB+d+oIxVZdnLEmASts36n8/3n61TcPIt9HGs=; b=Xpkcb5di7uIwourD/ATC8qAsaNGIi1Ctai7gK3AF4Dlr+00/LnzdG2uy6hBvttvVsutuedW24WoDOixFR2kCykyHOdCd96HV+z3aO0/GdmSNnp2G+7I+zlWnAQXxDyb1; Received: from mail by f23.mail.ru with local id 1PrCYb-0002wI-00; Sun, 20 Feb 2011 19:54:49 +0300 Received: from [91.202.27.126] by e.mail.ru with HTTP; Sun, 20 Feb 2011 19:54:49 +0300 From: Andrey Smagin To: Mike Tancsa Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: 172.17.1.151 via proxy [91.202.27.126] Date: Sun, 20 Feb 2011 19:54:49 +0300 References: <4D4A38FD.7000607@rdtc.ru> <4D6133AC.6070507@sentex.net> In-Reply-To: <4D6133AC.6070507@sentex.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-Id: X-Spam: Not detected X-Mras: Ok Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Eugene Grosbein , Andrew Boyer Subject: Re[2]: About "panic: bufwrite: buffer is not busy???" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Smagin List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 16:55:02 -0000 Sun, 20 Feb 2011 10:30:52 -0500 письмо от Mike Tancsa : > 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 > : > > > >> 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@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >> > >> -------------------------------------------------- > >> Andrew Boyer aboyer@averesystems.com > >> > >> > >> > >> > >> _______________________________________________ > >> 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" > > > > > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/