Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 03 Feb 2011 17:55:53 +0600
From:      Eugene Grosbein <egrosbein@rdtc.ru>
To:        Mike Tancsa <mike@sentex.net>
Cc:        freebsd-net@freebsd.org, John Baldwin <jhb@freebsd.org>
Subject:   Re: About "panic: bufwrite: buffer is not busy???"
Message-ID:  <4D4A97C9.9020007@rdtc.ru>
In-Reply-To: <4D4A8FF6.2090602@sentex.net>
References:  <4D3011DB.9050900@frasunek.com>	<4D30458D.30007@sentex.net>	<4D309983.70709@rdtc.ru>	<201101141437.55421.jhb@freebsd.org>	<4D46575A.802@rdtc.ru>	<4D4670C2.4050500@freebsd.org>	<4D48513C.40503@rdtc.ru>	<20110201185026.GB62007@glebius.int.ru> <4D4A38FD.7000607@rdtc.ru> <4D4A8FF6.2090602@sentex.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 03.02.2011 17:22, Mike Tancsa 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?
> 
> But it generates the dump despite the error message
> 
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 00
> fault virtual address   = 0x33b9fc
> fault code              = supervisor read, page not present
> instruction pointer     = 0x20:0xc072df2f
> stack pointer           = 0x28:0xe94c2a44
> frame pointer           = 0x28:0xe94c2a64
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 1089 (mpd5)
> trap number             = 12
> panic: page fault
> cpuid = 1
> KDB: stack backtrace:
> #0 0xc0681b07 at kdb_backtrace+0x47
> #1 0xc0652d27 at panic+0x117
> #2 0xc08cd873 at trap_fatal+0x323
> #3 0xc08cdaf0 at trap_pfault+0x270
> #4 0xc08ce035 at trap+0x465
> #5 0xc08b4e6c at calltrap+0x6
> #6 0xc07358df at in_leavegroup_locked+0x4f
> #7 0xc07320d1 at in_control+0x13d1
> #8 0xc06fb04a at ifioctl+0x1b4a
> #9 0xc0698422 at soo_ioctl+0x612
> #10 0xc0690c90 at kern_ioctl+0x250
> #11 0xc0690e04 at ioctl+0x134
> #12 0xc068d82f at syscallenter+0x30f
> #13 0xc08cdb44 at syscall+0x34
> #14 0xc08b4ed1 at Xint0x80_syscall+0x21
> Uptime: 1d4h20m49s
> Physical memory: 3574 MB
> Dumping 289 MB:panic: bufwrite: buffer is not busy???
> cpuid = 1
>  274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2
> Dump complete

It does not generate dump for me. Perhaps, due to greater amount of RAM
and/or amd64 differences.

Eugene Grosbein



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D4A97C9.9020007>