Re: [Panic] 6b3 + mdconfig -t malloc + unionfs + screeen

On 9/5/05, Kris Kennaway <kris_at_obsecurity.org> wrote:
> Double-check that you rebuilt it after updating your kernel.
Sure. In case of unionfs, i double-rebuilded ALL the tools involved.
> > panic: can't fifo/vnode bypass -1
> Read the unionfs manpage.
This is very sad. Even oldish Plan 9 always had union mounts.
Where is the problem? VFS? Locking? Lack of interest?

So, to unionfs panics... All works OK with three months old RELENG_5.
Everything's OK with 5.4 too. I will try latest RELENG_5 as well.

Here is _one of_ kgdb backtraces:

# cd /usr/include; kgdb -qvn 0 /boot/kernel.debug/kernel.debug
kgdb: core file: /var/crash/vmcore.0
kgdb: kernel image: /boot/kernel.debug/kernel.debug
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]

Unread portion of the kernel message buffer:
<118>Sep  7 13:11:11 <5.3> Droid syslogd: exiting on signal 15
GEOM: Reconfigure md1a, start 8192 length 16769024 end 16777215
GEOM: Reconfigure md1c, start 0 length 16777216 end 16777215
GEOM: Reconfigure md1a, start 8192 length 16769024 end 16777215
GEOM: Reconfigure md1c, start 0 length 16777216 end 16777215
union_mount: multi union mount?
panic: can't fifo/vnode bypass -1
cpuid = 0
KDB: enter: panic
panic: from debugger
cpuid = 0
Uptime: 7m12s
Dumping 383 MB (2 chunks)
  chunk 0: 1MB (159 pages) ... ok
  chunk 1: 383MB (98032 pages) 367 351 335 319 303 287 271 255 239 223
207 191 175 159 143 127 111 95 79 63 47 31 15

#0  doadump () at pcpu.h:165
165             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) backtrace
#0  doadump () at pcpu.h:165
#1  0xc06a479a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397
#2  0xc06a4b74 in panic (fmt=0xc08fd2c9 "from debugger") at
/usr/src/sys/kern/kern_shutdown.c:553
#3  0xc0475a22 in db_panic (addr=-1066652144, have_addr=0, count=-1,
modif=0xd6093780 "") at /usr/src/sys/ddb/db_command.c:435
#4  0xc0475992 in db_command (last_cmdp=0xc09e0bc4, cmd_table=0x0,
aux_cmd_tablep=0xc095dc1c, aux_cmd_tablep_end=0xc095dc38)
    at /usr/src/sys/ddb/db_command.c:349
#5  0xc0475aa5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455
#6  0xc0477c15 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221
#7  0xc06c313e in kdb_trap (type=0, code=0, tf=0xd60938e0) at
/usr/src/sys/kern/subr_kdb.c:473
#8  0xc08c5ec8 in trap (frame=
      {tf_fs = 8, tf_es = 40, tf_ds = -704053208, tf_edi = 256, tf_esi
= 1, tf_ebp = -704038616, tf_isp = -704038644, tf_ebx = -704038556,
tf_edx = 1, tf_ecx = -1056755712, tf_eax = 18, tf_trapno = 3, tf_err =
0, tf_eip = -1066652144, tf_cs = 32, tf_eflags = 646, tf_esp =
-1064089629, tf_ss = -1064098631}) at
/usr/src/sys/i386/i386/trap.c:601
#9  0xc08afe9a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#10 0x00000008 in ?? ()
#11 0x00000028 in ?? ()
#12 0xd6090028 in ?? ()
#13 0x00000100 in ?? ()
#14 0x00000001 in ?? ()
#15 0xd6093928 in ?? ()
#16 0xd609390c in ?? ()
#17 0xd6093964 in ?? ()
#18 0x00000001 in ?? ()
#19 0xc1033000 in ?? ()
#20 0x00000012 in ?? ()
#21 0x00000003 in ?? ()
#22 0x00000000 in ?? ()
#23 0xc06c2e10 in kdb_enter (msg=0x0) at cpufunc.h:60
#24 0xc06a4b0e in panic (fmt=0xc092b62f "can't fifo/vnode bypass %d")
at /usr/src/sys/kern/kern_shutdown.c:537
#25 0xc064c870 in fifo_open (ap=0xd60939e4) at
/usr/src/sys/fs/fifofs/fifo_vnops.c:284
#26 0xc08d900c in VOP_OPEN_APV (vop=0x0, a=0xd60939e4) at vnode_if.c:372
#27 0xc1e9ce1e in ?? ()
#28 0xc09d10c0 in ffs_vnodeops1 ()
#29 0xd60939e4 in ?? ()
#30 0xc1e0d780 in ?? ()
#31 0xd6093a54 in ?? ()
#32 0x00000001 in ?? ()
#33 0xc1e0d780 in ?? ()
#34 0xc1a5db80 in ?? ()
#35 0x00000005 in ?? ()
#36 0xc09df200 in vop_open_vp_offsets ()
#37 0xc1e3faa0 in ?? ()
#38 0x00000005 in ?? ()
#39 0xc1a5db80 in ?? ()
#40 0xc1e0d780 in ?? ()
#41 0xffffffff in ?? ()
#42 0xd60939e4 in ?? ()
#43 0x00000001 in ?? ()
#44 0xd6093a54 in ?? ()
#45 0xd6093bc4 in ?? ()
#46 0x00000005 in ?? ()
#47 0xd6093a28 in ?? ()
---Type <return> to continue, or q <return> to quit---
#48 0xc08d900c in VOP_OPEN_APV (vop=0x0, a=0xc1e3faa0) at vnode_if.c:372
Previous frame identical to this frame (corrupt stack?)
(kgdb)

What about this "??"s and corrupt stack message?
Note this is ONE OF backtraces. To dump it, i must run
my little script twice - hence double geom messages.

Other vmcores (those where script ran just one time) did nasty things
with kgdb. Nasty is when i run it, it infinitely prints things like
<118>....kernel message buffer contents here....
until i kill it. That was almost two days old RELENG_6 kgdb.
-- 
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
, net- and *BSD admin     '---''(_/--'  `-'\_)   ...translit rawx