From arhimed at gmx.net Thu Jul 2 18:10:38 2009 From: arhimed at gmx.net (Alexandre Fiveg) Date: Thu Jul 2 18:10:45 2009 Subject: how to disable Flow Control on e1000 Message-ID: <20090702174355.124320@gmx.net> Hello, how can I disable Flow-Control on Intel PRO/1000 MT Dual Port Server Adapter (e1000): VendorID:8086, DevID:1079 # uname -v FreeBSD 7.2-RELEASE-p1 #1: Wed Jun 24 19:11:31 CEST 2009 thanx, Alex -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate f?r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 From securityAlerts at a248.boa.aka_mai.com Tue Jul 7 23:48:26 2009 From: securityAlerts at a248.boa.aka_mai.com (Bank of America) Date: Tue Jul 7 23:48:33 2009 Subject: Bank Of America Online Alert : Verify Your Information ID# d885f20cbd1f2d7442e324bc1bcdb689 Message-ID: <200907071920.n67JKMcL083509@web04.triwdata.ch> [mhd_reg_logo.gif] [em_title_red.gif] Dear customer, Protecting the security of our customers and the Bank of America ! network , as a preventative measure, we have temporarily limited access to sensitive account features. To restore your account access, please take the following steps to ensure that your account has not been compromised: After updates : 1.Login to your Bank of America Online Banking account. In case you are not enrolled for Online Banking, you will have to fill in all the required information, including your name and you account number. 2. Review your recent account history for any unauthorized withdrawals or deposits, and check you account profile to make sure not changes have been made. If any unauthorized activity has taken place on your account, report this to Bank of America staff immediately. To get started, please click the link below: ! [1]https://sitekey.bankofamerica.com/sas/signon.do?&detect=3&p=d41d8cd 98f00b204e9800998ecf8427e3265464 _________________________________________________________________ This alert has been sent to you based on your preferences. If you would like to make any changes to your Online Banking Alerts service, please sign in to Online Banking and visit the Manage Alerts section. Because your reply will not be transmitted via secure e-mail, the e-mail address that generated this alert will not accept replies. If you would like to contact Bank of America with questions or comments, please sign in to Online Banking and visit the customer service section. _________________________________________________________________ Bank of America, N.A. Member FDIC. Equal Housing Lender © 2009 Bank of America Corporation. All rights reserved d885f20cbd1f2d7442e324bc1bcdb689 _________________________________________________________________ References 1. http://indietones.net/preview/Onlineid.bankofameri!ca.com/cgi-bini/668d93445065081fa9f2b085cbde792e0d2e0da50a9b4260a03c403a83c60055efdf4a1c/c7206040b068b58cba7fadd6a5b4e341/bofa/ibdIAS/bankofamerica/signon.php?section=signinpage&update=&cookiecheck=yes&destination=nba/signin From dhorvay at 4whitetiger.com Tue Jul 14 20:10:49 2009 From: dhorvay at 4whitetiger.com (David A. Horvay - MRINetwork ) Date: Tue Jul 14 20:11:17 2009 Subject: Atheros wireless device driver developer Message-ID: <4479AB36518147CE80FFE3A1CCE02A92@scmedina17> Hello Everyone, I have an opportunity for a device driver developer with a heavy wireless Atheros background. Please let me know if anyone is interested or might know someone. Please see job description below. Thank you very much.... -Dave Senior Software Engineer with WLAN Device Driver Development Experience The ideal candidate will have several years of communication experience as well as experience programming low level hardware drivers. Requirements: * BSCS or BSEE or relevant experience * 5+ years of experience in development of WLAN device drivers * Fluency in coding and debugging C * Experience with Atheros drivers a plus * Expertise in one or more of these protocols: ? 802.11 ? ATM ? Sonet/SDH ? NDIS ? Bluetooth ? Ethernet, GBit Ethernet * Experience with one or more of the following operating systems: ? MS Windows, WinCE ? Linux ? Embedded RTOS David A. Horvay Sr. Account Executive Technology Solutions Division MRINetwork Ultimate Placements, LLC One Park Centre Drive, Suite 305A TF:877-334-0285 ext. 202 dhorvay@4whitetiger.com http://www.linkedin.com/in/davidhorvay www.MRINetwork.com BUILDING THE HEART OF BUSINESS (TM) Please understand my mission at MRI Ultimate Placements is to partner with those select clients where there is a philosophical fit. My goal has never been to be all things to all people. ?As a client-focused search consultant I evaluate each potential assignment based on alignment with my area of expertise and the timing and urgency of each search.? From cjharrer at comcast.net Fri Jul 17 15:23:36 2009 From: cjharrer at comcast.net (Chris Harrer) Date: Fri Jul 17 15:23:42 2009 Subject: Driver development question Message-ID: <002801ca06f0$b1d42af0$157c80d0$@net> 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! Cheers, Chris From jhb at freebsd.org Mon Jul 20 21:35:58 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Jul 20 21:36:04 2009 Subject: Driver development question In-Reply-To: <002801ca06f0$b1d42af0$157c80d0$@net> References: <002801ca06f0$b1d42af0$157c80d0$@net> Message-ID: <200907200958.49119.jhb@freebsd.org> 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(). -- John Baldwin From sam at errno.com Mon Jul 20 23:17:58 2009 From: sam at errno.com (Sam Leffler) Date: Mon Jul 20 23:19:16 2009 Subject: Driver development question In-Reply-To: <200907200958.49119.jhb@freebsd.org> References: <002801ca06f0$b1d42af0$157c80d0$@net> <200907200958.49119.jhb@freebsd.org> Message-ID: <4A64F200.2060900@errno.com> 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). Sam From marc.loerner at hob.de Tue Jul 21 06:53:01 2009 From: marc.loerner at hob.de (Marc Loerner) Date: Tue Jul 21 06:53:08 2009 Subject: Driver development question In-Reply-To: <4A64F200.2060900@errno.com> References: <002801ca06f0$b1d42af0$157c80d0$@net> <200907200958.49119.jhb@freebsd.org> <4A64F200.2060900@errno.com> Message-ID: <200907210834.21541.marc.loerner@hob.de> 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? Regards, Marc From charrer at alacritech.com Tue Jul 21 11:11:31 2009 From: charrer at alacritech.com (Christopher J. Harrer) Date: Tue Jul 21 11:11:37 2009 Subject: Driver development question In-Reply-To: <200907210834.21541.marc.loerner@hob.de> References: <002801ca06f0$b1d42af0$157c80d0$@net> <200907200958.49119.jhb@freebsd.org> <4A64F200.2060900@errno.com> <200907210834.21541.marc.loerner@hob.de> Message-ID: <081601ca09f1$c1458ed0$43d0ac70$@com> > -----Original Message----- > From: owner-freebsd-drivers@freebsd.org [mailto:owner-freebsd- > drivers@freebsd.org] On Behalf Of Marc Loerner > Sent: Tuesday, July 21, 2009 2:34 AM > To: freebsd-drivers@freebsd.org > Subject: Re: Driver development question > > 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? > > Regards, > Marc Thanks for the suggestions everyone, I will be investigating more today. I appreciate all the pointers! Cheers, Chris From jhb at freebsd.org Tue Jul 21 21:43:53 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Jul 21 21:43:59 2009 Subject: Driver development question In-Reply-To: <200907210834.21541.marc.loerner@hob.de> References: <002801ca06f0$b1d42af0$157c80d0$@net> <4A64F200.2060900@errno.com> <200907210834.21541.marc.loerner@hob.de> Message-ID: <200907211743.12667.jhb@freebsd.org> 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. -- John Baldwin From alfred at freebsd.org Wed Jul 22 00:24:40 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Wed Jul 22 00:24:46 2009 Subject: Driver development question In-Reply-To: <200907211743.12667.jhb@freebsd.org> References: <002801ca06f0$b1d42af0$157c80d0$@net> <4A64F200.2060900@errno.com> <200907210834.21541.marc.loerner@hob.de> <200907211743.12667.jhb@freebsd.org> Message-ID: <20090722000713.GZ49724@elvis.mu.org> * 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. -- - Alfred Perlstein VMOA #5191, 03 vmax, 92 gs500, ch250 - FreeBSD From sam at errno.com Wed Jul 22 00:34:33 2009 From: sam at errno.com (Sam Leffler) Date: Wed Jul 22 00:34:41 2009 Subject: Driver development question In-Reply-To: <200907210834.21541.marc.loerner@hob.de> References: <002801ca06f0$b1d42af0$157c80d0$@net> <200907200958.49119.jhb@freebsd.org> <4A64F200.2060900@errno.com> <200907210834.21541.marc.loerner@hob.de> Message-ID: <4A665E98.2060800@errno.com> 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? These require a process context. alq is designed for exactly what the OP wants. The writes are non-blocking and can be done from interrupt context. The only (current) limitation is records must be fixed size but that's easy to deal with. I use alq to trace register r/w operations in a driver and it works great (low overhead so doesn't noticeably affect real-time operation). In fact it works so well that I ported the code to linux (you can find it in the madwifi code base). Sam From marc.loerner at hob.de Wed Jul 22 07:03:01 2009 From: marc.loerner at hob.de (Marc Loerner) Date: Wed Jul 22 07:03:08 2009 Subject: Driver development question In-Reply-To: <20090722000713.GZ49724@elvis.mu.org> References: <002801ca06f0$b1d42af0$157c80d0$@net> <200907211743.12667.jhb@freebsd.org> <20090722000713.GZ49724@elvis.mu.org> Message-ID: <200907220837.49615.marc.loerner@hob.de> Am Mittwoch 22 Juli 2009 02:07:13 schrieb Alfred Perlstein: > * 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. So when action on a "pseudo" driver is requested via IOCTL from the same userspace-thread the above kern_* functions can be used for file-io? From jhb at freebsd.org Wed Jul 22 13:21:06 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Jul 22 13:21:12 2009 Subject: Driver development question In-Reply-To: <200907220837.49615.marc.loerner@hob.de> References: <002801ca06f0$b1d42af0$157c80d0$@net> <20090722000713.GZ49724@elvis.mu.org> <200907220837.49615.marc.loerner@hob.de> Message-ID: <200907220758.18327.jhb@freebsd.org> On Wednesday 22 July 2009 2:37:49 am Marc Loerner wrote: > Am Mittwoch 22 Juli 2009 02:07:13 schrieb Alfred Perlstein: > > * 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. > > So when action on a "pseudo" driver is requested via IOCTL from the same > userspace-thread the above kern_* functions can be used for file-io? Possibly. If the userland ioctl gives you an fd then you could invoke kern_read(), etc. I still think doing an actual open (i.e kern_open()) or close in a driver that affects the state of a process is a bad thing. Applications expect that the only file descriptors they have are ones they open. For example, some apps have assumptions about the relative order of fd numbers (at the moment I can only think of regression tests I've written that check for leaked fd's, etc.), though you also have apps that assume if they do 'close(0); open()' then the new fd will be stdin (i.e. fd == 0). If the app were multithreaded and another thread was invoking your ioctl, your icotl handler might claim 0 instead resulting in possible security holes, etc. I really think that sort of thing is best avoided. If an application has already opened a file and passes you an fd you could use kern_read/kern_stat, etc. safely though. However, for your use case (dumping debug info) I think Sam is correct and that ALQ is the best thing for you to use. -- John Baldwin From jhb at freebsd.org Wed Jul 22 13:21:08 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Jul 22 13:21:34 2009 Subject: Driver development question In-Reply-To: <20090722000713.GZ49724@elvis.mu.org> References: <002801ca06f0$b1d42af0$157c80d0$@net> <200907211743.12667.jhb@freebsd.org> <20090722000713.GZ49724@elvis.mu.org> Message-ID: <200907220819.05087.jhb@freebsd.org> 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. -- John Baldwin From alfred at freebsd.org Sat Jul 25 03:56:44 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Sat Jul 25 03:56:51 2009 Subject: Driver development question In-Reply-To: <200907220819.05087.jhb@freebsd.org> References: <002801ca06f0$b1d42af0$157c80d0$@net> <200907211743.12667.jhb@freebsd.org> <20090722000713.GZ49724@elvis.mu.org> <200907220819.05087.jhb@freebsd.org> Message-ID: <20090725035643.GT49724@elvis.mu.org> * John Baldwin [090722 06:21] wrote: > 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. they do when you use an analogue to the old nfsd() syscall mechanism. -- - Alfred Perlstein VMOA #5191, 03 vmax, 92 gs500, ch250 - FreeBSD From cjharrer at comcast.net Wed Jul 29 17:23:48 2009 From: cjharrer at comcast.net (Chris Harrer) Date: Wed Jul 29 17:23:55 2009 Subject: Driver development question In-Reply-To: <20090725035643.GT49724@elvis.mu.org> 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> Message-ID: <000c01ca1071$54991d70$fdcb5850$@net> 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 jhb at freebsd.org Wed Jul 29 17:56:59 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Jul 29 18:00:17 2009 Subject: Driver development question In-Reply-To: <000c01ca1071$54991d70$fdcb5850$@net> References: <002801ca06f0$b1d42af0$157c80d0$@net> <20090725035643.GT49724@elvis.mu.org> <000c01ca1071$54991d70$fdcb5850$@net> Message-ID: <200907291356.51702.jhb@freebsd.org> 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 cjharrer at comcast.net Wed Jul 29 18:02:31 2009 From: cjharrer at comcast.net (Chris Harrer) Date: Wed Jul 29 18:02:41 2009 Subject: Driver development question In-Reply-To: <200907291356.51702.jhb@freebsd.org> References: <002801ca06f0$b1d42af0$157c80d0$@net> <20090725035643.GT49724@elvis.mu.org> <000c01ca1071$54991d70$fdcb5850$@net> <200907291356.51702.jhb@freebsd.org> Message-ID: <000d01ca1076$bdf58510$39e08f30$@net> >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 attilio at freebsd.org Wed Jul 29 18:04:07 2009 From: attilio at freebsd.org (Attilio Rao) Date: Wed Jul 29 18:04:14 2009 Subject: Driver development question 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> Message-ID: <3bbf2fe10907291032v6cb917aao34e4d40b6a4daa26@mail.gmail.com> 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 cjharrer at comcast.net Wed Jul 29 18:51:07 2009 From: cjharrer at comcast.net (Chris Harrer) Date: Wed Jul 29 18:51:13 2009 Subject: Driver development question References: <002801ca06f0$b1d42af0$157c80d0$@net> <20090725035643.GT49724@elvis.mu.org> <000c01ca1071$54991d70$fdcb5850$@net> <200907291356.51702.jhb@freebsd.org> Message-ID: <000e01ca107d$87a6ea60$96f4bf20$@net> >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 cjharrer at comcast.net Wed Jul 29 19:39:08 2009 From: cjharrer at comcast.net (Chris Harrer) Date: Wed Jul 29 19:39:14 2009 Subject: Driver development question References: <002801ca06f0$b1d42af0$157c80d0$@net> <20090725035643.GT49724@elvis.mu.org> <000c01ca1071$54991d70$fdcb5850$@net> <200907291356.51702.jhb@freebsd.org> Message-ID: <000f01ca1084$3c20caf0$b46260d0$@net> 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 jhb at freebsd.org Wed Jul 29 19:51:15 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Jul 29 19:51:22 2009 Subject: Driver development question In-Reply-To: <000e01ca107d$87a6ea60$96f4bf20$@net> References: <002801ca06f0$b1d42af0$157c80d0$@net> <200907291356.51702.jhb@freebsd.org> <000e01ca107d$87a6ea60$96f4bf20$@net> Message-ID: <200907291502.30250.jhb@freebsd.org> 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 doug.medz at gmail.com Wed Jul 29 23:03:46 2009 From: doug.medz at gmail.com (Douglas Medina) Date: Wed Jul 29 23:03:53 2009 Subject: envy24ht driver pcm0:record:dsp0.r1: record interrupt timeout, channel dead Message-ID: <4b47ee500907291542w39867dal261be134b376cbaa@mail.gmail.com> 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