Date: Sun, 20 Feb 2011 10:30:52 -0500 From: Mike Tancsa <mike@sentex.net> To: Andrey Smagin <samspeed@mail.ru> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Eugene Grosbein <egrosbein@rdtc.ru>, Andrew Boyer <aboyer@averesystems.com> Subject: Re: About "panic: bufwrite: buffer is not busy???" Message-ID: <4D6133AC.6070507@sentex.net> In-Reply-To: <E1PrAM9-0001fN-00.samspeed-mail-ru@f30.mail.ru> References: <4D4A38FD.7000607@rdtc.ru> <4D3011DB.9050900@frasunek.com> <4FD1B1C3-08A7-4F48-A30A-DE5A8F3D3834@averesystems.com> <E1PrAM9-0001fN-00.samspeed-mail-ru@f30.mail.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D6133AC.6070507>