Re: [HEADSUP] Please help test device vnode bypass!

From: Sebastian Schulze Struchtrup <seb_at_struchtrup.com>
Date: Fri, 12 Nov 2004 09:34:26 +0100
Sebastian Schulze Struchtrup wrote:

>>> phk         2004-11-08 10:46:47 UTC
>>>
>>> FreeBSD src repository
>>>
>>> Modified files:
>>>   sys/fs/devfs         devfs_vnops.c Log:
>>> Add optional device vnode bypass to DEVFS.
>>>
>>>   
>>
>
> fops=0
> 1000000 bytes transferred in 4.865386 secs (205534 bytes/sec)
>
> fops=1
> 1000000 bytes transferred in 2.513814 secs (397802 bytes/sec)
>
> This would result in approx. 2us per syscall.
>
> System is FreeBSD 6.0-CURRENT #25: Tue Nov  9 13:44:16 CET 2004  
> (something like an Athlon XP 2k) with invariants and witness, without 
> anything out of phk_bufwork.
>
> No problems until now.
>
Well, everything was ok for the first day.
But since yesterday morning I get reproducable panics (failed assertion).

in devfs_vnops.c:492

492 KASSERT(dev->si_refcount > 0,
493      ("devfs_ioctl() on un-referenced struct cdev *(%s)",
494    devtoname(dev)));

dev is console.

Everything works when setting vfs.devfs.fops=0.
I can give more details or test patches, but not before monday.



(kgdb) backtrace
#0  doadump () at pcpu.h:159
#1  0xc0470e6a in db_fncall (dummy1=-1066987583, dummy2=0, 
dummy3=-581727500,
    dummy4=0xdd538a8c "?\212S?") at /usr/src/sys/ddb/db_command.c:531
#2  0xc0471200 in db_command_loop () at /usr/src/sys/ddb/db_command.c:349
#3  0xc0472c08 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221
#4  0xc05272ca in kdb_trap (type=3, code=0, tf=0xdd538bb4)
    at /usr/src/sys/kern/subr_kdb.c:421
#5  0xc068346c in trap (frame=
      {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = 1, 
tf_ebp = -581727244, tf_isp = -581727264, tf_ebx = -581727200, tf_edx = 
-1066635249, tf_ecx = -1066221472, tf_eax = -1066626764, tf_trapno = 3, 
tf_err = 0, tf_eip = -1068339452, tf_cs = 8, tf_eflags = 646, tf_esp = 
-581727212, tf_ss = -1068430437})
    at /usr/src/sys/i386/i386/trap.c:576
#6  0xc0672a3a in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#7  0x00000018 in ?? ()
#8  0x00000010 in ?? ()
#9  0x00000010 in ?? ()
#10 0x00000000 in ?? ()
#11 0x00000001 in ?? ()
#12 0xdd538bf4 in ?? ()
#13 0xdd538be0 in ?? ()
#14 0xdd538c20 in ?? ()
#15 0xc06c700f in ?? ()
---Type <return> to continue, or q <return> to quit---
#16 0xc072c060 in shutdown_howto ()
#17 0xc06c9134 in ?? ()
#18 0x00000003 in ?? ()
#19 0x00000000 in ?? ()
#20 0xc0526f04 in kdb_enter (msg=0x0) at cpufunc.h:56
#21 0xc0510b9b in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:541
#22 0xc04cf360 in devfs_ioctl_f (fp=0xc1c61000, com=1074295912,
    data=0xdd538c60, cred=0xc199b480, td=0xc1c44900)
    at /usr/src/sys/fs/devfs/devfs_vnops.c:492
#23 0xc053244e in ioctl (td=0xc1c44900, uap=0xdd538d14) at file.h:258
#24 0xc068388c in syscall (frame=
      {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 671430416, tf_esi = 
-1077940528, tf_ebp = -1077940600, tf_isp = -581726860, tf_ebx = 
-1077942904, tf_edx = -1, tf_ecx = 25, tf_eax = 54, tf_trapno = 12, 
tf_err = 2, tf_eip = 672044823, tf_cs = 31, tf_eflags = 598, tf_esp = 
-1077943028, tf_ss = 47})
    at /usr/src/sys/i386/i386/trap.c:1001
#25 0xc0672a8f in Xint0x80_syscall () at 
/usr/src/sys/i386/i386/exception.s:201
#26 0x0000002f in ?? ()
#27 0x0000002f in ?? ()
#28 0x0000002f in ?? ()
#29 0x28053710 in ?? ()
#30 0xbfbfeed0 in ?? ()
#31 0xbfbfee88 in ?? ()
---Type <return> to continue, or q <return> to quit---
#32 0xdd538d74 in ?? ()
#33 0xbfbfe588 in ?? ()
#34 0xffffffff in ?? ()
#35 0x00000019 in ?? ()
#36 0x00000036 in ?? ()
#37 0x0000000c in ?? ()
#38 0x00000002 in ?? ()
#39 0x280e9717 in ?? ()
#40 0x0000001f in ?? ()
#41 0x00000256 in ?? ()
#42 0xbfbfe50c in ?? ()
#43 0x0000002f in ?? ()
#44 0xebaa7eae in ?? ()
#45 0xffcbdeef in ?? ()
#46 0xbab27eea in ?? ()
#47 0xbebf3a8a in ?? ()
#48 0x13069000 in ?? ()
#49 0xc21b6200 in ?? ()
#50 0xc1c44900 in ?? ()
#51 0xdd538c80 in ?? ()
#52 0xdd538c68 in ?? ()
#53 0xc19a3180 in ?? ()
#54 0xc05205e3 in sched_switch (td=0xbfbfeed0, newtd=0xbfbfe588, 
flags=Cannot access memory at address 0xbfbfee98
Received on Fri Nov 12 2004 - 07:35:23 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:21 UTC