From owner-freebsd-hackers Mon Aug 27 2:43:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bugz.infotecs.ru (bugz.infotecs.ru [195.210.139.22]) by hub.freebsd.org (Postfix) with ESMTP id B276A37B403 for ; Mon, 27 Aug 2001 02:43:45 -0700 (PDT) (envelope-from vel@bugz.infotecs.ru) Received: (from vel@localhost) by bugz.infotecs.ru (8.11.6/8.11.4) id f7R9hf901857 for freebsd-hackers@freebsd.org; Mon, 27 Aug 2001 13:43:41 +0400 (MSD) (envelope-from vel) From: "Eugene L. Vorokov" Message-Id: <200108270943.f7R9hf901857@bugz.infotecs.ru> Subject: problem with unloading device driver To: freebsd-hackers@freebsd.org Date: Mon, 27 Aug 2001 13:43:41 +0400 (MSD) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, I have a module which adds new device. It does make_dev() and then simulates mknod() syscall, so that /dev/name is always automatically created. Also I have a daemon which reads from and writes to this device. The daemon opens the device once and then holds it open. When my module unloads, it simulates unlink() and then does detsroy_dev(). I just noticed that when I unload my module, the first write() by daemon to the fd associated with that device causes system to crash. Trace looks like this: (kgdb) bt #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 #1 0xc0177ed7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:330 #2 0xc01782f1 in panic (fmt=0xc0276af8 "bwrite: buffer is not busy???") at /usr/src/sys/kern/kern_shutdown.c:623 #3 0xc01a4a7b in bwrite (bp=0xc26b2390) at /usr/src/sys/kern/vfs_bio.c:672 #4 0xc01a5d08 in vfs_bio_awrite (bp=0xc26b2390) at /usr/src/sys/kern/vfs_bio.c:1538 #5 0xc01580ac in spec_fsync (ap=0xc7319cec) at /usr/src/sys/fs/specfs/spec_vnops.c:400 #6 0xc0157cb9 in spec_vnoperate (ap=0xc7319cec) at /usr/src/sys/fs/specfs/spec_vnops.c:119 #7 0xc02161bc in ffs_sync (mp=0xc05ac000, waitfor=2, cred=0xc05b1d00, p=0xc02d3fa0) at vnode_if.h:441 #8 0xc01b1677 in sync (p=0xc02d3fa0, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:622 #9 0xc0177acb in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:239 #10 0xc01782f1 in panic (fmt=0xc0288ffe "%s") at /usr/src/sys/kern/kern_shutdown.c:623 #11 0xc025337b in trap_fatal (frame=0xc7319dec, eva=12) at /usr/src/sys/i386/i386/trap.c:936 #12 0xc02530c5 in trap_pfault (frame=0xc7319dec, usermode=0, eva=12) at /usr/src/sys/i386/i386/trap.c:850 #13 0xc0252a44 in trap (frame={tf_fs = -953090024, tf_es = -953090032, tf_ds = -1071972336, tf_edi = -953049344, tf_esi = -952992672, tf_ebp = -953049500, tf_isp = -953049576, tf_ebx = -1053283072, tf_edx = -953049456, tf_ecx = 7, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1072332928, tf_cs = 8, tf_eflags = 66195, tf_esp = -1053283072, tf_ss = -953049344}) at /usr/src/sys/i386/i386/trap.c:405 #14 0xc0157f80 in spec_write (ap=0xc7319e90) at /usr/src/sys/fs/specfs/spec_vnops.c:289 #15 0xc0157cb9 in spec_vnoperate (ap=0xc7319e90) at /usr/src/sys/fs/specfs/spec_vnops.c:119 #16 0xc01b6f6b in vn_write (fp=0xc137f280, uio=0xc7319f00, cred=0xc1363800, flags=0, p=0xc72a5540) at vnode_if.h:303 #17 0xc018fc18 in dofilewrite (p=0xc72a5540, fp=0xc137f280, fd=3, buf=0xbfbffbab, nbyte=1, offset=-1, flags=0) at /usr/src/sys/sys/file.h:162 #18 0xc018face in write (p=0xc72a5540, uap=0xc7319f80) at /usr/src/sys/kern/sys_generic.c:334 #19 0xc02538a5 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077937128, tf_esi = -1077937136, tf_ebp = -1077937220, tf_isp = -953049132, tf_ebx = 1, tf_edx = 0, tf_ecx = 0, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = 671760164, tf_cs = 31, tf_eflags = 663, tf_esp = -1077937280, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1123 #20 0xc024479d in syscall_with_err_pushed () #21 0x80486bd in ?? () (kgdb) frame 14 #14 0xc0157f80 in spec_write (ap=0xc7319e90) at /usr/src/sys/fs/specfs/spec_vnops.c:289 289 error = (*devsw(dev)->d_write) (dev, uio, ap->a_ioflag); (kgdb) p *dev $2 = {si_flags = 0, si_atime = {tv_sec = 998903778, tv_nsec = 2619315}, si_ctime = {tv_sec = 998903780, tv_nsec = 22640918}, si_mtime = {tv_sec = 998903780, tv_nsec = 22640918}, si_udev = 8448, si_hash = {le_next = 0xc02bcd38, le_prev = 0xc02bdca4}, si_hlist = {slh_first = 0xc7327c60}, si_children = {lh_first = 0x0}, si_siblings = {le_next = 0x0, le_prev = 0x0}, si_parent = 0x0, si_snapshots = {tqh_first = 0x0, tqh_last = 0xc1382d3c}, si_copyonwrite = 0, si_inode = 0, si_name = "paudit\000\000\000\000\000\000\000\000\000", si_drv1 = 0x0, si_drv2 = 0x0, si_devsw = 0x0, si_iosize_max = 65536, si_uid = 0, si_gid = 0, si_mode = 438, __si_u = {__si_tty = {__sit_tty = 0x0}, __si_disk = {__sid_disk = 0x0, __sid_mountpoint = 0x0, __sid_bsize_phys = 0, __sid_bsize_best = 0}}} si_devsw is 0 here, which seems to be a problem. Is this a bug, or can I do something inside my module to prevent this from happening ? Regards, Eugene To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message