Re: panic: getblk: size(131072) > MAXBCACHEBUF(65536)

On Thu, Oct 01, 2015 at 03:23:56PM +0200, Fabian Keil wrote:
> Shortly after upgrading to a kernel based on r288437 I got the following
> panic:
> 
> Unread portion of the kernel message buffer:
> [5112] panic: getblk: size(131072) > MAXBCACHEBUF(65536)
> [...]
> (kgdb) where
> #0  doadump (textdump=0) at pcpu.h:221
> #1  0xffffffff8030ca9e in db_dump (dummy=<value optimized out>, dummy2=false, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533
> #2  0xffffffff8030c651 in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440
> #3  0xffffffff8030c2e4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493
> #4  0xffffffff8030ef0b in db_trap (type=<value optimized out>, code=0) at /usr/src/sys/ddb/db_main.c:251
> #5  0xffffffff805d3cd4 in kdb_trap (type=3, code=0, tf=<value optimized out>) at /usr/src/sys/kern/subr_kdb.c:654
> #6  0xffffffff808651bf in trap (frame=0xfffffe009452b5f0) at /usr/src/sys/amd64/amd64/trap.c:549
> #7  0xffffffff80849e4a in calltrap () at /usr/src/sys/amd64/amd64/exception.S:234
> #8  0xffffffff805d33ae in kdb_enter (why=0xffffffff80953dc1 "panic", msg=0xffffffff805d9e90 "U[...]") at cpufunc.h:63
> #9  0xffffffff805902b9 in vpanic (fmt=<value optimized out>, ap=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:746
> #10 0xffffffff80590103 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:684
> #11 0xffffffff806310e7 in getblk (vp=<value optimized out>, blkno=<value optimized out>, size=<value optimized out>, slpflag=<value optimized out>, slptimeo=<value optimized out>, flags=<value optimized out>)
>     at /usr/src/sys/kern/vfs_bio.c:3324
> #12 0xffffffff8063cf81 in vop_stdadvise (ap=<value optimized out>) at /usr/src/sys/kern/vfs_default.c:1099
> #13 0xffffffff808ec827 in VOP_ADVISE_APV (vop=<value optimized out>, a=<value optimized out>) at vnode_if.c:3848
> #14 0xffffffff80662844 in vn_read (fp=<value optimized out>, uio=<value optimized out>, active_cred=<value optimized out>, flags=<value optimized out>, td=0x8) at vnode_if.h:1648
> #15 0xffffffff8065e27a in vn_io_fault (fp=0xfffff8000631eaf0, uio=0xfffffe009452baa0, active_cred=0xfffffe009452b5a0, flags=0, td=0x8) at /usr/src/sys/kern/vfs_vnops.c:1169
> #16 0xffffffff805f0385 in dofileread (td=0xfffff800279fd9a0, fd=3, fp=0xfffff8000631eaf0, auio=0xfffffe009452baa0, offset=<value optimized out>, flags=50) at file.h:300
> #17 0xffffffff805f00a8 in kern_readv (td=0xfffff800279fd9a0, fd=3, auio=0xfffffe009452baa0) at /usr/src/sys/kern/sys_generic.c:273
> #18 0xffffffff805f0033 in sys_read (td=0x0, uap=<value optimized out>) at /usr/src/sys/kern/sys_generic.c:186
> #19 0xffffffff808661e8 in amd64_syscall (td=0xfffff800279fd9a0, traced=0) at subr_syscall.c:139
> #20 0xffffffff8084a12b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:394
> #21 0x00000008014d752a in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> Current language:  auto; currently minimal
> 
> The system was running for about 50 minutes before the panic occurred and
> didn't do anything special at the time (running Xorg, Firefox, ssh ...).
> 
> I suspect r288431 and am currently compiling a kernel with the
> commit reverted. The previous kernel was based on r288265.
> 
> Fabian

Thanks for the report. This should be fixed as of r288451. (Sorry for
misspelling your first name in the commit message!)

-Mark