Re: CDC-WDM driver (4G modems)
> Message: 1 > Date: Thu, 11 Sep 2014 15:23:07 +0200 > From: Nick Hibma > To: freebsd-current@FreeBSD.ORG > Cc: Hans Petter Selasky > Subject: CDC-WDM driver (4G modems) > Message-ID: <2d4cf978-b2c2-4253-93c7-595dabac0...@van-laarhoven.org> > Content-Type: text/plain; charset=us-ascii > > Folks, Hans-Petter, > > Is anyone aware of an effort to create support for QMI based 4G modems? The > following parts need to be implemented I think: > > - CDC-WDM support > - Wrapper driver to access QMI devices as WDM? > - libqmi port to FreeBSD > > This would support any modem from Telit, Sierra Wireless, Option, etc. that > works with the Qualcomm chipsets. If you look in the cdc-wdm qmi driver in > Linux, it is a long list. > > I could not find any mention of FreeBSD and QMI on the same page, so I assume > no one is working on it. Actually, I'm working on it. Base part has been done. Currently, just adding more commands. But, I cannot release the code until 3 month after the release of the product. By the way, libqmi is just for QMI commands (controlling the modem). Tx/Rx data packets go though PPP. That's because qualcomm refused to release that part of information. > > > Nick Hibma > ___ 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: patches for if_iwi and wlan for WEP mode
> -- > > Message: 4 > Date: Wed, 7 Mar 2012 10:45:11 -0800 > From: Adrian Chadd > Subject: Re: patches for if_iwi and wlan for WEP mode > To: Mitsuru IWASAKI > Cc: freebsd-current@freebsd.org, freebsd-wirel...@freebsd.org, > bschm...@freebsd.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > I'd rather you didn't commit iwi_update_mcast() unless you absolutely > know that the NIC doesn't need to be notified of multicast group > membership changes. If so, IFF_ALLMULTI flag should be set. http://lists.freebsd.org/pipermail/svn-src-head/2010-May/016983.html 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: [CFT] Sierra Wireless HSPA+ USB modem
On Fri, Jul 8, 2011 at 1:35 AM, Hans Petter Selasky wrote: > On Friday 08 July 2011 03:25:39 PseudoCylon wrote: >> On Thu, Jul 7, 2011 at 6:47 AM, Hans Petter Selasky > wrote: >> > On Thursday 07 July 2011 14:43:22 PseudoCylon wrote: >> >> On Wed, Jul 6, 2011 at 9:19 AM, Hans Petter Selasky >> > >> > wrote: >> >> >> Hi, >> >> >> >> >> >> I'm going to review and import your driver. >> >> >> >> >> >> --HPS >> >> > >> >> > Hi, >> >> > >> >> > The intial patch had some bad code and didn't compile on 9-current. >> >> > I've tried to clean it up. Please test and report back if I didn't >> >> > break anything. >> >> > >> >> > http://hselasky.homeunix.org:8192/usie_for_FreeBSD_9_current.patch >> >> > >> >> > --HPS >> >> >> >> Hello, >> >> > > Hi, > > Can I remove the mock DHCP client? > Yes, you can. I had a feeling of it won't go into the src tree. That's why it was in a separate file. The only drawback is now users have to manually set up the connection. Here is an updated how-to-use #ifconfig usie0 up IP and DNS addr will be printed on the console. Using those addr, #ifconfig usie0 inet N.N.N.N #ifconfig usie0 defaultif #echo "nameserver N.N.N.N" > /etc/resolv.conf One nemaserve is sufficient. #echo "nameserver N.N.N.N" >> /etc/resolv.conf And, I have tried the committed version of the driver, and it is working fine. Thanks for committing. 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: [CFT] Sierra Wireless HSPA+ USB modem
On Thu, Jul 7, 2011 at 6:47 AM, Hans Petter Selasky wrote:
> On Thursday 07 July 2011 14:43:22 PseudoCylon wrote:
>> On Wed, Jul 6, 2011 at 9:19 AM, Hans Petter Selasky
> wrote:
>> >> Hi,
>> >>
>> >> I'm going to review and import your driver.
>> >>
>> >> --HPS
>> >
>> > Hi,
>> >
>> > The intial patch had some bad code and didn't compile on 9-current. I've
>> > tried to clean it up. Please test and report back if I didn't break
>> > anything.
>> >
>> > http://hselasky.homeunix.org:8192/usie_for_FreeBSD_9_current.patch
>> >
>> > --HPS
>>
>> Hello,
>>
>> Thanks for the patch.
>>
>> if_usie.c
>> 241 if (usbd_lookup_id_by_uaa(usie_devs, sizeof(usie_devs), uaa) != 0)
>> 242 return; /* no device match */
>>
>> It should return non-zero on success, but somehow this caused the
>> process to exit, and modem stayed being a CD-ROM.
>
> Hi,
>
> Is this device changing its USB vendor and product ID ?
>
Yes, it does. So I added the device id for cd-rom, SIERRA, TRUINSTALL
(already in usbdevs).
static const STRUCT_USB_HOST_ID usie_devs[] = {
#define USIE_DEV(v, d) {\
USB_VP(USB_VENDOR_##v, USB_PRODUCT_##v##_##d) }
USIE_DEV(SIERRA, MC8700),
USIE_DEV(AIRPRIME, USB308),
+USIE_DEV(SIERRA, TRUINSTALL),
#undef USIE_DEV
};
Now it works even if the modem is plugged in before loading the
driver. The device id 0x0fff is for cd-rom, but sierra didn't specify
the vendor id. So, there might be (AIRPRIME, TRUINSTALL).
With your "uint8_t pad" fix, the driver works fine.
Thanks
AK
Here is a patch.
diff --git a/sys/dev/usb/net/if_usie.c b/sys/dev/usb/net/if_usie.c
index 552765b..f6f6c60 100644
--- a/sys/dev/usb/net/if_usie.c
+++ b/sys/dev/usb/net/if_usie.c
@@ -88,6 +88,7 @@ static const STRUCT_USB_HOST_ID usie_devs[] = {
USB_VP(USB_VENDOR_##v, USB_PRODUCT_##v##_##d) }
USIE_DEV(SIERRA, MC8700),
USIE_DEV(AIRPRIME, USB308),
+ USIE_DEV(SIERRA, TRUINSTALL),
#undef USIE_DEV
};
@@ -1522,8 +1523,9 @@ usie_hip_rsp(struct usie_softc *sc, uint8_t
*rsp, uint32_t len)
DPRINTF("hip: len=%d msgID=%02x, param=%02x\n",
be16toh(hip->len), hip->id, hip->param);
+ pad = (hip->id & USIE_HIP_PAD) ? 1 : 0;
+
if ((hip->id & USIE_HIP_MASK) == USIE_HIP_CNS2H) {
- pad = (hip->id & USIE_HIP_PAD) ? 1 : 0;
cns = (struct usie_cns *)(((uint8_t *)(hip + 1)) + pad);
if (j < (sizeof(struct usie_cns) +
___
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: [CFT] Sierra Wireless HSPA+ USB modem
On Wed, Jul 6, 2011 at 9:19 AM, Hans Petter Selasky wrote: >> >> Hi, >> >> I'm going to review and import your driver. >> >> --HPS > > Hi, > > The intial patch had some bad code and didn't compile on 9-current. I've tried > to clean it up. Please test and report back if I didn't break anything. > > http://hselasky.homeunix.org:8192/usie_for_FreeBSD_9_current.patch > > --HPS > Hello, Thanks for the patch. if_usie.c 241 if (usbd_lookup_id_by_uaa(usie_devs, sizeof(usie_devs), uaa) != 0) 242 return; /* no device match */ It should return non-zero on success, but somehow this caused the process to exit, and modem stayed being a CD-ROM. The compiler complained about uninitialized int if_usie.c: 1484 - uint8_t pad; + uint8_t pad = 0; Otherwise it worked fine. 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: [CFT] Sierra Wireless HSPA+ USB modem
- Original Message - > From: Hans Petter Selasky > To: freebsd-current@freebsd.org; PseudoCylon > Cc: "freebsd-wirel...@freebsd.org" > Sent: Tuesday, June 28, 2011 12:50:57 AM > Subject: Re: [CFT] Sierra Wireless HSPA+ USB modem > > On Tuesday 28 June 2011 06:58:37 PseudoCylon wrote: >> Hello >> >> Here is a driver for Sierra Wireless HSPA+ USB modem. Please test it. My >> subscription will expire on June 29, 2011. (Yes, it sounds silly.) So, try >> it before too late. >> >> source tree https://gitorious.org/usie/usie/trees/master >> tarball https://gitorious.org/usie/usie/archive-tarball/master >> >> The driver should work on CURRENT and 8.2 RELEASE. >> Supports only Direct IP supported models with device ID of 0x68a3 >> >> (Direct IP == the device has a port we can throw IP packets at, no need to >> use any serial port) A list of supported device names are posted on >> FreeBSD forum. >> http://forums.freebsd.org/showthread.php?p=138758#post138758 >> >> >> * How to use >> 0) add a following to somewhere in /usr/src/sys/dev/usbdevs >> product AIRPRIME USB3080x68A3 USB308 HSPA+ USB Modem >> 1) compile >> 2) #kldload usie >> 3) plugin the device (Make sure load the module first) >> 4) wait while the modem is going though power up cycle >> 5) #dhclient usie0 >> 6) surf >> >> * To disconnect >> #ifconfig usie0 down >> or >> #kldunload usie >> > > Hi, > > I'm going to review and import your driver. Thank you. BTW, U3G_DEV(SIERRA, MC8700, 0) in u3g.c and USIE_DEV(SIERRA,MC8700) in usie.c are referring the same device, and MC8700 should support direct IP. 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"
[CFT] Sierra Wireless HSPA+ USB modem
Hello Here is a driver for Sierra Wireless HSPA+ USB modem. Please test it. My subscription will expire on June 29, 2011. (Yes, it sounds silly.) So, try it before too late. source tree https://gitorious.org/usie/usie/trees/master tarball https://gitorious.org/usie/usie/archive-tarball/master The driver should work on CURRENT and 8.2 RELEASE. Supports only Direct IP supported models with device ID of 0x68a3 (Direct IP == the device has a port we can throw IP packets at, no need to use any serial port) A list of supported device names are posted on FreeBSD forum. http://forums.freebsd.org/showthread.php?p=138758#post138758 * How to use 0) add a following to somewhere in /usr/src/sys/dev/usbdevs product AIRPRIME USB3080x68A3 USB308 HSPA+ USB Modem 1) compile 2) #kldload usie 3) plugin the device (Make sure load the module first) 4) wait while the modem is going though power up cycle 5) #dhclient usie0 6) surf * To disconnect #ifconfig usie0 down or #kldunload usie 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: [CFT]RT28xx/RT30xx wireless was [CFR]RT305xF support, w/o attachment
> > rt28600: mem 0xf7f0-0xf7f0 irq 17 at > > device 0.0 on pci3 > > rt28600: invalid EEPROM LNA gain #2: 0x00 > > rt28600: invalid EEPROM LNA gain #3: 0x00 > > rt28600: invalid EEPROM powersave level > > rt28600: MAC/BBP RT2860 (rev 0x28720200), RF RT3022 2.4G 2T2R > Wow, your device have same revision 0x28720200 like embedded into > RT3052F system on chip. > So now I understand, why driver won't work with your card. > I previously expect that this id related only for SoC version, but SoC > version don't have many things that PCI version have (MCU, EEPROM, > etc.) > Hi, I have 0x28720200 calling rt2872_rf_set_chan() instead of rt2860_rf_set_chan(). And, 0x2000 for initial RT2860_REG_MAX_LEN value in rt2860_init_locked(). If these are correct I can patch the driver up. 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: [CFR]RT305xF support, w/o attachment
> >>
> >> I urge you to have a closer look at ral(4) and it's way of handling
> >> RT2500 and RT2600 specific differences. In it's simplest form you can
> >> copy the OpenBSD code 1:1 without any functional changes, heck, it's
> >> the source of this driver anyway.
> >>
> >> --
> >> Bernhard
>
> I've look on difference between RT2[56]00 and RT2860 some time ago, but done
>it again, and found that we can only place
> RT2860/RT3090 support under same name (ral), but hardware have too big
>difference. And in case I do this patch for RT3052F SoC,
> when I placing RT2860 into ral, i get completely different driver (because
> SoC
>don't use PCI interface).
>
>
> So can You (or someone else) hint me, how to done this?
>
> switch (what to do) {
> case 'Remake run to support PCI and SoC interface':
> Much work to make driver bus independent;
> case 'Port OpenBSD one':
> driver do not support SoC (SoC device don't have MCU);
> break;
> case 'Place my RT2860 under dev/ral':
> different device in same driver;
> break;
> }
>
I'd say porting OpenBSD's is smarter move than remaking run(4).
OpenBSD's ral(4) supports RT2800/RT3090,
http://www.openbsd.org/cgi-bin/man.cgi?apropos=0&sektion=4&query=ral&manpath=OpenBSD+Current&arch=i386&format=html
so ported code should nicely fit into FreeBSD's sys/dev/ral/ folder.
It seems pci related code is separated,
http://fxr.watson.org/fxr/source/dev/ral/
driver - pci code might nicely fit SoC code too.
FreeBSD's if_runreg.h is the same as OpenBSD's if_rt2860reg.h. (Though, I have
been ignoring syncing changes related to RT3090. run(4) doesn't supports it.)
In
fact, OpenBSD doesn't have if_runreg.h, instead they share if_rt2860reg.h. We
can separate, but >90% of them would be identical.
I don't have h/w but I might be able help you out non-SoC portion of code.
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: svn commit: r203134 - in head: share/man/man4 sys/conf sys/contrib/dev/run sys/dev/usb sys/dev/usb/wlan sys/modules sys/modules/runfw sys/modules/usb sys/modules/usb/run
> > > > hostname.if(5) is something that only exists in OpenBSD. > > I think the following would be better: > > For more information on configuring this device, see > > .Xr ifconfig 8 . > > > > Hi, > > This is still relevant. hostname.if(5) is in OBSD. > Will someone fix this? > > -- > wbr, > pluknet > > Yes, I'm working on it, and about to submit with runfw.4. If you have them a quick peak, it will be appreciated. http://gitorious.org/run/man/trees/master/man/man4 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
- Original Message > From: Rui Paulo > To: PseudoCylon > Cc: Bernhard Schmidt ; freebsd-current@freebsd.org; >Adrian Chadd > 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 > >> To: freebsd-current@freebsd.org > >> Cc: PseudoCylon ; Adrian Chadd > > >> 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 > >>>> To: PseudoCylon > >>>> 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 > > 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 &g
Re: RFT: if_ath HAL refactoring
- Original Message > From: Bernhard Schmidt > To: freebsd-current@freebsd.org > Cc: PseudoCylon ; Adrian Chadd > 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 > > > To: PseudoCylon > > > 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 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
- Original Message > From: Adrian Chadd > To: PseudoCylon > 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 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
> Message: 9 > Date: Sun, 19 Sep 2010 01:04:47 +0800 > From: Adrian Chadd > Subject: Re: RFT: if_ath HAL refactoring > To: Brandon Weisz > Cc: freebsd-current@freebsd.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > On 19 September 2010 01:01, Adrian Chadd 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: [panic] Race in IEEE802.11 layer towards device drivers
"FreeBSD and all other open source projects are the Tower of Babel in computer era." --me So, join me @ git://dev.nasreddine.com/run.git (or http://dev.nasreddine.com/gitweb/?p=run.git;a=summary ) Just work on any of *_dev branches. - Original Message > From: Hans Petter Selasky > To: freebsd-current@freebsd.org > Cc: PseudoCylon ; Sam Leffler ; >freebsd-...@freebsd.org > Sent: Wed, July 21, 2010 10:00:26 AM > Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers > > Hi, > > Please confirm that this patch is working for you: > > http://p4web.freebsd.org/@@181261?ac=10 > > --HPS > Confirmed it's properly been updated. 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: [panic] Race in IEEE802.11 layer towards device drivers
- Original Message
> From: Hans Petter Selasky
> To: PseudoCylon
> Cc: freebsd-current@freebsd.org; Sam Leffler ;
>freebsd-...@freebsd.org
> Sent: Tue, July 20, 2010 4:46:34 AM
> Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers
>
> On Tuesday 20 July 2010 12:03:22 PseudoCylon wrote:
> > - Original Message
> >
> > > From: Hans Petter Selasky
> > > To: freebsd-current@freebsd.org
> > > Cc: PseudoCylon ; Sam Leffler
;
> > >
> > >freebsd-...@freebsd.org
> > >
> > > Sent: Mon, July 19, 2010 1:17:04 PM
> > > Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers
> > >
> > > Hi AK,
> > >
> > > I've committed your patches to USB P4. I've made some additional
> > > patches.
> > >
> > > Can you check and verify everything?
> > >
> > > http://p4web.freebsd.org/@@181189?ac=10
> >
> > Hi
> >
> > If we change sc->cmdq_run = RUN_CMDQ_ABORT,
> >
> > -- begin excerpt --
> >
> >
> > @@ -4890,7 +4877,10 @@ run_stop(void *arg)
> > ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE);
> >
> > sc->ratectl_run = RUN_RATECTL_OFF;
> > -sc->cmdq_run = RUN_CMDQ_ABORT;
> > +
> > +RUN_CMDQ_LOCK(sc);
> > +sc->cmdq_run = sc->cmdq_key_set = RUN_CMDQ_ABORT;
> > +RUN_CMDQ_UNLOCK(sc);
> >
> > -- end excerpt --
> >
> >
> > we also need to change this, otherwise key will be cleared.
>
> Ok.
>
> Try to give the second mutex a different name, and see how many warnings go
> away.
>
> --HPS
>
Giving different name makes all of "duplicate lock" warnings away.
Here is the patch includes all changes
-- begin patch --
diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c
index 017e4b0..da22077 100644
--- a/dev/usb/wlan/if_run.c
+++ b/dev/usb/wlan/if_run.c
@@ -549,7 +549,7 @@ run_attach(device_t self)
mtx_init(&sc->sc_mtx, device_get_nameunit(sc->sc_dev),
MTX_NETWORK_LOCK, MTX_DEF);
mtx_init(&sc->sc_cmdq_mtx, device_get_nameunit(sc->sc_dev),
-MTX_NETWORK_LOCK, MTX_DEF);
+"command queue", MTX_DEF);
iface_index = RT2860_IFACE_INDEX;
@@ -4670,8 +4670,6 @@ run_init_locked(struct run_softc *sc)
if(ic->ic_nrunning > 1)
return;
-run_stop(sc);
-
for (ntries = 0; ntries < 100; ntries++) {
if (run_read(sc, RT2860_ASIC_VER_ID, &tmp) != 0)
goto fail;
-- end patch --
___
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: [panic] Race in IEEE802.11 layer towards device drivers
- Original Message
> From: Hans Petter Selasky
> To: freebsd-current@freebsd.org
> Cc: PseudoCylon ; Sam Leffler ;
>freebsd-...@freebsd.org
> Sent: Mon, July 19, 2010 1:17:04 PM
> Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers
>
> Hi AK,
>
> I've committed your patches to USB P4. I've made some additional patches.
>
> Can you check and verify everything?
>
> http://p4web.freebsd.org/@@181189?ac=10
>
Hi
If we change sc->cmdq_run = RUN_CMDQ_ABORT,
-- begin excerpt --
@@ -4890,7 +4877,10 @@ run_stop(void *arg)
ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE);
sc->ratectl_run = RUN_RATECTL_OFF;
-sc->cmdq_run = RUN_CMDQ_ABORT;
+
+RUN_CMDQ_LOCK(sc);
+sc->cmdq_run = sc->cmdq_key_set = RUN_CMDQ_ABORT;
+RUN_CMDQ_UNLOCK(sc);
-- end excerpt --
we also need to change this, otherwise key will be cleared.
-- begin patch --
diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c
index 017e4b0..f7abe17 100644
--- a/dev/usb/wlan/if_run.c
+++ b/dev/usb/wlan/if_run.c
@@ -4670,8 +4670,6 @@ run_init_locked(struct run_softc *sc)
if(ic->ic_nrunning > 1)
return;
-run_stop(sc);
-
for (ntries = 0; ntries < 100; ntries++) {
if (run_read(sc, RT2860_ASIC_VER_ID, &tmp) != 0)
goto fail;
-- end patch --
> Also please compile a kernel with WITNESS enabled to catch any LOR's, hence
> we
>
> introduced another mutex.
>
The 2nd mutex did solve a deadlock, but doesn't solve the LOR.
-- begin message --
lock order reversal:
1st 0xff8000a257d0 run0_node_lock (run0_node_lock) @
/usr/src/sys/net80211/ieee80211_node.c:1736
2nd 0xff8000a19348 run0 (network driver) @
/mnt/share/home/AK/FreeBSD/modules/usb/run/../../../../mnt/dev/usb/wlan/if_run.c:2212
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
run_key_delete() at run_key_delete+0x45
_ieee80211_crypto_delkey() at _ieee80211_crypto_delkey+0x9e
ieee80211_crypto_delkey() at ieee80211_crypto_delkey+0x28
ieee80211_node_delucastkey() at ieee80211_node_delucastkey+0x78
ieee80211_sta_leave() at ieee80211_sta_leave+0x16
ieee80211_node_leave() at ieee80211_node_leave+0x11d
hostap_recv_mgmt() at hostap_recv_mgmt+0x33f
hostap_input() at hostap_input+0xc09
run_rx_frame() at run_rx_frame+0x13f
run_bulk_rx_callback() at run_bulk_rx_callback+0x3b7
usbd_callback_wrapper() at usbd_callback_wrapper+0x12b
usb_command_wrapper() at usb_command_wrapper+0x76
usb_callback_proc() at usb_callback_proc+0x76
usb_process() at usb_process+0xbb
fork_exit() at fork_exit+0x12a
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff8029b4ed30, rbp = 0 ---
-- end message --
or
-- begin message --
lock order reversal:
1st 0xff8000a257d0 run0_node_lock (run0_node_lock) @
/usr/src/sys/net80211/ieee80211_node.c:1736
2nd 0xff8000a19348 run0 (network driver) @
/mnt/share/home/AK/FreeBSD/modules/usb/run/../../../../mnt/dev/usb/wlan/if_run.c:2212
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
run_key_delete() at run_key_delete+0x47
_ieee80211_crypto_delkey() at _ieee80211_crypto_delkey+0x9e
ieee80211_crypto_delkey() at ieee80211_crypto_delkey+0x28
ieee80211_node_delucastkey() at ieee80211_node_delucastkey+0x78
ieee80211_sta_leave() at ieee80211_sta_leave+0x16
ieee80211_node_leave() at ieee80211_node_leave+0x11d
ieee80211_node_timeout() at ieee80211_node_timeout+0x1d5
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 ---
-- end message --
There are new warning, "acquiring duplicate lock." For example,
-- begin message --
acquiring duplicate lock of same type: "network driver"
1st run0 @ /usr/src/sys/dev/usb/usb_request.c:691
2nd run0 @
/mnt/share/home/AK/FreeBSD/modules/usb/run/../../../../mnt/dev/usb/wlan/if_run.c:4831
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x8ef
_mtx_lock_flags() at _mtx_lock_flags+0x78
run_init_locked() at run_init_locked+0x753
run_ioctl() at run_ioctl+0xad
taskqueue_run() at taskqueue_run+0x91
taskqueue_thread_loop() at taskqueue_thread_loop+0x3f
fork_exit() at fork_exit+0x12a
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff803e5b2d30, rbp = 0 ---
-- end message --
I don't know if it's worth patching or safe to patch (specially lock/unlock in
Re: [panic] Race in IEEE802.11 layer towards device drivers
[NB] Obviously, I didn't click "reply ALL" last time, so here are missing part
> > > > -if(vap->iv_opmode == IEEE80211_M_HOSTAP){
> > > >
> > > > -RUN_LOCK(sc);
> > > > +if (vap->iv_opmode == IEEE80211_M_HOSTAP)
> > > >
> > > > sc->cmdq_key_set = RUN_CMDQ_GO;
> > > >
> > > > -RUN_UNLOCK(sc);
> > > > -}
> > > >
> > > >
> > > > Why are you removing these locks?
> >
> > It is simple assignment, it must be atomic.
>
> Not necessarily. If you don't put lock statements around it or use the
> volatile keyword, the compiler can re-organize the execution order. I will
> have a look at it.
>
> >
> > > Another question:
> > > i = RUN_CMDQ_GET(&sc->cmdq_store);
> > > DPRINTF("cmdq_store=%d\n", i);
> > >
> > >sc->cmdq[i].func = run_update_beacon_cb;
> > >sc->cmdq[i].arg0 = vap;
> > >
> > > Why is this code and similar places not enclosed with mutexes?
> >
> > First, I couldn't use a lock in key_delete() because of LoR. So, I use
> > atomic instead. RUN_CMDQ_GET is atomic_fetch_add(). Whatever executes that
> > code gets unique place (cmdq[i]) to write, so there shouldn't be any race.
> >
> > Then out of order execution happened. Specially, when key_set() overtakes
> > key_delete(), encryption fails. So, all deferred processes are called back
> > via run_cmdq_cb() to maintain the order. Because cmdq functions are first
> > written for key_delete() where lock causes LoR. So, lock isn't needed.
> >
> > run_cmdq_cb() uses lock. But it is for calling callback functions locked.
> > So that, functions just call another function locked, like
> > ##_callback()
> > {
> >LOCK();
> >##_locked();
> >UNLOCK();
> > }
> > won't be needed.
>
> If the run_cmdq_cb() is running at the same time which you are queuing
> elements, then I note that you set .func before .arg0. The ##_callback() code
> only checks if .func has been set. Actually the "i" increment should be after
> that you filled out the data, and then you see that you cannot use atomic. I
> think the most simple solution is to add another mutex, sc->sc_cmdq_mtx,
which
> protects the queue and it's associated data. Also, what do you do if the
queue
> wraps around? You should have a mechanism to prevent that, because you then
> might start executing commands in random order?
>
Here is a patch (patch against P4 if_run.c rev 14 and if_runvar.h rev 8)
-- begin patch --
diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c
index 8c96534..c988ad4 100644
--- a/dev/usb/wlan/if_run.c
+++ b/dev/usb/wlan/if_run.c
@@ -90,12 +90,6 @@ SYSCTL_INT(_hw_usb_run, OID_AUTO, debug, CTLFLAG_RW,
&run_debug, 0,
#define IEEE80211_HAS_ADDR4(wh) \
(((wh)->i_fc[1] & IEEE80211_FC1_DIR_MASK) == IEEE80211_FC1_DIR_DSTODS)
-/*
- * Because of LOR in run_key_delete(), use atomic instead.
- * '& RUN_CMDQ_MASQ' is to loop cmdq[].
- */
-#define RUN_CMDQ_GET(c)(atomic_fetchadd_32((c), 1) & RUN_CMDQ_MASQ)
-
static const struct usb_device_id run_devs[] = {
{ USB_VP(USB_VENDOR_ABOCOM,USB_PRODUCT_ABOCOM_RT2770) },
{ USB_VP(USB_VENDOR_ABOCOM,USB_PRODUCT_ABOCOM_RT2870) },
@@ -554,6 +548,8 @@ run_attach(device_t self)
mtx_init(&sc->sc_mtx, device_get_nameunit(sc->sc_dev),
MTX_NETWORK_LOCK, MTX_DEF);
+mtx_init(&sc->sc_cmdq_mtx, device_get_nameunit(sc->sc_dev),
+MTX_NETWORK_LOCK, MTX_DEF);
iface_index = RT2860_IFACE_INDEX;
@@ -737,6 +733,7 @@ run_detach(device_t self)
}
mtx_destroy(&sc->sc_mtx);
+mtx_destroy(&sc->sc_cmdq_mtx);
return (0);
}
@@ -830,9 +827,6 @@ run_vap_create(struct ieee80211com *ic,
if(sc->rvp_cnt++ == 0)
ic->ic_opmode = opmode;
-if(opmode == IEEE80211_M_HOSTAP)
-sc->cmdq_run = RUN_CMDQ_GO;
-
DPRINTF("rvp_id=%d bmap=%x rvp_cnt=%d\n",
rvp->rvp_id, sc->rvp_bmap, sc->rvp_cnt);
@@ -889,27 +883,31 @@ run_cmdq_cb(void *arg, int pending)
struct run_softc *sc = arg;
uint8_t i;
-/* call cmdq[].func locked */
-RUN_LOCK(sc);
-for(i = sc->cmdq_exec; sc->cmdq[i].func && pending;
-i = sc->cmdq_exec, pending--){
+RUN_CMDQ_LOCK(sc);
+for (i = sc->cmdq_exec; sc->cmdq[i].func; i = sc->cmdq_exec) {
DPRINTFN(6, "cmdq_exec=%d pending=%d\n", i, pending);
-if(sc->cmdq_run == RUN_CMDQ_GO){
+if (sc->cmdq_run == RUN_CMDQ_GO ||
+(sc->cmdq_key_set == RUN_CMDQ_GO &&
+sc->cmdq[i].func == run_key_set_cb)) {
+RUN_CMDQ_UNLOCK(sc);
+RUN_LOCK(sc);
/*
* If arg0 is NULL, callback func needs more
* than one arg. So, pass ptr to cmdq struct.
*/
-if(sc->cmdq[i].arg0)
+if (sc->cmdq[i].arg0)
sc->cmdq[i].func(sc->cmdq[i].arg0);
else
sc->cmdq[i].func(&sc->cmdq[i]);
+RUN_UNLOCK(sc);
+RUN_CMDQ_LOCK(sc);
}
sc->cmdq[i].arg0 = NULL;
sc->cmdq[i].func = NULL;
sc->cmdq_exec++;
sc->cmdq_exec &= RUN_CMDQ_MASQ;
}
-RUN_UNLOCK(sc);
+RUN_CMDQ_UNLOCK(sc);
}
static void
@@ -1771,6 +1769,19 @@ run_newstate(struct ieee80211vap *vap, enum
ieee80211_state nstate, int arg)
case IEEE80211_S_INIT:
restart_ratectl = 1;
+/*
+ * When hostapd has set a key, don't clear it.
+ * But, when the devic
Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message > From: Ganbold > To: PseudoCylon > Cc: Ganbold Tsagaankhuu ; freebsd-current@freebsd.org > Sent: Tue, July 13, 2010 11:04:59 AM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > > PseudoCylon wrote: > > - Original Message > > > >> From: PseudoCylon > >> To: Ganbold Tsagaankhuu > >> Cc: Ganbold ; freebsd-current@freebsd.org > >> Sent: Tue, July 6, 2010 12:26:58 AM > >> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > >> > >> > >>>>>>>> From: Ganbold > >>>>>>>> To: PseudoCylon > >>>>>>>> Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu > >>>>>>>> > >> > >> > >>>>>>>> Sent: Wed, June 16, 2010 6:33:47 AM > >>>>>>>> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > >>>>>>>> > >>>>>>>> AK-san, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> PseudoCylon wrote: > >>>>>>> > >>>>>>> Strange, looks like this time works as expected, but sometimes it > >>>>>>> doesn'twork. > >>>>>>> > >>>>>>> In some cases it doesn't work and you can find complete tcpdump >output > >>>>>>> from very beginning to the modem hang: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> Are following true? > >>>>>> When manually load/reload hostapd, works > >>>>>> When loaded by rc.conf, doesn't work > >>>>>> > >>>>>> If so, please try attached patch. (patch to if_run.c only) Or, here > >>>>>> is >a > > >>>>>> > >> patched file. > >> > >>>>>> http://gitorious.org/run/run/blobs/raw/cmdq_fix/dev/usb/wlan/if_run.c > >>>>>> > >>>>>> When auto-loading, the driver is brought up and down a few times. It > >>>>>> > >> might be the cause. > >> > >>>>>> > >>>>>> > >>>>> I will test it few more days and let you know. > >>>>> > >>>>> thanks, > >>>>> > >>>>> Ganbold > >>>>> > >>>>> > >>>> Hello, > >>>> > >>>> How is the patch doing on your rspro? Is it working well? > >>>> > >>>> > >>> Sorry for late response. Due to business trip I tested couple of times > >>> only and it seems working relatively ok. 1-2 times ADSL modem hang, but > >>> seemed like after 3-4 hours. > >>> Tried couple of times again, but I couldn't reproduce it. I will try to > >>> reproduce it and let you know the results. > >>> > >>> thanks a lot, > >>> > >>> Ganbold > >>> > > Hello, Ganbold > > > > Is the latest patch working? > > > > AK-san, > > Only tested once, the patch works ok so far. > > thanks, > > Ganbold > Good to hear. If anything goes wrong please report. Thanks for testing. 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: [panic] Race in IEEE802.11 layer towards device drivers
- Original Message
> From: Hans Petter Selasky
> To: freebsd-current@freebsd.org
> Cc: Andrew Thompson ; Sam Leffler ;
>PseudoCylon ; freebsd-...@freebsd.org
> Sent: Mon, July 12, 2010 2:01:11 PM
> Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers
>
> Hi Andrew,
>
> Your patch appears to be working. Can you fix this issue in the other WLAN
> drivers aswell? Then send an e-mail to request testing? I had a go at it
here:
>
> http://p4web.freebsd.org/@@180844?ac=10
>
Can this patch be included into testing? patch to P4 USB rev. 14 if_run.c
If not, at least please delete an extra semicolon at the end of line 3191 (must
be an merge bug). I missed it since it wans't in diff/patch.
AK
summary of changes
* fixes bugs in rev 209144
a shared key was written properly only on first time init, but not
subsequent
init. Make sure the key is written all the time.
* stop checking 'pending' in run_cmdq_cb().
When loop 'pending' times, new tasks enqueued while looping won't be
executed
because 'pending' passed from taskqueue function won't be incremented.
-- patch begin --
diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c
index 7a3952c..12b45ec 100644
--- a/dev/usb/wlan/if_run.c
+++ b/dev/usb/wlan/if_run.c
@@ -830,9 +830,6 @@ run_vap_create(struct ieee80211com *ic,
if(sc->rvp_cnt++ == 0)
ic->ic_opmode = opmode;
-if(opmode == IEEE80211_M_HOSTAP)
-sc->cmdq_run = RUN_CMDQ_GO;
-
DPRINTF("rvp_id=%d bmap=%x rvp_cnt=%d\n",
rvp->rvp_id, sc->rvp_bmap, sc->rvp_cnt);
@@ -891,15 +888,16 @@ run_cmdq_cb(void *arg, int pending)
/* call cmdq[].func locked */
RUN_LOCK(sc);
-for(i = sc->cmdq_exec; sc->cmdq[i].func && pending;
-i = sc->cmdq_exec, pending--){
+for (i = sc->cmdq_exec; sc->cmdq[i].func; i = sc->cmdq_exec) {
DPRINTFN(6, "cmdq_exec=%d pending=%d\n", i, pending);
-if(sc->cmdq_run == RUN_CMDQ_GO){
+if (sc->cmdq_run == RUN_CMDQ_GO ||
+(sc->cmdq_key_set == RUN_CMDQ_GO &&
+sc->cmdq[i].func == run_key_set_cb)) {
/*
* If arg0 is NULL, callback func needs more
* than one arg. So, pass ptr to cmdq struct.
*/
-if(sc->cmdq[i].arg0)
+if (sc->cmdq[i].arg0)
sc->cmdq[i].func(sc->cmdq[i].arg0);
else
sc->cmdq[i].func(&sc->cmdq[i]);
@@ -1771,6 +1769,19 @@ run_newstate(struct ieee80211vap *vap, enum
ieee80211_state nstate, int arg)
case IEEE80211_S_INIT:
restart_ratectl = 1;
+/*
+ * When hostapd has set a key, don't clear it.
+ * But, when the device is being brought down, clear it.
+ */
+if (sc->cmdq_key_set != RUN_CMDQ_GO ||
+ostate == IEEE80211_S_RUN) {
+/* clear shared key table */
+run_set_region_4(sc,
+RT2860_SKEY(rvp->rvp_id, 0), 0, 4 * 32);
+/* clear shared key mode */
+run_set_region_4(sc, RT2860_SKEY_MODE_0_7, 0, 4);
+}
+
if (ostate != IEEE80211_S_RUN)
break;
@@ -2100,13 +2111,10 @@ run_key_set(struct ieee80211vap *vap, struct
ieee80211_key *k,
* To make sure key will be set when hostapd
* calls iv_key_set() before if_init().
*/
-if(vap->iv_opmode == IEEE80211_M_HOSTAP){
-RUN_LOCK(sc);
+if (vap->iv_opmode == IEEE80211_M_HOSTAP)
sc->cmdq_key_set = RUN_CMDQ_GO;
-RUN_UNLOCK(sc);
-}
-return(1);
+return (1);
}
/*
@@ -3188,7 +3196,7 @@ run_sendprot(struct run_softc *sc,
ackrate = ieee80211_ack_rate(ic->ic_rt, rate);
isshort = (ic->ic_flags & IEEE80211_F_SHPREAMBLE) != 0;
-dur = ieee80211_compute_duration(ic->ic_rt, pktlen, rate, isshort);
+dur = ieee80211_compute_duration(ic->ic_rt, pktlen, rate, isshort)
+ ieee80211_ack_duration(ic->ic_rt, rate, isshort);
wflags = RT2860_TX_FRAG;
@@ -4693,14 +4701,6 @@ run_init_locked(struct run_softc *sc)
/* clear WCID attribute table */
run_set_region_4(sc, RT2860_WCID_ATTR(0), 0, 8 * 32);
-/* hostapd sets a key before init. So, don't clear it. */
-if(sc->cmdq_key_set != RUN_CMDQ_GO){
-/* clear shared key table */
-run_set_region_4(sc, RT2860_SKEY(0, 0), 0, 8 * 32);
-/* clear shared key mode */
-run_set_region_4(sc, RT2860_SKEY_MODE_0_7, 0, 4);
-}
-
run_read(sc, RT2860_US_CYC_CNT, &tmp);
tmp = (tmp & ~0xff) | 0x1e;
run_write(sc, RT2860_US_CYC_CNT, tmp);
@@ -4807,7 +4807,7 @@ run_stop(void *arg)
ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE);
sc->ratectl_run = RUN_RATECTL_OFF;
-sc->cmdq_run = sc->cmdq_key_set;
+sc->cmdq_run = RUN_CMDQ_ABORT;
RUN_UNLOCK(sc);
-- end patch --
___
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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message
> From: PseudoCylon
> To: Ganbold Tsagaankhuu
> Cc: Ganbold ; freebsd-current@freebsd.org
> Sent: Tue, July 6, 2010 12:26:58 AM
> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
>
> >>>>>> From: Ganbold
> >>>>>> To: PseudoCylon
> >>>>>> Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu
>
> >>>>>> Sent: Wed, June 16, 2010 6:33:47 AM
> >>>>>> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
> >>>>>>
> >>>>>> AK-san,
> >>>>>>
> >>>>>>
> >>>>> PseudoCylon wrote:
> >>>>>
> >>>>> Strange, looks like this time works as expected, but sometimes it
> >>>>> doesn't work.
> >>>>>
> >>>>> In some cases it doesn't work and you can find complete tcpdump output
> >>>>> from very beginning to the modem hang:
> >>>>>
> >>>>>
> >>>>>
> >>>> Hello,
> >>>>
> >>>> Are following true?
> >>>> When manually load/reload hostapd, works
> >>>> When loaded by rc.conf, doesn't work
> >>>>
> >>>> If so, please try attached patch. (patch to if_run.c only) Or, here is
> >>>> a
>patched file.
> >>>> http://gitorious.org/run/run/blobs/raw/cmdq_fix/dev/usb/wlan/if_run.c
> >>>>
> >>>> When auto-loading, the driver is brought up and down a few times. It
>might be the cause.
> >>>>
> >>> I will test it few more days and let you know.
> >>>
> >>> thanks,
> >>>
> >>> Ganbold
> >>>
> >> Hello,
> >>
> >> How is the patch doing on your rspro? Is it working well?
> >>
> >
> >Sorry for late response. Due to business trip I tested couple of times
> >only and it seems working relatively ok. 1-2 times ADSL modem hang, but
> >seemed like after 3-4 hours.
> >Tried couple of times again, but I couldn't reproduce it. I will try to
> >reproduce it and let you know the results.
> >
> >thanks a lot,
> >
> >Ganbold
>
Hello, Ganbold
Is the latest patch working?
AK
> Hello,
>
> I say every one has a job.
>
> At least it's start up OK, right?
>
> Can you try attached patch? (patch to if_run.c you currently using) Or, here
>is a patched file
> http://gitorious.org/run/run/blobs/raw/cmdq_fix/dev/usb/wlan/if_run.c
>
> I encountered similar problem about 5 days ago. It kind of hard to
> reproduce.
>A couple of things have to happen at the right (or wrong) time.
>
> If the modem still hangs at the start up, please let me know. That means the
>last patch isn't working.
>
> AK
>
> -- begin patch --
>
> diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c
> index f302246..e5a2a4d 100644
> --- a/dev/usb/wlan/if_run.c
> +++ b/dev/usb/wlan/if_run.c
> @@ -888,8 +888,7 @@ run_cmdq_cb(void *arg, int pending)
>
> /* call cmdq[].func locked */
> RUN_LOCK(sc);
> -for(i = sc->cmdq_exec; sc->cmdq[i].func && pending;
> -i = sc->cmdq_exec, pending--){
> +for(i = sc->cmdq_exec; sc->cmdq[i].func; i = sc->cmdq_exec){
> DPRINTFN(6, "cmdq_exec=%d pending=%d\n", i, pending);
> if(sc->cmdq_run == RUN_CMDQ_GO ||
> (sc->cmdq_key_set == RUN_CMDQ_GO &&
>
> -- end patch --
>
>
>
>
___
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: [panic] Race in IEEE802.11 layer towards device drivers
- Original Message > From: Hans Petter Selasky > To: freebsd-current@freebsd.org > Cc: Andrew Thompson ; Sam Leffler ; >PseudoCylon ; freebsd-...@freebsd.org > Sent: Mon, July 12, 2010 2:01:11 PM > Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers > > Hi Andrew, > > Your patch appears to be working. Can you fix this issue in the other WLAN > drivers aswell? Then send an e-mail to request testing? I had a go at it here: > > http://p4web.freebsd.org/@@180844?ac=10 > Since I wasn't able to reproduce the panic, I can only confirm the patched run(4) driver runs OK. I just want to patch hostap related fix before calling for this test. I'll ask the user if it's fixed. Should the debugging code, usb_pause_mtx(), be left in the code for testing? If the drivers don't panic to begin with, we won't know the patch really fixed the issue. AK > I found another panic issue: > > ifconfig wlan0 delete > ifconfig wlan0 destroy > > When not associate or associated. > > Backtrace (AMD64 - 9-current): > > node_free() + 0x2c > rum_tx_free() + 0x3b > which is called from the bulk tx callback > > Another thread is running an IOCTL -> rum_stop(), which causes the CANCELLED > event to be passed to USB. Can't we free any nodes at this point? > > --HPS > > > This turned out to be refcounting of the ieee80211_node struct which > > was causing this panic. vap->iv_bss can be freed at any time so all > > users of it need to bump the refcount to use it safely. > > > > This patch should fix the panic in the rum driver. > > http://people.freebsd.org/~thompsa/rum_node_refcnt.diff > > > > There are other places where it is still an issue such as the > > ieee80211_tx_mgt_timeout callout which havnt been addressed yet, and > > of course all other ieee80211 drivers. > > > ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message > From: Hans Petter Selasky > To: freebsd-current@freebsd.org > Cc: PseudoCylon ; Ganbold Tsagaankhuu >; Ganbold > Sent: Tue, July 6, 2010 12:54:31 AM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > Hello PseudoCylon is here. Unfortunately it successfully associates without an error. > Hi, > > PseudoCylon: Can you try to reproduce this: > > 1) Setup OPEN HOST AP (ssid = xxx). > > 2) Configure WLAN client with: > > ssid=xxx > auth_alg=SHARED > key_mgmt=NONE > > Wait until wpa_cli announces that it tries to associate, but fails. > This didn't happen. wpa_cli didn't say anything, just keep re-scanning. There was a change in wpa. So, I'll rebuilt world and retry > 3) Then update wpa_supplicant.conf: > > ssid=xxx > auth_alg=OPEN > key_mgmt=NONE > > 4) Enter: "reconfigure" in wpa_cli (panic should happen shortly due to > callback from IEEE802.11 layer which appears to refer a NULL pointer). > > --HPS > For now, do you have any error message? And, are you using committed version of the driver or testing the patch? 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
>>>>>> From: Ganbold
>>>>>> To: PseudoCylon
>>>>>> Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu
>>>>>> Sent: Wed, June 16, 2010 6:33:47 AM
>>>>>> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
>>>>>>
>>>>>> AK-san,
>>>>>>
>>>>>>
>>>>> PseudoCylon wrote:
>>>>>
>>>>> Strange, looks like this time works as expected, but sometimes it
>>>>> doesn't work.
>>>>>
>>>>> In some cases it doesn't work and you can find complete tcpdump output
>>>>> from very beginning to the modem hang:
>>>>>
>>>>>
>>>>>
>>>> Hello,
>>>>
>>>> Are following true?
>>>> When manually load/reload hostapd, works
>>>> When loaded by rc.conf, doesn't work
>>>>
>>>> If so, please try attached patch. (patch to if_run.c only) Or, here is a
>>>> patched file.
>>>> http://gitorious.org/run/run/blobs/raw/cmdq_fix/dev/usb/wlan/if_run.c
>>>>
>>>> When auto-loading, the driver is brought up and down a few times. It might
>>>> be the cause.
>>>>
>>> I will test it few more days and let you know.
>>>
>>> thanks,
>>>
>>> Ganbold
>>>
>> Hello,
>>
>> How is the patch doing on your rspro? Is it working well?
>>
>
>Sorry for late response. Due to business trip I tested couple of times
>only and it seems working relatively ok. 1-2 times ADSL modem hang, but
>seemed like after 3-4 hours.
>Tried couple of times again, but I couldn't reproduce it. I will try to
>reproduce it and let you know the results.
>
>thanks a lot,
>
>Ganbold
Hello,
I say every one has a job.
At least it's start up OK, right?
Can you try attached patch? (patch to if_run.c you currently using) Or, here is
a patched file
http://gitorious.org/run/run/blobs/raw/cmdq_fix/dev/usb/wlan/if_run.c
I encountered similar problem about 5 days ago. It kind of hard to reproduce. A
couple of things have to happen at the right (or wrong) time.
If the modem still hangs at the start up, please let me know. That means the
last patch isn't working.
AK
-- begin patch --
diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c
index f302246..e5a2a4d 100644
--- a/dev/usb/wlan/if_run.c
+++ b/dev/usb/wlan/if_run.c
@@ -888,8 +888,7 @@ run_cmdq_cb(void *arg, int pending)
/* call cmdq[].func locked */
RUN_LOCK(sc);
-for(i = sc->cmdq_exec; sc->cmdq[i].func && pending;
-i = sc->cmdq_exec, pending--){
+for(i = sc->cmdq_exec; sc->cmdq[i].func; i = sc->cmdq_exec){
DPRINTFN(6, "cmdq_exec=%d pending=%d\n", i, pending);
if(sc->cmdq_run == RUN_CMDQ_GO ||
(sc->cmdq_key_set == RUN_CMDQ_GO &&
-- end patch --
___
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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
>>>> From: Ganbold >>>> To: PseudoCylon >>>> Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu >>>> Sent: Wed, June 16, 2010 6:33:47 AM >>>> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless >>>> >>>> AK-san, >>>> >>> PseudoCylon wrote: >>> >>> Strange, looks like this time works as expected, but sometimes it >>> doesn't work. >>> >>> In some cases it doesn't work and you can find complete tcpdump output >>> from very beginning to the modem hang: >>> >>> >> >> Hello, >> >> Are following true? >> When manually load/reload hostapd, works >> When loaded by rc.conf, doesn't work >> >> If so, please try attached patch. (patch to if_run.c only) Or, here is a >> patched file. >> http://gitorious.org/run/run/blobs/raw/cmdq_fix/dev/usb/wlan/if_run.c >> >> When auto-loading, the driver is brought up and down a few times. It might >> be the cause. > >I will test it few more days and let you know. > >thanks, > >Ganbold Hello, How is the patch doing on your rspro? Is it working well? 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message
>> From: Ganbold
>> To: PseudoCylon
>> Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu
>> Sent: Wed, June 16, 2010 6:33:47 AM
>> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
>>
>> AK-san,
>
>PseudoCylon wrote:
>>>>
>>>
>
>Strange, looks like this time works as expected, but sometimes it
>doesn't work.
>
>In some cases it doesn't work and you can find complete tcpdump output
> from very beginning to the modem hang:
>
Hello,
Are following true?
When manually load/reload hostapd, works
When loaded by rc.conf, doesn't work
If so, please try attached patch. (patch to if_run.c only) Or, here is a
patched file.
http://gitorious.org/run/run/blobs/raw/cmdq_fix/dev/usb/wlan/if_run.c
When auto-loading, the driver is brought up and down a few times. It might be
the cause. So, when you test, please reboot rspro and let rc.conf handle init
process rather than manually start driver/hostapd. And
#arp -d -a
on rspro, freebsd laptop. and macbook would help for testing. (If it works on
mac) So, that clients have to send arp request. If macbook receives "who-has
192.168.1.50" arp request packets, it should work. If macbook supports
# tcpdump -vv -xxx -i wlan0 'arp'
and see if macbook gets this.
19:34:30.469720 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.1.50 tell 192.168.1.1, length 46
0x: 0030 5462 3d24 0806 0001
0x0010: 0800 0604 0001 0030 5462 3d24 c0a8 0101
0x0020: c0a8 0132
0x0030:
AK
-- begin patch --
diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c
index e4fc8d2..f302246 100644
--- a/dev/usb/wlan/if_run.c
+++ b/dev/usb/wlan/if_run.c
@@ -17,7 +17,7 @@
*/
#include
-__FBSDID("$FreeBSD: src/sys/dev/usb/wlan/if_run.c,v 1.11 2010/06/14 23:01:50
jkim Exp $");
+__FBSDID("$FreeBSD$");
/*-
* Ralink Technology RT2700U/RT2800U/RT3000U chipset driver.
@@ -830,9 +830,6 @@ run_vap_create(struct ieee80211com *ic,
if(sc->rvp_cnt++ == 0)
ic->ic_opmode = opmode;
-if(opmode == IEEE80211_M_HOSTAP)
-sc->cmdq_run = RUN_CMDQ_GO;
-
DPRINTF("rvp_id=%d bmap=%x rvp_cnt=%d\n",
rvp->rvp_id, sc->rvp_bmap, sc->rvp_cnt);
@@ -894,7 +891,9 @@ run_cmdq_cb(void *arg, int pending)
for(i = sc->cmdq_exec; sc->cmdq[i].func && pending;
i = sc->cmdq_exec, pending--){
DPRINTFN(6, "cmdq_exec=%d pending=%d\n", i, pending);
-if(sc->cmdq_run == RUN_CMDQ_GO){
+if(sc->cmdq_run == RUN_CMDQ_GO ||
+(sc->cmdq_key_set == RUN_CMDQ_GO &&
+sc->cmdq[i].func == run_key_set_cb)){
/*
* If arg0 is NULL, callback func needs more
* than one arg. So, pass ptr to cmdq struct.
@@ -4798,7 +4797,7 @@ run_stop(void *arg)
ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE);
sc->ratectl_run = RUN_RATECTL_OFF;
-sc->cmdq_run = sc->cmdq_key_set;
+sc->cmdq_run = RUN_CMDQ_ABORT;
RUN_UNLOCK(sc);
-- end patch --
___
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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message > From: Ganbold > To: PseudoCylon > Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu > Sent: Tue, June 15, 2010 8:02:02 AM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > > AK-san, >PseudoCylon wrote: >>>>> From: Ganbold >>>>> To: PseudoCylon >>>>> Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu >>>>> Sent: Thu, June 10, 2010 10:53:30 AM >>>>> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless >>>>> >>>>> It seems like it is running without any problem so far, no more adsl >>>>> modem problem. >>>>> I can see arp packets in wlan0 interface as well as in macbook. >>>>> I will continue testing and let you know if there comes any problem. >>>>> >>>>> thanks again, >>>>> >>>>> Ganbold >>>>> >>>>> >>>> Hello, >>>> >>>> Glad to hear. It was an encryption problem. A client was dropping packets.. >>>> >>>> Please let me know if you find another bug. (Hope there won't be) >>>> >>>> >>> Well, looks like I was too fast :( >>> >>> It seems like client is not receiving any arp packets when rspro doesn't >>> first initiate ping (maybe arp request) to client. >>> If I first ping to client from rspro, later on arp packets can be seen >>> on client. >>> When I ping from rspro to client, response is very different: >>> >>> # arp -a >>> ? (192.168.1.43) at 8e:fd:59:d6:3a:50 on bridge0 permanent [bridge] >>> ? (192.168.1.42) at 00:22:cf:03:e0:30 on wlan0 permanent [ethernet] >>> ? (192.168.1.41) at 00:15:6d:c1:c7:77 on arge0 permanent [ethernet] >>> ? (192.168.1.1) at 00:30:54:62:3d:24 on arge0 expires in 1200 seconds >>> [ethernet] >>> ? (192.168.1.7) at 00:1c:25:9d:36:1d on arge0 expires in 824 seconds >>> [ethernet] >>> # ping 192.168.1.50 >>> PING 192.168.1.50 (192.168.1.50): 56 data bytes >>> 64 bytes from 192.168.1.50: icmp_seq=0 ttl=64 time=2.694 ms >>> 64 bytes from 192.168.1.50: icmp_seq=1 ttl=64 time=302.177 ms >>> 64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=1.041 ms >>> 64 bytes from 192.168.1.50: icmp_seq=4 ttl=64 time=5234.417 ms >>> 64 bytes from 192.168.1.50: icmp_seq=5 ttl=64 time=4225.060 ms >>> 64 bytes from 192.168.1.50: icmp_seq=6 ttl=64 time=3214.908 ms >>> 64 bytes from 192.168.1.50: icmp_seq=7 ttl=64 time=2207.241 ms >>> 64 bytes from 192.168.1.50: icmp_seq=8 ttl=64 time=1197.061 ms >>> 64 bytes from 192.168.1.50: icmp_seq=9 ttl=64 time=186.833 ms >>> ^C >>> --- 192.168.1.50 ping statistics --- >>> 11 packets transmitted, 9 packets received, 18.2% packet loss >>> round-trip min/avg/max/stddev = 1.041/1841.270/5234.417/1870.962 ms >>> # arp -a >>> ? (192.168.1.43) at 8e:fd:59:d6:3a:50 on bridge0 permanent [bridge] >>> ? (192.168.1.42) at 00:22:cf:03:e0:30 on wlan0 permanent [ethernet] >>> ? (192.168.1.41) at 00:15:6d:c1:c7:77 on arge0 permanent [ethernet] >>> ? (192.168.1.1) at 00:30:54:62:3d:24 on arge0 expires in 1183 seconds >>> [ethernet] >>> ? (192.168.1.7) at 00:1c:25:9d:36:1d on arge0 expires in 805 seconds >>> [ethernet] >>> ? (192.168.1.50) at 00:26:bb:17:f6:61 on arge0 expires in 1186 seconds >>> [ethernet] >>> # ping 192.168.1.50 >>> PING 192.168.1.50 (192.168.1.50): 56 data bytes >>> 64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=1590.035 ms >>> 64 bytes from 192.168.1.50: icmp_seq=3 ttl=64 time=580.201 ms >>> 64 bytes from 192.168.1.50: icmp_seq=4 ttl=64 time=528.019 ms >>> ^C >>> --- 192.168.1.50 ping statistics --- >>> 5 packets transmitted, 3 packets received, 40.0% packet loss >>> round-trip min/avg/max/stddev = 528.019/899.418/1590.035/488.804 ms >>> >>> >> >> Well, the patch is working (sort of). Old driver wouldn't let you ping >> anywhere. >> >> Replies are taking awfully long. One of them took 5 sec. This could be a >> different issue. >> >> Can you try a few thing? (Unfortunately, everything is working on my side.) >> * Before ping from rspro, does ping from macbook to 192.168.1.42 (wlan0) >> work? >> > >No. I will check again and let you know. > >> * If you give IP address to only bridge0, does it make any difference? >> > >I will let you know a
Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
>>> From: Ganbold >>> To: PseudoCylon >>> Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu >>> Sent: Thu, June 10, 2010 10:53:30 AM >>> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless >>> >>> It seems like it is running without any problem so far, no more adsl >>> modem problem. >>> I can see arp packets in wlan0 interface as well as in macbook. >>> I will continue testing and let you know if there comes any problem. >>> >>> thanks again, >>> >>> Ganbold >>> >> >> Hello, >> >> Glad to hear. It was an encryption problem. A client was dropping packets.. >> >> Please let me know if you find another bug. (Hope there won't be) >> > >Well, looks like I was too fast :( > >It seems like client is not receiving any arp packets when rspro doesn't >first initiate ping (maybe arp request) to client. >If I first ping to client from rspro, later on arp packets can be seen >on client. >When I ping from rspro to client, response is very different: > ># arp -a >? (192.168.1.43) at 8e:fd:59:d6:3a:50 on bridge0 permanent [bridge] >? (192.168.1.42) at 00:22:cf:03:e0:30 on wlan0 permanent [ethernet] >? (192.168.1.41) at 00:15:6d:c1:c7:77 on arge0 permanent [ethernet] >? (192.168.1.1) at 00:30:54:62:3d:24 on arge0 expires in 1200 seconds >[ethernet] >? (192.168.1.7) at 00:1c:25:9d:36:1d on arge0 expires in 824 seconds >[ethernet] ># ping 192.168.1.50 >PING 192.168.1.50 (192.168.1.50): 56 data bytes >64 bytes from 192.168.1.50: icmp_seq=0 ttl=64 time=2.694 ms >64 bytes from 192.168.1.50: icmp_seq=1 ttl=64 time=302.177 ms >64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=1.041 ms >64 bytes from 192.168.1.50: icmp_seq=4 ttl=64 time=5234.417 ms >64 bytes from 192.168.1.50: icmp_seq=5 ttl=64 time=4225.060 ms >64 bytes from 192.168.1.50: icmp_seq=6 ttl=64 time=3214.908 ms >64 bytes from 192.168.1.50: icmp_seq=7 ttl=64 time=2207.241 ms >64 bytes from 192.168.1.50: icmp_seq=8 ttl=64 time=1197.061 ms >64 bytes from 192.168.1.50: icmp_seq=9 ttl=64 time=186.833 ms >^C >--- 192.168.1.50 ping statistics --- >11 packets transmitted, 9 packets received, 18.2% packet loss >round-trip min/avg/max/stddev = 1.041/1841.270/5234.417/1870.962 ms ># arp -a >? (192.168.1.43) at 8e:fd:59:d6:3a:50 on bridge0 permanent [bridge] >? (192.168.1.42) at 00:22:cf:03:e0:30 on wlan0 permanent [ethernet] >? (192.168.1.41) at 00:15:6d:c1:c7:77 on arge0 permanent [ethernet] >? (192.168.1.1) at 00:30:54:62:3d:24 on arge0 expires in 1183 seconds >[ethernet] >? (192.168.1.7) at 00:1c:25:9d:36:1d on arge0 expires in 805 seconds >[ethernet] >? (192.168.1.50) at 00:26:bb:17:f6:61 on arge0 expires in 1186 seconds >[ethernet] ># ping 192.168.1.50 >PING 192.168.1.50 (192.168.1.50): 56 data bytes >64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=1590.035 ms >64 bytes from 192.168.1.50: icmp_seq=3 ttl=64 time=580.201 ms >64 bytes from 192.168.1.50: icmp_seq=4 ttl=64 time=528.019 ms >^C >--- 192.168.1.50 ping statistics --- >5 packets transmitted, 3 packets received, 40.0% packet loss >round-trip min/avg/max/stddev = 528.019/899.418/1590.035/488.804 ms > Well, the patch is working (sort of). Old driver wouldn't let you ping anywhere. Replies are taking awfully long. One of them took 5 sec. This could be a different issue. Can you try a few thing? (Unfortunately, everything is working on my side.) * Before ping from rspro, does ping from macbook to 192.168.1.42 (wlan0) work? * If you give IP address to only bridge0, does it make any difference? * Does it make any difference if use rspro without 192.168.1.7 (if possible)? wlandebug doesn't work on macbook, does it? Can you show me your hostapd.conf (minus password, of course). I'll try with the same config. And, if you ping from macbook, would it take that long? AK >Any idea? > >thanks, > >Ganbold ___ 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: run(4) patch
- Original Message > From: Hans Petter Selasky > To: PseudoCylon > Cc: freebsd-...@freebsd.org; freebsd-current@freebsd.org > Sent: Sat, June 12, 2010 12:30:18 AM > Subject: Re: run(4) patch > >> On Friday 11 June 2010 08:27:53 PseudoCylon wrote: >> Hello, >> >> >> Here is a patch for recent fix. >> >> href="http://lists.freebsd.org/pipermail/freebsd-current/2010-June/017749.html"; >> >> target=_blank >> http://lists.freebsd.org/pipermail/freebsd-current/2010-June/017749.html >> >> Please update codes in your repository. >> >> Diff against the latest >> change, 178418. >> * if_run.c - rev. 11 >> * if_runvar.h - rev. 7 >> >> summary of changes >> * Because hostapd calls iv_key_set() before if_init(), made sure key_set >> callback function will be executed, and the key won't be deleted during >> init process. * txmic and rxmic are written into the chip the same >> place regardless of opmode. * Made hardware generate 802.11 sequence >> numbers. >> >> Thank you. >> >> AK >> > >Hi, > >Please verify USB P4 change #179518. > > >> href="http://p4web.freebsd.org/@@179518?ac=10"; target=_blank >> http://p4web.freebsd.org/@@179518?ac=10 > >--HPS Hello, All files are up-to-date. if_run.c change #179518 (rev.12), and http://p4web.freebsd.org/@@179518?ac=10 if_runvar.h change #179519 (rev. 8) http://p4web.freebsd.org/@@179519?ac=10 if_runreg.h is listed in change #179518 without any change in code. Thank you. 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message > From: Ganbold > To: PseudoCylon > Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu > Sent: Thu, June 10, 2010 10:53:30 AM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > > It seems like it is running without any problem so far, no more adsl > modem problem. > I can see arp packets in wlan0 interface as well as in macbook. > I will continue testing and let you know if there comes any problem. > > thanks again, > > Ganbold Hello, Glad to hear. It was an encryption problem. A client was dropping packets.. Please let me know if you find another bug. (Hope there won't be) Thank you for testing 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
> Hello, > > Sorry for taking long. > > But, please try following update (if_run.c and if_runvar.h) > http://gitorious.org/run/run/blobs/raw/a74fa9ba5a16f1d1f058efa724261351e267a474/dev/usb/wlan/if_run.c > http://gitorious.org/run/run/blobs/raw/a74fa9ba5a16f1d1f058efa724261351e267a474/dev/usb/wlan/if_runvar.h > > If any of client running 8.0-RELEASE please apply this patch > http://svn.freebsd.org/viewvc/base/stable/8/sys/net80211/ieee80211_crypto_tkip.c?r1=199583&r2=204215 > Otherwise TKIP might not work. (That was the last piece of puzzle I had.) > Oops, please use this if_run.c instead. http://gitorious.org/run/run/blobs/raw/b1976c8333721f88368a32dbf04f04e19ef487fc/dev/usb/wlan/if_run.c 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message > From: Ganbold > To: PseudoCylon > Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu > Sent: Wed, June 9, 2010 9:09:22 AM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > > Any update on driver side? > Please let me know. > > thanks, > > Ganbold Hello, Sorry for taking long. But, please try following update (if_run.c and if_runvar.h) http://gitorious.org/run/run/blobs/raw/a74fa9ba5a16f1d1f058efa724261351e267a474/dev/usb/wlan/if_run.c http://gitorious.org/run/run/blobs/raw/a74fa9ba5a16f1d1f058efa724261351e267a474/dev/usb/wlan/if_runvar.h If any of client running 8.0-RELEASE please apply this patch http://svn.freebsd.org/viewvc/base/stable/8/sys/net80211/ieee80211_crypto_tkip.c?r1=199583&r2=204215 Otherwise TKIP might not work. (That was the last piece of puzzle I had.) ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message
> From: Ganbold
> To: PseudoCylon
> Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu
> Sent: Wed, May 26, 2010 10:10:46 AM
> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
>
> It looks like either bridge or wlan/run driver is not
> forwarding/allowing incoming arp request for wireless client behind this
> access point.
> Wireless client is not getting any arp request and after sending several
> arp request to wireless client ADSL modem stops responding (had to
> restart modem).
> Any idea?
>
> thanks,
>
> Ganbold
Hello again Ganbold,
This time I can reproduce the problem on my computer. Please try attached
patch. (patch to if_run.c) I suppose arp is for during dhcp negotiation. So,
client does associate but cannot get IP address.
The device won't talk with other devices until 2-way handshake has happens. I
thought it happens after 4-way handshake, but hostapd with -d option shows it
happens several minutes later. I added code to set some registers ahead of it.
So, no need to wait renegotiation happens.
-- patch begin --
diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c
index 61784d9..9beb582 100644
--- a/dev/usb/wlan/if_run.c
+++ b/dev/usb/wlan/if_run.c
@@ -2053,6 +2053,17 @@ run_key_set_cb(void *arg)
attr = (attr & ~0xf) | (mode << 1) | RT2860_RX_PKEY_EN;
if(run_write(sc, RT2860_WCID_ATTR(wcid), attr))
return;
+
+if(vap->iv_opmode == IEEE80211_M_HOSTAP){
+if(run_read(sc, RT2860_SKEY_MODE_0_7, &attr))
+return;
+attr &= ~(0xf << (1 * 4));
+attr &= ~(0xf << (2 * 4));
+attr |= mode << (1 * 4);
+attr |= mode << (2 * 4);
+if(run_write(sc, RT2860_SKEY_MODE_0_7, attr))
+return;
+}
}
/* TODO create a pass-thru key entry? */
-- patch end --
___
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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message
> From: Hans Petter Selasky
> To: freebsd-current@freebsd.org
> Cc: Ganbold ; PseudoCylon ;
> Ganbold Tsagaankhuu
> Sent: Wed, May 5, 2010 2:00:02 PM
> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
>
> Hi,
>
> Can you check if I've integrated correctly?
>
> http://p4web.freebsd.org/@@17?ac=10
>
Hello,
Thank you for promptly applying changes.
Yes, you did correctly. But, I missed r207554 and removing some meaningless
debug messages i.e. DPRINTF("called\n"). I will send you patch with change
summary.
> Who is taking this code into -current?
Please drop me a line. I also have new firmware to submit.
Best,
AK
> --HPS
___
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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message > From: Ganbold > To: PseudoCylon > Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu > Sent: Mon, May 3, 2010 8:54:11 AM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > > Thanks a lot, works no problem so far here with bridge (no > auth/hostapd/WPA2). > rspro# uname -an FreeBSD rspro 9.0-CURRENT FreeBSD 9.0-CURRENT #64 r207140M: > Mon May 3 > 21:49:50 ULAT 2010 > ts...@beastie:/usr/obj/mips/usr/mysrc/sys/RSPRO_AR71XX mips Yes! finally. I'm so happy to hear. If there are any other bugs, please report. I'll wait a few days before submit the changes just to make sure every thing is fine on your routerstation. Thank you for testing the driver several times and your patient. 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message > From: Ganbold > To: PseudoCylon > Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu > Sent: Sun, April 25, 2010 1:44:20 AM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > > Thank you very much. > However it still panics when I tried to use bridge. Please try this. http://gitorious.org/run/run/trees/master/dev/usb/wlan (if_run.c and if_runvar.h have been updated.) Sorry I haven't test on bridge (only with nat). It did panic with bridge. This should work. But, please #sysctl hw.usb.run.debug=1 just in case. Thanks. 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
Hello, Thank you for all the info. This one shall work. http://projects.nasreddine.com/projects/run/repository/revisions/mips_fix/show/dev/usb/wlan Please update if_run.c and if_runvar.h (2 files). Just in case, after kldload, please issue # sysctl hw.usb.run.debug=1 Now it prints out very little messages, and no need to issue wlandebug. Thanks AK > Got another panic. Maybe it is > something else. > > run_rx_frame: rx done > run_rx_frame: rx done > run_rx_frame: rx done > run_rx_frame: rx done > run_rx_frame: rx done > Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode) > [ thread pid 0 tid 100062 ] > Stopped at run_drain_fifo+0xd8:lw v0,6444(a1) > db> bt > Tracing pid 0 tid 100062 td 0xc0f88be0 > db_trace_thread+30 (?,?,?,?) ra 800ac688 sp c7e83970 sz 24 > 800ac56c+11c (0,?,,?) ra 800abd30 sp c7e83988 sz 32 > 800ab99c+394 (?,?,?,?) ra 800abec0 sp c7e839a8 sz 168 > db_command_loop+78 (?,?,?,?) ra 800ae4d8 sp c7e83a50 sz 24 > 800ae3d0+108 (?,?,?,?) ra 80208060 sp c7e83a68 sz 424 > kdb_trap+108 (?,?,?,?) ra 80407624 sp c7e83c10 sz 32 > trap+ff4 (?,?,?,?) ra 803ff090 sp c7e83c30 sz 168 > MipsKernGenException+134 (1a3,0,0,21c) ra c7e5bd24 sp c7e83cd8 sz 200 > PC 0xc7e5bd24: not in kernel > 0+c7e5bd24 (?,?,?,?) ra 0 sp c7e83da0 sz 0 > pid 0 > db> > > Ganbold ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
Hello, Can you try this? (all 3 files has been updated) http://projects.nasreddine.com/projects/run/repository/revisions/mips_fix/show/dev/usb/wlan This is for rev 207077 or newer. If you are using older rev, please let me know with rev #, I'll change the code accordingly. If it isn't too much trouble, can you run the driver with following debug option on? # wlandebug -i wlan0 0x6930 (after wlan create) To make this work, kernel need to be compiled with IEEE80211_DEBUG option which is enabled in generic AR71XX conf file by default. And, maybe with INVARIANTS option? the bug has been fixed in rev 206400 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/mips/atheros/if_arge.c Sorry for asking too much. The driver is causing the trouble, but something goes wrong outside the driver. Thanks AK > >> Is your kernel compiled with INVARIANTS >> option? >> > Tried, but if_arge panics at boot with INVARIANTS > option. > arge0: at > mem 0x1900-0x19000fff irq 2 on nexus0 panic: mtx_lock() of spin mutex > arge mii lock > @ /usr/mysrc/sys/mips/atheros/if_arge.c:554 > thanks, > Ganbold ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
Hi, Sorry for taking long to fix. Here is another patch. **But before trying it out, please check rev. of your system.** If you are using r206358 (15:29 UTC Apr. 7) or newer, the driver won't work. If you are using older system, please try this patch. http://projects.nasreddine.com/projects/run/repository/revisions/mips1_fix/show/dev/usb/wlan Only if_run.c is patched since last time. (click file name, then click "download") If you are using r206358 or newer, please give me some time to fix. I'm stating it now. Is your kernel compiled with INVARIANTS option? AK - Original Message > From: Ganbold > To: PseudoCylon > Cc: freebsd-current@freebsd.org > Sent: Tue, April 6, 2010 7:29:16 AM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > > PseudoCylon wrote: > - Original Message > > >> From: Ganbold < > href="mailto:ganb...@gmail.com";>ganb...@gmail.com> >> To: > PseudoCylon < > href="mailto:moonlightak...@yahoo.ca";>moonlightak...@yahoo.ca> >> > Cc: > href="mailto:freebsd-current@freebsd.org";>freebsd-current@freebsd.org >> > Sent: Wed, March 31, 2010 8:08:29 AM >> Subject: Re: CALL for TEST > [HOSTAP] run(4) ralink usb wireless >> >> Does stock run(4) > support hostap mode yet? >> > > No. There > were some bugs and I thought I fixed them. So, I called for test. It seems > the > driver is working on x86, but not on mips. hostap mode should work on your > other > computer with i386. > > I'm still working on patch. It panics where > there wasn't any changes made. Strange... > > Hi, Sorry, it looks like I missed some of your emails. Please > let me know if you need any info from my > side. thanks, Ganbold > > > AK > > __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message > From: Ganbold > To: PseudoCylon > Cc: freebsd-current@freebsd.org > Sent: Wed, March 31, 2010 8:08:29 AM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > > Does stock run(4) support hostap mode yet? No. There were some bugs and I thought I fixed them. So, I called for test. It seems the driver is working on x86, but not on mips. hostap mode should work on your other computer with i386. I'm still working on patch. It panics where there wasn't any changes made. Strange... AK __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message > From: Ganbold > To: PseudoCylon > Cc: freebsd-current@freebsd.org > Sent: Sat, March 27, 2010 7:01:32 AM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > > JFYI, I have just tested if_run and works fine on HEAD (i386). > But on RouterStation Pro it still has problem with your patch. > Ganbold Thank you for taking extra time to test the driver. Yes, it works on x86. It's hard to find bugs if everything is working on my computers (core2 and atom 330). Here is patch. http://dev.nasreddine.com/gitweb/?p=run.git;a=tree;f=dev/usb/wlan;h=695689599706b01ed9ef0f1be8dfc5790076e1ae;hb=bdc7558bfbd4f3b1c4491cb56853de24580a5434 Please download if_run.c and if_runvar.h (click "raw" to download) It will print out lots of messages. Please show me last 5 or so messages if it still panics. Does stock run(4) still works on RouterStation? There were some update (r205042). Yours (r205084) has it. AK __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
>> Same.
>>
>> rspro# ifconfig wlan0 up
>>
>> rspro# Trap cause = 5 (address error (store) - kernel
> mode)
>> [ thread pid 0 tid 100047 ]
>> Stopped at
> ieee80211_radiotap_vdetach+0x70:
> sh v1,0(a0)
>> db> bt
>> Tracing pid 0
> tid 100047 td 0xc0f1f260
>> db_trace_thread+30 (?,?,?,?) ra 80071160 sp
> c7ec9948 sz 24
>> 80071044+11c (0,?,,?) ra 80070b54 sp c7ec9960
> sz 32
>> 800707c0+394 (?,?,?,?) ra 80070ce4 sp c7ec9980 sz
> 168
>> db_command_loop+78 (?,?,?,?) ra 800733b8 sp c7ec9a28 sz
> 24
>> 800732b0+108 (?,?,?,?) ra 801d8b1c sp c7ec9a40 sz 424
>>
> kdb_trap+10c (?,?,?,?) ra 803c2690 sp c7ec9be8 sz 32
>> trap+134c
> (?,?,?,?) ra 803b97c8 sp c7ec9c08 sz 176
>> MipsKernGenException+10c
> (c0f6a637,c0f721c8,c7ea7c04,e51) ra 802c95b8 sp
>> c7ec9cb8 sz
> 200
>> 802c95a8+10 (?,?,?,?) ra 0 sp c7ec9d80 sz 0
>> pid
> 0
>> db>
>>
>> Ganbold
>>
Hi,
Can you try this patch? (Patch is for if_run.c)
Before "ifconfig wlan0 up", please run
sysctl hw.usb.run.debug=1
This will give me more clues.
Does it panic right after wlan up, or are there some seconds before panic?
Regards,
AK
-- begin patch --
*** old_if_run.c2010-03-27 02:44:20.0 -0600
--- new_if_run.c2010-03-27 02:47:28.0 -0600
***
*** 414,416
static const struct {
! uint32_treg;
uint32_tval;
--- 414,416
static const struct {
! uint16_treg;
uint32_tval;
***
*** 1225,1227
! *val = tmp & 0xff;
return 0;
--- 1225,1227
! *val = (uint8_t)(tmp & 0xff);
return 0;
__
The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo!
Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
___
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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
Can you show me output of followings? (I have only intel chips.) #kldstat | grep if_run (after loading the driver. no need to run it) #objdump -h /boot/kernel/if_run.ko | grep text #objdump --source /boot/kernel/if_run.ko | grep \>: AK > Same. > rspro# ifconfig wlan0 up > > rspro# Trap cause = 5 (address error (store) - kernel mode) > [ thread pid 0 tid 100047 ] > Stopped at ieee80211_radiotap_vdetach+0x70:sh v1,0(a0) > db> bt > Tracing pid 0 tid 100047 td 0xc0f1f260 > db_trace_thread+30 (?,?,?,?) ra 80071160 sp c7ec9948 sz 24 > 80071044+11c (0,?,,?) ra 80070b54 sp c7ec9960 sz 32 > 800707c0+394 (?,?,?,?) ra 80070ce4 sp c7ec9980 sz 168 > db_command_loop+78 (?,?,?,?) ra 800733b8 sp c7ec9a28 sz 24 > 800732b0+108 (?,?,?,?) ra 801d8b1c sp c7ec9a40 sz 424 > kdb_trap+10c (?,?,?,?) ra 803c2690 sp c7ec9be8 sz 32 > trap+134c (?,?,?,?) ra 803b97c8 sp c7ec9c08 sz 176 > MipsKernGenException+10c (c0f6a637,c0f721c8,c7ea7c04,e51) ra 802c95b8 sp > c7ec9cb8 sz 200 > 802c95a8+10 (?,?,?,?) ra 0 sp c7ec9d80 sz 0 > pid 0 > db> > Ganbold __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
Hello, again. Can you try this patch? Patch is for if_runvar.h --begin patch-- *** old_if_runvar.h2010-03-16 19:14:25.0 -0600 --- new_if_runvar.h2010-03-16 19:15:51.0 -0600 *** *** 184,186 uint8_tval; ! }bbp[8], rf[10]; uint8_tleds; --- 184,186 uint8_tval; ! }bbp[10], rf[10]; uint8_tleds; --end patch-- Does your mips use big endian? AK Tried this version on routerstation pro (mips) board. Root fs is in > NFS. (FreeBSD 9.0-CURRENT #13 r205084M: Tue Mar 16 22:35:25 ULAT > 2010). ... run0: <1.0> on usbus0 run0: MAC/BBP RT3070 (rev > 0x0200), RF RT3020 (MIMO 1T1R), address 00:22:cf:03:e0:30 Updating > motd:run0: firmware RT2870 loaded . ... run0: > flags=8802 metric 0 mtu 2290 > ether 00:22:cf:03:e0:30 media: IEEE > 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier wlan0: flags=8802 > metric 0 mtu 1500 ether > 00:22:cf:03:e0:30 media: IEEE 802.11 Wireless > Ethernet autoselect mode 11g status: no > carrier ssid bsd channel 6 (2437 MHz > 11g) country US authmode OPEN privacy OFF txpower > 0 bmiss 7 scanvalid 60 protmode CTS wme bintval > 0 rspro# ifconfig wlan0 up rspro# Trap cause = 5 (address > error (store) - kernel mode) [ thread pid 0 tid 100047 ] Stopped at > ieee80211_radiotap_vdetach+0x70: > sh v1,0(a0) db> c panic: trap KDB: enter: > panic [ thread pid 0 tid 100047 ] Stopped at > kdb_enter+0x50: lui at,0x804c db> bt Tracing pid 0 tid > 100047 td 0xc0f1f260 db_trace_thread+30 (?,?,?,?) ra 80071160 sp c7ec9790 sz > 24 80071044+11c (0,?,,?) ra 80070b54 sp c7ec97a8 sz > 32 800707c0+394 (?,?,?,?) ra 80070ce4 sp c7ec97c8 sz > 168 db_command_loop+78 (?,?,?,?) ra 800733b8 sp c7ec9870 sz > 24 800732b0+108 (?,?,?,?) ra 801d8b1c sp c7ec9888 sz 424 kdb_trap+10c > (?,?,?,?) ra 803c2440 sp c7ec9a30 sz 32 trap+10fc (?,?,?,?) ra 803b97c8 sp > c7ec9a50 sz 176 MipsKernGenException+10c (0,a,804e0fe4,2) ra 801d8d74 sp > c7ec9b00 sz 200 kdb_enter+50 (?,?,?,?) ra 8019ccc0 sp c7ec9bc8 sz > 24 panic+f8 (?,802c95b8,,c7ec9990) ra 803c26a0 sp c7ec9be0 sz > 40 trap+135c (?,?,?,?) ra 803b97c8 sp c7ec9c08 sz > 176 MipsKernGenException+10c (c0f6a62f,c0f72268,c7ea7c14,e51) ra 802c95b8 > sp c7ec9cb8 sz 200 802c95a8+10 (?,?,?,?) ra 0 sp c7ec9d80 sz 0 pid > 0 db> Btw, ifconfig wlan0 up works on with stock run(4) which > was committed to HEAD end of Jan. Please let me know if you need any more > information. Ganbold > Best, > AK > > > > "FreeBSD and all other open source projects are the Tower of Babel > in computer era." --me > So, join me @ > git://dev.nasreddine.com/run.git > (or > href="http://dev.nasreddine.com/gitweb/?p=run.git;a=summary"; target=_blank > >http://dev.nasreddine.com/gitweb/?p=run.git;a=summary ) > Just work > on any of *_dev branches. > > > > > __ > > Looking for the perfect gift? Give the gift of Flickr! > > > href="http://www.flickr.com/gift/"; target=_blank > >http://www.flickr.com/gift/ > > ___ > > ymailto="mailto:freebsd-current@freebsd.org"; > href="mailto:freebsd-current@freebsd.org";>freebsd-current@freebsd.org > mailing list > > href="http://lists.freebsd.org/mailman/listinfo/freebsd-current"; > target=_blank > >http://lists.freebsd.org/mailman/listinfo/freebsd-current > To > unsubscribe, send any mail to " > ymailto="mailto:freebsd-current-unsubscr...@freebsd.org"; > href="mailto:freebsd-current-unsubscr...@freebsd.org";>freebsd-current-unsubscr...@freebsd.org" > > > > > -- One thing about the past. It's likely to last. -- Ogden > Nash __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
Hello, Can you check version of firmware for me? At the end of ralink's license (before the actual code) in rt2870.fw.uu, if it says RT2870 v. 0.11 RT3071 v. 0.11 it's the latest. If there is no version info, it is old version. Your chipset, rt3070 + rf3020 uses mcu command to select the antenna available in new firmware. Best, AK Tried this version on routerstation pro (mips) board. Root fs is in > NFS. (FreeBSD 9.0-CURRENT #13 r205084M: Tue Mar 16 22:35:25 ULAT > 2010). ... run0: <1.0> on usbus0 run0: MAC/BBP RT3070 (rev > 0x0200), RF RT3020 (MIMO 1T1R), address 00:22:cf:03:e0:30 Updating > motd:run0: firmware RT2870 loaded . ... run0: > flags=8802 metric 0 mtu 2290 > ether 00:22:cf:03:e0:30 media: IEEE > 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier wlan0: flags=8802 > metric 0 mtu 1500 ether > 00:22:cf:03:e0:30 media: IEEE 802.11 Wireless > Ethernet autoselect mode 11g status: no > carrier ssid bsd channel 6 (2437 MHz > 11g) country US authmode OPEN privacy OFF txpower > 0 bmiss 7 scanvalid 60 protmode CTS wme bintval > 0 rspro# ifconfig wlan0 up rspro# Trap cause = 5 (address > error (store) - kernel mode) [ thread pid 0 tid 100047 ] Stopped at > ieee80211_radiotap_vdetach+0x70: > sh v1,0(a0) db> c panic: trap KDB: enter: > panic [ thread pid 0 tid 100047 ] Stopped at > kdb_enter+0x50: lui at,0x804c db> bt Tracing pid 0 tid > 100047 td 0xc0f1f260 db_trace_thread+30 (?,?,?,?) ra 80071160 sp c7ec9790 sz > 24 80071044+11c (0,?,,?) ra 80070b54 sp c7ec97a8 sz > 32 800707c0+394 (?,?,?,?) ra 80070ce4 sp c7ec97c8 sz > 168 db_command_loop+78 (?,?,?,?) ra 800733b8 sp c7ec9870 sz > 24 800732b0+108 (?,?,?,?) ra 801d8b1c sp c7ec9888 sz 424 kdb_trap+10c > (?,?,?,?) ra 803c2440 sp c7ec9a30 sz 32 trap+10fc (?,?,?,?) ra 803b97c8 sp > c7ec9a50 sz 176 MipsKernGenException+10c (0,a,804e0fe4,2) ra 801d8d74 sp > c7ec9b00 sz 200 kdb_enter+50 (?,?,?,?) ra 8019ccc0 sp c7ec9bc8 sz > 24 panic+f8 (?,802c95b8,,c7ec9990) ra 803c26a0 sp c7ec9be0 sz > 40 trap+135c (?,?,?,?) ra 803b97c8 sp c7ec9c08 sz > 176 MipsKernGenException+10c (c0f6a62f,c0f72268,c7ea7c14,e51) ra 802c95b8 > sp c7ec9cb8 sz 200 802c95a8+10 (?,?,?,?) ra 0 sp c7ec9d80 sz 0 pid > 0 db> Btw, ifconfig wlan0 up works on with stock run(4) which > was committed to HEAD end of Jan. Please let me know if you need any more > information. Ganbold > Best, > AK > > > > "FreeBSD and all other open source projects are the Tower of Babel > in computer era." --me > So, join me @ > git://dev.nasreddine.com/run.git > (or > href="http://dev.nasreddine.com/gitweb/?p=run.git;a=summary";; target=_blank > >http://dev.nasreddine.com/gitweb/?p=run.git;a=summary ) > Just work > on any of *_dev branches. > > > > > __ > > Looking for the perfect gift? Give the gift of Flickr! > > > href="http://www.flickr.com/gift/";; target=_blank > >http://www.flickr.com/gift/ > > ___ > > ymailto="mailto:freebsd-current@freebsd.org"; > href="mailto:freebsd-current@freebsd.org";>freebsd-current@freebsd.org > mailing list > > href="http://lists.freebsd.org/mailman/listinfo/freebsd-current";; > target=_blank > >http://lists.freebsd.org/mailman/listinfo/freebsd-current > To > unsubscribe, send any mail to " > ymailto="mailto:freebsd-current-unsubscr...@freebsd.org"; > href="mailto:freebsd-current-unsubscr...@freebsd.org";>freebsd-current-unsubscr...@freebsd.org" > > > > > -- One thing about the past. It's likely to last. -- Ogden > Nash __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message > From: Rui Paulo > To: Weongyo Jeong > Cc: PseudoCylon ; Alexander Egorenkov > ; freebsd-current@freebsd.org > Sent: Fri, March 12, 2010 7:42:46 PM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > > On 13 Mar 2010, at 09:18, Weongyo Jeong wrote: > Out of curiosity, what's the difference between run(4) and rt2870 > driver > written by Alexander Egorenkov? And why there are two > drivers? The thread says it all. Just need to go though some pages. His user name is egorenar. http://forums.freebsd.org/showthread.php?s=1d3b01fbed80c61ff508e12e9805146e&t=7562 > From what I understand, Alexander's driver supports 11n ann > run(4) doesn't. That's correct. Besides run(4) supports rt3XXX chipsets. AK __ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message
> From: Rui Paulo
> To: PseudoCylon
> Cc: freebsd-current@freebsd.org
> Sent: Thu, March 4, 2010 5:02:50 PM
> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
>
> Hi,
>
>
> This code is fine from a quick review. It just needs a few style fixes.
> We could probably start thinking about committing it.
>
> --
> Rui Paulo
Thank you for checking my code out. Please check other patches/fixes at P4DB as
well
http://p4db.freebsd.org/chv.cgi?CH=174936
Let me know if any changes are needed. Specially, lock related process in
run_wme_update()
run_key_delete()
run_update_beacon()
run_updateslot()
I had hard time on those places. And using ieee80211_key{.wk_pad} It's sorta
cheating.
Regards,
AK
__
Looking for the perfect gift? Give the gift of Flickr!
http://www.flickr.com/gift/
___
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"
CALL for TEST [HOSTAP] run(4) ralink usb wireless
Hello, Finally, I have fixed mysterious device lock out and run(4) works fine in HOSTAP mode. Up time is 80 hours and counting. I even filed tax though it. The device supports up to 253 stations. I only tested with 2 station. If you have resources, please hit it with bunch of STAs. As usual codes are posted at my git repository git://dev.nasreddine.com/run.git http://dev.nasreddine.com/gitweb/?p=run.git;a=summary Please fetch 'hostap_rc' branch not 'master' this time. or freebsd forums http://forums.freebsd.org/showthread.php?s=1d3b01fbed80c61ff508e12e9805146e&t=7562 Best, AK "FreeBSD and all other open source projects are the Tower of Babel in computer era." --me So, join me @ git://dev.nasreddine.com/run.git (or http://dev.nasreddine.com/gitweb/?p=run.git;a=summary ) Just work on any of *_dev branches. __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ ___ 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"
quick Call for Test run(4) ralink usb wireless
Hello, There are revisions on OpenBSD run(4), so I applied the applicable changes to ours. Because lots of changes has been made (more than 20 revisions in 24 hour period), I thought I should do a quick test. Please give it a try. The driver is posted at http://forums.freebsd.org/showpost.php?s=51e84afd1607d632ae06552113cad13f&p=67831&postcount=156 or git://dev.nasreddine.com/run.git http://dev.nasreddine.com/gitweb/?p=run.git;a=summary (please fetch 'master' branch) IMPORTANT NOTE Please update BOTH firmware AND driver. Thanks in advance. Best, Akinori P.S. Can anyone tell me where to submit the change/patch? "FreeBSD and all other open source projects are the Tower of Babel in computer era." --me So, join me @ git://dev.nasreddine.com/run.git (or http://dev.nasreddine.com/gitweb/?p=run.git;a=summary ) Just work on any of *_dev branches. __ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com ___ 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"
