From owner-freebsd-drivers@FreeBSD.ORG Wed Jul 29 17:23:47 2009 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9553D106568F for ; Wed, 29 Jul 2009 17:23:47 +0000 (UTC) (envelope-from cjharrer@comcast.net) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 038988FC3B for ; Wed, 29 Jul 2009 17:23:46 +0000 (UTC) (envelope-from cjharrer@comcast.net) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA01.westchester.pa.mail.comcast.net with comcast id MpkA1c00516LCl051tNi5J; Wed, 29 Jul 2009 17:22:42 +0000 Received: from record ([69.253.164.177]) by OMTA06.westchester.pa.mail.comcast.net with comcast id MtPm1c0053py3KZ3StPmTa; Wed, 29 Jul 2009 17:23:46 +0000 From: "Chris Harrer" To: "'Alfred Perlstein'" , "'John Baldwin'" References: <002801ca06f0$b1d42af0$157c80d0$@net> <200907211743.12667.jhb@freebsd.org> <20090722000713.GZ49724@elvis.mu.org> <200907220819.05087.jhb@freebsd.org> <20090725035643.GT49724@elvis.mu.org> In-Reply-To: <20090725035643.GT49724@elvis.mu.org> Date: Wed, 29 Jul 2009 13:23:46 -0400 Message-ID: <000c01ca1071$54991d70$fdcb5850$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcoM2/HxF+aq067YQpuS7VXhlGBevQDkv71g Content-Language: en-us Cc: freebsd-drivers@freebsd.org Subject: RE: Driver development question X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 17:23:48 -0000 Warning LONG message below, I figured I'd give as much information as possible to try and help me along. > On Tuesday 21 July 2009 8:07:13 pm Alfred Perlstein wrote: > > * John Baldwin [090721 14:44] wrote: > > > On Tuesday 21 July 2009 2:34:21 am Marc Loerner wrote: > > > > Am Dienstag 21 Juli 2009 00:38:56 schrieb Sam Leffler: > > > > > John Baldwin wrote: > > > > > > On Friday 17 July 2009 11:10:17 am Chris Harrer wrote: > > > > > >> Hi All, > > > > > >> > > > > > >> I'm hoping someone can point me in the right direction... I'm > > > > > >> developing a FreeBSD driver for a PCIe card. The driver controls a > > > > > >> hardware device that has DRAM and various state information on it. > I'm > > > > > >> trying to mimic functionality I have for other OS support such that > I > > > > > >> can dump memory and state information from the card to a file I > create > > > > > >> from within my driver (kernel module). > > > > > >> > > > > > >> For example, in a Linux driver I use filp_open to create the dump > file > > > > > >> (represented by fp), then use fp->f_op->write to put information > into > > > > > >> the file. > > > > > >> > > > > > >> FreeBSD doesn't have filp_* API's. I've tried searching for > example > > > > > >> drivers and googling for file API's from kernel modules to no > avail. > > > > > >> Can someone please offer some guidance as to how I might proceed > here? > > > > > >> > > > > > >> Thanks in advance and any insight would be most appreciated! > > > > > > > > > > > > You can look at sys/kern/kern_ktrace.c to see how the ktrace() > system > > > > > > call creates a file. I think in general you will wind up using > > > > > > NDINIT/namei() (to lookup the vnode for a pathname) and then > vn_open() / > > > > > > vn_rdwr() / vn_close(). > > > > > > > > > > man alq(9). > > > > > > > > > > > > > > > > > > Why not use kern_open, kern_close, kern_preadv, kern_pwritev? > > > > > > Those affect the state of the current process by opening a new file > > > descriptor, etc. That is generally bad practice for a device driver to be > > > interfering with a process' state, and it will not work for kernel > threads. > > > You can rather easily have userland open a file and then pass the file > > > descriptor to a driver which can then do operations on a file directly. > > > > If the vnode operations are annoying to wrap ones head around, one > > could have the driver defer this this to a kernel resident process > > that the driver would create on attach. > > Kernel processes don't have file descriptor tables. Hi All, I'm hoping you can provide a bit more guidance here as I'm still struggling with this and I'm running out of ideas. Again, what I want to do is, some event (interrupt from an intelligent PCIe card indicating it's "dead") will cause me to: 1) Open/create a file 2) write raw/random/non-patterned/variable sized data to the file 3) close/save the file from within my device driver. To this point, I've tried several things using vn_open, vn_open_cred, alq_open and cutting/massaging the code from alq_open with no success. I've done this from within the context of my interrupt handler as well as a timer (callout_init, callout_reset) thread as well as from a thread I create with kproc_create. In each and every instance, I get the following crash: (gdb) bt 15 #0 _mtx_lock_flags (m=0xc0, opts=0x0, file=0xffffffff80611dc0 "/src/FreeBSD/HECTOR/src/sys/kern/vfs_subr.c", line=0x847) at /src/FreeBSD/HECTOR/src/sys/kern/kern_mutex.c:195 #1 0xffffffff803c8431 in vref (vp=0x0) at /src/FreeBSD/HECTOR/src/sys/kern/vfs_subr.c:2119 #2 0xffffffff803c02de in namei (ndp=0xffffff80003bfdf2) at /src/FreeBSD/HECTOR/src/sys/kern/vfs_lookup.c:229 #3 0xffffffff803d6100 in vn_open_cred (ndp=0xffffff80003bfdf2, flagp=0xffffff8000045a2c, cmode=0x180, cred=0xffffff00014d5000, fp=0x0) at /src/FreeBSD/HECTOR/src/sys/kern/vfs_vnops.c:133 #4 0xffffffff8023497a in sxg_dump_open_file (adapter=0xffffff80003b4000) at /src/FreeBSD/HECTOR/src/sys/dev/sxg/sxg.c:5064 #5 0xffffffff8023524a in sxg_dump_thread (arg=) at /src/FreeBSD/HECTOR/src/sys/dev/sxg/sxg.c:5170 #6 0xffffffff80235398 in sxg_check_for_hang_timer (arg1=) at /src/FreeBSD/HECTOR/src/sys/dev/sxg/sxg.c:4956 #7 0xffffffff80350741 in softclock (arg=) at /src/FreeBSD/HECTOR/src/sys/kern/kern_timeout.c:411 #8 0xffffffff80318b08 in intr_event_execute_handlers (p=, ie=0xffffff00014d5600) at /src/FreeBSD/HECTOR/src/sys/kern/kern_intr.c:1146 #9 0xffffffff80319762 in ithread_loop (arg=0xffffff00014da8a0) at /src/FreeBSD/HECTOR/src/sys/kern/kern_intr.c:1159 #10 0xffffffff80316a9a in fork_exit (callout=0xffffffff803196b0 , arg=0xffffff00014da8a0, frame=0xffffff8000045c90) at /src/FreeBSD/HECTOR/src/sys/kern/kern_fork.c:829 #11 0xffffffff8054dd5e in fork_trampoline () at /src/FreeBSD/HECTOR/src/sys/amd64/amd64/exception.S:552 #12 0x0000000000000000 in ?? () The offending "SIGSEGV, Segmentation fault" is from the following code (frame 2): if (dp == NULL) { dp = fdp->fd_cdir; <----- fdp->fd_cdir = 0 VREF(dp); FILEDESC_SUNLOCK(fdp); if (ndp->ni_startdir != NULL) { vfslocked = VFS_LOCK_GIANT(ndp->ni_startdir->v_mount); vrele(ndp->ni_startdir); VFS_UNLOCK_GIANT(vfslocked); } } The *fdp structure looks like: (gdb) print *fdp $4 = { fd_ofiles = 0xffffff0001345680, fd_ofileflags = 0xffffff0001345720 "", fd_cdir = 0x0, fd_rdir = 0x0, fd_jdir = 0x0, fd_nfiles = 0x14, fd_map = 0xffffff0001345738, fd_lastfile = 0xffffffff, fd_freefile = 0x0, fd_cmask = 0x12, fd_refcnt = 0x1, fd_holdcnt = 0x1, fd_sx = { lock_object = { lo_name = 0xffffffff805fc20d "filedesc structure", lo_flags = 0x2330000, lo_data = 0x0, lo_witness = 0xffffff8000206c00 }, sx_lock = 0x11 }, fd_kqlist = { slh_first = 0x0 }, fd_holdleaderscount = 0x0, fd_holdleaderswakeup = 0x0 } In this particular instance, I created a nameidata structure via NDINIT that is: (gdb) print *ndp $2 = { ni_dirp = 0xffffff8000045a30 "/var/tmp/sxgdump", ni_segflg = UIO_SYSSPACE, ni_startdir = 0x0, ni_rootdir = 0x0, ni_topdir = 0x0, ni_dirfd = 0xffffff9c, ni_vp = 0x0, ni_dvp = 0x0, ni_pathlen = 0x11, ni_next = 0x0, ni_loopcnt = 0x0, ni_cnd = { cn_nameiop = 0x1, cn_flags = 0x520000c, cn_thread = 0xffffff00014eb390, cn_cred = 0xffffff00014d5000, cn_lkflags = 0x0, cn_pnbuf = 0xffffff000620c000 "/var/tmp/sxgdump", cn_nameptr = 0x0, cn_namelen = 0x0, cn_consume = 0x0 } } I appreciate the guidance you've given to date and I hope you can provide a few more words of wisdom to me. Thanks in advance! Chris From owner-freebsd-drivers@FreeBSD.ORG Wed Jul 29 17:56:59 2009 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86616106568D; Wed, 29 Jul 2009 17:56:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5719A8FC19; Wed, 29 Jul 2009 17:56:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0994E46B2C; Wed, 29 Jul 2009 13:56:59 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id EE8D08A0A4; Wed, 29 Jul 2009 13:56:57 -0400 (EDT) From: John Baldwin To: "Chris Harrer" Date: Wed, 29 Jul 2009 13:56:51 -0400 User-Agent: KMail/1.9.7 References: <002801ca06f0$b1d42af0$157c80d0$@net> <20090725035643.GT49724@elvis.mu.org> <000c01ca1071$54991d70$fdcb5850$@net> In-Reply-To: <000c01ca1071$54991d70$fdcb5850$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907291356.51702.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 29 Jul 2009 13:56:58 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-drivers@freebsd.org Subject: Re: Driver development question X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 17:56:59 -0000 On Wednesday 29 July 2009 1:23:46 pm Chris Harrer wrote: > Warning LONG message below, I figured I'd give as much information as > possible to try and help me along. > > > > On Tuesday 21 July 2009 8:07:13 pm Alfred Perlstein wrote: > > > * John Baldwin [090721 14:44] wrote: > > > > On Tuesday 21 July 2009 2:34:21 am Marc Loerner wrote: > > > > > Am Dienstag 21 Juli 2009 00:38:56 schrieb Sam Leffler: > > > > > > John Baldwin wrote: > > > > > > > On Friday 17 July 2009 11:10:17 am Chris Harrer wrote: > > > > > > >> Hi All, > > > > > > >> > > > > > > >> I'm hoping someone can point me in the right direction... I'm > > > > > > >> developing a FreeBSD driver for a PCIe card. The driver > controls a > > > > > > >> hardware device that has DRAM and various state information on > it. > > I'm > > > > > > >> trying to mimic functionality I have for other OS support such > that > > I > > > > > > >> can dump memory and state information from the card to a file I > > > create > > > > > > >> from within my driver (kernel module). > > > > > > >> > > > > > > >> For example, in a Linux driver I use filp_open to create the > dump > > file > > > > > > >> (represented by fp), then use fp->f_op->write to put > information > > into > > > > > > >> the file. > > > > > > >> > > > > > > >> FreeBSD doesn't have filp_* API's. I've tried searching for > > example > > > > > > >> drivers and googling for file API's from kernel modules to no > > avail. > > > > > > >> Can someone please offer some guidance as to how I might > proceed > > here? > > > > > > >> > > > > > > >> Thanks in advance and any insight would be most appreciated! > > > > > > > > > > > > > > You can look at sys/kern/kern_ktrace.c to see how the ktrace() > > system > > > > > > > call creates a file. I think in general you will wind up using > > > > > > > NDINIT/namei() (to lookup the vnode for a pathname) and then > > vn_open() / > > > > > > > vn_rdwr() / vn_close(). > > > > > > > > > > > > man alq(9). > > > > > > > > > > > > > > > > > > > > > > Why not use kern_open, kern_close, kern_preadv, kern_pwritev? > > > > > > > > Those affect the state of the current process by opening a new file > > > > descriptor, etc. That is generally bad practice for a device driver > to be > > > > interfering with a process' state, and it will not work for kernel > > threads. > > > > You can rather easily have userland open a file and then pass the file > > > > > descriptor to a driver which can then do operations on a file > directly. > > > > > > If the vnode operations are annoying to wrap ones head around, one > > > could have the driver defer this this to a kernel resident process > > > that the driver would create on attach. > > > > Kernel processes don't have file descriptor tables. > > Hi All, > > I'm hoping you can provide a bit more guidance here as I'm still struggling > with this and I'm running out of ideas. Again, what I want to do is, some > event (interrupt from an intelligent PCIe card indicating it's "dead") will > cause me to: > > 1) Open/create a file > 2) write raw/random/non-patterned/variable sized data to the file > 3) close/save the file > > from within my device driver. To this point, I've tried several things > using vn_open, vn_open_cred, alq_open and cutting/massaging the code from > alq_open with no success. I've done this from within the context of my > interrupt handler as well as a timer (callout_init, callout_reset) thread as > well as from a thread I create with kproc_create. In each and every > instance, I get the following crash: The problem is that kernel threads do not have a valid file descriptor table, hence fd_cdir is NULL. You could work around this if you create a dedicated kproc and set fd_cdir to rootvnode (but vref() rootvnode when you do this). You should also set fd_rdir and fd_jdir to rootvnode as well (also doing appropriate vref() of rootvnode for each reference). Something like this: struct filedesc *fdp; fdp = curthread->td_proc->p_fd; FILEDESC_XLOCK(fdp); fd->fd_rdir = rootvnode; vref(rootvnode); fd->fd_jdir = rootvnode; vref(rootvnode); fd->fd_cdir = rootvnode; vref(rootvnode); FILEDESC_XUNLOCK(fdp); You should not do this from a callout routine or interrupt handler however. You could do this via a TASK to a private taskqueue with a dedicated kernel process however. (i.e. queue a task that does the above during after creating the taskqueue and then queue a task to create the file later). -- John Baldwin From owner-freebsd-drivers@FreeBSD.ORG Wed Jul 29 18:02:31 2009 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CCC01065675 for ; Wed, 29 Jul 2009 18:02:31 +0000 (UTC) (envelope-from cjharrer@comcast.net) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id CE69F8FC17 for ; Wed, 29 Jul 2009 18:02:30 +0000 (UTC) (envelope-from cjharrer@comcast.net) Received: from OMTA20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA08.westchester.pa.mail.comcast.net with comcast id MnCq1c0051YDfWL58u2XYK; Wed, 29 Jul 2009 18:02:31 +0000 Received: from record ([69.253.164.177]) by OMTA20.westchester.pa.mail.comcast.net with comcast id Mu4P1c00B3py3KZ3gu4PGZ; Wed, 29 Jul 2009 18:04:24 +0000 From: "Chris Harrer" To: "'John Baldwin'" References: <002801ca06f0$b1d42af0$157c80d0$@net> <20090725035643.GT49724@elvis.mu.org> <000c01ca1071$54991d70$fdcb5850$@net> <200907291356.51702.jhb@freebsd.org> In-Reply-To: <200907291356.51702.jhb@freebsd.org> Date: Wed, 29 Jul 2009 14:02:30 -0400 Message-ID: <000d01ca1076$bdf58510$39e08f30$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcoQdfiCG9t44+1bSKSxSEicpj0saQAAHWVQ Content-Language: en-us Cc: freebsd-drivers@freebsd.org Subject: RE: Driver development question X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 18:02:31 -0000 >The problem is that kernel threads do not have a valid file descriptor table, >hence fd_cdir is NULL. You could work around this if you create a dedicated >kproc and set fd_cdir to rootvnode (but vref() rootvnode when you do this). >You should also set fd_rdir and fd_jdir to rootvnode as well (also doing >appropriate vref() of rootvnode for each reference). Something like this: > > struct filedesc *fdp; > > fdp = curthread->td_proc->p_fd; > FILEDESC_XLOCK(fdp); > fd->fd_rdir = rootvnode; > vref(rootvnode); > fd->fd_jdir = rootvnode; > vref(rootvnode); > fd->fd_cdir = rootvnode; > vref(rootvnode); > FILEDESC_XUNLOCK(fdp); > >You should not do this from a callout routine or interrupt handler however. >You could do this via a TASK to a private taskqueue with a dedicated kernel >process however. (i.e. queue a task that does the above during after >creating the taskqueue and then queue a task to create the file later). > >-- >John Baldwin John, Thanks so much for the help and quick response, I will try this now. Cheers, Chris From owner-freebsd-drivers@FreeBSD.ORG Wed Jul 29 18:04:07 2009 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 834741065673 for ; Wed, 29 Jul 2009 18:04:07 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id F39C68FC0C for ; Wed, 29 Jul 2009 18:04:06 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by bwz2 with SMTP id 2so120970bwz.43 for ; Wed, 29 Jul 2009 11:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=fsNnUB+YB9B2x2enXooQxZGjc6mNMfcclGkkcfTSnow=; b=jciqEox9lTvaTJTJ6tJeH+V012c0HjYY2u+Q4agd4FZIPPcZVHVvJexAbue0lt2pQP w2SnrwQP8XVHSlQwdjxykFdEXMnzwilGCIEKZrwtzSv3seZJlbDLtLP8/8Vl8P2f8lVq aENh7GEEqc6PjzAoYpya4z4jGIGSjvMZCagFo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=WvhywWsFoZxrmfh08YZyeOXf8MQ1u47g1BEt3REi9k1UDL5GoxvfmbLcAIkN95LFpr uwUQMe7ieAN0Ig8uB9KhU08zln8aC/vUokEHBW2EG/U7qfUx/tgjQcMzb9dkgjJXAgn4 uqd1ex0bomVxc9xDi4mDTDL35FXu9CNElndgs= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.120.197 with SMTP id e5mr59373far.25.1248888757637; Wed, 29 Jul 2009 10:32:37 -0700 (PDT) In-Reply-To: <000c01ca1071$54991d70$fdcb5850$@net> References: <002801ca06f0$b1d42af0$157c80d0$@net> <200907211743.12667.jhb@freebsd.org> <20090722000713.GZ49724@elvis.mu.org> <200907220819.05087.jhb@freebsd.org> <20090725035643.GT49724@elvis.mu.org> <000c01ca1071$54991d70$fdcb5850$@net> Date: Wed, 29 Jul 2009 19:32:37 +0200 X-Google-Sender-Auth: 54556ce58550f6c5 Message-ID: <3bbf2fe10907291032v6cb917aao34e4d40b6a4daa26@mail.gmail.com> From: Attilio Rao To: Chris Harrer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-drivers@freebsd.org Subject: Re: Driver development question X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 18:04:07 -0000 2009/7/29 Chris Harrer : > Warning LONG message below, I figured I'd give as much information as > possible to try and help me along. > > >> On Tuesday 21 July 2009 8:07:13 pm Alfred Perlstein wrote: >> > * John Baldwin [090721 14:44] wrote: >> > > On Tuesday 21 July 2009 2:34:21 am Marc Loerner wrote: >> > > > Am Dienstag 21 Juli 2009 00:38:56 schrieb Sam Leffler: >> > > > > John Baldwin wrote: >> > > > > > On Friday 17 July 2009 11:10:17 am Chris Harrer wrote: >> > > > > >> Hi All, >> > > > > >> >> > > > > >> I'm hoping someone can point me in the right direction... I'm >> > > > > >> developing a FreeBSD driver for a PCIe card. The driver > controls a >> > > > > >> hardware device that has DRAM and various state information on > it. >> I'm >> > > > > >> trying to mimic functionality I have for other OS support such > that >> I >> > > > > >> can dump memory and state information from the card to a file I > >> create >> > > > > >> from within my driver (kernel module). >> > > > > >> >> > > > > >> For example, in a Linux driver I use filp_open to create the > dump >> file >> > > > > >> (represented by fp), then use fp->f_op->write to put > information >> into >> > > > > >> the file. >> > > > > >> >> > > > > >> FreeBSD doesn't have filp_* API's. I've tried searching for >> example >> > > > > >> drivers and googling for file API's from kernel modules to no >> avail. >> > > > > >> Can someone please offer some guidance as to how I might > proceed >> here? >> > > > > >> >> > > > > >> Thanks in advance and any insight would be most appreciated! >> > > > > > >> > > > > > You can look at sys/kern/kern_ktrace.c to see how the ktrace() >> system >> > > > > > call creates a file. I think in general you will wind up using >> > > > > > NDINIT/namei() (to lookup the vnode for a pathname) and then >> vn_open() / >> > > > > > vn_rdwr() / vn_close(). >> > > > > >> > > > > man alq(9). >> > > > > >> > > > > >> > > > >> > > > Why not use kern_open, kern_close, kern_preadv, kern_pwritev? >> > > >> > > Those affect the state of the current process by opening a new file >> > > descriptor, etc. That is generally bad practice for a device driver > to be >> > > interfering with a process' state, and it will not work for kernel >> threads. >> > > You can rather easily have userland open a file and then pass the file > >> > > descriptor to a driver which can then do operations on a file > directly. >> > >> > If the vnode operations are annoying to wrap ones head around, one >> > could have the driver defer this this to a kernel resident process >> > that the driver would create on attach. >> >> Kernel processes don't have file descriptor tables. > > Hi All, > > I'm hoping you can provide a bit more guidance here as I'm still struggling > with this and I'm running out of ideas. Again, what I want to do is, some > event (interrupt from an intelligent PCIe card indicating it's "dead") will > cause me to: > > 1) Open/create a file > 2) write raw/random/non-patterned/variable sized data to the file > 3) close/save the file > > from within my device driver. To this point, I've tried several things > using vn_open, vn_open_cred, alq_open and cutting/massaging the code from > alq_open with no success. I've done this from within the context of my > interrupt handler as well as a timer (callout_init, callout_reset) thread as > well as from a thread I create with kproc_create. In each and every > instance, I get the following crash: I think there is an important thing to consider. vnode handling is all consider a sleepable operation so you can't cater this inside a callout handler. The usual way to do that is to use a character device and specify an ioctl interface that gates such requests. Said that, it seems you alredy used a kthread for such operation in some cases? can you share the complete code? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-drivers@FreeBSD.ORG Wed Jul 29 18:51:07 2009 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 018791065677 for ; Wed, 29 Jul 2009 18:51:06 +0000 (UTC) (envelope-from cjharrer@comcast.net) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id 299828FC1A for ; Wed, 29 Jul 2009 18:51:06 +0000 (UTC) (envelope-from cjharrer@comcast.net) Received: from OMTA15.westchester.pa.mail.comcast.net ([76.96.62.87]) by QMTA08.westchester.pa.mail.comcast.net with comcast id Mplo1c0061swQuc58ur6ec; Wed, 29 Jul 2009 18:51:06 +0000 Received: from record ([69.253.164.177]) by OMTA15.westchester.pa.mail.comcast.net with comcast id Mutw1c0033py3KZ3butwcx; Wed, 29 Jul 2009 18:53:56 +0000 From: "Chris Harrer" To: "'Chris Harrer'" , "'John Baldwin'" References: <002801ca06f0$b1d42af0$157c80d0$@net> <20090725035643.GT49724@elvis.mu.org> <000c01ca1071$54991d70$fdcb5850$@net> <200907291356.51702.jhb@freebsd.org> In-Reply-To: Date: Wed, 29 Jul 2009 14:51:06 -0400 Message-ID: <000e01ca107d$87a6ea60$96f4bf20$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcoQdfiCG9t44+1bSKSxSEicpj0saQAAHWVQAAGBFBA= Content-Language: en-us Cc: freebsd-drivers@freebsd.org Subject: RE: Driver development question X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 18:51:07 -0000 >The problem is that kernel threads do not have a valid file descriptor table, >hence fd_cdir is NULL. You could work around this if you create a dedicated >kproc and set fd_cdir to rootvnode (but vref() rootvnode when you do this). >You should also set fd_rdir and fd_jdir to rootvnode as well (also doing >appropriate vref() of rootvnode for each reference). Something like this: > > struct filedesc *fdp; > > fdp = curthread->td_proc->p_fd; > FILEDESC_XLOCK(fdp); > fd->fd_rdir = rootvnode; > vref(rootvnode); > fd->fd_jdir = rootvnode; > vref(rootvnode); > fd->fd_cdir = rootvnode; > vref(rootvnode); > FILEDESC_XUNLOCK(fdp); > >You should not do this from a callout routine or interrupt handler however. >You could do this via a TASK to a private taskqueue with a dedicated kernel >process however. (i.e. queue a task that does the above during after >creating the taskqueue and then queue a task to create the file later). > >-- >John Baldwin Hi John, I tried this and rootvnode = 0x0, so I am still getting a SIGSEGV. I create a thread in my "attach" routine via: status = kproc_create(sxg_dump_thread, adapter, &adapter->dumpproc, RFNOWAIT , 0, "sxgdump"); if (status) { SXG_DBG_MSG(adapter->dev, "%s[%p], Cannot create dump thread, status: %d\n", __func__, adapter, status); return (status); } Then my thread does: static void sxg_dump_thread(void * arg) { adapter_t *adapter = (adapter_t *)arg; struct filedesc *fdp; ulong32 index = 0; // Set up some file descriptor stuff so we can // actually open/create a dump file. Kernel // threads, by design, do not have a valid // file descriptor table. So, we're gonna // make this thread point to one! fdp = curthread->td_proc->p_fd; FILEDESC_XLOCK(fdp); fdp->fd_rdir = rootvnode; vref(rootvnode); <----- SIGSEGV on this line, rootvnode = 0x0 fdp->fd_jdir = rootvnode; vref(rootvnode); fdp->fd_cdir = rootvnode; vref(rootvnode); FILEDESC_XUNLOCK(fdp); for (;;){ ... Sorry if I'm doing something obviously wrong, I'm trying to come up to speed as quickly as I can. Cheers, Chris From owner-freebsd-drivers@FreeBSD.ORG Wed Jul 29 19:39:07 2009 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A99710657ED for ; Wed, 29 Jul 2009 19:39:07 +0000 (UTC) (envelope-from cjharrer@comcast.net) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id CF15E8FC16 for ; Wed, 29 Jul 2009 19:39:06 +0000 (UTC) (envelope-from cjharrer@comcast.net) Received: from OMTA24.westchester.pa.mail.comcast.net ([76.96.62.76]) by QMTA02.westchester.pa.mail.comcast.net with comcast id MnN71c0041ei1Bg52vf7oQ; Wed, 29 Jul 2009 19:39:07 +0000 Received: from record ([69.253.164.177]) by OMTA24.westchester.pa.mail.comcast.net with comcast id Mvhg1c0063py3KZ3kvhgcM; Wed, 29 Jul 2009 19:41:40 +0000 From: "Chris Harrer" To: "'Chris Harrer'" , "'John Baldwin'" References: <002801ca06f0$b1d42af0$157c80d0$@net> <20090725035643.GT49724@elvis.mu.org> <000c01ca1071$54991d70$fdcb5850$@net> <200907291356.51702.jhb@freebsd.org> In-Reply-To: Date: Wed, 29 Jul 2009 15:39:05 -0400 Message-ID: <000f01ca1084$3c20caf0$b46260d0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcoQdfiCG9t44+1bSKSxSEicpj0saQAAHWVQAAGBFBAAAe3ikA== Content-Language: en-us Cc: freebsd-drivers@freebsd.org Subject: RE: Driver development question X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 19:39:08 -0000 Hi John, Sorry for top posting... I put a delay in my thread waiting for rootvnode to be set and I'm able to create a file now. Thanks! Chris -----Original Message----- From: Chris Harrer [mailto:cjharrer@comcast.net] Sent: Wednesday, July 29, 2009 2:51 PM To: 'Chris Harrer'; 'John Baldwin' Cc: 'Alfred Perlstein'; 'freebsd-drivers@freebsd.org' Subject: RE: Driver development question >The problem is that kernel threads do not have a valid file descriptor table, >hence fd_cdir is NULL. You could work around this if you create a dedicated >kproc and set fd_cdir to rootvnode (but vref() rootvnode when you do this). >You should also set fd_rdir and fd_jdir to rootvnode as well (also doing >appropriate vref() of rootvnode for each reference). Something like this: > > struct filedesc *fdp; > > fdp = curthread->td_proc->p_fd; > FILEDESC_XLOCK(fdp); > fd->fd_rdir = rootvnode; > vref(rootvnode); > fd->fd_jdir = rootvnode; > vref(rootvnode); > fd->fd_cdir = rootvnode; > vref(rootvnode); > FILEDESC_XUNLOCK(fdp); > >You should not do this from a callout routine or interrupt handler however. >You could do this via a TASK to a private taskqueue with a dedicated kernel >process however. (i.e. queue a task that does the above during after >creating the taskqueue and then queue a task to create the file later). > >-- >John Baldwin Hi John, I tried this and rootvnode = 0x0, so I am still getting a SIGSEGV. I create a thread in my "attach" routine via: status = kproc_create(sxg_dump_thread, adapter, &adapter->dumpproc, RFNOWAIT , 0, "sxgdump"); if (status) { SXG_DBG_MSG(adapter->dev, "%s[%p], Cannot create dump thread, status: %d\n", __func__, adapter, status); return (status); } Then my thread does: static void sxg_dump_thread(void * arg) { adapter_t *adapter = (adapter_t *)arg; struct filedesc *fdp; ulong32 index = 0; // Set up some file descriptor stuff so we can // actually open/create a dump file. Kernel // threads, by design, do not have a valid // file descriptor table. So, we're gonna // make this thread point to one! fdp = curthread->td_proc->p_fd; FILEDESC_XLOCK(fdp); fdp->fd_rdir = rootvnode; vref(rootvnode); <----- SIGSEGV on this line, rootvnode = 0x0 fdp->fd_jdir = rootvnode; vref(rootvnode); fdp->fd_cdir = rootvnode; vref(rootvnode); FILEDESC_XUNLOCK(fdp); for (;;){ ... Sorry if I'm doing something obviously wrong, I'm trying to come up to speed as quickly as I can. Cheers, Chris From owner-freebsd-drivers@FreeBSD.ORG Wed Jul 29 19:51:15 2009 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B56D106564A; Wed, 29 Jul 2009 19:51:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BDF698FC15; Wed, 29 Jul 2009 19:51:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5B49C46B53; Wed, 29 Jul 2009 15:51:14 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 7A38F8A0A5; Wed, 29 Jul 2009 15:51:13 -0400 (EDT) From: John Baldwin To: "Chris Harrer" Date: Wed, 29 Jul 2009 15:02:29 -0400 User-Agent: KMail/1.9.7 References: <002801ca06f0$b1d42af0$157c80d0$@net> <200907291356.51702.jhb@freebsd.org> <000e01ca107d$87a6ea60$96f4bf20$@net> In-Reply-To: <000e01ca107d$87a6ea60$96f4bf20$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907291502.30250.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 29 Jul 2009 15:51:13 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-drivers@freebsd.org Subject: Re: Driver development question X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 19:51:15 -0000 On Wednesday 29 July 2009 2:51:06 pm Chris Harrer wrote: > >The problem is that kernel threads do not have a valid file descriptor > table, > >hence fd_cdir is NULL. You could work around this if you create a > dedicated > >kproc and set fd_cdir to rootvnode (but vref() rootvnode when you do this). > > >You should also set fd_rdir and fd_jdir to rootvnode as well (also doing > >appropriate vref() of rootvnode for each reference). Something like this: > > > > struct filedesc *fdp; > > > > fdp = curthread->td_proc->p_fd; > > FILEDESC_XLOCK(fdp); > > fd->fd_rdir = rootvnode; > > vref(rootvnode); > > fd->fd_jdir = rootvnode; > > vref(rootvnode); > > fd->fd_cdir = rootvnode; > > vref(rootvnode); > > FILEDESC_XUNLOCK(fdp); > > > >You should not do this from a callout routine or interrupt handler however. > > >You could do this via a TASK to a private taskqueue with a dedicated kernel > > >process however. (i.e. queue a task that does the above during after > >creating the taskqueue and then queue a task to create the file later). > > > >-- > >John Baldwin > > Hi John, > > I tried this and rootvnode = 0x0, so I am still getting a SIGSEGV. I create > a thread in my "attach" routine via: > > status = kproc_create(sxg_dump_thread, adapter, &adapter->dumpproc, > RFNOWAIT , 0, "sxgdump"); > if (status) { > SXG_DBG_MSG(adapter->dev, "%s[%p], Cannot create dump > thread, status: %d\n", > __func__, adapter, status); > return (status); > } > > Then my thread does: > > static void > sxg_dump_thread(void * arg) > { > adapter_t *adapter = (adapter_t *)arg; > struct filedesc *fdp; > ulong32 index = 0; > > // Set up some file descriptor stuff so we can > // actually open/create a dump file. Kernel > // threads, by design, do not have a valid > // file descriptor table. So, we're gonna > // make this thread point to one! > fdp = curthread->td_proc->p_fd; > FILEDESC_XLOCK(fdp); > fdp->fd_rdir = rootvnode; > vref(rootvnode); <----- SIGSEGV on this line, rootvnode = 0x0 > fdp->fd_jdir = rootvnode; > vref(rootvnode); > fdp->fd_cdir = rootvnode; > vref(rootvnode); > FILEDESC_XUNLOCK(fdp); > for (;;){ > ... > > Sorry if I'm doing something obviously wrong, I'm trying to come up to speed > as quickly as I can. Ah, this could happen if you do this during boot. You can work around that by using an EVENTHANDLER() to hook into the 'mountroot' event and not start your kproc until then. To support loading your driver as a module post-boot, you can instead just start the kproc directly if rootvnode != NULL instead of hooking into 'mountroot'. -- John Baldwin From owner-freebsd-drivers@FreeBSD.ORG Wed Jul 29 23:03:46 2009 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D784106567E for ; Wed, 29 Jul 2009 23:03:46 +0000 (UTC) (envelope-from doug.medz@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by mx1.freebsd.org (Postfix) with ESMTP id D733E8FC19 for ; Wed, 29 Jul 2009 23:03:45 +0000 (UTC) (envelope-from doug.medz@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so295342wfg.7 for ; Wed, 29 Jul 2009 16:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=YTNxsbrIwqTeDrR5c0tJYzV7SOV0IolCDa/cAbBmGkI=; b=w4us0cbY/ZkNVNcbZixnimd5JN8AQVzk/dYtucSOiJUXEAgnyWlUSqftBJ+nO3GnYZ T0i0eH+VC1uDe7YH/mQ3DxtbGiYeaGSVp9zo1EG76QgklsmkXXh2bPltGLGLuACWMYra Iz20Lc2jxJrrjWBeEevMPgsreuvzjq77cuYlY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=EeDYc83VDvHBrXr8Y49Ppm2NZejaFvHJAs/YZlRBWQvw80LMIEPV2E+B54o9vv4Nv+ dzWzygZ6illLbEFMQuKmw+iH1UGKS89QefzihcPHPXR3foCavn7Hn07BV6S2tjAPk2KO +ei3hjMA9FMmUS3jczj5664JVaM4BuaJBVdLg= MIME-Version: 1.0 Received: by 10.142.13.21 with SMTP id 21mr5867wfm.236.1248907377468; Wed, 29 Jul 2009 15:42:57 -0700 (PDT) Date: Wed, 29 Jul 2009 16:42:57 -0600 Message-ID: <4b47ee500907291542w39867dal261be134b376cbaa@mail.gmail.com> From: Douglas Medina To: freebsd-drivers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: envy24ht driver pcm0:record:dsp0.r1: record interrupt timeout, channel dead X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 23:03:46 -0000 Hello, I am trying to get a audiophile 192 to work on FreeBSD 7.2 release for capturing audio. The problem I have been having (I tried to record a small amount of wav using wavrec) is pcm0:record:dsp0.r1: record interrupt timeout, channel dead the wavrec process hangs for about 4 seconds, and then the above message appears in dmesg. devinfo shows that the IRQ 18 is taken by pcm0 it is not shared or anything. Using sysctl i disabled vchans but this made no difference. I also tried on a seperate mainboard with a completely different chipset/vendor etc. I had exactly the same error. Then I tried using Konstantin Dimitrov's patched envy24ht.c envh24ht.h and they compile cleanly, and insert to running kernel without problem, but the exact same issue persisted. Since the computer in question has onboard audio after I exhausted everything I could think of to try, I enabled the onboard audio in the BIOS and tried recording and that worked without problems. I also tried a revolution 7.1 and had the exact same issue. The audiophile 192 in question I have since tested in windows on the exact same hardware, and it works. I would be happy to try any suggestions, patches or whatever. I also have a 1010lt at my disposal. Douglas Medina