Re: RFT: if_ath HAL refactoring
On Wednesday, September 22, 2010 06:04:49 PseudoCylon wrote: - Original Message From: Adrian Chadd adr...@freebsd.org To: PseudoCylon moonlightak...@yahoo.ca Cc: freebsd-current@freebsd.org Sent: Tue, September 21, 2010 7:04:37 AM Subject: Re: RFT: if_ath HAL refactoring On 21 September 2010 11:58, PseudoCylon moonlightak...@yahoo.ca wrote: Just in case anyone wonders, I've added 11n support to run(4) (USB NIC). http://gitorious.org/run/run/trees/11n_beta2 It still has some issues, * doesn't work well with atheros chips * HT + AP + bridge = Tx may stall (seems OK with nat) So, use it at your own discretion. Want to put together a patch? sure! Does it introduce issues in the non-11n case? No, only in 11n mode. What I have found so far is that Ralink's driver checks MAC address of other end and identify atheros chip by oui. Then, sets special prot mode for it. Does this ring a bell? Are your sure that this is based on the actual MAC addresses? Atheros drivers tend to announce additional capabilities in beacons and probe responses. Has node lock in ieee80211_node_timeout() cased dead lock in HT + AP + bridge? I'm not aware of any issues there, though, I'm not very familiar with HT use cases. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: if_ath HAL refactoring
- Original Message From: Bernhard Schmidt bschm...@techwires.net To: freebsd-current@freebsd.org Cc: PseudoCylon moonlightak...@yahoo.ca; Adrian Chadd adr...@freebsd.org Sent: Wed, September 22, 2010 12:09:36 AM Subject: Re: RFT: if_ath HAL refactoring On Wednesday, September 22, 2010 06:04:49 PseudoCylon wrote: - Original Message From: Adrian Chadd adr...@freebsd.org To: PseudoCylon moonlightak...@yahoo.ca Cc: freebsd-current@freebsd.org Sent: Tue, September 21, 2010 7:04:37 AM Subject: Re: RFT: if_ath HAL refactoring On 21 September 2010 11:58, PseudoCylon moonlightak...@yahoo.ca wrote: Just in case anyone wonders, I've added 11n support to run(4) (USB NIC). http://gitorious.org/run/run/trees/11n_beta2 It still has some issues, * doesn't work well with atheros chips * HT + AP + bridge = Tx may stall (seems OK with nat) So, use it at your own discretion. Want to put together a patch? sure! Does it introduce issues in the non-11n case? No, only in 11n mode. What I have found so far is that Ralink's driver checks MAC address of other end and identify atheros chip by oui. Then, sets special prot mode for it. Does this ring a bell? Are your sure that this is based on the actual MAC addresses? Atheros drivers tend to announce additional capabilities in beacons and probe responses. It is based on the actual MAC, but it is Broadcom's oui (00904c). sorry. Has node lock in ieee80211_node_timeout() cased dead lock in HT + AP + bridge? I'm not aware of any issues there, though, I'm not very familiar with HT use cases. I attached witness messages. Those 2 LORs always happen together before deadlock. I hooked iv_input() and unlock/lock node lock to avoid deadlock. (I don't know if it's safe.) I wonder if this is run(4) specific problem. AK lock order reversal: 1st 0xff8000a267d0 run0_node_lock (run0_node_lock) @ /usr/src/sys/net80211/ieee80211_node.c:1360 2nd 0xff0001716818 if_bridge (if_bridge) @ /usr/src/sys/net/if_bridge.c:2184 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _mtx_lock_flags() at _mtx_lock_flags+0x78 bridge_input() at bridge_input+0x7e ether_input() at ether_input+0x143 hostap_input() at hostap_input+0x4ea ampdu_rx_flush() at ampdu_rx_flush+0x5e ieee80211_ht_node_age() at ieee80211_ht_node_age+0x7b ieee80211_node_timeout() at ieee80211_node_timeout+0x2dc softclock() at softclock+0x2a0 intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0xb2 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff852d30, rbp = 0 --- lock order reversal: 1st 0xff8000a267d0 run0_node_lock (run0_node_lock) @ /usr/src/sys/net80211/ieee80211_node.c:1360 2nd 0x80a186c8 tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:498 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _rw_rlock() at _rw_rlock+0x5f tcp_input() at tcp_input+0xa58 ip_input() at ip_input+0xbc netisr_dispatch_src() at netisr_dispatch_src+0xb8 ether_demux() at ether_demux+0x17d ether_input() at ether_input+0x175 hostap_input() at hostap_input+0x4ea ampdu_rx_flush() at ampdu_rx_flush+0x5e ieee80211_ht_node_age() at ieee80211_ht_node_age+0x7b ieee80211_node_timeout() at ieee80211_node_timeout+0x2dc softclock() at softclock+0x2a0 intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0xb2 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff852d30, rbp = 0 --- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: if_ath HAL refactoring
On 22 Sep 2010, at 23:42, PseudoCylon wrote: - Original Message From: Bernhard Schmidt bschm...@techwires.net To: freebsd-current@freebsd.org Cc: PseudoCylon moonlightak...@yahoo.ca; Adrian Chadd adr...@freebsd.org Sent: Wed, September 22, 2010 12:09:36 AM Subject: Re: RFT: if_ath HAL refactoring On Wednesday, September 22, 2010 06:04:49 PseudoCylon wrote: - Original Message From: Adrian Chadd adr...@freebsd.org To: PseudoCylon moonlightak...@yahoo.ca Cc: freebsd-current@freebsd.org Sent: Tue, September 21, 2010 7:04:37 AM Subject: Re: RFT: if_ath HAL refactoring On 21 September 2010 11:58, PseudoCylon moonlightak...@yahoo.ca wrote: Just in case anyone wonders, I've added 11n support to run(4) (USB NIC). http://gitorious.org/run/run/trees/11n_beta2 It still has some issues, * doesn't work well with atheros chips * HT + AP + bridge = Tx may stall (seems OK with nat) So, use it at your own discretion. Want to put together a patch? sure! Does it introduce issues in the non-11n case? No, only in 11n mode. What I have found so far is that Ralink's driver checks MAC address of other end and identify atheros chip by oui. Then, sets special prot mode for it. Does this ring a bell? Are your sure that this is based on the actual MAC addresses? Atheros drivers tend to announce additional capabilities in beacons and probe responses. It is based on the actual MAC, but it is Broadcom's oui (00904c). sorry. Has node lock in ieee80211_node_timeout() cased dead lock in HT + AP + bridge? I'm not aware of any issues there, though, I'm not very familiar with HT use cases. I attached witness messages. Those 2 LORs always happen together before deadlock. I hooked iv_input() and unlock/lock node lock to avoid deadlock. (I don't know if it's safe.) I wonder if this is run(4) specific problem. AK lock order reversal: 1st 0xff8000a267d0 run0_node_lock (run0_node_lock) @ /usr/src/sys/net80211/ieee80211_node.c:1360 2nd 0xff0001716818 if_bridge (if_bridge) @ /usr/src/sys/net/if_bridge.c:2184 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _mtx_lock_flags() at _mtx_lock_flags+0x78 bridge_input() at bridge_input+0x7e ether_input() at ether_input+0x143 hostap_input() at hostap_input+0x4ea ampdu_rx_flush() at ampdu_rx_flush+0x5e ieee80211_ht_node_age() at ieee80211_ht_node_age+0x7b ieee80211_node_timeout() at ieee80211_node_timeout+0x2dc softclock() at softclock+0x2a0 intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0xb2 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff852d30, rbp = 0 --- lock order reversal: 1st 0xff8000a267d0 run0_node_lock (run0_node_lock) @ /usr/src/sys/net80211/ieee80211_node.c:1360 2nd 0x80a186c8 tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:498 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _rw_rlock() at _rw_rlock+0x5f tcp_input() at tcp_input+0xa58 ip_input() at ip_input+0xbc netisr_dispatch_src() at netisr_dispatch_src+0xb8 ether_demux() at ether_demux+0x17d ether_input() at ether_input+0x175 hostap_input() at hostap_input+0x4ea ampdu_rx_flush() at ampdu_rx_flush+0x5e ieee80211_ht_node_age() at ieee80211_ht_node_age+0x7b ieee80211_node_timeout() at ieee80211_node_timeout+0x2dc softclock() at softclock+0x2a0 intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0xb2 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff852d30, rbp = 0 --- Can you explain why the run0_node_lock is locked ? I don't have the code at hand.. Regards, -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: if_ath HAL refactoring
- Original Message From: Rui Paulo rpa...@freebsd.org To: PseudoCylon moonlightak...@yahoo.ca Cc: Bernhard Schmidt bschm...@techwires.net; freebsd-current@freebsd.org; Adrian Chadd adr...@freebsd.org Sent: Wed, September 22, 2010 4:48:14 PM Subject: Re: RFT: if_ath HAL refactoring On 22 Sep 2010, at 23:42, PseudoCylon wrote: - Original Message From: Bernhard Schmidt bschm...@techwires.net To: freebsd-current@freebsd.org Cc: PseudoCylon moonlightak...@yahoo.ca; Adrian Chadd adr...@freebsd.org Sent: Wed, September 22, 2010 12:09:36 AM Subject: Re: RFT: if_ath HAL refactoring On Wednesday, September 22, 2010 06:04:49 PseudoCylon wrote: - Original Message From: Adrian Chadd adr...@freebsd.org To: PseudoCylon moonlightak...@yahoo.ca Cc: freebsd-current@freebsd.org Sent: Tue, September 21, 2010 7:04:37 AM Subject: Re: RFT: if_ath HAL refactoring On 21 September 2010 11:58, PseudoCylon moonlightak...@yahoo.ca wrote: Just in case anyone wonders, I've added 11n support to run(4) (USB NIC). http://gitorious.org/run/run/trees/11n_beta2 It still has some issues, * doesn't work well with atheros chips * HT + AP + bridge = Tx may stall (seems OK with nat) So, use it at your own discretion. Want to put together a patch? sure! Does it introduce issues in the non-11n case? No, only in 11n mode. What I have found so far is that Ralink's driver checks MAC address of other end and identify atheros chip by oui. Then, sets special prot mode for it. Does this ring a bell? Are your sure that this is based on the actual MAC addresses? Atheros drivers tend to announce additional capabilities in beacons and probe responses. It is based on the actual MAC, but it is Broadcom's oui (00904c). sorry. Has node lock in ieee80211_node_timeout() cased dead lock in HT + AP + bridge? I'm not aware of any issues there, though, I'm not very familiar with HT use cases. I attached witness messages. Those 2 LORs always happen together before deadlock. I hooked iv_input() and unlock/lock node lock to avoid deadlock. (I don't know if it's safe.) I wonder if this is run(4) specific problem. AK lock order reversal: 1st 0xff8000a267d0 run0_node_lock (run0_node_lock) @ /usr/src/sys/net80211/ieee80211_node.c:1360 2nd 0xff0001716818 if_bridge (if_bridge) @ /usr/src/sys/net/if_bridge.c:2184 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _mtx_lock_flags() at _mtx_lock_flags+0x78 bridge_input() at bridge_input+0x7e ether_input() at ether_input+0x143 hostap_input() at hostap_input+0x4ea ampdu_rx_flush() at ampdu_rx_flush+0x5e ieee80211_ht_node_age() at ieee80211_ht_node_age+0x7b ieee80211_node_timeout() at ieee80211_node_timeout+0x2dc softclock() at softclock+0x2a0 intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0xb2 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff852d30, rbp = 0 --- lock order reversal: 1st 0xff8000a267d0 run0_node_lock (run0_node_lock) @ /usr/src/sys/net80211/ieee80211_node.c:1360 2nd 0x80a186c8 tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:498 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _rw_rlock() at _rw_rlock+0x5f tcp_input() at tcp_input+0xa58 ip_input() at ip_input+0xbc netisr_dispatch_src() at netisr_dispatch_src+0xb8 ether_demux() at ether_demux+0x17d ether_input() at ether_input+0x175 hostap_input() at hostap_input+0x4ea ampdu_rx_flush() at ampdu_rx_flush+0x5e ieee80211_ht_node_age() at ieee80211_ht_node_age+0x7b ieee80211_node_timeout() at ieee80211_node_timeout+0x2dc softclock() at softclock+0x2a0 intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0xb2 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff852d30, rbp = 0 --- Can you explain why the run0_node_lock is locked ? I don't have the code at hand.. Regards, -- Rui Paulo I don't know why, but I know where. run0_node_lock is locked at ieee80211_node.c:1917 ieee80211_node_timeout() - ieee80211_timeout_stations() http://fxr.watson.org/fxr/source/net80211/ieee80211_node.c?im=bigexcerpts#L1917 ieee80211_node.c:1360 (one witness reports) hostap_input() - hostap_deliver_data() -ieee80211_find_vap_node() - lock @ ieee80211_node.c:1360 (I think it's recursed.) and run(4) calls
Re: RFT: if_ath HAL refactoring
On 21 September 2010 11:58, PseudoCylon moonlightak...@yahoo.ca wrote: Just in case anyone wonders, I've added 11n support to run(4) (USB NIC). http://gitorious.org/run/run/trees/11n_beta2 It still has some issues, * doesn't work well with atheros chips * HT + AP + bridge = Tx may stall (seems OK with nat) So, use it at your own discretion. Want to put together a patch? Does it introduce issues in the non-11n case? Having more 11n options for FreeBSD-9.0 would be really nice. :) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: if_ath HAL refactoring
On Monday, September 20, 2010 10:06:53 am Adrian Chadd wrote: On 20 September 2010 21:25, John Baldwin j...@freebsd.org wrote: Why not include this iff both 'device ath' and 'device pci' are included? That is what is normally done for bus-specific attachments. I've not idea right now whether there's an Atheros SoC with an AHB-attached wireless device and a PCI bus. In fact, that won't work at the present time because the device names would clash. Why would the device names clash? We have _lots_ of drivers with multiple bus attachments that use the same name regardless of which bus they are on, and making a bus attachment conditional on the bus being present is what every other driver that desires this level of granularity does. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: if_ath HAL refactoring
On 21 September 2010 21:19, John Baldwin j...@freebsd.org wrote: I've not idea right now whether there's an Atheros SoC with an AHB-attached wireless device and a PCI bus. In fact, that won't work at the present time because the device names would clash. Why would the device names clash? We have _lots_ of drivers with multiple bus attachments that use the same name regardless of which bus they are on, and making a bus attachment conditional on the bus being present is what every other driver that desires this level of granularity does. Cool. Well, that's one less thing I have to worry about. :-) Thanks, Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: if_ath HAL refactoring
- Original Message From: Adrian Chadd adr...@freebsd.org To: PseudoCylon moonlightak...@yahoo.ca Cc: freebsd-current@freebsd.org Sent: Tue, September 21, 2010 7:04:37 AM Subject: Re: RFT: if_ath HAL refactoring On 21 September 2010 11:58, PseudoCylon moonlightak...@yahoo.ca wrote: Just in case anyone wonders, I've added 11n support to run(4) (USB NIC). http://gitorious.org/run/run/trees/11n_beta2 It still has some issues, * doesn't work well with atheros chips * HT + AP + bridge = Tx may stall (seems OK with nat) So, use it at your own discretion. Want to put together a patch? sure! Does it introduce issues in the non-11n case? No, only in 11n mode. What I have found so far is that Ralink's driver checks MAC address of other end and identify atheros chip by oui. Then, sets special prot mode for it. Does this ring a bell? Has node lock in ieee80211_node_timeout() cased dead lock in HT + AP + bridge? AK ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: if_ath HAL refactoring
On Saturday, September 18, 2010 12:09:21 pm Adrian Chadd wrote: Hi all, I've uploaded a snapshot of the if_ath HAL which i've been working on. I've been refactoring out various bits of the AR5416 HAL into something that resembles the ath9k hardware MAC/PHY operations to make it easier to port further ath9k updates over. It also includes the AR9100 support (but it's missing a couple bits of glue needed to use it outside of my GIT tree.) Finally, it includes the probe/attach operations for the AR2427, but I haven't at all tested it yet (and i've explained why it isn't working in a previous email.) It's available for download at http://people.freebsd.org/~adrian/ath/ . There's a diff against src/sys/files/conf and a tarball that just replaces the ath device/module directory. Note you'll need to add device if_ath_pci to your kernel configuration file as the PCI bus glue is now not built by default in a static kernel in this HAL. (It's included in the module Makefile by default.) This was done to allow multiple backend bus types - now being PCI and AHB for the AR9100 SoC. Why not include this iff both 'device ath' and 'device pci' are included? That is what is normally done for bus-specific attachments. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: if_ath HAL refactoring
On 20 September 2010 21:25, John Baldwin j...@freebsd.org wrote: Why not include this iff both 'device ath' and 'device pci' are included? That is what is normally done for bus-specific attachments. I've not idea right now whether there's an Atheros SoC with an AHB-attached wireless device and a PCI bus. In fact, that won't work at the present time because the device names would clash. I'm happy to do that in whatever form the eventual merged codebase takes. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: if_ath HAL refactoring
Message: 9 Date: Sun, 19 Sep 2010 01:04:47 +0800 From: Adrian Chadd adr...@freebsd.org Subject: Re: RFT: if_ath HAL refactoring To: Brandon Weisz li...@avioc.org Cc: freebsd-current@freebsd.org Message-ID: aanlkti=tcbozkeft15=158s=7my9c7sebku+5nycq...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On 19 September 2010 01:01, Adrian Chadd adr...@freebsd.org wrote: Are there plans for AR9287 support? Unfortunately that is the only ath card I have to test with at the moment. At some point, yes. There's a lot of code missing in our driver for ar92xx series chips. I'd rather get the existing stuff updated and tidied up before I look at importing support for others. I'd also like to somehow acquire some hardware to test it against - I only have (very) legacy (pre AR5416), AR5416, AR9160 and AR2427 chips. I don't yet have anything with an AR9280/9285 in it. And before anyone asks - no, I won't be looking at the USB NICs, sorry. :-) Just in case anyone wonders, I've added 11n support to run(4) (USB NIC). http://gitorious.org/run/run/trees/11n_beta2 It still has some issues, * doesn't work well with atheros chips * HT + AP + bridge = Tx may stall (seems OK with nat) So, use it at your own discretion. Adrian -- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: if_ath HAL refactoring
On 19 Sep 2010, at 02:34, Adrian Chadd wrote: On 19 September 2010 06:38, Rui Paulo rpa...@freebsd.org wrote: Can you also provide a diff against HEAD please? Done. It's in the same place; named complete.diff. Hmm, I don't see it :-( Regards, -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: if_ath HAL refactoring
oops, I put it in the wrong place. Try again! adrian On 19 September 2010 18:03, Rui Paulo rpa...@freebsd.org wrote: On 19 Sep 2010, at 02:34, Adrian Chadd wrote: On 19 September 2010 06:38, Rui Paulo rpa...@freebsd.org wrote: Can you also provide a diff against HEAD please? Done. It's in the same place; named complete.diff. Hmm, I don't see it :-( Regards, -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RFT: if_ath HAL refactoring
Hi all, I've uploaded a snapshot of the if_ath HAL which i've been working on. I've been refactoring out various bits of the AR5416 HAL into something that resembles the ath9k hardware MAC/PHY operations to make it easier to port further ath9k updates over. It also includes the AR9100 support (but it's missing a couple bits of glue needed to use it outside of my GIT tree.) Finally, it includes the probe/attach operations for the AR2427, but I haven't at all tested it yet (and i've explained why it isn't working in a previous email.) It's available for download at http://people.freebsd.org/~adrian/ath/ . There's a diff against src/sys/files/conf and a tarball that just replaces the ath device/module directory. Note you'll need to add device if_ath_pci to your kernel configuration file as the PCI bus glue is now not built by default in a static kernel in this HAL. (It's included in the module Makefile by default.) This was done to allow multiple backend bus types - now being PCI and AHB for the AR9100 SoC. I'd appreciate testing by AR5416/AR9160/AR9280/AR9285 users. I only currently have easy access to AR5416/AR9160. Please let me know immediately if something doesn't work with this which does work in -head. If you're an AR2427 user, I'd appreciate some brief testing with HAL_DEBUG_ATTACH/HAL_DEBUG_EEPROM enabled (sysctl hw.ath.hal.debug=0x8002.) I doubt it'll work but it should attach and then spit out some computetxtime errors. Let me know if that happens and I'll see about trying to fix that. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: if_ath HAL refactoring
On 09/18/2010 11:09 AM, Adrian Chadd wrote: Hi all, I've uploaded a snapshot of the if_ath HAL which i've been working on. I've been refactoring out various bits of the AR5416 HAL into something that resembles the ath9k hardware MAC/PHY operations to make it easier to port further ath9k updates over. It also includes the AR9100 support (but it's missing a couple bits of glue needed to use it outside of my GIT tree.) Finally, it includes the probe/attach operations for the AR2427, but I haven't at all tested it yet (and i've explained why it isn't working in a previous email.) It's available for download at http://people.freebsd.org/~adrian/ath/ . There's a diff against src/sys/files/conf and a tarball that just replaces the ath device/module directory. Note you'll need to add device if_ath_pci to your kernel configuration file as the PCI bus glue is now not built by default in a static kernel in this HAL. (It's included in the module Makefile by default.) This was done to allow multiple backend bus types - now being PCI and AHB for the AR9100 SoC. I'd appreciate testing by AR5416/AR9160/AR9280/AR9285 users. I only currently have easy access to AR5416/AR9160. Please let me know immediately if something doesn't work with this which does work in -head. Are there plans for AR9287 support? Unfortunately that is the only ath card I have to test with at the moment. If you're an AR2427 user, I'd appreciate some brief testing with HAL_DEBUG_ATTACH/HAL_DEBUG_EEPROM enabled (sysctl hw.ath.hal.debug=0x8002.) I doubt it'll work but it should attach and then spit out some computetxtime errors. Let me know if that happens and I'll see about trying to fix that. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: if_ath HAL refactoring
On 19 September 2010 00:54, Brandon Weisz li...@avioc.org wrote: I'd appreciate testing by AR5416/AR9160/AR9280/AR9285 users. I only currently have easy access to AR5416/AR9160. Please let me know immediately if something doesn't work with this which does work in -head. Are there plans for AR9287 support? Unfortunately that is the only ath card I have to test with at the moment. At some point, yes. There's a lot of code missing in our driver for ar92xx series chips. I'd rather get the existing stuff updated and tidied up before I look at importing support for others. I'd also like to somehow acquire some hardware to test it against - I only have (very) legacy (pre AR5416), AR5416, AR9160 and AR2427 chips. I don't yet have anything with an AR9280/9285 in it. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: if_ath HAL refactoring
On 19 September 2010 01:01, Adrian Chadd adr...@freebsd.org wrote: Are there plans for AR9287 support? Unfortunately that is the only ath card I have to test with at the moment. At some point, yes. There's a lot of code missing in our driver for ar92xx series chips. I'd rather get the existing stuff updated and tidied up before I look at importing support for others. I'd also like to somehow acquire some hardware to test it against - I only have (very) legacy (pre AR5416), AR5416, AR9160 and AR2427 chips. I don't yet have anything with an AR9280/9285 in it. And before anyone asks - no, I won't be looking at the USB NICs, sorry. :-) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: if_ath HAL refactoring
On 18 Sep 2010, at 17:09, Adrian Chadd wrote: Hi all, I've uploaded a snapshot of the if_ath HAL which i've been working on. I've been refactoring out various bits of the AR5416 HAL into something that resembles the ath9k hardware MAC/PHY operations to make it easier to port further ath9k updates over. It also includes the AR9100 support (but it's missing a couple bits of glue needed to use it outside of my GIT tree.) Finally, it includes the probe/attach operations for the AR2427, but I haven't at all tested it yet (and i've explained why it isn't working in a previous email.) It's available for download at http://people.freebsd.org/~adrian/ath/ . There's a diff against src/sys/files/conf and a tarball that just replaces the ath device/module directory. Note you'll need to add device if_ath_pci to your kernel configuration file as the PCI bus glue is now not built by default in a static kernel in this HAL. (It's included in the module Makefile by default.) This was done to allow multiple backend bus types - now being PCI and AHB for the AR9100 SoC. I'd appreciate testing by AR5416/AR9160/AR9280/AR9285 users. I only currently have easy access to AR5416/AR9160. Please let me know immediately if something doesn't work with this which does work in -head. If you're an AR2427 user, I'd appreciate some brief testing with HAL_DEBUG_ATTACH/HAL_DEBUG_EEPROM enabled (sysctl hw.ath.hal.debug=0x8002.) I doubt it'll work but it should attach and then spit out some computetxtime errors. Let me know if that happens and I'll see about trying to fix that. Can you also provide a diff against HEAD please? Regards, -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: if_ath HAL refactoring
On 19 September 2010 06:38, Rui Paulo rpa...@freebsd.org wrote: Can you also provide a diff against HEAD please? Done. It's in the same place; named complete.diff. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
