Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
On Wednesday, January 19, 2011 06:35:51 Alexander Zagrebin wrote: > Hi! > > On 18.01.2011 12:31:20 +0100, Bernhard Schmidt wrote: > > > I'm trying to use the RT2872-based USB adapter in the hostap mode > > > on the latest RELENG_8 (8.2-PRERELEASE) for amd64. > > > [..] > > > > Pull that > > http://svn.freebsd.org/viewvc/base?view=revision&revision=217511 > > and let me know if that fixes the issue. > > I've retrieved the ieee80211_node.c and if_run.c and recompiled > wlan.ko and if_run.ko. > > Here results: > > Case 1: both if_run.ko and wlan_amrr.ko are loaded via loader.conf > > stable/8: panic > rev217511: panic > > Case 2: wlan_amrr.ko loaded manually _after_ if_run.ko but before > creation of the wlan interface > > stable/8: panic on rate control > rev217511: no panic, but rate control doesn't work; tx rate is > fixed on 1 Mbit/s > > Case 3: wlan_amrr.ko loaded _before_ if_run.ko > > stable/8: panic on rate control > rev217511: no panic, rate control works as expected > > So rev217511 partially fixes the issue. That sounds rather weird to me, I can't imagine how the module loading order should make any difference. Well, at least, before creating the VAP, because that is the point where that stuff gets initialized/used. Do you have anything configured in rc.conf maybe? That would create the VAP right after loading if_run.ko even before you are able to load wlan_amrr.ko. I'll have look at that again.. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
> Message: 19
> Date: Tue, 18 Jan 2011 13:26:58 +0300
> From: Alexander Zagrebin
> Subject: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
> To: freebsd-net@freebsd.org
> Message-ID: <20110118102658.ga3...@gw.zagrebin.ru>
> Content-Type: text/plain; charset=us-ascii
> mostly works (there is an issue with the devices with the 'power save mode'
> enabled),
>
Yes, there is.
Due to lack of documents, I haven't figured out how to add support, how to set
tim, etc.
> enabled), but transmission rate is limited with 1 Mbit/s.
Can you try attached patch and see if tx rate goes up.
AK
-- begin patch --
--- a/dev/usb/wlan/if_run.c +++ b/dev/usb/wlan/if_run.c @@ -2223,12 +2223,15 @@
run_drain_fifo(void *arg) struct ifnet *ifp = sc->sc_ifp; struct
ieee80211_node *ni = sc->sc_ni[0]; /* make compiler happy */
uint32_t stat;
- int retrycnt = 0; + int retrycnt; uint8_t wcid, mcs, pid;
RUN_LOCK_ASSERT(sc, MA_OWNED); for (;;) { +/*
clear on every loop */
+ retrycnt = 0; + /* drain Tx status FIFO
(maxsize = 16) */ run_read(sc,
RT2860_TX_STAT_FIFO, &stat);DPRINTFN(4, "tx stat 0x%08x\n", stat);
-- end patch --
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
Hi! On 19.01.2011 09:37:12 +0100, Bernhard Schmidt wrote: > > Case 2: wlan_amrr.ko loaded manually _after_ if_run.ko but before > > creation of the wlan interface > > > > stable/8: panic on rate control > > rev217511: no panic, but rate control doesn't work; tx rate is > > fixed on 1 Mbit/s > > That sounds rather weird to me, I can't imagine how the module loading > order should make any difference. Well, at least, before creating the > VAP, because that is the point where that stuff gets initialized/used. It seems you're right. I couldn't reproduce it again. May be I have missed anything. Sorry... > Do you have anything configured in rc.conf maybe? That would create the > VAP right after loading if_run.ko even before you are able to load > wlan_amrr.ko. Yes, I have wlans_run0="wlan0" and create_args_wlan0=... in the rc.conf, but while testing I've used `ifconfig wlan0 destroy` after `kldload if_run`. May be it was mistyping... Also I've noticed that messages like "ieee80211_load_module: load the wlan_amrr module by hand for now." has disappeared from the log. Is it normal? So there is the one issue only: the panic if runfw.ko and wlan_amrr.ko both loaded via loader.conf. Have you any ideas? Will be rev. 217511 MFC'd on the 20 january? -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
On Wednesday, January 19, 2011 12:23:30 Alexander Zagrebin wrote: > Hi! > > On 19.01.2011 09:37:12 +0100, Bernhard Schmidt wrote: > > > Case 2: wlan_amrr.ko loaded manually _after_ if_run.ko but before > > > creation of the wlan interface > > > > > > stable/8: panic on rate control > > > rev217511: no panic, but rate control doesn't work; tx rate is > > > > > > fixed on 1 Mbit/s > > > > That sounds rather weird to me, I can't imagine how the module > > loading order should make any difference. Well, at least, before > > creating the VAP, because that is the point where that stuff gets > > initialized/used. > > It seems you're right. I couldn't reproduce it again. > May be I have missed anything. Sorry... Ok, thanks. > > Do you have anything configured in rc.conf maybe? That would create > > the VAP right after loading if_run.ko even before you are able to > > load wlan_amrr.ko. > > Yes, I have wlans_run0="wlan0" and create_args_wlan0=... in the > rc.conf, but while testing I've used `ifconfig wlan0 destroy` after > `kldload if_run`. May be it was mistyping... > Also I've noticed that messages like > "ieee80211_load_module: load the wlan_amrr module by hand for now." > has disappeared from the log. Is it normal? That message only appears if wlan_amrr.ko isn't loaded while creating a VAP. If you do see the message if wlan_amrr.ko is loaded, that'd be a bug, also the other way around. > So there is the one issue only: the panic if runfw.ko and > wlan_amrr.ko both loaded via loader.conf. > Have you any ideas? No yet, I'll dig around there later today. > Will be rev. 217511 MFC'd on the 20 january? Yes, probably in the evening (CET). -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
Hi! On 19.01.2011 01:23:18 -0800, PseudoCylon wrote: > > mostly works (there is an issue with the devices with the 'power save mode' > > enabled), If device, connected to the freebsd based AP, is in 'power save mode', then there are: - very large dispersion of the ping time; like this 64 bytes from 192.168.1.12: icmp_seq=0 ttl=68 time=228.479 ms 64 bytes from 192.168.1.12: icmp_seq=1 ttl=68 time=2695.647 ms 64 bytes from 192.168.1.12: icmp_seq=2 ttl=68 time=1674.081 ms 64 bytes from 192.168.1.12: icmp_seq=3 ttl=68 time=653.757 ms 64 bytes from 192.168.1.12: icmp_seq=4 ttl=68 time=3785.051 ms 64 bytes from 192.168.1.12: icmp_seq=5 ttl=68 time=2764.311 ms 64 bytes from 192.168.1.12: icmp_seq=6 ttl=68 time=1742.506 ms 64 bytes from 192.168.1.12: icmp_seq=7 ttl=68 time=720.719 ms 64 bytes from 192.168.1.12: icmp_seq=10 ttl=68 time=568.465 ms 64 bytes from 192.168.1.12: icmp_seq=11 ttl=68 time=3.489 ms 64 bytes from 192.168.1.12: icmp_seq=12 ttl=68 time=8469.515 ms 64 bytes from 192.168.1.12: icmp_seq=13 ttl=68 time=7447.776 ms 64 bytes from 192.168.1.12: icmp_seq=14 ttl=68 time=6428.403 ms 64 bytes from 192.168.1.12: icmp_seq=15 ttl=68 time=5407.636 ms 64 bytes from 192.168.1.12: icmp_seq=16 ttl=68 time=4385.875 ms 64 bytes from 192.168.1.12: icmp_seq=17 ttl=68 time=3364.814 ms 64 bytes from 192.168.1.12: icmp_seq=18 ttl=68 time=2343.062 ms 64 bytes from 192.168.1.12: icmp_seq=19 ttl=68 time=1322.413 ms 64 bytes from 192.168.1.12: icmp_seq=20 ttl=68 time=300.670 ms 64 bytes from 192.168.1.12: icmp_seq=25 ttl=68 time=206.728 ms - periodical loss of packets, designated to device (like keepalive, icmp etc.), isn't it? > Yes, there is. > Due to lack of documents, I haven't figured out how to add support, how to > set > tim, etc. Due to lack of documents, related to the Ralink chipsets? > > enabled), but transmission rate is limited with 1 Mbit/s. > > Can you try attached patch and see if tx rate goes up. It seems the commit r217511 have fixed issue. Have you any thoughts about kernel panic when if_run, runfw and wlan_amrr are loaded via loader.conf? -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
kern/154007: [ath] Atheros ar9287 card does not get recognized.
Hi, I have this wifi card, and I have free time. I can help solve this problem, but I am not developer or programmer. I can only "serve" as a tester :) kuba ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
On Wednesday 19 January 2011 12:40:15 Bernhard Schmidt wrote: > On Wednesday, January 19, 2011 12:23:30 Alexander Zagrebin wrote: > > Hi! > > > > On 19.01.2011 09:37:12 +0100, Bernhard Schmidt wrote: > > > > Case 2: wlan_amrr.ko loaded manually _after_ if_run.ko but before > > > > creation of the wlan interface > > > > > > > > stable/8: panic on rate control > > > > rev217511: no panic, but rate control doesn't work; tx rate is > > > > > > > > fixed on 1 Mbit/s > > > > > > That sounds rather weird to me, I can't imagine how the module > > > loading order should make any difference. Well, at least, before > > > creating the VAP, because that is the point where that stuff gets > > > initialized/used. > > > > It seems you're right. I couldn't reproduce it again. > > May be I have missed anything. Sorry... > > Ok, thanks. > > > > Do you have anything configured in rc.conf maybe? That would create > > > the VAP right after loading if_run.ko even before you are able to > > > load wlan_amrr.ko. > > > > Yes, I have wlans_run0="wlan0" and create_args_wlan0=... in the > > rc.conf, but while testing I've used `ifconfig wlan0 destroy` after > > `kldload if_run`. May be it was mistyping... > > Also I've noticed that messages like > > "ieee80211_load_module: load the wlan_amrr module by hand for now." > > has disappeared from the log. Is it normal? > > That message only appears if wlan_amrr.ko isn't loaded while creating a > VAP. If you do see the message if wlan_amrr.ko is loaded, that'd be a > bug, also the other way around. > > > So there is the one issue only: the panic if runfw.ko and > > wlan_amrr.ko both loaded via loader.conf. > > Have you any ideas? > > No yet, I'll dig around there later today. Hmm, I'm not able to reproduce this, works as expected. Is this still the same backtrace as the previous error? > > Will be rev. 217511 MFC'd on the 20 january? > > Yes, probably in the evening (CET). > -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bug in ieee80211_mesh.c code?
On Monday 17 January 2011 19:06:39 Monthadar Al Jaberi wrote: > Hi, > > This line 1466 in ieee80211_mesh.c: > frm += frm[2] + 2; > > When I look at the other modes it should be > frm += frm[1] + 2; > > ?? Committed, thanks! -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [SCTP] transport address unconfirmed instead of inactive
On Jan 17, 2011, at 8:11 AM, Schoch Christian wrote: > I did some test with multihoming and failover. My problem is that if one > transport failes it never comes back to active (no heartbeats are sent any > more). > > My setup: > > FreeBSD 8.1 Linux 2.6.36 > 172.16.1.4 - 172.16.1.3 > 172.17.1.4 - 172.17.1.3 > > Packets from 16.1.4 to 17.1.3 and 17.1.4 to 16.1.3 are dropped. > > The transfer starts with 172.16.1.4 to 16.1.3 which is working as expected. Which side is the client, which one is the server? Which side is sending user data? > If the transfer on this transport failes, it is switching to 17.1.4 & 17.1.3 > as expected. How do you fail the connection? Disconnecting the cable? Configuring dummynet? > 172.16.1.4 gets SCTP_UNCONFIRMED, 172.16.1.3 gets SCTP_INACTIVE So you mean on the FreeBSD machine you get a SCTP_UNCONFIRMED? For which address? 172.16.1.3? > Now, if the first connection is available again, the first transport address > of FreeBSD stays at unconfirmed with no HB sent to 16.1.3 > Linux sends HB from 16.1.3 to 16.1.4 with ACK coming back from 17.1.4 to > 16.1.3 (which is dropped). > > So why are HBs sent from new primary instead of received address ? As > specified in RFC it should sent back from address, it receives the HB packet. Correct. Somethings seems strange. Please answer the above and I will try to reproduce the problem. Thanks for the report. Best regards Michael > > Regards, > Christian > > > > This message was sent using IMP, the Internet Messaging Program. > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
Hi! On 19.01.2011 17:57:00 +0100, Bernhard Schmidt wrote: > > > So there is the one issue only: the panic if runfw.ko and > > > wlan_amrr.ko both loaded via loader.conf. > > > Have you any ideas? > > > > No yet, I'll dig around there later today. > > Hmm, I'm not able to reproduce this, works as expected. Is this still the > same > backtrace as the previous error? The panic occurs on very early stage, so there is no dump created. I'll try to recompile kernel with the kdb support tomorrow. May be it will help to get backtrace. -- Alexander Zagrebin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [SCTP] transport address unconfirmed instead of inactive
On Jan 19, 2011, at 11:02 PM, Schoch Christian wrote: > Dear Michael, > > as I could figure out, the problem with UNCONFIRMED is solved. My test tools > is based on lksctp-tools and written for linux testing. Now the problem here > is that there is a inconsistency between linux and FreeBSD of the return > value of spinfo_state. Perhaps these return values could be standardized in > the sctp socket-api. Leaving a note on the linux dev mailing list on this > topic. Hi Christian, the actual values are not standardized, only the names of the constants. If you use the names and recompile the code when moving from Linux to FreeBSD, it should work. > > The other problem may depend on the fact, that i did the test with vmware and > a remote machine using only one network interface with 2 different Addresses > assigned. Furthermore, both addresses had a netmask of 255.255.0.0 so both > addresses were located in the same subnet. Did the same test with 2 Vmware > machines and other addresses which was successful. Yes, that mask may result in problems. Thanks for reporting. Best regards Michael > > Regards, > Christian > >> On Jan 17, 2011, at 8:11 AM, Schoch Christian wrote: >> >>> I did some test with multihoming and failover. My problem is that if one >>> transport failes it never comes back to active (no heartbeats are sent any >>> more). >>> >>> My setup: >>> >>> FreeBSD 8.1 Linux 2.6.36 >>> 172.16.1.4 - 172.16.1.3 >>> 172.17.1.4 - 172.17.1.3 >>> >>> Packets from 16.1.4 to 17.1.3 and 17.1.4 to 16.1.3 are dropped. >>> >>> The transfer starts with 172.16.1.4 to 16.1.3 which is working as expected. >> Which side is the client, which one is the server? Which side is sending user >> data? >>> If the transfer on this transport failes, it is switching to 17.1.4 & >>> 17.1.3 as expected. >> How do you fail the connection? Disconnecting the cable? Configuring >> dummynet? >>> 172.16.1.4 gets SCTP_UNCONFIRMED, 172.16.1.3 gets SCTP_INACTIVE >> So you mean on the FreeBSD machine you get a SCTP_UNCONFIRMED? For which >> address? 172.16.1.3? >>> Now, if the first connection is available again, the first transport >>> address of FreeBSD stays at unconfirmed with no HB sent to 16.1.3 >>> Linux sends HB from 16.1.3 to 16.1.4 with ACK coming back from 17.1.4 to >>> 16.1.3 (which is dropped). >>> >>> So why are HBs sent from new primary instead of received address ? As >>> specified in RFC it should sent back from address, it receives the HB >>> packet. >> Correct. Somethings seems strange. Please answer the above and I will try to >> reproduce >> the problem. >> >> Thanks for the report. >> Best regards >> Michael >>> >>> Regards, >>> Christian >>> >>> >>> >>> This message was sent using IMP, the Internet Messaging Program. >>> >>> ___ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >>> >> >> > > > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [SCTP] transport address unconfirmed instead of inactive
Dear Michael, as I could figure out, the problem with UNCONFIRMED is solved. My test tools is based on lksctp-tools and written for linux testing. Now the problem here is that there is a inconsistency between linux and FreeBSD of the return value of spinfo_state. Perhaps these return values could be standardized in the sctp socket-api. Leaving a note on the linux dev mailing list on this topic. The other problem may depend on the fact, that i did the test with vmware and a remote machine using only one network interface with 2 different Addresses assigned. Furthermore, both addresses had a netmask of 255.255.0.0 so both addresses were located in the same subnet. Did the same test with 2 Vmware machines and other addresses which was successful. Regards, Christian On Jan 17, 2011, at 8:11 AM, Schoch Christian wrote: I did some test with multihoming and failover. My problem is that if one transport failes it never comes back to active (no heartbeats are sent any more). My setup: FreeBSD 8.1 Linux 2.6.36 172.16.1.4 - 172.16.1.3 172.17.1.4 - 172.17.1.3 Packets from 16.1.4 to 17.1.3 and 17.1.4 to 16.1.3 are dropped. The transfer starts with 172.16.1.4 to 16.1.3 which is working as expected. Which side is the client, which one is the server? Which side is sending user data? If the transfer on this transport failes, it is switching to 17.1.4 & 17.1.3 as expected. How do you fail the connection? Disconnecting the cable? Configuring dummynet? 172.16.1.4 gets SCTP_UNCONFIRMED, 172.16.1.3 gets SCTP_INACTIVE So you mean on the FreeBSD machine you get a SCTP_UNCONFIRMED? For which address? 172.16.1.3? Now, if the first connection is available again, the first transport address of FreeBSD stays at unconfirmed with no HB sent to 16.1.3 Linux sends HB from 16.1.3 to 16.1.4 with ACK coming back from 17.1.4 to 16.1.3 (which is dropped). So why are HBs sent from new primary instead of received address ? As specified in RFC it should sent back from address, it receives the HB packet. Correct. Somethings seems strange. Please answer the above and I will try to reproduce the problem. Thanks for the report. Best regards Michael Regards, Christian This message was sent using IMP, the Internet Messaging Program. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bogus 0 len IP packet, was: Hang in VOP_LOCK1_APV on 8-STABLE with NFS.
On Tue, Jan 18, 2011 at 07:35:30PM +0100, sth...@nethelp.no wrote: > > > I'm seeing the same problem with Broadcom NetXtreme (bce) cards: > > > > > > bce0@pci0:3:0:0:class=0x02 card=0x03421014 chip=0x164c14e4 > > > rev=0x12 hdr=0x00 > > > vendor = 'Broadcom Corporation' > > > device = 'Broadcom NetXtreme II Gigabit Ethernet Adapter > > > (BCM5708)' > > > class = network > > > subclass = ethernet > > > > > > This is with 8.2-PRERELEASE. Turning off TSO (ifconfig bce0 -tso) > > > removes the problem. > > > > > > > Is there a reliable way to trigger this on bce(4)? I don't have > > BCM5708 but I have BCM5709 so I can verify that. > > It showed up pretty much immediately when running a csup sessions > against cvsup2.us.freebsd.org. > > I have a pcap file from the session, if you're interested. > I vaguely guess upper stack might pass less than MSS sized segment to TSO capable driver with CSUM_TSO. How about merging r212803 to stable/8? > Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
- Original Message > From: Alexander Zagrebin > To: PseudoCylon > Cc: freebsd-net@freebsd.org > Sent: Wed, January 19, 2011 5:07:46 AM > Subject: Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64 > > > Yes, there is. > > Due to lack of documents, I haven't figured out how to add support, how to >set > > > tim, etc. > > Due to lack of documents, related to the Ralink chipsets? > Yes. Currently, only source of info is ralink's own driver. It consists of 100+ files. You need to be quite motivated to browse them. Can you tell me what kind of clients you are using, NICs and os? > >>> It seems the commit r217511 have fixed issue. <<< > > Have you any thoughts about kernel panic when if_run, runfw and > wlan_amrr are loaded via loader.conf? > wlan_XXX modules are depend on wlan(4). Maybe that's the cause. AK ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/154007: [ath] Atheros ar9287 card does not get recognized.
Synopsis: [ath] Atheros ar9287 card does not get recognized. Responsible-Changed-From-To: freebsd-net->adrian Responsible-Changed-By: adrian Responsible-Changed-When: Thu Jan 20 06:34:53 UTC 2011 Responsible-Changed-Why: I'm acting as spear-head for atheros stuff for now. http://www.freebsd.org/cgi/query-pr.cgi?pr=154007 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/154007: [ath] Atheros ar9287 card does not get recognized.
Hiya, I'll take this over. Making it recognised isn't going to be too difficult. Making it stable, that's a whole other problem. I'm happy to commit the bare minimum needed to make the AR9287 recognised but there's quite a bit of further work needing to be done to the AR9280 support before I'm comfortable working on AR9285/AR9287. If you know of a place to acquire AR9285/AR9287 equipment then please let me know so I can acquire some also. Adrian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
