From owner-freebsd-hackers Sun Jul 5 22:23:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA04767 for freebsd-hackers-outgoing; Sun, 5 Jul 1998 22:23:34 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA04762 for ; Sun, 5 Jul 1998 22:23:27 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id OAA07737; Mon, 6 Jul 1998 14:53:10 +0930 (CST) Message-ID: <19980706145310.C6528@freebie.lemis.com> Date: Mon, 6 Jul 1998 14:53:10 +0930 From: Greg Lehey To: FreeBSD Hackers Subject: HEADS UP: Sleeping in strategy routines? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At USENIX I discussed the idea of calling block^H^H^H^H^H device strategy routines from the bottom half of a driver, and the general consensus was yes, you can do this. I've just had a panic which seems to point to other problems. Here's the trace: Program received signal SIGSEGV, Segmentation fault. tsleep (ident=0xf0278964, priority=0x10, wmesg=0xf01f7536 "bncwai", timo=0x0) at ../../kern/kern_synch.c:374 374 if (KTRPOINT(p, KTR_CSW)) (kgdb) bt #0 tsleep (ident=0xf0278964, priority=0x10, wmesg=0xf01f7536 "bncwai", timo=0x0) at ../../kern/kern_synch.c:374 #1 0xf01f75b3 in vm_bounce_page_find (count=0x1) at ../../i386/i386/vm_machdep.c:160 #2 0xf01f7be7 in vm_bounce_alloc (bp=0xf0783018) at ../../i386/i386/vm_machdep.c:397 #3 0xf01bae01 in sd_strategy (bp=0xf0783018, sc_link=0xf075dd80) at ../../scsi/sd.c:623 #4 0xf01b792c in scsi_strategy (bp=0xf0783018, device=0xf025333c) at ../../scsi/scsi_driver.c:220 #5 0xf01ba804 in sdstrategy (bp=0xf0783018) at ../../scsi/sd.c:173 #6 0xf01494de in spec_strategy (ap=0xf024ae2c) at ../../miscfs/specfs/spec_vnops.c:557 #7 0xf0148bc9 in spec_vnoperate (ap=0xf024ae2c) at ../../miscfs/specfs/spec_vnops.c:127 #8 0xf01cb6f1 in ufs_vnoperatespec (ap=0xf024ae2c) at ../../ufs/ufs/ufs_vnops.c:2282 #9 0xf430a04f in VOP_STRATEGY (bp=0xf0783018) at vnode_if.h:1100 #10 0xf4309fd8 in complete_raid5_write (rqe=0xf0783018) at raid5.c:767 #11 0xf4307ae0 in complete_rqe (bp=0xf0783160) at request.c:797 #12 0xf0137d52 in biodone (bp=0xf0783160) at ../../kern/vfs_bio.c:1912 #13 0xf01b6954 in scsi_done (xs=0xf07b9000) at ../../scsi/scsi_base.c:448 #14 0xf01f924b in aha_done (aha=0xf075f000, ccb=0xf075fa64) at ../../i386/isa/aha1542.c:945 #15 0xf01f8d39 in ahaintr (unit=0x0) at ../../i386/isa/aha1542.c:751 (kgdb) l 369 struct proc *p = curproc; 370 int s, sig, catch = priority & PCATCH; 371 struct callout_handle thandle; 372 373 #ifdef KTRACE 374 if (KTRPOINT(p, KTR_CSW)) 375 ktrcsw(p->p_tracep, 1, 0); 376 #endif 377 s = splhigh(); 378 if (cold || panicstr) { (kgdb) p p $1 = (struct proc *) 0x0 I can't make up my mind whose fault this is. If it's true that you should be able to call a strategy routine from the lower half, then vm_bounce_page_find shouldn't be tsleeping. But so far this is an assertion, even if it's shared by others. On the other hand, I've been working quite happily with this driver (well, I haven't run into problems like this :-) until I changed to a system with more than 16 MB of memory and didn't change the controller (AHA 1542, as the trace shows). This really boils down to a policy question: should strategy routines do anything that requires a process context? Do *you* have code which relies on being in a process context? Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message