From jdp at elvis.rowan.edu Mon Nov 3 16:30:43 2008 From: jdp at elvis.rowan.edu (Joe Pellegrino) Date: Mon Nov 3 16:30:49 2008 Subject: Basic Driver Development Questions. Message-ID: I am trying to develop a small kernel module and I wanted to ask some questions about implementation. First, there is a component of Linux, called netlink, which permits IPC communication between a userspace app and kernel module using sockets. Is there a FreeBSD equivalent? I know you can do this with IOCTL and perhaps through proc but I would prefer using a technique similar to netlink. Toward that I am looking at netgraph (ng_socket) but have run into some trouble mostly related to inexperience with netgraph. So basically: 1. Is there something similar to netlink? 2. Would that be NetGraph? 3. If not what is it? I do have further questions depending on how these are answered. Thanks for your help. :) ---jdp From alfred at freebsd.org Tue Nov 4 07:50:35 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue Nov 4 07:50:41 2008 Subject: Basic Driver Development Questions. In-Reply-To: References: Message-ID: <20081104155035.GS60438@elvis.mu.org> * Joe Pellegrino [081103 16:30] wrote: > I am trying to develop a small kernel module and I wanted to ask some > questions about implementation. First, there is a component of Linux, > called netlink, which permits IPC communication between a userspace app > and kernel module using sockets. Is there a FreeBSD equivalent? I know you > can do this with IOCTL and perhaps through proc but I would prefer using a > technique similar to netlink. > > Toward that I am looking at netgraph (ng_socket) but have run into some > trouble mostly related to inexperience with netgraph. So basically: > > 1. Is there something similar to netlink? > > 2. Would that be NetGraph? > > 3. If not what is it? > > I do have further questions depending on how these are answered. Thanks > for your help. :) Hey Joe, can you give a link to us that explains what "netlink" is and how to use it? examples and such? thank you, -- - Alfred Perlstein From ndenev at gmail.com Tue Nov 4 08:26:45 2008 From: ndenev at gmail.com (Nikolay Denev) Date: Tue Nov 4 08:26:51 2008 Subject: Basic Driver Development Questions. In-Reply-To: <20081104155035.GS60438@elvis.mu.org> References: <20081104155035.GS60438@elvis.mu.org> Message-ID: <19FD5239-C9C8-4F2A-A320-D58F8002CE42@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4 Nov, 2008, at 17:50 , Alfred Perlstein wrote: > * Joe Pellegrino [081103 16:30] wrote: >> I am trying to develop a small kernel module and I wanted to ask some >> questions about implementation. First, there is a component of Linux, >> called netlink, which permits IPC communication between a userspace >> app >> and kernel module using sockets. Is there a FreeBSD equivalent? I >> know you >> can do this with IOCTL and perhaps through proc but I would prefer >> using a >> technique similar to netlink. >> >> Toward that I am looking at netgraph (ng_socket) but have run into >> some >> trouble mostly related to inexperience with netgraph. So basically: >> >> 1. Is there something similar to netlink? >> >> 2. Would that be NetGraph? >> >> 3. If not what is it? >> >> I do have further questions depending on how these are answered. >> Thanks >> for your help. :) > > Hey Joe, can you give a link to us that explains what "netlink" is > and how to use it? examples and such? > > thank you, > -- > - Alfred Perlstein > _______________________________________________ > freebsd-drivers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-drivers > To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org > " Hi, http://www.ietf.org/rfc/rfc3549.txt http://en.wikipedia.org/wiki/Netlink http://www.linuxjournal.com/article/7356 (this one is a bit dated, but has some examples) - -- Regards, Nikolay Denev -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAkkQd78ACgkQHNAJ/fLbfrkhfQCgu0EM6qM3qQM7PhOf6n8tUX+3 ewoAnAmADfsS3Mf9Cnq7ssbXPYf5E/ZE =Sz8R -----END PGP SIGNATURE----- From jdp at elvis.rowan.edu Tue Nov 4 09:15:20 2008 From: jdp at elvis.rowan.edu (Joe Pellegrino) Date: Tue Nov 4 09:15:30 2008 Subject: Basic Driver Development Questions. In-Reply-To: <19FD5239-C9C8-4F2A-A320-D58F8002CE42@gmail.com> References: <20081104155035.GS60438@elvis.mu.org> <19FD5239-C9C8-4F2A-A320-D58F8002CE42@gmail.com> Message-ID: i was just going to post those myself. Funny thing is, according to the article, this has been available since the 2.2 kernel version but it isn't in the device driver development book (oreilly) In any case I am looking for a similar component for FreeBSD. And if there isn't a precise match what would the closest way be to get that functionality? ---jdp On Tue, 4 Nov 2008, Nikolay Denev wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 4 Nov, 2008, at 17:50 , Alfred Perlstein wrote: > >> * Joe Pellegrino [081103 16:30] wrote: >>> I am trying to develop a small kernel module and I wanted to ask some >>> questions about implementation. First, there is a component of Linux, >>> called netlink, which permits IPC communication between a userspace app >>> and kernel module using sockets. Is there a FreeBSD equivalent? I know you >>> can do this with IOCTL and perhaps through proc but I would prefer using a >>> technique similar to netlink. >>> >>> Toward that I am looking at netgraph (ng_socket) but have run into some >>> trouble mostly related to inexperience with netgraph. So basically: >>> >>> 1. Is there something similar to netlink? >>> >>> 2. Would that be NetGraph? >>> >>> 3. If not what is it? >>> >>> I do have further questions depending on how these are answered. Thanks >>> for your help. :) >> >> Hey Joe, can you give a link to us that explains what "netlink" is >> and how to use it? examples and such? >> >> thank you, >> -- >> - Alfred Perlstein >> _______________________________________________ >> freebsd-drivers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-drivers >> To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org" > > > Hi, > > http://www.ietf.org/rfc/rfc3549.txt > > http://en.wikipedia.org/wiki/Netlink > > http://www.linuxjournal.com/article/7356 (this one is a bit dated, but has > some examples) > > > - -- > Regards, > Nikolay Denev > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (Darwin) > > iEYEARECAAYFAkkQd78ACgkQHNAJ/fLbfrkhfQCgu0EM6qM3qQM7PhOf6n8tUX+3 > ewoAnAmADfsS3Mf9Cnq7ssbXPYf5E/ZE > =Sz8R > -----END PGP SIGNATURE----- From imp at bsdimp.com Tue Nov 4 10:02:27 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Nov 4 10:02:33 2008 Subject: Basic Driver Development Questions. In-Reply-To: References: <20081104155035.GS60438@elvis.mu.org> <19FD5239-C9C8-4F2A-A320-D58F8002CE42@gmail.com> Message-ID: <20081104.110056.-1350515023.imp@bsdimp.com> In message: Joe Pellegrino writes: : i was just going to post those myself. Funny thing is, according to the : article, this has been available since the 2.2 kernel version but it isn't : in the device driver development book (oreilly) In any case I am looking : for a similar component for FreeBSD. And if there isn't a precise match : what would the closest way be to get that functionality? Can you post a pointer to the article? Warner : ---jdp : : On Tue, 4 Nov 2008, Nikolay Denev wrote: : : > -----BEGIN PGP SIGNED MESSAGE----- : > Hash: SHA1 : > : > : > On 4 Nov, 2008, at 17:50 , Alfred Perlstein wrote: : > : >> * Joe Pellegrino [081103 16:30] wrote: : >>> I am trying to develop a small kernel module and I wanted to ask some : >>> questions about implementation. First, there is a component of Linux, : >>> called netlink, which permits IPC communication between a userspace app : >>> and kernel module using sockets. Is there a FreeBSD equivalent? I know you : >>> can do this with IOCTL and perhaps through proc but I would prefer using a : >>> technique similar to netlink. : >>> : >>> Toward that I am looking at netgraph (ng_socket) but have run into some : >>> trouble mostly related to inexperience with netgraph. So basically: : >>> : >>> 1. Is there something similar to netlink? : >>> : >>> 2. Would that be NetGraph? : >>> : >>> 3. If not what is it? : >>> : >>> I do have further questions depending on how these are answered. Thanks : >>> for your help. :) : >> : >> Hey Joe, can you give a link to us that explains what "netlink" is : >> and how to use it? examples and such? : >> : >> thank you, : >> -- : >> - Alfred Perlstein : >> _______________________________________________ : >> freebsd-drivers@freebsd.org mailing list : >> http://lists.freebsd.org/mailman/listinfo/freebsd-drivers : >> To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org" : > : > : > Hi, : > : > http://www.ietf.org/rfc/rfc3549.txt : > : > http://en.wikipedia.org/wiki/Netlink : > : > http://www.linuxjournal.com/article/7356 (this one is a bit dated, but has : > some examples) : > : > : > - -- : > Regards, : > Nikolay Denev : > : > : > : > : > -----BEGIN PGP SIGNATURE----- : > Version: GnuPG v2.0.9 (Darwin) : > : > iEYEARECAAYFAkkQd78ACgkQHNAJ/fLbfrkhfQCgu0EM6qM3qQM7PhOf6n8tUX+3 : > ewoAnAmADfsS3Mf9Cnq7ssbXPYf5E/ZE : > =Sz8R : > -----END PGP SIGNATURE----- : _______________________________________________ : freebsd-drivers@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-drivers : To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org" : : From jdp at elvis.rowan.edu Tue Nov 4 14:38:41 2008 From: jdp at elvis.rowan.edu (Joe Pellegrino) Date: Tue Nov 4 14:38:47 2008 Subject: Basic Driver Development Questions. In-Reply-To: <20081104.110056.-1350515023.imp@bsdimp.com> References: <20081104155035.GS60438@elvis.mu.org> <19FD5239-C9C8-4F2A-A320-D58F8002CE42@gmail.com> <20081104.110056.-1350515023.imp@bsdimp.com> Message-ID: > Can you post a pointer to the article? > > Warner > > http://www.ietf.org/rfc/rfc3549.txt http://en.wikipedia.org/wiki/Netlink http://www.linuxjournal.com/article/7356 From imp at bsdimp.com Tue Nov 4 15:35:27 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Nov 4 15:35:34 2008 Subject: Basic Driver Development Questions. In-Reply-To: References: <20081104.110056.-1350515023.imp@bsdimp.com> Message-ID: <20081104.163537.2040711491.imp@bsdimp.com> In message: Joe Pellegrino writes: : > Can you post a pointer to the article? : > : > Warner : > : > : : http://www.ietf.org/rfc/rfc3549.txt : : http://en.wikipedia.org/wiki/Netlink : : http://www.linuxjournal.com/article/7356 So this is the stuff that replaces routing sockets, eh? Warner From jdp at elvis.rowan.edu Tue Nov 4 18:38:43 2008 From: jdp at elvis.rowan.edu (Joe Pellegrino) Date: Tue Nov 4 18:38:50 2008 Subject: Basic Driver Development Questions. In-Reply-To: <20081104.163537.2040711491.imp@bsdimp.com> References: <20081104.110056.-1350515023.imp@bsdimp.com> <20081104.163537.2040711491.imp@bsdimp.com> Message-ID: On Tue, 4 Nov 2008, M. Warner Losh wrote: > In message: > Joe Pellegrino writes: > > So this is the stuff that replaces routing sockets, eh? > I am not really sure but it looks like it could. I got the impression from the article that they were using it to replace IOCTLs. ---jdp From imp at bsdimp.com Tue Nov 4 20:08:09 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Nov 4 20:08:16 2008 Subject: Basic Driver Development Questions. In-Reply-To: References: <20081104.163537.2040711491.imp@bsdimp.com> Message-ID: <20081104.210723.-202616185.imp@bsdimp.com> In message: Joe Pellegrino writes: : On Tue, 4 Nov 2008, M. Warner Losh wrote: : : > In message: : > Joe Pellegrino writes: : > : > So this is the stuff that replaces routing sockets, eh? : > : : I am not really sure but it looks like it could. I got the impression from : the article that they were using it to replace IOCTLs. It is for a lot more than just that, since it does multicast, etc. Warner From jdp at elvis.rowan.edu Tue Nov 4 20:56:45 2008 From: jdp at elvis.rowan.edu (Joe Pellegrino) Date: Tue Nov 4 20:56:51 2008 Subject: Basic Driver Development Questions. In-Reply-To: <20081104.210723.-202616185.imp@bsdimp.com> References: <20081104.163537.2040711491.imp@bsdimp.com> <20081104.210723.-202616185.imp@bsdimp.com> Message-ID: So again the question is what would be the parallel in FreeBSD? An IPC component where I can register a handler on both sides, ect... ---jdp On Tue, 4 Nov 2008, M. Warner Losh wrote: > In message: > Joe Pellegrino writes: > : On Tue, 4 Nov 2008, M. Warner Losh wrote: > : > : > In message: > : > Joe Pellegrino writes: > : > > : > So this is the stuff that replaces routing sockets, eh? > : > > : > : I am not really sure but it looks like it could. I got the impression from > : the article that they were using it to replace IOCTLs. > > It is for a lot more than just that, since it does multicast, etc. > > Warner > From jasonh at borisch.com Wed Nov 5 15:06:40 2008 From: jasonh at borisch.com (Jason J. Hellenthal) Date: Wed Nov 5 15:06:52 2008 Subject: ath driver (Linksys WMP110 RangePlus) ar5416 Message-ID: <6AB9DD44-C91B-4F0D-8F5C-168C57D44911@mimectl> Anyone know if the Linksys WMP110 RangePlus support will be added to 7-stable. I would rather use a native driver for this card for more features but the ndis driver seems to be working great for a couple of weeks now with no flaw. This is what the device reports in pciconf. ndis0@pci0:1:8:0: class=0x028000 card=0x00721737 chip=0x0023168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5008 Wireless Network Adapter' I have tried the ath module and it never picked up the card and I don't have to much time to modify or look into this any more than I already have. The driver name from under windows is ar5416.sys. [from Linksys support on cd/disc] If additional information or resources is needed I will be more than willing to provide whatever needed. Thanks in advance... -- J. Hellenthal (892) Aerospace Special Operations Support Borisch Manufacturing Corporation http://www.Borisch.com/ jasonh@Borisch.com "... as we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously." -- Benjamin Franklin P Only print if necessary From alexander.renn at gmail.com Mon Nov 10 00:53:27 2008 From: alexander.renn at gmail.com (Alexander Renn) Date: Mon Nov 10 00:53:33 2008 Subject: NDIS support: /boot/loader.conf vs kldload Message-ID: Hello, I'm running the NDIS driver on WLAN chip 0x431514e4 (Broadcom) and it works only if I load it from /boot/loader.conf. First attempt to load it using kldload succeeds but it does not detect the chip. The second attempt to load the driver using kldload triggers kernel panic. The problem is that the chip becomes unusable after resuming the system from suspend and I cannot use kldload to re-load the driver again (system panics). What is the difference in loading the driver using /boot/loader.conf and using the kldload after the system bootup? I tried to change the dev.ndis sysctls but it did not seem to solve the problem with non-working driver when resumed after suspend. -- Best regards, Alexander Renn From itavy at itavy.com Mon Nov 10 02:31:36 2008 From: itavy at itavy.com (itavy@itavy.com) Date: Mon Nov 10 02:31:44 2008 Subject: Driver for Atheros L1 FastEthernet Message-ID: <1520.86.55.4.142.1226311495.squirrel@www.itavy.com> hi, i have downloaded latest driver for Atheros L1 FastEthernet from http://people.freebsd.org/~yongari/ale/ and when i compile them i receive the following error: if_ale.c:804:37: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, but takes just 7 if_ale.c: In function 'ale_sysctl_node': if_ale.c:803: error: 'SYSCTL_ADD_ULONG' undeclared (first use in this function) if_ale.c:803: error: (Each undeclared identifier is reported only once if_ale.c:803: error: for each funtion it appears in.) if_ale.c:806:53: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, but takes just 7 if_ale.c:808:53: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, but takes just 7 if_ale.c:858:37: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, but takes just 7 if_ale.c:860:53: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, but takes just 7 if_ale.c:862:53: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, but takes just 7 *** Error code 1 can anyone help me about it? Thank you From itavy at itavy.com Mon Nov 10 02:51:03 2008 From: itavy at itavy.com (itavy@itavy.com) Date: Mon Nov 10 02:51:10 2008 Subject: Driver for Atheros L1 FastEthernet In-Reply-To: <20081110103602.GK22162@cdnetworks.co.kr> References: <1520.86.55.4.142.1226311495.squirrel@www.itavy.com> <20081110103602.GK22162@cdnetworks.co.kr> Message-ID: <1815.86.55.4.142.1226314260.squirrel@www.itavy.com> thank you for the fast respone :) i have compiled but now i have another error wehn i try to load it: link_elf: symbol m_collapse undefined Best regards, Octavian Ionescu > On Mon, Nov 10, 2008 at 04:04:55AM -0600, itavy@itavy.com wrote: > > hi, > > > > i have downloaded latest driver for Atheros L1 FastEthernet from > > http://people.freebsd.org/~yongari/ale/ and when i compile them i > receive > > the following error: > > > > if_ale.c:804:37: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, > but > > takes just 7 > > if_ale.c: In function 'ale_sysctl_node': > > if_ale.c:803: error: 'SYSCTL_ADD_ULONG' undeclared (first use in this > > function) > > if_ale.c:803: error: (Each undeclared identifier is reported only once > > if_ale.c:803: error: for each funtion it appears in.) > > if_ale.c:806:53: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, > but > > takes just 7 > > if_ale.c:808:53: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, > but > > takes just 7 > > if_ale.c:858:37: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, > but > > takes just 7 > > if_ale.c:860:53: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, > but > > takes just 7 > > if_ale.c:862:53: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, > but > > takes just 7 > > *** Error code 1 > > > > can anyone help me about it? > > > > It was fixed. Would you try it again after re-fetching the file? > http://people.freebsd.org/~yongari/ale/ale.20081110.tar.gz > > -- > Regards, > Pyun YongHyeon > From pyunyh at gmail.com Mon Nov 10 03:01:08 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Nov 10 03:01:16 2008 Subject: Driver for Atheros L1 FastEthernet In-Reply-To: <1520.86.55.4.142.1226311495.squirrel@www.itavy.com> References: <1520.86.55.4.142.1226311495.squirrel@www.itavy.com> Message-ID: <20081110103602.GK22162@cdnetworks.co.kr> On Mon, Nov 10, 2008 at 04:04:55AM -0600, itavy@itavy.com wrote: > hi, > > i have downloaded latest driver for Atheros L1 FastEthernet from > http://people.freebsd.org/~yongari/ale/ and when i compile them i receive > the following error: > > if_ale.c:804:37: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, but > takes just 7 > if_ale.c: In function 'ale_sysctl_node': > if_ale.c:803: error: 'SYSCTL_ADD_ULONG' undeclared (first use in this > function) > if_ale.c:803: error: (Each undeclared identifier is reported only once > if_ale.c:803: error: for each funtion it appears in.) > if_ale.c:806:53: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, but > takes just 7 > if_ale.c:808:53: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, but > takes just 7 > if_ale.c:858:37: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, but > takes just 7 > if_ale.c:860:53: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, but > takes just 7 > if_ale.c:862:53: error: macro "SYSCTL_ADD_ULONG" passed 8 arguments, but > takes just 7 > *** Error code 1 > > can anyone help me about it? > It was fixed. Would you try it again after re-fetching the file? http://people.freebsd.org/~yongari/ale/ale.20081110.tar.gz -- Regards, Pyun YongHyeon From pyunyh at gmail.com Mon Nov 10 03:08:27 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Nov 10 03:10:13 2008 Subject: Driver for Atheros L1 FastEthernet In-Reply-To: <1815.86.55.4.142.1226314260.squirrel@www.itavy.com> References: <1520.86.55.4.142.1226311495.squirrel@www.itavy.com> <20081110103602.GK22162@cdnetworks.co.kr> <1815.86.55.4.142.1226314260.squirrel@www.itavy.com> Message-ID: <20081110110624.GL22162@cdnetworks.co.kr> On Mon, Nov 10, 2008 at 04:51:00AM -0600, itavy@itavy.com wrote: > thank you for the fast respone :) > > i have compiled but now i have another error wehn i try to load it: > > link_elf: symbol m_collapse undefined Hmm, I guess you're not using latest stable/7. Please find m_collaspe() in if_ale.c(line number 1686) and change it from the following. from: m = m_collapse(*m_head, M_DONTWAIT, ALE_MAXTXSEGS); to: m = m_defrag(*m_head, M_DONTWAIT); And build ale(4) again. -- Regards, Pyun YongHyeon From itavy at itavy.com Mon Nov 10 03:17:06 2008 From: itavy at itavy.com (itavy@itavy.com) Date: Mon Nov 10 03:17:13 2008 Subject: Driver for Atheros L1 FastEthernet In-Reply-To: <20081110110624.GL22162@cdnetworks.co.kr> References: <1520.86.55.4.142.1226311495.squirrel@www.itavy.com> <20081110103602.GK22162@cdnetworks.co.kr> <1815.86.55.4.142.1226314260.squirrel@www.itavy.com> <20081110110624.GL22162@cdnetworks.co.kr> Message-ID: <1973.86.55.4.142.1226315822.squirrel@www.itavy.com> i have updated to RELENG_7 before i have compiled the driver wich is working now:) thank you, Best regards, Octavian Ionescu > On Mon, Nov 10, 2008 at 04:51:00AM -0600, itavy@itavy.com wrote: > > thank you for the fast respone :) > > > > i have compiled but now i have another error wehn i try to load it: > > > > link_elf: symbol m_collapse undefined > > Hmm, I guess you're not using latest stable/7. > Please find m_collaspe() in if_ale.c(line number 1686) and change > it from the following. > from: > m = m_collapse(*m_head, M_DONTWAIT, ALE_MAXTXSEGS); > > to: > m = m_defrag(*m_head, M_DONTWAIT); > > And build ale(4) again. > -- > Regards, > Pyun YongHyeon > From pyunyh at gmail.com Mon Nov 10 03:22:13 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Nov 10 03:22:19 2008 Subject: Driver for Atheros L1 FastEthernet In-Reply-To: <1973.86.55.4.142.1226315822.squirrel@www.itavy.com> References: <1520.86.55.4.142.1226311495.squirrel@www.itavy.com> <20081110103602.GK22162@cdnetworks.co.kr> <1815.86.55.4.142.1226314260.squirrel@www.itavy.com> <20081110110624.GL22162@cdnetworks.co.kr> <1973.86.55.4.142.1226315822.squirrel@www.itavy.com> Message-ID: <20081110112003.GM22162@cdnetworks.co.kr> On Mon, Nov 10, 2008 at 05:17:02AM -0600, itavy@itavy.com wrote: > i have updated to RELENG_7 before i have compiled the driver wich is > working now:) > Ok. Would you show me console output for ale(4)? ale(4) may have printed a few lines of messages related with your hardware. Since you said it's fastethernt I'd like to know what was printed there. > thank you, > > Best regards, > Octavian Ionescu > > On Mon, Nov 10, 2008 at 04:51:00AM -0600, itavy@itavy.com wrote: > > > thank you for the fast respone :) > > > > > > i have compiled but now i have another error wehn i try to load it: > > > > > > link_elf: symbol m_collapse undefined > > > > Hmm, I guess you're not using latest stable/7. > > Please find m_collaspe() in if_ale.c(line number 1686) and change > > it from the following. > > from: > > m = m_collapse(*m_head, M_DONTWAIT, ALE_MAXTXSEGS); > > > > to: > > m = m_defrag(*m_head, M_DONTWAIT); > > > > And build ale(4) again. > > -- > > Regards, > > Pyun YongHyeon > > > > -- Regards, Pyun YongHyeon From itavy at itavy.com Wed Nov 12 14:31:22 2008 From: itavy at itavy.com (Octavian Ionescu) Date: Wed Nov 12 14:31:28 2008 Subject: Driver for Atheros Wireless LAN Message-ID: <491B5931.1030801@itavy.com> hi, i have folowed the instructions on http://wiki.freebsd.org/AsusEee for setting up the drivers for an Asus EEE PC 1000H and i have managed to set up at least the wired ethernet with the help of Pyun YongHyeon. but for the wireless ethernet i can't see any wireless interface up. i see the message wich i shall see in dmesg but i cant see the interface : # dmesg | grep ath ath_hal: 0.10.5.10 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) am i doing something wrong ? here is the result of pciconf # pciconf -v -l hostb0@pci0:0:0:0: class=0x060000 card=0x83401043 chip=0x27ac8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI vgapci0@pci0:0:2:0: class=0x030000 card=0x83401043 chip=0x27ae8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0x83401043 chip=0x27a68086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 945GM/GU Express Integrated Graphics Controller' class = display pcm0@pci0:0:27:0: class=0x040300 card=0x831a1043 chip=0x27d88086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) High Definition Audio' class = multimedia pcib1@pci0:0:28:0: class=0x060400 card=0x830f1043 chip=0x27d08086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib2@pci0:0:28:1: class=0x060400 card=0x830f1043 chip=0x27d28086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:3: class=0x060400 card=0x830f1043 chip=0x27d68086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI uhci0@pci0:0:29:0: class=0x0c0300 card=0x830f1043 chip=0x27c88086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci1@pci0:0:29:1: class=0x0c0300 card=0x830f1043 chip=0x27c98086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci2@pci0:0:29:2: class=0x0c0300 card=0x830f1043 chip=0x27ca8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci3@pci0:0:29:3: class=0x0c0300 card=0x830f1043 chip=0x27cb8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB ehci0@pci0:0:29:7: class=0x0c0320 card=0x830f1043 chip=0x27cc8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB pcib4@pci0:0:30:0: class=0x060401 card=0x830f1043 chip=0x24488086 rev=0xe2 hdr=0x01 vendor = 'Intel Corporation' device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x830f1043 chip=0x27b98086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801GBM (ICH7-M) LPC Interface Controller' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:2: class=0x010180 card=0x830f1043 chip=0x27c48086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controller' class = mass storage subclass = ATA ale0@pci0:3:0:0: class=0x020000 card=0x83241043 chip=0x10261969 rev=0xb0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' class = network subclass = ethernet none0@pci0:1:0:0: class=0x028000 card=0x27901814 chip=0x07811814 rev=0x00 hdr=0x00 vendor = 'Ralink Technology, Corp' class = network Thank you, Octavian Ionescu From volker at vwsoft.com Wed Nov 12 15:22:25 2008 From: volker at vwsoft.com (Volker) Date: Wed Nov 12 15:22:32 2008 Subject: Driver for Atheros Wireless LAN In-Reply-To: <491B5931.1030801@itavy.com> References: <491B5931.1030801@itavy.com> Message-ID: <491B5D6F.1030003@vwsoft.com> On 11/12/08 23:31, Octavian Ionescu wrote: > hi, > > i have folowed the instructions on http://wiki.freebsd.org/AsusEee for > setting up the drivers for an Asus EEE PC 1000H and i have managed to > set up at least the wired ethernet with the help of Pyun YongHyeon. but > for the wireless ethernet i can't see any wireless interface up. i see > the message wich i shall see in dmesg but i cant see the interface : > > # dmesg | grep ath > ath_hal: 0.10.5.10 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, > RF2413, RF5413, RF2133, RF2425, RF2417) > > am i doing something wrong ? > > here is the result of pciconf > > # pciconf -v -l > hostb0@pci0:0:0:0: class=0x060000 card=0x83401043 chip=0x27ac8086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > vgapci0@pci0:0:2:0: class=0x030000 card=0x83401043 chip=0x27ae8086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > class = display > subclass = VGA > vgapci1@pci0:0:2:1: class=0x038000 card=0x83401043 chip=0x27a68086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Mobile 945GM/GU Express Integrated Graphics Controller' > class = display > pcm0@pci0:0:27:0: class=0x040300 card=0x831a1043 chip=0x27d88086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) High Definition Audio' > class = multimedia > pcib1@pci0:0:28:0: class=0x060400 card=0x830f1043 chip=0x27d08086 > rev=0x02 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) PCIe Root Port' > class = bridge > subclass = PCI-PCI > pcib2@pci0:0:28:1: class=0x060400 card=0x830f1043 chip=0x27d28086 > rev=0x02 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) PCIe Root Port' > class = bridge > subclass = PCI-PCI > pcib3@pci0:0:28:3: class=0x060400 card=0x830f1043 chip=0x27d68086 > rev=0x02 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) PCIe Root Port' > class = bridge > subclass = PCI-PCI > uhci0@pci0:0:29:0: class=0x0c0300 card=0x830f1043 chip=0x27c88086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > uhci1@pci0:0:29:1: class=0x0c0300 card=0x830f1043 chip=0x27c98086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > uhci2@pci0:0:29:2: class=0x0c0300 card=0x830f1043 chip=0x27ca8086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > uhci3@pci0:0:29:3: class=0x0c0300 card=0x830f1043 chip=0x27cb8086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > ehci0@pci0:0:29:7: class=0x0c0320 card=0x830f1043 chip=0x27cc8086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' > class = serial bus > subclass = USB > pcib4@pci0:0:30:0: class=0x060401 card=0x830f1043 chip=0x24488086 > rev=0xe2 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI > Bridge' > class = bridge > subclass = PCI-PCI > isab0@pci0:0:31:0: class=0x060100 card=0x830f1043 chip=0x27b98086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801GBM (ICH7-M) LPC Interface Controller' > class = bridge > subclass = PCI-ISA > atapci0@pci0:0:31:2: class=0x010180 card=0x830f1043 chip=0x27c48086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage > Controller' > class = mass storage > subclass = ATA > ale0@pci0:3:0:0: class=0x020000 card=0x83241043 chip=0x10261969 > rev=0xb0 hdr=0x00 > vendor = 'Attansic (Now owned by Atheros)' > class = network > subclass = ethernet > none0@pci0:1:0:0: class=0x028000 card=0x27901814 chip=0x07811814 > rev=0x00 hdr=0x00 > vendor = 'Ralink Technology, Corp' > class = network Did you load ral(4)? Your interface is using a ral chipset, not an atheros one. ``kldload if_ral'' /boot/loader.conf: if_ral_load="YES" Whenever asking questions like these, it may be useful to know the FreeBSD version you're using. _If_ we're talking about 7.x or 6.x, your kernel needs a bit tweaking (AFAIK the pciid 0x0781 isn't known by ral). Volker From sam at freebsd.org Wed Nov 12 16:14:10 2008 From: sam at freebsd.org (Sam Leffler) Date: Wed Nov 12 16:14:16 2008 Subject: Driver for Atheros Wireless LAN In-Reply-To: <491B5D6F.1030003@vwsoft.com> References: <491B5931.1030801@itavy.com> <491B5D6F.1030003@vwsoft.com> Message-ID: <491B6A6F.3050007@freebsd.org> Volker wrote: > On 11/12/08 23:31, Octavian Ionescu wrote: > >> hi, >> >> i have folowed the instructions on http://wiki.freebsd.org/AsusEee for >> setting up the drivers for an Asus EEE PC 1000H and i have managed to >> set up at least the wired ethernet with the help of Pyun YongHyeon. but >> for the wireless ethernet i can't see any wireless interface up. i see >> the message wich i shall see in dmesg but i cant see the interface : >> >> # dmesg | grep ath >> ath_hal: 0.10.5.10 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, >> RF2413, RF5413, RF2133, RF2425, RF2417) >> >> am i doing something wrong ? >> >> here is the result of pciconf >> >> # pciconf -v -l >> hostb0@pci0:0:0:0: class=0x060000 card=0x83401043 chip=0x27ac8086 >> rev=0x03 hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> vgapci0@pci0:0:2:0: class=0x030000 card=0x83401043 chip=0x27ae8086 >> rev=0x03 hdr=0x00 >> vendor = 'Intel Corporation' >> class = display >> subclass = VGA >> vgapci1@pci0:0:2:1: class=0x038000 card=0x83401043 chip=0x27a68086 >> rev=0x03 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Mobile 945GM/GU Express Integrated Graphics Controller' >> class = display >> pcm0@pci0:0:27:0: class=0x040300 card=0x831a1043 chip=0x27d88086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) High Definition Audio' >> class = multimedia >> pcib1@pci0:0:28:0: class=0x060400 card=0x830f1043 chip=0x27d08086 >> rev=0x02 hdr=0x01 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) PCIe Root Port' >> class = bridge >> subclass = PCI-PCI >> pcib2@pci0:0:28:1: class=0x060400 card=0x830f1043 chip=0x27d28086 >> rev=0x02 hdr=0x01 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) PCIe Root Port' >> class = bridge >> subclass = PCI-PCI >> pcib3@pci0:0:28:3: class=0x060400 card=0x830f1043 chip=0x27d68086 >> rev=0x02 hdr=0x01 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) PCIe Root Port' >> class = bridge >> subclass = PCI-PCI >> uhci0@pci0:0:29:0: class=0x0c0300 card=0x830f1043 chip=0x27c88086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) USB Universal Host Controller' >> class = serial bus >> subclass = USB >> uhci1@pci0:0:29:1: class=0x0c0300 card=0x830f1043 chip=0x27c98086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) USB Universal Host Controller' >> class = serial bus >> subclass = USB >> uhci2@pci0:0:29:2: class=0x0c0300 card=0x830f1043 chip=0x27ca8086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) USB Universal Host Controller' >> class = serial bus >> subclass = USB >> uhci3@pci0:0:29:3: class=0x0c0300 card=0x830f1043 chip=0x27cb8086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) USB Universal Host Controller' >> class = serial bus >> subclass = USB >> ehci0@pci0:0:29:7: class=0x0c0320 card=0x830f1043 chip=0x27cc8086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' >> class = serial bus >> subclass = USB >> pcib4@pci0:0:30:0: class=0x060401 card=0x830f1043 chip=0x24488086 >> rev=0xe2 hdr=0x01 >> vendor = 'Intel Corporation' >> device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI >> Bridge' >> class = bridge >> subclass = PCI-PCI >> isab0@pci0:0:31:0: class=0x060100 card=0x830f1043 chip=0x27b98086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801GBM (ICH7-M) LPC Interface Controller' >> class = bridge >> subclass = PCI-ISA >> atapci0@pci0:0:31:2: class=0x010180 card=0x830f1043 chip=0x27c48086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage >> Controller' >> class = mass storage >> subclass = ATA >> ale0@pci0:3:0:0: class=0x020000 card=0x83241043 chip=0x10261969 >> rev=0xb0 hdr=0x00 >> vendor = 'Attansic (Now owned by Atheros)' >> class = network >> subclass = ethernet >> none0@pci0:1:0:0: class=0x028000 card=0x27901814 chip=0x07811814 >> rev=0x00 hdr=0x00 >> vendor = 'Ralink Technology, Corp' >> class = network >> > > Did you load ral(4)? Your interface is using a ral chipset, not an > atheros one. > > ``kldload if_ral'' > /boot/loader.conf: if_ral_load="YES" > > Whenever asking questions like these, it may be useful to know the > FreeBSD version you're using. > > _If_ we're talking about 7.x or 6.x, your kernel needs a bit tweaking > (AFAIK the pciid 0x0781 isn't known by ral). > 0x781 is an RT2790; not supported by any driver in the tree. Andrew was working on support but I know he hasn't looked at wireless in a while. Sam From itavy at itavy.com Sat Nov 15 11:54:37 2008 From: itavy at itavy.com (Octavian Ionescu) Date: Sat Nov 15 11:54:43 2008 Subject: Driver for Atheros Wireless LAN In-Reply-To: <491B6A6F.3050007@freebsd.org> References: <491B5931.1030801@itavy.com> <491B5D6F.1030003@vwsoft.com> <491B6A6F.3050007@freebsd.org> Message-ID: <491F28F5.50906@itavy.com> hi, i have upgraded to head but still the same issues. the version is: # uname -a FreeBSD 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Fri Nov 14 21:39:23 UTC 2008 root@:/usr/obj/var/src/head/sys/ITAVYEEE2 i386 as for loading driver ral: #kldload if_ral module_register: module cardbus/ral already exists! Module cardbus/ral failed to register: 17 module_register: module pci/ral already exists! Module pci/ral failed to register: 17 i saw something wich Volker wrote wich i shall give it a try, what tweaking is need to be made ? Best regards, Octavian Ionescu Sam Leffler wrote: > Volker wrote: >> On 11/12/08 23:31, Octavian Ionescu wrote: >> >>> hi, >>> >>> i have folowed the instructions on http://wiki.freebsd.org/AsusEee for >>> setting up the drivers for an Asus EEE PC 1000H and i have managed to >>> set up at least the wired ethernet with the help of Pyun YongHyeon. >>> but >>> for the wireless ethernet i can't see any wireless interface up. i see >>> the message wich i shall see in dmesg but i cant see the interface : >>> >>> # dmesg | grep ath >>> ath_hal: 0.10.5.10 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, >>> RF2413, RF5413, RF2133, RF2425, RF2417) >>> >>> am i doing something wrong ? >>> >>> here is the result of pciconf >>> >>> # pciconf -v -l >>> hostb0@pci0:0:0:0: class=0x060000 card=0x83401043 chip=0x27ac8086 >>> rev=0x03 hdr=0x00 >>> vendor = 'Intel Corporation' >>> class = bridge >>> subclass = HOST-PCI >>> vgapci0@pci0:0:2:0: class=0x030000 card=0x83401043 chip=0x27ae8086 >>> rev=0x03 hdr=0x00 >>> vendor = 'Intel Corporation' >>> class = display >>> subclass = VGA >>> vgapci1@pci0:0:2:1: class=0x038000 card=0x83401043 chip=0x27a68086 >>> rev=0x03 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = 'Mobile 945GM/GU Express Integrated Graphics >>> Controller' >>> class = display >>> pcm0@pci0:0:27:0: class=0x040300 card=0x831a1043 chip=0x27d88086 >>> rev=0x02 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82801G (ICH7 Family) High Definition Audio' >>> class = multimedia >>> pcib1@pci0:0:28:0: class=0x060400 card=0x830f1043 chip=0x27d08086 >>> rev=0x02 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = '82801G (ICH7 Family) PCIe Root Port' >>> class = bridge >>> subclass = PCI-PCI >>> pcib2@pci0:0:28:1: class=0x060400 card=0x830f1043 chip=0x27d28086 >>> rev=0x02 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = '82801G (ICH7 Family) PCIe Root Port' >>> class = bridge >>> subclass = PCI-PCI >>> pcib3@pci0:0:28:3: class=0x060400 card=0x830f1043 chip=0x27d68086 >>> rev=0x02 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = '82801G (ICH7 Family) PCIe Root Port' >>> class = bridge >>> subclass = PCI-PCI >>> uhci0@pci0:0:29:0: class=0x0c0300 card=0x830f1043 chip=0x27c88086 >>> rev=0x02 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82801G (ICH7 Family) USB Universal Host Controller' >>> class = serial bus >>> subclass = USB >>> uhci1@pci0:0:29:1: class=0x0c0300 card=0x830f1043 chip=0x27c98086 >>> rev=0x02 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82801G (ICH7 Family) USB Universal Host Controller' >>> class = serial bus >>> subclass = USB >>> uhci2@pci0:0:29:2: class=0x0c0300 card=0x830f1043 chip=0x27ca8086 >>> rev=0x02 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82801G (ICH7 Family) USB Universal Host Controller' >>> class = serial bus >>> subclass = USB >>> uhci3@pci0:0:29:3: class=0x0c0300 card=0x830f1043 chip=0x27cb8086 >>> rev=0x02 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82801G (ICH7 Family) USB Universal Host Controller' >>> class = serial bus >>> subclass = USB >>> ehci0@pci0:0:29:7: class=0x0c0320 card=0x830f1043 chip=0x27cc8086 >>> rev=0x02 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' >>> class = serial bus >>> subclass = USB >>> pcib4@pci0:0:30:0: class=0x060401 card=0x830f1043 chip=0x24488086 >>> rev=0xe2 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI >>> Bridge' >>> class = bridge >>> subclass = PCI-PCI >>> isab0@pci0:0:31:0: class=0x060100 card=0x830f1043 chip=0x27b98086 >>> rev=0x02 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82801GBM (ICH7-M) LPC Interface Controller' >>> class = bridge >>> subclass = PCI-ISA >>> atapci0@pci0:0:31:2: class=0x010180 card=0x830f1043 chip=0x27c48086 >>> rev=0x02 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage >>> Controller' >>> class = mass storage >>> subclass = ATA >>> ale0@pci0:3:0:0: class=0x020000 card=0x83241043 chip=0x10261969 >>> rev=0xb0 hdr=0x00 >>> vendor = 'Attansic (Now owned by Atheros)' >>> class = network >>> subclass = ethernet >>> none0@pci0:1:0:0: class=0x028000 card=0x27901814 chip=0x07811814 >>> rev=0x00 hdr=0x00 >>> vendor = 'Ralink Technology, Corp' >>> class = network >>> >> >> Did you load ral(4)? Your interface is using a ral chipset, not an >> atheros one. >> >> ``kldload if_ral'' >> /boot/loader.conf: if_ral_load="YES" >> >> Whenever asking questions like these, it may be useful to know the >> FreeBSD version you're using. >> >> _If_ we're talking about 7.x or 6.x, your kernel needs a bit tweaking >> (AFAIK the pciid 0x0781 isn't known by ral). >> > 0x781 is an RT2790; not supported by any driver in the tree. Andrew > was working on support but I know he hasn't looked at wireless in a > while. > > Sam > From volker at vwsoft.com Sat Nov 15 12:53:43 2008 From: volker at vwsoft.com (Volker) Date: Sat Nov 15 12:53:50 2008 Subject: Driver for Atheros Wireless LAN In-Reply-To: <491F28F5.50906@itavy.com> References: <491B5931.1030801@itavy.com> <491B5D6F.1030003@vwsoft.com> <491B6A6F.3050007@freebsd.org> <491F28F5.50906@itavy.com> Message-ID: <491F36C3.5060800@vwsoft.com> On 11/15/08 20:54, Octavian Ionescu wrote: > Sam Leffler wrote: >> Volker wrote: >>> On 11/12/08 23:31, Octavian Ionescu wrote: >>> >>>> hi, >>>> >>>> i have folowed the instructions on http://wiki.freebsd.org/AsusEee for >>>> setting up the drivers for an Asus EEE PC 1000H and i have managed to >>>> set up at least the wired ethernet with the help of Pyun YongHyeon. >>>> but >>>> for the wireless ethernet i can't see any wireless interface up. i see >>>> the message wich i shall see in dmesg but i cant see the interface : >>>> >>>> # dmesg | grep ath >>>> ath_hal: 0.10.5.10 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, >>>> RF2413, RF5413, RF2133, RF2425, RF2417) >>>> >>>> am i doing something wrong ? >>>> >>>> here is the result of pciconf >>>> >>>> # pciconf -v -l >>>> hostb0@pci0:0:0:0: class=0x060000 card=0x83401043 chip=0x27ac8086 >>>> rev=0x03 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> class = bridge >>>> subclass = HOST-PCI >>>> vgapci0@pci0:0:2:0: class=0x030000 card=0x83401043 chip=0x27ae8086 >>>> rev=0x03 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> class = display >>>> subclass = VGA >>>> vgapci1@pci0:0:2:1: class=0x038000 card=0x83401043 chip=0x27a68086 >>>> rev=0x03 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = 'Mobile 945GM/GU Express Integrated Graphics >>>> Controller' >>>> class = display >>>> pcm0@pci0:0:27:0: class=0x040300 card=0x831a1043 chip=0x27d88086 >>>> rev=0x02 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = '82801G (ICH7 Family) High Definition Audio' >>>> class = multimedia >>>> pcib1@pci0:0:28:0: class=0x060400 card=0x830f1043 chip=0x27d08086 >>>> rev=0x02 hdr=0x01 >>>> vendor = 'Intel Corporation' >>>> device = '82801G (ICH7 Family) PCIe Root Port' >>>> class = bridge >>>> subclass = PCI-PCI >>>> pcib2@pci0:0:28:1: class=0x060400 card=0x830f1043 chip=0x27d28086 >>>> rev=0x02 hdr=0x01 >>>> vendor = 'Intel Corporation' >>>> device = '82801G (ICH7 Family) PCIe Root Port' >>>> class = bridge >>>> subclass = PCI-PCI >>>> pcib3@pci0:0:28:3: class=0x060400 card=0x830f1043 chip=0x27d68086 >>>> rev=0x02 hdr=0x01 >>>> vendor = 'Intel Corporation' >>>> device = '82801G (ICH7 Family) PCIe Root Port' >>>> class = bridge >>>> subclass = PCI-PCI >>>> uhci0@pci0:0:29:0: class=0x0c0300 card=0x830f1043 chip=0x27c88086 >>>> rev=0x02 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = '82801G (ICH7 Family) USB Universal Host Controller' >>>> class = serial bus >>>> subclass = USB >>>> uhci1@pci0:0:29:1: class=0x0c0300 card=0x830f1043 chip=0x27c98086 >>>> rev=0x02 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = '82801G (ICH7 Family) USB Universal Host Controller' >>>> class = serial bus >>>> subclass = USB >>>> uhci2@pci0:0:29:2: class=0x0c0300 card=0x830f1043 chip=0x27ca8086 >>>> rev=0x02 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = '82801G (ICH7 Family) USB Universal Host Controller' >>>> class = serial bus >>>> subclass = USB >>>> uhci3@pci0:0:29:3: class=0x0c0300 card=0x830f1043 chip=0x27cb8086 >>>> rev=0x02 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = '82801G (ICH7 Family) USB Universal Host Controller' >>>> class = serial bus >>>> subclass = USB >>>> ehci0@pci0:0:29:7: class=0x0c0320 card=0x830f1043 chip=0x27cc8086 >>>> rev=0x02 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' >>>> class = serial bus >>>> subclass = USB >>>> pcib4@pci0:0:30:0: class=0x060401 card=0x830f1043 chip=0x24488086 >>>> rev=0xe2 hdr=0x01 >>>> vendor = 'Intel Corporation' >>>> device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI >>>> Bridge' >>>> class = bridge >>>> subclass = PCI-PCI >>>> isab0@pci0:0:31:0: class=0x060100 card=0x830f1043 chip=0x27b98086 >>>> rev=0x02 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = '82801GBM (ICH7-M) LPC Interface Controller' >>>> class = bridge >>>> subclass = PCI-ISA >>>> atapci0@pci0:0:31:2: class=0x010180 card=0x830f1043 chip=0x27c48086 >>>> rev=0x02 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage >>>> Controller' >>>> class = mass storage >>>> subclass = ATA >>>> ale0@pci0:3:0:0: class=0x020000 card=0x83241043 chip=0x10261969 >>>> rev=0xb0 hdr=0x00 >>>> vendor = 'Attansic (Now owned by Atheros)' >>>> class = network >>>> subclass = ethernet >>>> none0@pci0:1:0:0: class=0x028000 card=0x27901814 chip=0x07811814 >>>> rev=0x00 hdr=0x00 >>>> vendor = 'Ralink Technology, Corp' >>>> class = network >>>> >>> >>> Did you load ral(4)? Your interface is using a ral chipset, not an >>> atheros one. >>> >>> ``kldload if_ral'' >>> /boot/loader.conf: if_ral_load="YES" >>> >>> Whenever asking questions like these, it may be useful to know the >>> FreeBSD version you're using. >>> >>> _If_ we're talking about 7.x or 6.x, your kernel needs a bit tweaking >>> (AFAIK the pciid 0x0781 isn't known by ral). >>> >> 0x781 is an RT2790; not supported by any driver in the tree. Andrew >> was working on support but I know he hasn't looked at wireless in a >> while. >> >> Sam > > i have upgraded to head but still the same issues. > the version is: > # uname -a > FreeBSD 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Fri Nov 14 21:39:23 UTC 2008 > root@:/usr/obj/var/src/head/sys/ITAVYEEE2 i386 > as for loading driver ral: > #kldload if_ral > module_register: module cardbus/ral already exists! > Module cardbus/ral failed to register: 17 > module_register: module pci/ral already exists! > Module pci/ral failed to register: 17 > > i saw something wich Volker wrote wich i shall give it a try, what > tweaking is need to be made ? Octavian, tweaking is not really the right thing. As Sam stated (thanks Sam for your correction), your RAL device is using an unsupported chipset. I thought it might have been a new pci id for an already supported device. Until we have a driver for it, your best (and fastest) choice is to replace the mini-PCIe card with a well known, already supported chipset. I just bought the same model an hour ago and mine has an (unsupported) Atheros b/g/n chipset. I'll replace that with whatever card I've laying around here (I think it's an iwi). Volker From pingmai at yahoo.com Wed Nov 19 14:13:14 2008 From: pingmai at yahoo.com (Ping Mai) Date: Wed Nov 19 15:42:37 2008 Subject: ipmi on smbus Message-ID: <19035.86173.qm@web52908.mail.re2.yahoo.com> I'm tracing through dev/ipmi. it seems ipmi_smbus_identify() and ipmi_smbus_probe() never gets call on my board. smbus module is included in my kernel. what am I missing? From jhb at freebsd.org Thu Nov 20 11:07:59 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Nov 20 11:08:08 2008 Subject: ipmi on smbus In-Reply-To: <19035.86173.qm@web52908.mail.re2.yahoo.com> References: <19035.86173.qm@web52908.mail.re2.yahoo.com> Message-ID: <200811201356.58906.jhb@freebsd.org> On Wednesday 19 November 2008 04:46:32 pm Ping Mai wrote: > I'm tracing through dev/ipmi. it seems ipmi_smbus_identify() > and ipmi_smbus_probe() never gets call on my board. > smbus module is included in my kernel. what am I missing? Do you have a smbus0 device? -- John Baldwin From pingmai at yahoo.com Thu Nov 20 18:01:29 2008 From: pingmai at yahoo.com (Ping Mai) Date: Thu Nov 20 18:01:35 2008 Subject: ipmi on smbus In-Reply-To: <200811201356.58906.jhb@freebsd.org> Message-ID: <225413.17309.qm@web52905.mail.re2.yahoo.com> no I don't see smbus0. --- On Thu, 11/20/08, John Baldwin wrote: > From: John Baldwin > Subject: Re: ipmi on smbus > To: pingmai@yahoo.com > Cc: freebsd-drivers@freebsd.org > Date: Thursday, November 20, 2008, 10:56 AM > On Wednesday 19 November 2008 04:46:32 pm Ping Mai wrote: > > I'm tracing through dev/ipmi. it seems > ipmi_smbus_identify() > > and ipmi_smbus_probe() never gets call on my board. > > smbus module is included in my kernel. what am I > missing? > > Do you have a smbus0 device? > > -- > John Baldwin From jhb at freebsd.org Fri Nov 21 11:59:20 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri Nov 21 11:59:32 2008 Subject: ipmi on smbus In-Reply-To: <225413.17309.qm@web52905.mail.re2.yahoo.com> References: <225413.17309.qm@web52905.mail.re2.yahoo.com> Message-ID: <200811211407.55669.jhb@freebsd.org> On Thursday 20 November 2008 09:01:28 pm Ping Mai wrote: > no I don't see smbus0. You have to have an smbus0 device for ipmi_smbus_identify() to get called. Perhaps you are missing the 'ichsmb' driver or some other smbus front-end driver? > --- On Thu, 11/20/08, John Baldwin wrote: > > > From: John Baldwin > > Subject: Re: ipmi on smbus > > To: pingmai@yahoo.com > > Cc: freebsd-drivers@freebsd.org > > Date: Thursday, November 20, 2008, 10:56 AM > > On Wednesday 19 November 2008 04:46:32 pm Ping Mai wrote: > > > I'm tracing through dev/ipmi. it seems > > ipmi_smbus_identify() > > > and ipmi_smbus_probe() never gets call on my board. > > > smbus module is included in my kernel. what am I > > missing? > > > > Do you have a smbus0 device? > > > > -- > > John Baldwin > -- John Baldwin From pingmai at yahoo.com Fri Nov 21 18:54:05 2008 From: pingmai at yahoo.com (Ping Mai) Date: Fri Nov 21 18:54:11 2008 Subject: ipmi on smbus In-Reply-To: <200811211407.55669.jhb@freebsd.org> Message-ID: <994895.98848.qm@web52904.mail.re2.yahoo.com> yes, that makes sense. Thanks John! --- On Fri, 11/21/08, John Baldwin wrote: > From: John Baldwin > Subject: Re: ipmi on smbus > To: pingmai@yahoo.com > Cc: freebsd-drivers@freebsd.org > Date: Friday, November 21, 2008, 11:07 AM > On Thursday 20 November 2008 09:01:28 pm Ping Mai wrote: > > no I don't see smbus0. > > You have to have an smbus0 device for ipmi_smbus_identify() > to get called. > Perhaps you are missing the 'ichsmb' driver or some > other smbus front-end > driver? > > > --- On Thu, 11/20/08, John Baldwin > wrote: > > > > > From: John Baldwin > > > Subject: Re: ipmi on smbus > > > To: pingmai@yahoo.com > > > Cc: freebsd-drivers@freebsd.org > > > Date: Thursday, November 20, 2008, 10:56 AM > > > On Wednesday 19 November 2008 04:46:32 pm Ping > Mai wrote: > > > > I'm tracing through dev/ipmi. it seems > > > ipmi_smbus_identify() > > > > and ipmi_smbus_probe() never gets call on my > board. > > > > smbus module is included in my kernel. what > am I > > > missing? > > > > > > Do you have a smbus0 device? > > > > > > -- > > > John Baldwin > > > > > > -- > John Baldwin From huntting at glarp.com Mon Nov 24 07:33:12 2008 From: huntting at glarp.com (Brad Huntting) Date: Mon Nov 24 07:33:43 2008 Subject: add huntting@glarp.com Message-ID: From huntting at glarp.com Mon Nov 24 08:19:35 2008 From: huntting at glarp.com (Brad Huntting) Date: Mon Nov 24 08:19:42 2008 Subject: mutex quandry Message-ID: Dear hackers: My device driver, like many, maintains a counter (sc_inuse) and a flag (sc_running) to keep track of how many 'users' are using the device instance variables (softc) and wheather the device is trying to detach. I call the functions scm_reserver() and scm_leave() (see below) before and after any block of code that uses the softc. Then, in my detach() function I clear the sc_running flag and msleep() waiting for the sc_inuse counter to drain to zero before continuing, eventually destroying the very mutex I use to protect these two variables. My problem is here: if (sc && mtx_initialized(&sc->sc_inuse_mtx)) { mtx_lock(&sc->sc_inuse_mtx); ... Unfortunately, { mtx_initialized(x) && (mtx_lock(x), 1); } is not atomic. In the unlikely (but possible) event that the lock is destroyed after mtx_initialized(x) and before mtx_lock(x), the system will behave badly (probably panic). It would seem to be a common problem for most device drivers to implement this 'open/closing' lock where the lock starts out zero-filled in the pre-open state and destroyed in the post-closed state. So how should one deal with this? I could invent my own locking with atomic_*() operations, but then I loose the advantages of using standard system locks (like witness). thanx in advance, brad /* * scm_reserve() increments a inuse and scm_release() keep track * of how many customers are on site. To shut down we close the * door (sc_running=0), but we dont actually turn out the lights * untill the last customer has left (sc_inuse==0). * * If device is configured, this returns TRUE and caller must call * scm_release() when done. If device is not configured returns * FALSE and no further action is required. */ static int scm_reserve(struct scmicro_softc *sc) { int r; if (sc && mtx_initialized(&sc->sc_inuse_mtx)) { mtx_lock(&sc->sc_inuse_mtx); KASSERT(sc->sc_inuse >= 0, "scmicro: scm_reserve() sc_inuse <0!\n"); r = ( sc->sc_running ? ++sc->sc_inuse : 0 ); mtx_unlock(&sc->sc_inuse_mtx); } else { r = 0; DPRINTF(("scmicro: scm_reserve() failed to reserve sc=%p!\n", sc)); } return (r); } /* call this iff scm_reserve() returns true. */ static inline void scm_release(struct scmicro_softc *sc) { mtx_lock(&sc->sc_inuse_mtx); if (--sc->sc_inuse == 0) wakeup(&sc->sc_inuse); KASSERT(sc->sc_inuse >= 0, "scmicro: scm_release() sc_inuse <0!\n"); mtx_unlock(&sc->sc_inuse_mtx); } static int scmicro_detach(device_t self) { /*....*/ mtx_lock(&sc->sc_inuse_mtx); sc->sc_running = 0; /* redundant */ if (sc->sc_inuse > 0) msleep_spin((void *)&sc->sc_inuse, &sc->sc_inuse_mtx, "scmicro detach", 0); mtx_unlock(&sc->sc_inuse_mtx); /*....*/ mtx_destroy(&sc->sc_inuse_mtx); /*....*/ } From imp at bsdimp.com Mon Nov 24 09:39:02 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Mon Nov 24 09:39:08 2008 Subject: mutex quandry In-Reply-To: References: Message-ID: <20081124.103816.1649771647.imp@bsdimp.com> In message: "Brad Huntting" writes: : Dear hackers: : : My device driver, like many, maintains a counter (sc_inuse) and a flag : (sc_running) to keep track of how many 'users' are using the device : instance variables (softc) and wheather the device is trying to : detach. I call the functions scm_reserver() and scm_leave() (see : below) before and after any block of code that uses the softc. Then, : in my detach() function I clear the sc_running flag and msleep() : waiting for the sc_inuse counter to drain to zero before continuing, : eventually destroying the very mutex I use to protect these two : variables. My problem is here: : : if (sc && mtx_initialized(&sc->sc_inuse_mtx)) { : mtx_lock(&sc->sc_inuse_mtx); : ... : : Unfortunately, { mtx_initialized(x) && (mtx_lock(x), 1); } is not : atomic. In the unlikely (but possible) event that the lock is : destroyed after mtx_initialized(x) and before mtx_lock(x), the system : will behave badly (probably panic). Why do you care that it is initialized? This mutex should be created in the attach routine, and nothing can race it there unless it is creating threads, registering interrupts, etc before initializing it. : It would seem to be a common problem for most device drivers to : implement this 'open/closing' lock where the lock starts out : zero-filled in the pre-open state and destroyed in the post-closed : state. So how should one deal with this? I could invent my own : locking with atomic_*() operations, but then I loose the advantages of : using standard system locks (like witness). Right. I guess I still don't understand why you need to check to see if it is initialized. You should never be destroying the mutex if there are other threads accessing it. I guess I'm having problems understanding why you are even doing the non-atomic test, and why it is needed. Once you remove the test, the code falls into standard norms. Warner : thanx in advance, : brad : : /* : * scm_reserve() increments a inuse and scm_release() keep track : * of how many customers are on site. To shut down we close the : * door (sc_running=0), but we dont actually turn out the lights : * untill the last customer has left (sc_inuse==0). : * : * If device is configured, this returns TRUE and caller must call : * scm_release() when done. If device is not configured returns : * FALSE and no further action is required. : */ : static int : scm_reserve(struct scmicro_softc *sc) : { : int r; : : if (sc && mtx_initialized(&sc->sc_inuse_mtx)) { : mtx_lock(&sc->sc_inuse_mtx); : KASSERT(sc->sc_inuse >= 0, "scmicro: scm_reserve() : sc_inuse <0!\n"); : r = ( sc->sc_running ? ++sc->sc_inuse : 0 ); : mtx_unlock(&sc->sc_inuse_mtx); : } else { : r = 0; : DPRINTF(("scmicro: scm_reserve() failed to reserve : sc=%p!\n", sc)); : } : : return (r); : } : : /* call this iff scm_reserve() returns true. */ : static inline void : scm_release(struct scmicro_softc *sc) : { : : mtx_lock(&sc->sc_inuse_mtx); : if (--sc->sc_inuse == 0) : wakeup(&sc->sc_inuse); : KASSERT(sc->sc_inuse >= 0, "scmicro: scm_release() sc_inuse <0!\n"); : mtx_unlock(&sc->sc_inuse_mtx); : } : : static int : scmicro_detach(device_t self) : { : /*....*/ : mtx_lock(&sc->sc_inuse_mtx); : sc->sc_running = 0; /* redundant */ : if (sc->sc_inuse > 0) : msleep_spin((void *)&sc->sc_inuse, &sc->sc_inuse_mtx, : "scmicro detach", 0); : mtx_unlock(&sc->sc_inuse_mtx); : /*....*/ : mtx_destroy(&sc->sc_inuse_mtx); : /*....*/ : } : _______________________________________________ : freebsd-drivers@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-drivers : To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org" : : From huntting at glarp.com Mon Nov 24 11:40:16 2008 From: huntting at glarp.com (Brad Huntting) Date: Mon Nov 24 11:40:23 2008 Subject: mutex quandry In-Reply-To: Your message of "Mon, 24 Nov 2008 10:38:16 MST." <20081124.103816.1649771647.imp@bsdimp.com> Message-ID: <200811241911.mAOJBVkM067002@antediluvian.glarp.com> >: Dear hackers: >: >: My device driver, like many, maintains a counter (sc_inuse) and a flag >: (sc_running) to keep track of how many 'users' are using the device >: instance variables (softc) and wheather the device is trying to >: detach. I call the functions scm_reserver() and scm_leave() (see >: below) before and after any block of code that uses the softc. Then, >: in my detach() function I clear the sc_running flag and msleep() >: waiting for the sc_inuse counter to drain to zero before continuing, >: eventually destroying the very mutex I use to protect these two >: variables. My problem is here: >: >: if (sc && mtx_initialized(&sc->sc_inuse_mtx)) { >: mtx_lock(&sc->sc_inuse_mtx); >: ... >: >: Unfortunately, { mtx_initialized(x) && (mtx_lock(x), 1); } is not >: atomic. In the unlikely (but possible) event that the lock is >: destroyed after mtx_initialized(x) and before mtx_lock(x), the system >: will behave badly (probably panic). > >Why do you care that it is initialized? This mutex should be created >in the attach routine, and nothing can race it there unless it is >creating threads, registering interrupts, etc before initializing it. I meant to check if it's been destroyed. Does mtx_initialized() not do this? >: It would seem to be a common problem for most device drivers to >: implement this 'open/closing' lock where the lock starts out >: zero-filled in the pre-open state and destroyed in the post-closed >: state. So how should one deal with this? I could invent my own >: locking with atomic_*() operations, but then I loose the advantages of >: using standard system locks (like witness). > >Right. I guess I still don't understand why you need to check to see >if it is initialized. You should never be destroying the mutex if >there are other threads accessing it. My own threads will certainly be gone by the time I destroy the mutex. But this particular device has methods for kernel level consumers (with they're own threads). It's these methods that need to check to see if the device is still running. They can get the softc and check (sc && sc->sc_running). But to ensure the device doesnt go away while they're using it, they increment the counter sc_inuse. The combination of checking sc_running and incrementing sc_inuse needs to be atomic (hence a mutex around them) but at some point detach() has to destroy the mutex but my code may still need to use it. My solution was to use mtx_inialized() to see if they lock had been destroyed before trying to mtx_lock() it. I'm beginning to think that I should avoid a mutex entirely and somehow use just atomic_*() ops. >I guess I'm having problems understanding why you are even doing the >non-atomic test, and why it is needed. Once you remove the test, the >code falls into standard norms. > >Warner > > >: thanx in advance, >: brad >: >: /* >: * scm_reserve() increments a inuse and scm_release() keep track >: * of how many customers are on site. To shut down we close the >: * door (sc_running=0), but we dont actually turn out the lights >: * untill the last customer has left (sc_inuse==0). >: * >: * If device is configured, this returns TRUE and caller must call >: * scm_release() when done. If device is not configured returns >: * FALSE and no further action is required. >: */ >: static int >: scm_reserve(struct scmicro_softc *sc) >: { >: int r; >: >: if (sc && mtx_initialized(&sc->sc_inuse_mtx)) { >: mtx_lock(&sc->sc_inuse_mtx); >: KASSERT(sc->sc_inuse >= 0, "scmicro: scm_reserve() >: sc_inuse <0!\n"); >: r = ( sc->sc_running ? ++sc->sc_inuse : 0 ); >: mtx_unlock(&sc->sc_inuse_mtx); >: } else { >: r = 0; >: DPRINTF(("scmicro: scm_reserve() failed to reserve >: sc=%p!\n", sc)); >: } >: >: return (r); >: } >: >: /* call this iff scm_reserve() returns true. */ >: static inline void >: scm_release(struct scmicro_softc *sc) >: { >: >: mtx_lock(&sc->sc_inuse_mtx); >: if (--sc->sc_inuse == 0) >: wakeup(&sc->sc_inuse); >: KASSERT(sc->sc_inuse >= 0, "scmicro: scm_release() sc_inuse <0!\n"); >: mtx_unlock(&sc->sc_inuse_mtx); >: } >: >: static int >: scmicro_detach(device_t self) >: { >: /*....*/ >: mtx_lock(&sc->sc_inuse_mtx); >: sc->sc_running = 0; /* redundant */ >: if (sc->sc_inuse > 0) >: msleep_spin((void *)&sc->sc_inuse, &sc->sc_inuse_mtx, >: "scmicro detach", 0); >: mtx_unlock(&sc->sc_inuse_mtx); >: /*....*/ >: mtx_destroy(&sc->sc_inuse_mtx); >: /*....*/ >: } From imp at bsdimp.com Mon Nov 24 12:42:04 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Mon Nov 24 12:42:10 2008 Subject: mutex quandry In-Reply-To: <200811241911.mAOJBVkM067002@antediluvian.glarp.com> References: <20081124.103816.1649771647.imp@bsdimp.com> <200811241911.mAOJBVkM067002@antediluvian.glarp.com> Message-ID: <20081124.134236.723203643.imp@bsdimp.com> In message: <200811241911.mAOJBVkM067002@antediluvian.glarp.com> Brad Huntting writes: : The combination of checking sc_running and incrementing sc_inuse : needs to be atomic (hence a mutex around them) but at some point : detach() has to destroy the mutex but my code may still need to use : it. Your solution to this is to make sure that never happens. Anything else is really racy. If you are destroying your mutex and allowing detach to return, the entire sc is freed, so you're dead from that anyway... Warner From davidch at broadcom.com Mon Nov 24 13:46:15 2008 From: davidch at broadcom.com (David Christensen) Date: Mon Nov 24 13:46:26 2008 Subject: Gathering Hardware State During a Driver Initiated Kernel Panic Message-ID: <5D267A3F22FD854F8F48B3D2B52381933940B2DEFE@IRVEXCHCCR01.corp.ad.broadcom.com> Is there a method or callback in FreeBSD where a driver can be notified that it has caused a kernel panic in order to generate a dump of internal hardware state information? I've written a sysctl call for manual intervention and can handle some "expected" hardware events completely in the driver but I don't know of a way to get control again in cases where the driver wasn't expecting a failure. Dave From sam at freebsd.org Mon Nov 24 13:56:24 2008 From: sam at freebsd.org (Sam Leffler) Date: Mon Nov 24 13:56:30 2008 Subject: Gathering Hardware State During a Driver Initiated Kernel Panic In-Reply-To: <5D267A3F22FD854F8F48B3D2B52381933940B2DEFE@IRVEXCHCCR01.corp.ad.broadcom.com> References: <5D267A3F22FD854F8F48B3D2B52381933940B2DEFE@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <492B2306.60404@freebsd.org> David Christensen wrote: > Is there a method or callback in FreeBSD where a driver can > be notified that it has caused a kernel panic in order to > generate a dump of internal hardware state information? I've > written a sysctl call for manual intervention and can handle > some "expected" hardware events completely in the driver but > I don't know of a way to get control again in cases where the > driver wasn't expecting a failure. > Not sure how one can deduce a driver is at fault but you might define a ddb command for the driver and invoke that on panic using the ddb script mechanisms (see ddb(4)). Sam From imp at bsdimp.com Tue Nov 25 09:22:09 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Nov 25 09:22:21 2008 Subject: mutex quandry In-Reply-To: <200811251707.mAPH7JRg090619@antediluvian.glarp.com> References: <20081124.134236.723203643.imp@bsdimp.com> <200811251707.mAPH7JRg090619@antediluvian.glarp.com> Message-ID: <20081125.102030.-1272479009.imp@bsdimp.com> In message: <200811251707.mAPH7JRg090619@antediluvian.glarp.com> Brad Huntting writes: : : >: The combination of checking sc_running and incrementing sc_inuse : >: needs to be atomic (hence a mutex around them) but at some point : >: detach() has to destroy the mutex but my code may still need to use : >: it. : > : >Your solution to this is to make sure that never happens. Anything : >else is really racy. If you are destroying your mutex and allowing : >detach to return, the entire sc is freed, so you're dead from that : >anyway... : : Fair enough. I guess I was just too focused on my small part of : the larger system. : : But that brings up another issue. How do my (kernel level) users : know if my module is loaded or not? I cant find any section 9 docs : on kernal loadable modules. Am I looking in the wrong place? Or : do I just need to read the source. It should be documented in section 9. Use level users can do a kldstat to find this information. I think kern_kldload will load the module, but I'm not sure how to get status. I've cc'd drivers@ to see if someone there knows. Warner