Re: EHCI on armv6 with Write-Back caches

[Hans Petter Selasky]

Hi,

I've run some basic tests over here (x86) which passed after some patch 
modifications. Please test and verify for your ARM targets:

http://svnweb.freebsd.org/changeset/base/244500
http://svnweb.freebsd.org/changeset/base/244503

Please also verify that upgt and uwrt and uath still works like expected.

--HPS
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: panic on removing urtw0

[Hans Petter Selasky]

On Sunday 10 February 2013 03:17:03 Adrian Chadd wrote:
> Yes to both - i think some USB stack / memory buffer changes are
> responsible for your issue. :-)
> 

Hi,

Can you send me the backtrace of the panic and I'll fix it. I fixed panic upon 
attach.

--HPS
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

RE: My WLI-UC-GNM up crash

[Hans Petter Selasky]

Hi,

Can you try the attached patch?

--HPS
diff --git a/sys/net80211/ieee80211_radiotap.h b/sys/net80211/ieee80211_radiotap.h
index b8a8b51..c199d48 100644
--- a/sys/net80211/ieee80211_radiotap.h
+++ b/sys/net80211/ieee80211_radiotap.h
@@ -78,7 +78,7 @@ struct ieee80211_radiotap_header {
 	 * Additional extensions are made
 	 * by setting bit 31.
 	 */
-} __packed;
+} __packed __aligned(4);
 
 /*
  * Name Data type   Units
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

RE: My WLI-UC-GNM up crash

[Hans Petter Selasky]

Can you tell us which compiler you used to build your image?

--HPS

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

RE: My WLI-UC-GNM up crash

[Hans Petter Selasky]

This patch?

commit bae4e38c197f464c4bffe7037d5d491e462105b0
Author: sam 
Date:   Thu Apr 1 00:38:45 2004 +

radiotap updates:

o force little-endian byte order for header
o pad header to 32-bit boundary to guard against applications that assume
  packet data alignment

--HPS
 
 
-Original message-
> From:Adrian Chadd mailto:adr...@freebsd.org> >
> Sent: Sunday 28th July 2013 6:29
> To: XiaoQI Ge mailto:g...@7axu.com> >
> Cc: freebsd-arm mailto:freebsd-...@freebsd.org> >; 
> freebsd-wireless@freebsd.org  
> Subject: Re: My WLI-UC-GNM up crash
> 
> Not sure, I haven't dug into it. It shouldn't be hard to fix though.
> 
> I think someone just screwed up in defining the structures in the USB
> drivers and didn't specify alignment. ath(4) got it right because Sam
> ran it on MIPS/ARM boards.
> 
> 
> 
> -adrian
> 
> On 27 July 2013 20:34, XiaoQI Ge mailto:g...@7axu.com> > 
> wrote:
> > That should be how to solve it?
> > --
> > Regards.
> > By: XiaoQI Ge; PGP:8B09D5F7
> > WWW: https://www.7axu.com/
> >
> >
> >
> > 2013/7/27 Adrian Chadd mailto:adr...@freebsd.org> >:
> >> This is known; there's some alignment issue with the radiotap TX/RX
> >> structures in some of these USB devices.
> >>
> >>
> >>
> >> -adrain
> >>
> >> On 25 July 2013 20:23, XiaoQI Ge mailto:g...@7axu.com> > 
> >> wrote:
> >>> 我更新到最新的源码（r253662），这次错误信息变成了0xde9f4d34
> >>>
> >>> [root@FreeBSD.ttyu0  ] ˜ # Fatal kernel mode 
> >>> data abort: 'Alignment Fault 1'
> >>> trapframe: 0xde9f4d34
> >>> FSR=0801, FAR=c284afbb, spsr=0013
> >>> r0 =c284c000, r1 =c284afbb, r2 =c284c210, r3 =096c
> >>> r4 =c284c024, r5 =c05f07c5, r6 =0014, r7 =c2844800
> >>> r8 =c05f07c5, r9 =c284c000, r10=35cb, r11=de9f4e10
> >>> r12=002e, ssp=de9f4d80, slr=, pc =c046d20c
> >>>
> >>> [ thread pid 0 tid 100053 ]
> >>> Stopped at  ieee80211_radiotap_chan_change+0x90:strhr3, [r1]
> >>> db>
> >>> ---
> >>> Kernel wlan related options
> >>> device  wlan# 802.11 support
> >>> options IEEE80211_DEBUG # enable debug msgs
> >>> options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's
> >>> options IEEE80211_SUPPORT_MESH  # enable 802.11s draft support
> >>> device  wlan_wep# 802.11 WEP support
> >>> device  wlan_ccmp   # 802.11 CCMP support
> >>> device  wlan_tkip   # 802.11 TKIP support
> >>> device  wlan_amrr   # AMRR transmit rate control algorithm
> >>> device  firmware# firmware assist module
> >>> device run  #Ralink Technology USB IEEE 802.11a/g/n
> >>> wireless network device
> >>> device runfw#Firmware Module for Ralink driver
> >>>
> >>> ---
> >>> The compiler command
> >>> make TARGET_ARCH=armv6 TARGET_CPUTYPE=armv6 KERNCONF=BBB WITH_FDT=yes
> >>> buildkernel
> >>> --
> >>> Regards.
> >>> By: XiaoQI Ge; PGP:8B09D5F7
> >>> WWW: https://www.7axu.com/
> >>>
> >>>
> >>>
> >>> 2013/7/24 XiaoQI Ge mailto:g...@7axu.com> >:
>  How do I debug it? Can provide useful information
> 
>  login: root
>  Jul 24 18:27:31 FreeBSD login: ROOT LOGIN (root) ON ttyu0
>  FreeBSD 10.0-CURRENT (BBB) #4 r253585M: Wed Jul 24 17:07:53 CST 2013
>  [root@FreeBSD.ttyu0  ] ˜ # ifconfig wlan 
>  create wlandev run0
>  wlan0: Ethernet address: 10:6f:3f:2b:fd:6d
>  wlan0
>  [root@FreeBSD.ttyu0  ] ˜ # ifconfig wlan0 up
>  run0: firmware RT2870 ver. 0.236 loaded
>  Fatal kernel mode data abort: 'Alignment Fault 1'
>  trapframe: 0xde9e4d5c
>  FSR=0801, FAR=c282ffbb, spsr=0013
>  r0 =c2831000, r1 =c282ffbb, r2 =c2831210, r3 =096c
>  r4 =c2831024, r5 =c2831000, r6 =c05d9362, r7 =c2829800
>  r8 =0014, r9 =c08144d8, r10=80001cce, r11=de9e4e10
>  r12=002e, ssp=de9e4da8, slr=, pc =c045c510
> 
>  [ thread pid 0 tid 100053 ]
>  Stopped at  ieee80211_radiotap_chan_change+0x90:strhr3, [r1]
>  db>
> 
> 
>  These two places modified:
>  2522 }
>  2523
>  2524 ant = run_maxrssi_chain(sc, rxwi);
>  2525 rssi = rxwi->rssi[ant];
>  2526 nf = run_rssi2dbm(sc, rssi, ant);
>  2527
>  2528 m->m_pkthdr.rcvif = ifp;
>  2529 m->m_pkthdr.len = m->m_len = len;
>  2530 /*
>  2531 if (ni != NULL) {
>  2532 (void)ieee80211_input(ni, m, rssi, nf);
>  2533 ieee80211_free_node(ni);
>  2534 } else {
>  2535 (void)ieee80211_input_all(ic, m, rssi, nf);
>  2536 }
>  2537 */
>  2538 /*
>  2539  * DAAN: fill-in tap header BEFORE calling ieee80211_input*() 
>  so the
>  2540  * user will see the actual data that belongs to THIS packet..
>  2541  */
>  2542 if (__predict_false(ieee80211_radiotap_active(ic))) {
> 

Re: My WLI-UC-GNM up crash

[Hans Petter Selasky]

Hi,

Can you try the attached patch?

--HPS
=== sys/dev/usb/wlan/if_rumvar.h
==
--- sys/dev/usb/wlan/if_rumvar.h	(revision 253548)
+++ sys/dev/usb/wlan/if_rumvar.h	(local)
@@ -29,7 +29,7 @@
 	int8_t		wr_antsignal;
 	int8_t		wr_antnoise;
 	uint8_t		wr_antenna;
-};
+} __packed __aligned(8);
 
 #define RT2573_RX_RADIOTAP_PRESENT	\
 	((1 << IEEE80211_RADIOTAP_FLAGS) |\
@@ -47,7 +47,7 @@
 	uint16_t	wt_chan_freq;
 	uint16_t	wt_chan_flags;
 	uint8_t		wt_antenna;
-};
+} __packed __aligned(8);
 
 #define RT2573_TX_RADIOTAP_PRESENT	\
 	((1 << IEEE80211_RADIOTAP_FLAGS) |\
=== sys/dev/usb/wlan/if_runvar.h
==
--- sys/dev/usb/wlan/if_runvar.h	(revision 253548)
+++ sys/dev/usb/wlan/if_runvar.h	(local)
@@ -58,7 +58,7 @@
 	int8_t		wr_dbm_antsignal;
 	uint8_t		wr_antenna;
 	uint8_t		wr_antsignal;
-} __packed;
+} __packed __aligned(8);
 
 #define RUN_RX_RADIOTAP_PRESENT\
 	(1 << IEEE80211_RADIOTAP_FLAGS |		\
@@ -75,7 +75,7 @@
 	uint16_t	wt_chan_freq;
 	uint16_t	wt_chan_flags;
 	uint8_t		wt_hwqueue;
-} __packed;
+} __packed __aligned(8);
 
 #define IEEE80211_RADIOTAP_HWQUEUE 15
 
=== sys/dev/usb/wlan/if_uathvar.h
==
--- sys/dev/usb/wlan/if_uathvar.h	(revision 253548)
+++ sys/dev/usb/wlan/if_uathvar.h	(local)
@@ -52,7 +52,7 @@
 	int8_t		wr_antsignal;
 	int8_t		wr_antnoise;
 	u_int8_t	wr_antenna;
-} __packed;
+} __packed __aligned(8);
 
 #define UATH_RX_RADIOTAP_PRESENT (		\
 	(1 << IEEE80211_RADIOTAP_TSFT)		| \
@@ -69,7 +69,7 @@
 	uint8_t		wt_flags;
 	uint16_t	wt_chan_freq;
 	uint16_t	wt_chan_flags;
-} __packed;
+} __packed __aligned(8);
 
 #define	UATH_TX_RADIOTAP_PRESENT	\
 	((1 << IEEE80211_RADIOTAP_FLAGS) |\
=== sys/dev/usb/wlan/if_upgtvar.h
==
--- sys/dev/usb/wlan/if_upgtvar.h	(revision 253548)
+++ sys/dev/usb/wlan/if_upgtvar.h	(local)
@@ -380,7 +380,7 @@
 	uint16_t	wr_chan_freq;
 	uint16_t	wr_chan_flags;
 	int8_t		wr_antsignal;
-} __packed;
+} __packed __aligned(8);
 
 #define UPGT_RX_RADIOTAP_PRESENT	\
 	((1 << IEEE80211_RADIOTAP_FLAGS) |\
@@ -394,7 +394,7 @@
 	uint8_t		wt_rate;
 	uint16_t	wt_chan_freq;
 	uint16_t	wt_chan_flags;
-} __packed;
+} __packed __aligned(8);
 
 #define UPGT_TX_RADIOTAP_PRESENT	\
 	((1 << IEEE80211_RADIOTAP_FLAGS) |\
=== sys/dev/usb/wlan/if_uralvar.h
==
--- sys/dev/usb/wlan/if_uralvar.h	(revision 253548)
+++ sys/dev/usb/wlan/if_uralvar.h	(local)
@@ -34,7 +34,7 @@
 	int8_t		wr_antsignal;
 	int8_t		wr_antnoise;
 	uint8_t		wr_antenna;
-};
+} __packed __aligned(8);
 
 #define RAL_RX_RADIOTAP_PRESENT		\
 	((1 << IEEE80211_RADIOTAP_FLAGS) |\
@@ -51,7 +51,7 @@
 	uint16_t	wt_chan_freq;
 	uint16_t	wt_chan_flags;
 	uint8_t		wt_antenna;
-};
+} __packed __aligned(8);
 
 #define RAL_TX_RADIOTAP_PRESENT		\
 	((1 << IEEE80211_RADIOTAP_FLAGS) |\
=== sys/dev/usb/wlan/if_urtwnreg.h
==
--- sys/dev/usb/wlan/if_urtwnreg.h	(revision 253548)
+++ sys/dev/usb/wlan/if_urtwnreg.h	(local)
@@ -1030,7 +1030,7 @@
 	uint16_t	wr_chan_freq;
 	uint16_t	wr_chan_flags;
 	uint8_t		wr_dbm_antsignal;
-} __packed;
+} __packed __aligned(8);
 
 #define URTWN_RX_RADIOTAP_PRESENT			\
 	(1 << IEEE80211_RADIOTAP_FLAGS |		\
@@ -1043,7 +1043,7 @@
 	uint8_t		wt_flags;
 	uint16_t	wt_chan_freq;
 	uint16_t	wt_chan_flags;
-} __packed;
+} __packed __aligned(8);
 
 #define URTWN_TX_RADIOTAP_PRESENT			\
 	(1 << IEEE80211_RADIOTAP_FLAGS |		\
=== sys/dev/usb/wlan/if_urtwvar.h
==
--- sys/dev/usb/wlan/if_urtwvar.h	(revision 253548)
+++ sys/dev/usb/wlan/if_urtwvar.h	(local)
@@ -63,7 +63,7 @@
 	uint16_t	wr_chan_freq;
 	uint16_t	wr_chan_flags;
 	int8_t		wr_dbm_antsignal;
-} __packed;
+} __packed __aligned(8);
 
 #define URTW_RX_RADIOTAP_PRESENT	\
 	((1 << IEEE80211_RADIOTAP_FLAGS) |\
@@ -75,7 +75,7 @@
 	uint8_t		wt_flags;
 	uint16_t	wt_chan_freq;
 	uint16_t	wt_chan_flags;
-} __packed;
+} __packed __aligned(8);
 
 #define URTW_TX_RADIOTAP_PRESENT	\
 	((1 << IEEE80211_RADIOTAP_FLAGS) |\
=== sys/dev/usb/wlan/if_zydreg.h
==
--- sys/dev/usb/wlan/if_zydreg.h	(revision 253548)
+++ sys/dev/usb/wlan/if_zydreg.h	(local)
@@ -1185,7 +1185,7 @@
 	uint16_t		wr_chan_flags;
 	int8_t			wr_antsignal;
 	int8_t			wr_antnoise;
-} __packed;
+} __packed __aligned(8);
 
 #define ZYD_RX_RADIOTAP_PRESENT		\
 	((1 << IEEE80211_RADIOTAP_FLAGS) |\
@@ -1200,7 +1200,7 @@
 	uint8_t			wt_rate;
 	uint16_t		wt_chan_freq;
 	uint16_t		wt_chan_flags;
-} __packed;
+} __packed __aligned(8);
 
 #define ZYD_TX_RADIOTAP_PRESENT		\
 	((1 << IEEE80211_RADIOTAP_FLAGS) |\
___

RE: My WLI-UC-GNM up crash

[Hans Petter Selasky]

Hi,

The aligned will make sure that the structure gets padded properly to the size 
specified. Only on ARM/MIPS etc, structures get automatically aligned according 
to the element in the structure requiring the greatest alignment. I've 
test-compiled the USB WLAN drivers, and the aligned makes a difference. The 
problem is that the radiotap header skews some following elements, so that they 
are no longer aligned. The radiotap header itself is packed, and this is not a 
problem.

--HPS

 
-Original message-
> From:Warner Losh mailto:i...@bsdimp.com> >
> Sent: Monday 29th July 2013 17:04
> To: Adrian Chadd mailto:adr...@freebsd.org> >
> Cc: Hans Petter Selasky  <mailto:hans.petter.sela...@bitfrost.no> >; freebsd-arm 
> mailto:freebsd-...@freebsd.org> >; 
> freebsd-wireless@freebsd.org <mailto:freebsd-wireless@freebsd.org> 
> Subject: Re: My WLI-UC-GNM up crash
> 
> Aren't structures already aligned to 4 bytes when placed inside other 
> structures (unless marked __packed)?
> 
> Warner
> 
> On Jul 28, 2013, at 11:50 AM, Adrian Chadd wrote:
> 
> > As long as that results in the radiotap structures being 4 or 8 byte
> > padded when it's embedded in the softc - then yes, indeed.
> > 
> > Xiao, can you try?
> > 
> > 
> > -adrian
> > 
> > On 28 July 2013 03:35, Hans Petter Selasky  > <mailto:h...@bitfrost.no> > wrote:
> >> Hi,
> >> 
> >> Can you try the attached patch?
> >> 
> >> --HPS
> > ___
> > freebsd-...@freebsd.org <mailto:freebsd-...@freebsd.org>  mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-arm 
> > <http://lists.freebsd.org/mailman/listinfo/freebsd-arm> 
> > To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org 
> > <mailto:freebsd-arm-unsubscr...@freebsd.org> "
> 
> 

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

RE: My WLI-UC-GNM up crash

[Hans Petter Selasky]

Hi,

Typically this means the USB firmware died, or some command needs to be 
re-transmitted.

See:

usbdump -i usbusX -s 65536

What is really going on.

--HPS
 
 
-Original message-
> From:Adrian Chadd mailto:adr...@freebsd.org> >
> Sent: Wednesday 31st July 2013 20:03
> To: Ian Lepore mailto:i...@freebsd.org> >
> Cc: freebsd-arm mailto:freebsd-...@freebsd.org> >; 
> freebsd-wireless@freebsd.org <mailto:freebsd-wireless@freebsd.org> ; Hans 
> Petter Selasky  <mailto:hans.petter.sela...@bitfrost.no> >
> Subject: Re: My WLI-UC-GNM up crash
> 
> No idea about the device disconnect, sorry. is it a power draw problem?
> 
> 
> -adrian
> 
> On 31 July 2013 06:41, Ian Lepore mailto:i...@freebsd.org> 
> > wrote:
> > On Wed, 2013-07-31 at 16:28 +0800, XiaoQI Ge wrote:
> >> Last night, I use the latest FreeBSD source (r253827) and
> >> crochet-freebsd compile img
> >> My WLI-UC-GNM will be disconnected after a period of operation
> >>
> >> run0: device timeout
> >> run0: at uhub0, port 1, addr 2 (disconnected)
> >>
> >> Another log prompted
> >> ti_mmchs0: Error: current cmd NULL, already done?
> >>
> >> My BB-Black broken?
> >
> > The ti_mmchs0 error is not new.  My old BBW has done that for months.
> > I'm not sure it's totally harmless, but it's not related to the run0
> > timeouts.
> >
> > -- Ian
> >
> > ___
> > freebsd-...@freebsd.org <mailto:freebsd-...@freebsd.org>  mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-arm 
> > <http://lists.freebsd.org/mailman/listinfo/freebsd-arm> 
> > To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org 
> > <mailto:freebsd-arm-unsubscr...@freebsd.org> "
> ___
> freebsd-...@freebsd.org <mailto:freebsd-...@freebsd.org>  mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm 
> <http://lists.freebsd.org/mailman/listinfo/freebsd-arm> 
> To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org 
> <mailto:freebsd-arm-unsubscr...@freebsd.org> "
> 

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: if_rsu hardware causes a kernel panic on removal..

[Hans Petter Selasky]

On 05/19/14 23:21, Idwer Vollering wrote:

..while running a kernel that has rsu_debug set to >0.

Line 1712: "fault virtual address   = 0x8040"
core0.txt -> 
http://ra.openbios.org/~idwer/freebsd/fbsd_10-stable_rsu_panic_core_0.txt

HTH,


Hi,

Does this patch make any difference?

--HPS

=== ./if_rsu.c
==
--- ./if_rsu.c  (revision 266400)
+++ ./if_rsu.c  (local)
@@ -423,8 +423,6 @@
struct ifnet *ifp = sc->sc_ifp;
struct ieee80211com *ic = ifp->if_l2com;

-   if (!device_is_attached(self))
-   return (0);
rsu_stop(ifp, 1);
usbd_transfer_unsetup(sc->sc_xfer, RSU_N_TRANSFER);
ieee80211_ifdetach(ic);

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: if_rsu hardware causes a kernel panic on removal..

[Hans Petter Selasky]

On 05/20/14 14:13, Idwer Vollering wrote:

2014-05-20 7:47 GMT+02:00 Hans Petter Selasky :

On 05/19/14 23:21, Idwer Vollering wrote:


..while running a kernel that has rsu_debug set to >0.

Line 1712: "fault virtual address   = 0x8040"
core0.txt ->
http://ra.openbios.org/~idwer/freebsd/fbsd_10-stable_rsu_panic_core_0.txt

HTH,



Hi,

Does this patch make any difference?


Yes, this solves the panic.



Hi,

Please verify:

http://svnweb.freebsd.org/changeset/base/266466

--HPS
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: if_rsu hardware causes a kernel panic on removal..

[Hans Petter Selasky]

On 05/20/14 17:00, Idwer Vollering wrote:

2014-05-20 14:24 GMT+02:00 Hans Petter Selasky :

On 05/20/14 14:13, Idwer Vollering wrote:


2014-05-20 7:47 GMT+02:00 Hans Petter Selasky :


On 05/19/14 23:21, Idwer Vollering wrote:



..while running a kernel that has rsu_debug set to >0.

Line 1712: "fault virtual address   = 0x8040"
core0.txt ->

http://ra.openbios.org/~idwer/freebsd/fbsd_10-stable_rsu_panic_core_0.txt

HTH,




Hi,

Does this patch make any difference?



Yes, this solves the panic.



Hi,

Please verify:

http://svnweb.freebsd.org/changeset/base/266466

--HPS


Looks good to me.. if only it wasn't panicking on insertion, again
with rsu_debug set to anything greater than 0 (5, in this case). The
panic on insertion is reproducable with otherwise unmodified r266465.
Any thoughts?



Hi,

Can you get the backtrace of this panic?

--HPS
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: if_rsu hardware causes a kernel panic on removal..

[Hans Petter Selasky]

Hi,

Is your kernel built clean with modules?

--HPS
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: if_rsu hardware causes a kernel panic on removal..

[Hans Petter Selasky]

Hi,

Certainly, here it is:
http://ra.openbios.org/~idwer/freebsd/core.txt.9_fbsd_10-stable_rsu-panic-on-insertion

Idwer



Does the attached patch make any difference?

--HPS
=== if_rsu.c
==
--- if_rsu.c	(revision 266476)
+++ if_rsu.c	(local)
@@ -189,9 +189,9 @@
 static void	rsu_init_locked(struct rsu_softc *);
 static void	rsu_watchdog(void *);
 static int	rsu_tx_start(struct rsu_softc *, struct ieee80211_node *, 
-		struct mbuf *, struct rsu_data *);
+		struct mbuf *, struct rsu_data *, struct usb_xfer *);
 static void	rsu_start(struct ifnet *);
-static void	rsu_start_locked(struct ifnet *);
+static void	rsu_start_locked(struct ifnet *, struct usb_xfer *);
 static int	rsu_ioctl(struct ifnet *, u_long, caddr_t);
 static void	rsu_stop(struct ifnet *, int);
 static void	rsu_stop_locked(struct ifnet *, int);
@@ -1610,7 +1610,7 @@
 		usbd_xfer_set_frame_data(xfer, 0, data->buf, data->buflen);
 		DPRINTF("submitting transfer %p\n", data);
 		usbd_transfer_submit(xfer);
-		rsu_start_locked(ifp);
+		rsu_start_locked(ifp, xfer);
 		break;
 	default:
 		data = STAILQ_FIRST(&sc->sc_tx_active);
@@ -1631,7 +1631,7 @@
 
 static int
 rsu_tx_start(struct rsu_softc *sc, struct ieee80211_node *ni, 
-struct mbuf *m0, struct rsu_data *data)
+struct mbuf *m0, struct rsu_data *data, struct usb_xfer *xfer_self)
 {
 	struct ifnet *ifp = sc->sc_ifp;
 	struct ieee80211com *ic = ifp->if_l2com;
@@ -1736,8 +1736,9 @@
 	data->ni = ni;
 	data->m = m0;
 	STAILQ_INSERT_TAIL(&sc->sc_tx_pending, data, next);
-	usbd_transfer_start(xfer);
 
+	if (xfer != xfer_self)
+		usbd_transfer_start(xfer);
 	return (0);
 }
 
@@ -1750,12 +1751,12 @@
 		return;
 
 	RSU_LOCK(sc);
-	rsu_start_locked(ifp);
+	rsu_start_locked(ifp, NULL);
 	RSU_UNLOCK(sc);
 }
 
 static void
-rsu_start_locked(struct ifnet *ifp)
+rsu_start_locked(struct ifnet *ifp, struct usb_xfer *xfer_self)
 {
 	struct rsu_softc *sc = ifp->if_softc;
 	struct ieee80211_node *ni;
@@ -1776,7 +1777,7 @@
 		ni = (struct ieee80211_node *)m->m_pkthdr.rcvif;
 		m->m_pkthdr.rcvif = NULL;
 
-		if (rsu_tx_start(sc, ni, m, bf) != 0) {
+		if (rsu_tx_start(sc, ni, m, bf, xfer_self) != 0) {
 			ifp->if_oerrors++;
 			STAILQ_INSERT_HEAD(&sc->sc_tx_inactive, bf, next);
 			ieee80211_free_node(ni);
@@ -2303,7 +2304,7 @@
 		return (ENOBUFS);
 	}
 	ifp->if_opackets++;
-	if (rsu_tx_start(sc, ni, m, bf) != 0) {
+	if (rsu_tx_start(sc, ni, m, bf, NULL) != 0) {
 		ieee80211_free_node(ni);
 		ifp->if_oerrors++;
 		STAILQ_INSERT_HEAD(&sc->sc_tx_inactive, bf, next);
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: if_rsu hardware causes a kernel panic on removal..

[Hans Petter Selasky]

On 05/21/14 00:16, Idwer Vollering wrote:

2014-05-20 20:22 GMT+02:00 Hans Petter Selasky :

Hi,

Certainly, here it is:

http://ra.openbios.org/~idwer/freebsd/core.txt.9_fbsd_10-stable_rsu-panic-on-insertion

Idwer



Does the attached patch make any difference?

--HPS


Yes, it seems to improve the situation.
Apparently putting "wlandebug_wlan2=0x4000" in /etc/rc.conf and
compiling+booting with rsu_debug=5 triggers the panic.

A verbose boot, so that debug.boothowto=2048 and debug.bootverbose=1,
doesn't seem to influence behaviour.



Hi,

Can you SVN up to:

http://svnweb.freebsd.org/changeset/base/266484

at least, and compile a new kernel and modules without any additional 
patches.


Then send backtrace of any new panics.

--HPS
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: if_rsu hardware causes a kernel panic on removal..

[Hans Petter Selasky]

On 05/21/14 16:23, Idwer Vollering wrote:

2014-05-21 8:26 GMT+02:00 Hans Petter Selasky :

Hi,

Can you SVN up to:

http://svnweb.freebsd.org/changeset/base/266484

at least, and compile a new kernel and modules without any additional
patches.


As said earlier, the only local change is 'int rsu_debug=5'.


Then send backtrace of any new panics.


http://ra.openbios.org/~idwer/freebsd/core.txt.0_fbsd-current-r266496-rsu-panic-insertion



--HPS




Hi,

Can you try the attached patch and report back?

--HPS
=== ./if_rsu.c
==
--- ./if_rsu.c	(revision 266497)
+++ ./if_rsu.c	(local)
@@ -128,7 +128,10 @@
 static device_probe_t   rsu_match;
 static device_attach_t  rsu_attach;
 static device_detach_t  rsu_detach;
-static usb_callback_t   rsu_bulk_tx_callback;
+static usb_callback_t   rsu_bulk_tx_callback_0;
+static usb_callback_t   rsu_bulk_tx_callback_1;
+static usb_callback_t   rsu_bulk_tx_callback_2;
+static usb_callback_t   rsu_bulk_tx_callback_3;
 static usb_callback_t   rsu_bulk_rx_callback;
 static usb_error_t	rsu_do_request(struct rsu_softc *,
 			struct usb_device_request *, void *);
@@ -241,7 +244,7 @@
 			.pipe_bof = 1,
 			.force_short_xfer = 1
 		},
-		.callback = rsu_bulk_tx_callback,
+		.callback = rsu_bulk_tx_callback_0,
 		.timeout = RSU_TX_TIMEOUT
 	},
 	[RSU_BULK_TX_BK] = {
@@ -254,7 +257,7 @@
 			.pipe_bof = 1,
 			.force_short_xfer = 1
 		},
-		.callback = rsu_bulk_tx_callback,
+		.callback = rsu_bulk_tx_callback_1,
 		.timeout = RSU_TX_TIMEOUT
 	},
 	[RSU_BULK_TX_VI] = {
@@ -267,7 +270,7 @@
 			.pipe_bof = 1,
 			.force_short_xfer = 1
 		},
-		.callback = rsu_bulk_tx_callback,
+		.callback = rsu_bulk_tx_callback_2,
 		.timeout = RSU_TX_TIMEOUT
 	},
 	[RSU_BULK_TX_VO] = {
@@ -280,7 +283,7 @@
 			.pipe_bof = 1,
 			.force_short_xfer = 1
 		},
-		.callback = rsu_bulk_tx_callback,
+		.callback = rsu_bulk_tx_callback_3,
 		.timeout = RSU_TX_TIMEOUT
 	},
 };
@@ -598,10 +601,13 @@
 	if (error != 0)
 		return (error);
 
-	STAILQ_INIT(&sc->sc_tx_active);
 	STAILQ_INIT(&sc->sc_tx_inactive);
-	STAILQ_INIT(&sc->sc_tx_pending);
 
+	for (i = 0; i != RSU_MAX_TX_EP; i++) {
+		STAILQ_INIT(&sc->sc_tx_active[i]);
+		STAILQ_INIT(&sc->sc_tx_pending[i]);
+	}
+
 	for (i = 0; i < RSU_TX_LIST_COUNT; i++) {
 		STAILQ_INSERT_HEAD(&sc->sc_tx_inactive, &sc->sc_tx[i], next);
 	}
@@ -843,10 +849,12 @@
 static int
 rsu_fw_cmd(struct rsu_softc *sc, uint8_t code, void *buf, int len)
 {
+	const uint8_t which = RSU_BULK_TX_VO - RSU_BULK_TX_BE;
 	struct rsu_data *data;
 	struct r92s_tx_desc *txd;
 	struct r92s_fw_cmd_hdr *cmd;
-	int cmdsz, xferlen;
+	int cmdsz;
+	int xferlen;
 
 	data = rsu_getbuf(sc);
 	if (data == NULL)
@@ -879,8 +887,8 @@
 
 	DPRINTFN(2, "Tx cmd code=0x%x len=0x%x\n", code, cmdsz);
 	data->buflen = xferlen;
-	STAILQ_INSERT_TAIL(&sc->sc_tx_pending, data, next);
-	usbd_transfer_start(sc->sc_xfer[RSU_BULK_TX_VO]);
+	STAILQ_INSERT_TAIL(&sc->sc_tx_pending[which], data, next);
+	usbd_transfer_start(sc->sc_xfer[which + RSU_BULK_TX_BE]);
 
 	return (0);
 }
@@ -1580,7 +1588,7 @@
 }
 
 static void
-rsu_bulk_tx_callback(struct usb_xfer *xfer, usb_error_t error)
+rsu_bulk_tx_callback_sub(struct usb_xfer *xfer, usb_error_t error, uint8_t which)
 {
 	struct rsu_softc *sc = usbd_xfer_softc(xfer);
 	struct ifnet *ifp = sc->sc_ifp;
@@ -1590,23 +1598,23 @@
 
 	switch (USB_GET_STATE(xfer)) {
 	case USB_ST_TRANSFERRED:
-		data = STAILQ_FIRST(&sc->sc_tx_active);
+		data = STAILQ_FIRST(&sc->sc_tx_active[which]);
 		if (data == NULL)
 			goto tr_setup;
 		DPRINTF("transfer done %p\n", data);
-		STAILQ_REMOVE_HEAD(&sc->sc_tx_active, next);
+		STAILQ_REMOVE_HEAD(&sc->sc_tx_active[which], next);
 		rsu_txeof(xfer, data);
 		STAILQ_INSERT_TAIL(&sc->sc_tx_inactive, data, next);
 		/* FALLTHROUGH */
 	case USB_ST_SETUP:
 tr_setup:
-		data = STAILQ_FIRST(&sc->sc_tx_pending);
+		data = STAILQ_FIRST(&sc->sc_tx_pending[which]);
 		if (data == NULL) {
 			DPRINTF("empty pending queue sc %p\n", sc);
 			return;
 		}
-		STAILQ_REMOVE_HEAD(&sc->sc_tx_pending, next);
-		STAILQ_INSERT_TAIL(&sc->sc_tx_active, data, next);
+		STAILQ_REMOVE_HEAD(&sc->sc_tx_pending[which], next);
+		STAILQ_INSERT_TAIL(&sc->sc_tx_active[which], data, next);
 		usbd_xfer_set_frame_data(xfer, 0, data->buf, data->buflen);
 		DPRINTF("submitting transfer %p\n", data);
 		usbd_transfer_submit(xfer);
@@ -1613,14 +1621,21 @@
 		rsu_start_locked(ifp, xfer);
 		break;
 	default:
-		data = STAILQ_FIRST(&sc->sc_tx_active);
-		if (data == NULL)
+		data = STAILQ_FIRST(&sc->sc_tx_active[which]);
+		if (data == NULL) {
+			if (error == USB_ERR_CANCELLED)
+break;
+
+			usbd_xfer_set_stall(xfer);
 			goto tr_setup;
-		if (data->ni != NULL) {
-			ieee80211_free_node(data->

Re: if_rsu hardware causes a kernel panic on removal..

[Hans Petter Selasky]

FYI:

http://svnweb.freebsd.org/changeset/base/266505

--HPS
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: if_rsu hardware causes a kernel panic on removal..

[Hans Petter Selasky]

On 05/21/14 23:23, Idwer Vollering wrote:

2014-05-21 19:35 GMT+02:00 Hans Petter Selasky :

FYI:

http://svnweb.freebsd.org/changeset/base/266505

--HPS


Newer backtrace:
http://ra.openbios.org/~idwer/freebsd/core.txt.0_fbsd-current-r266514-rsu-panic-insertion



Hi,

Try this:

http://svnweb.freebsd.org/changeset/base/266535

--HPS
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: if_rsu hardware causes a kernel panic on removal..

[Hans Petter Selasky]

On 05/22/14 13:22, Idwer Vollering wrote:

rsu0: timeout waiting for EMEM transfer


Does this patch make any difference:

=== ./if_rsu.c
==
--- ./if_rsu.c  (revision 266539)
+++ ./if_rsu.c  (local)
@@ -2220,13 +2220,13 @@
goto fail;
}
/* Wait for load to complete. */
-   for (ntries = 0; ntries != 10; ntries++) {
+   for (ntries = 0; ntries != 50; ntries++) {
usb_pause_mtx(&sc->sc_mtx, hz / 100);
reg = rsu_read_2(sc, R92S_TCR);
if (reg & R92S_TCR_EMEM_CODE_DONE)
break;
}
-   if (ntries == 10) {
+   if (ntries == 50) {
device_printf(sc->sc_dev, "timeout waiting for EMEM 
transfer\n");
error = ETIMEDOUT;
goto fail;

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: if_rsu hardware causes a kernel panic on removal..

[Hans Petter Selasky]

On 05/22/14 20:34, Idwer Vollering wrote:

Hi,

This patch again improves its stability, but the interface keeps flapping:

May 22 20:29:03 machete wpa_supplicant[2211]: ioctl[SIOCS80211, op=20,
val=0, arg_len=7]: Device not configured
May 22 20:29:03 machete last message repeated 3 times
May 22 20:29:03 machete wpa_supplicant[2211]: ioctl[SIOCS80211, op=25,
val=0, arg_len=0]: Device not configured
May 22 20:29:03 machete wpa_supplicant[2211]: ioctl[SIOCS80211, op=95,
val=208, arg_len=0]: Device not configured
May 22 20:29:03 machete wpa_supplicant[2211]: ioctl[SIOCS80211, op=17,
val=0, arg_len=0]: Device not configured
May 22 20:29:03 machete wpa_supplicant[2211]: ioctl[SIOCS80211, op=26,
val=0, arg_len=0]: Device not configured
May 22 20:29:03 machete wpa_supplicant[2211]: ioctl[SIOCS80211, op=95,
val=208, arg_len=0]: Device not configured
May 22 20:29:03 machete wpa_supplicant[2211]: ioctl[SIOCS80211, op=17,
val=0, arg_len=0]: Device not configured
May 22 20:29:03 machete wpa_supplicant[2211]: ioctl[SIOCS80211, op=26,
val=0, arg_len=0]: Device not configured
May 22 20:29:03 machete wpa_supplicant[2211]: ioctl[SIOCS80211, op=16,
val=1, arg_len=0]: Device not configured

May 22 20:30:27 machete dhclient[2734]: send_packet: Invalid argument
wlan2: link state changed to UP
wlan2: link state changed to DOWN
wlan2: link state changed to UP
wlan2: link state changed to DOWN
May 22 20:30:27 machete dhclient[2734]: send_packet: Invalid argument
wlan2: link state changed to UP
May 22 20:30:36 machete dhclient[2734]: send_packet: No buffer space available
wlan2: link state changed to DOWN
wlan2: link state changed to UP
May 22 20:31:03 machete dhclient[2734]: send_packet: No buffer space available



Hi,

I guess you need to enable rsu debugging to figure out why the hardware 
reports link loss.


--HPS
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: Change for the worse in rsu wireless driver

[Hans Petter Selasky]

On 06/02/14 07:30, Thomas Mueller wrote:

I sent this message, without this top part, over an hour ago, and notice wlan0 
is still up.  I intended but forgot to CC to freebsd-current.  But I am in 
newcons, having not started X so far this boot session.  Maybe something rotten 
with Xorg, or interaction between rsu and X, or rsu and Firefox.

I am afraid to try again with X, don't want to mess the file system to the 
extent of losing data.

WLAN device is Hiro H50191 USB wireless adapter, chipset RTL8191SU.

I just updated FreeBSD-current, both amd64 and i386, now both rsu and Xorg are 
highly unstable, at least on amd64.

FreeBSD amelia4 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r266948: Sun Jun  1 
19:12:44 UTC 2014 root@amelia4:/usr/obj/usr/src/sys/SANDY11NC  amd64

root@amelia4:~ # ls -l /usr/src/sys/dev/usb/wlan

total 1164

-rw-r--r--  1 root  wheel   65759 Jun  1 16:23 if_rsu.c

-rw-r--r--  1 root  wheel   19964 Jun  1 16:23 if_rsureg.h

(snip)

This is a change for the worse.  Now I can connect with Hiro H50191; bug in re 
Ethernet driver persists, so I can't connect that way.

I also had several crashes in Xorg, so am typing this with vi in newcons.

Tom


Hi,

Re-compile the rsu module with USB debugging enabled:

Add to: sys/modules/usb/rsu/Makefile

CFLAGS+= -DUSB_DEBUG

Rebuild and install.

After that lookup the debug knob using "sysctl hw.usb | grep rsu" and 
set it to 16. Then collect some debug messages in dmesg, when problems 
appear.


Thank you.

--HPS

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: Change for the worse in rsu wireless driver

[Hans Petter Selasky]

On 06/03/14 12:15, Thomas Mueller wrote:

from Idwer Vollering :

I have a patch for that:

Index: head/sys/dev/usb/wlan/if_rsu.c
===
--- head/sys/dev/usb/wlan/if_rsu.c  (revision 266970)
+++ head/sys/dev/usb/wlan/if_rsu.c  (working copy)
@@ -69,11 +69,13 @@

  #include 

+static SYSCTL_NODE(_hw_usb, OID_AUTO, rsu, CTLFLAG_RW, 0, "USB rsu");
+
  #ifdef USB_DEBUG
-static int rsu_debug = 0;
-SYSCTL_NODE(_hw_usb, OID_AUTO, rsu, CTLFLAG_RW, 0, "USB rsu");
-SYSCTL_INT(_hw_usb_rsu, OID_AUTO, debug, CTLFLAG_RW, &rsu_debug, 0,
+int rsu_debug = 0;
+SYSCTL_INT(_hw_usb_rsu, OID_AUTO, debug, CTLFLAG_RW | CTLFLAG_TUN,
&rsu_debug, 0,
  "Debug level");
+TUNABLE_INT("hw.usb.rsu.debug", &rsu_debug);
  #endif

  static const STRUCT_USB_HOST_ID rsu_devs[] = {
@@ -1284,7 +1286,7 @@
 DPRINTF("WPS PBC pushed.\n");
 break;
 case R92S_EVT_FWDBG:
-   if (ifp->if_flags & IFF_DEBUG) {
+   if (rsu_debug >= 6) {
 buf[60] = '\0';
 printf("FWDBG: %s\n", (char *)buf);
 }

(end of quote)

I do not put "> " in front of these lines for quoting here.

Patch failed to apply, something was malformed.

I have no directory named head, but even removing that left errors.

I suppose I could look through original file and patch, and manually make the 
changes with vi.  Should I try that?  I am already long overdue for bed.

Anyway, I have other stuff to do on computer, including NetBSD-current amd64 
and i386 installations on USB sticks, plan to install on new hard drive as well.

I'll be more inclined to come back when cups 1.7.3 becomes available in ports 
tree.  I need to be able to print.  Maybe NetBSD will be mainly a way station 
for cross-compiling Linux?

Now FreeBSD 11-current amd64 betrays me again as I lost the wireless connection 
and have to boot into my FreeBSD 10-stable amd64 or i386 installation or 
NetBSD-head amd64.

Tom


Yes, please apply by hand. I'll see if I can do some testing myself. I 
happen to have one of these adapters too and the link is very unstable :-)


--HPS

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: Change for the worse in rsu wireless driver

[Hans Petter Selasky]

On 06/04/14 04:13, Thomas Mueller wrote:

Yes, please apply by hand. I'll see if I can do some testing myself. I happen   
to have one of these adapters too and the link is very unstable :-)

--HPS

Sometimes Hiro H50191 USB-stick wireless adapter works well in FreeBSD, 
sometimes, like now and the past few days, it's flaky.  It can't seem to 
download distfile for qt4-xml, on two occasions.

I also have Atheros AR9271 quasi-USB wireless adapter on this motherboard as 
well as Realtek 8111E (?) Ethernet that is recognized by FreeBSD but fails to 
connect (same as with OpenBSD and DragonFlyBSD, but good with NetBSD and Linux).

So I don't want to buy another wireless adapter (USB or PCIE?) until I find if 
the Hiro H50191 works better with Linux and OpenBSD.  Maybe the hardware is 
perfectly good and the software is soft.

All I have for OpenBSD is LiveUSB OpenBSD 5.4 from 
liveusb-openbsd.sourceforge.net , since OpenBSD can't read my hard drive at 
all, neither could DragonFlyBSD.

Tom


Previously there was a bug in the if_rsu driver that prevented the 
firmware from loading. Is this device on your mainboard? Does the BIOS 
support it?


--HPS

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: Change for the worse in rsu wireless driver

[Hans Petter Selasky]

On 06/04/14 08:53, Hans Petter Selasky wrote:

On 06/04/14 04:13, Thomas Mueller wrote:

Yes, please apply by hand. I'll see if I can do some testing myself.
I happen   to have one of these adapters too and the link is very
unstable :-)

--HPS


Hi,

Please test the following patch, applied to top of 10-stable as of now:

http://svnweb.freebsd.org/changeset/base/267041

At least my adapter is working a bit more stable now :-)

--HPS

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: rsu wireless driver crapshoot

[Hans Petter Selasky]

On 06/27/14 06:39, Thomas Mueller wrote:

My Internet connection on this computer is very iffy at best, not running as I 
type this.

Motherboard is MSI Z77 MPOWER.

Ethernet is Realtek (re): good with NetBSD, Linux and Haiku, (Free,Open and 
DragonFly)BSD bug out.

Only Internet connection for FreeBSD is Hiro H50191 USB-stick wireless adapter, 
chipset RTL8191SU, device rsu.

Sometimes it connects.  Running ifconfig (by itself), I get, whether connection 
is working ot not,



Hi,

You can help us by sending an e-mail to the manufacturer to provide the 
programmers guide for this device so that we can make a proper driver. I 
understand your device does not work that great under FreeBSD.


It is also possible for you look into the code and try and modify 
things, watch debug prints and so on and propose a patch. It is not that 
difficult.


Another option is to buy a Raalink based WLAN dongle. See ural/run/rum 
drivers. They work much more reliably!


Thank you!

--HPS

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: Zyxel NWD2105 support not complete in FreeBSD 10.2-stable

[Hans Petter Selasky]

On 12/13/15 23:05, Torfinn Ingolfsen wrote:

Hello,
Today I added a Zyxel NWD2015[1] usb network adapter to a laptop running latest 
FreeBSD 10.2-stable:
root@kg-z30b# uname -a


Forgot to MFC to 10-stable. Please try again. Thank you!

--HPS

___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: D-link wireless not detected

[Hans Petter Selasky]

On 12/29/15 10:42, Daniel Braniss wrote:



On 29 Dec 2015, at 11:33, Vladimir Botka  wrote:

Hi Danny,

On Tue, 29 Dec 2015 11:16:27 +0200
Daniel Braniss  wrote:

Hi All,
I have a working tp-link usb (realtek), but can’t get a d-link(also realtek) to 
work.
usbconfig:
ugen0.4:  at usbus0, cfg=0 md=HOST 
spd=HIGH (480Mbps) pwr=ON (500mA)
This is on a raspberry pi running a resent current.
cheers & season greetings,
danny


I've added freebsd-wireless list.

My 2 cents. It might be helpful to see more details about the adapters.
For example:

# usbconfig -u 0 -a 7 dump_device_desc
ugen0.7: <802.11 n WLAN Ralink> at usbus0, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=ON (450mA)
  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x  
  bDeviceSubClass = 0x
  bDeviceProtocol = 0x
  bMaxPacketSize0 = 0x0040
  idVendor = 0x148f
  idProduct = 0x5370
  bcdDevice = 0x0101
  iManufacturer = 0x0001  
  iProduct = 0x0002  <802.11 n WLAN>
  iSerialNumber = 0x0003  <1.0>
  bNumConfigurations = 0x0001



so here it is:
root@:~ # usbconfig -u 0 -a 4 dump_device_desc
ugen0.4:  at usbus0, cfg=0 md=HOST 
spd=HIGH (480Mbps) pwr=ON (500mA)

   bLength = 0x0012
   bDescriptorType = 0x0001
   bcdUSB = 0x0210
   bDeviceClass = 0x  
   bDeviceSubClass = 0x
   bDeviceProtocol = 0x
   bMaxPacketSize0 = 0x0040
   idVendor = 0x2001
   idProduct = 0x3319
   bcdDevice = 0x0200
   iManufacturer = 0x0001  
   iProduct = 0x0002  
   iSerialNumber = 0x0003  <00e04c01>
   bNumConfigurations = 0x0001

thanks,
danny



Did you google the idVendor and idProduct values and see if Linux has a 
driver already?


--HPS

___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: D-link wireless not detected

[Hans Petter Selasky]

On 12/29/15 11:12, Daniel Braniss wrote:


https://github.com/Mange/rtl8192eu-linux-driver/blob/master/os_dep/linux/usb_intf.c  

and look at line 216

danny


Hi,

You should be able to get this device working by adding a device entry to:

src/sys/dev/usb/wlan/if_urtwn.c

Can you make a patch and PR for this, and I'll submit upstream. I 
recommend you test using an 11-current kernel.


--HPS
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: D-link wireless not detected

[Hans Petter Selasky]

On 12/29/15 13:26, Daniel Braniss wrote:



On 29 Dec 2015, at 12:20, Hans Petter Selasky  wrote:

On 12/29/15 11:12, Daniel Braniss wrote:


https://github.com/Mange/rtl8192eu-linux-driver/blob/master/os_dep/linux/usb_intf.c  
<https://github.com/Mange/rtl8192eu-linux-driver/blob/master/os_dep/linux/usb_intf.c>
and look at line 216

danny


Hi,

You should be able to get this device working by adding a device entry to:

src/sys/dev/usb/wlan/if_urtwn.c

Can you make a patch and PR for this, and I'll submit upstream. I recommend you 
test using an 11-current kernel.

--HPS


clearly, I’m missing something, because it’s not working :-(
the only visible change is now
ugen0.4: <802.11n WLAN Adapter RealtekWireless N Nano USB A> at usbus0, cfg=0 
md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
before it was
ugen0.4:  at usbus0, cfg=0 md=HOST 
spd=HIGH (480Mbps) pwr=ON (500mA)

rnd> svn diff
Index: usbdevs
===
--- usbdevs (revision 291745)
+++ usbdevs (working copy)
@@ -1657,6 +1657,7 @@
  product DLINK2 RTL8192SU_1 0x3300  RTL8192SU
  product DLINK2 RTL8192SU_2 0x3302  RTL8192SU
  product DLINK2 DWA131A10x3303  DWA-131 A1
+product DLINK  DWA131  0x3319  DWA-131
  product DLINK2 DWA160A20x3a09  DWA-160 A2
  product DLINK2 DWA120  0x3a0c  DWA-120
  product DLINK2 DWA120_NF   0x3a0d  DWA-120 (no firmware)
Index: wlan/if_urtwn.c
===
--- wlan/if_urtwn.c (revision 291745)
+++ wlan/if_urtwn.c (working copy)
@@ -116,6 +116,7 @@
 URTWN_DEV(DLINK,RTL8192CU_2),
 URTWN_DEV(DLINK,RTL8192CU_3),
 URTWN_DEV(DLINK,DWA131B),
+   URTWN_DEV(DLINK,DWA131), // danny
 URTWN_DEV(EDIMAX,   EW7811UN),
 URTWN_DEV(EDIMAX,   RTL8192CU),
 URTWN_DEV(FEIXUN,   RTL8188CU),



Hi,

You should use vendor RALINK (according to your usbconfig dump)

vendor RALINK   0x148f  Ralink Technology

--HPS
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: D-link wireless not detected

[Hans Petter Selasky]

On 12/29/15 13:36, Daniel Braniss wrote:




Until /etc/devd/usb.conf is regenerated, you'll need to manually load 
the kernel module for urtwn. Did you do that?


--HPS

___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: D-link wireless not detected

[Hans Petter Selasky]

On 12/29/15 14:00, Daniel Braniss wrote:



On 29 Dec 2015, at 14:44, Hans Petter Selasky  wrote:

On 12/29/15 13:36, Daniel Braniss wrote:




Until /etc/devd/usb.conf is regenerated, you'll need to manually load the 
kernel module for urtwn. Did you do that?

--HPS


ok, set if_urtwn_load=yes
and now I get:

ugen0.4:  at usbus0
urtwn0:  on usbus0
urtwn0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
Fatal kernel mode data abort: 'Translation Fault (L1)' on write
trapframe: 0xda29fb88
FSR=0805, FAR=, spsr=6013
r0 =, r1 =, r2 =c0a72cb0, r3 =0165
r4 =c2cd, r5 =c0a86650, r6 =c2cd1a80, r7 =
r8 =c2cd1dd8, r9 =c2cd1a20, r10=c2a85dd0, r11=da29fc20
r12=, ssp=da29fc18, slr=0004, pc =c0a3f7cc

[ thread pid 13 tid 100045 ]
Stopped at  ieee80211_ifdetach+0x4c:str r0, [r1]
db>

btw, as long as you are willing to help, I will keep testing,
in other words, i’m ok.


Hi Andriy,

Can you fix the crash above and verify this error patch?

Andriy:

After:
usbd_transfer_unsetup(sc->sc_xfer, URTWN_N_TRANSFER);
There is no need for:
usbd_transfer_drain(sc->sc_xfer[x]);

--HPS

___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: D-link wireless not detected

[Hans Petter Selasky]

On 12/29/15 15:02, Hans Petter Selasky wrote:

On 12/29/15 14:00, Daniel Braniss wrote:



On 29 Dec 2015, at 14:44, Hans Petter Selasky  wrote:

On 12/29/15 13:36, Daniel Braniss wrote:




Until /etc/devd/usb.conf is regenerated, you'll need to manually load
the kernel module for urtwn. Did you do that?

--HPS


ok, set if_urtwn_load=yes
and now I get:

ugen0.4:  at usbus0
urtwn0:  on usbus0
urtwn0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
Fatal kernel mode data abort: 'Translation Fault (L1)' on write
trapframe: 0xda29fb88
FSR=0805, FAR=, spsr=6013
r0 =, r1 =, r2 =c0a72cb0, r3 =0165
r4 =c2cd, r5 =c0a86650, r6 =c2cd1a80, r7 =
r8 =c2cd1dd8, r9 =c2cd1a20, r10=c2a85dd0, r11=da29fc20
r12=, ssp=da29fc18, slr=0004, pc =c0a3f7cc

[ thread pid 13 tid 100045 ]
Stopped at  ieee80211_ifdetach+0x4c:str r0, [r1]
db>

btw, as long as you are willing to help, I will keep testing,
in other words, i’m ok.


Hi Andriy,

Can you fix the crash above and verify this error patch?



Hi,

I see 11-current has a fix. Maybe MFC that to 10-stable?


Andriy:

After:
 usbd_transfer_unsetup(sc->sc_xfer, URTWN_N_TRANSFER);
There is no need for:
 usbd_transfer_drain(sc->sc_xfer[x]);


--HPS

___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: Deadlock between device_detach() and usbd_do_request_flags()

[Hans Petter Selasky]

On 09/04/16 23:20, Andriy Voskoboinyk wrote:

There is a rare, but reproducible deadlock for wlan(4) drivers:

Thread 1:
 * uhub_explore_handle_re_enumerate() (obtains enum_sx lock)
 * usbd_set_config_index()
 * usb_unconfigure()
 * usb_detach_device()
 * usb_detach_device_sub()
 * 
   typically  is executed here (prevents
another possible deadlock?)
 * ieee80211_ifdetach()
 * ieee80211_vap_destroy()
 * ic_vap_delete>
 * ieee80211_vap_detach()
   here it calls ieee80211_stop() and waits for  -> INIT state
   transition

Thread 2 (started from thread 1):
 * ieee80211_newstate_cb()
 * vap->iv_newstate()
   here: if the driver will try to call usbd_do_request_flags()
   (typically via  / ) it will hang
   (because enum_sx lock is already held by thread 1).


Another way: execute some periodical task that will try to access
some registers (urtwn_temp_calib(), rum_ratectl_task(),
run_ratectl_cb()) while thread 1 is running - deadlock is
here too, since  will wait for them indefinitely
(via ieee80211_draintask())

Right now the most obvious (and, probably, wrong) way is to just
detect & release all locks (usbd_enum_unlock()) for
ieee80211_ifdetach() / ieee80211_draintask() and re-acquire them
later (not tested yet).



Hi,

I think the right solution is to let usbd_do_request_flags() use its own 
SX lock for synchronization, instead of re-using the enumeration SX 
lock. What do you think about that?


--HPS

___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: Deadlock between device_detach() and usbd_do_request_flags()

[Hans Petter Selasky]

On 09/05/16 09:53, Hans Petter Selasky wrote:


Hi,

I think the right solution is to let usbd_do_request_flags() use its own
SX lock for synchronization, instead of re-using the enumeration SX
lock. What do you think about that?

--HPS



Hi,

Another approach which will work is to setup your own USB control 
endpoint xfer, and use that. I'll have a look and see what can be done.


--HPS

___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: Deadlock between device_detach() and usbd_do_request_flags()

[Hans Petter Selasky]

Hi,

Can you test the attached patch? Does it solve your issue?

--HPS
Index: sys/dev/usb/usb_device.c
===
--- sys/dev/usb/usb_device.c	(revision 304569)
+++ sys/dev/usb/usb_device.c	(working copy)
@@ -1585,6 +1585,7 @@
 	/* initialise our SX-lock */
 	sx_init_flags(&udev->enum_sx, "USB config SX lock", SX_DUPOK);
 	sx_init_flags(&udev->sr_sx, "USB suspend and resume SX lock", SX_NOWITNESS);
+	sx_init_flags(&udev->ctrl_sx, "USB control transfer SX lock", SX_DUPOK);
 
 	cv_init(&udev->ctrlreq_cv, "WCTRL");
 	cv_init(&udev->ref_cv, "UGONE");
@@ -2195,6 +2196,7 @@
 	
 	sx_destroy(&udev->enum_sx);
 	sx_destroy(&udev->sr_sx);
+	sx_destroy(&udev->ctrl_sx);
 
 	cv_destroy(&udev->ctrlreq_cv);
 	cv_destroy(&udev->ref_cv);
Index: sys/dev/usb/usb_device.h
===
--- sys/dev/usb/usb_device.h	(revision 304569)
+++ sys/dev/usb/usb_device.h	(working copy)
@@ -183,6 +183,7 @@
 	struct usb_udev_msg cs_msg[2];
 	struct sx enum_sx;
 	struct sx sr_sx;
+  	struct sx ctrl_sx;
 	struct mtx device_mtx;
 	struct cv ctrlreq_cv;
 	struct cv ref_cv;
Index: sys/dev/usb/usb_request.c
===
--- sys/dev/usb/usb_request.c	(revision 304569)
+++ sys/dev/usb/usb_request.c	(working copy)
@@ -418,7 +418,6 @@
 	uint16_t length;
 	uint16_t temp;
 	uint16_t acttemp;
-	uint8_t do_unlock;
 
 	if (timeout < 50) {
 		/* timeout is too small */
@@ -460,16 +459,16 @@
 	}
 
 	/*
-	 * Grab the USB device enumeration SX-lock serialization is
-	 * achieved when multiple threads are involved:
+	 * Serialize access to this function:
 	 */
-	do_unlock = usbd_enum_lock(udev);
+	sx_xlock(&udev->ctrl_sx);
 
 	/*
 	 * We need to allow suspend and resume at this point, else the
 	 * control transfer will timeout if the device is suspended!
 	 */
-	usbd_sr_unlock(udev);
+	if (usbd_enum_is_locked(udev))
+		usbd_sr_unlock(udev);
 
 	hr_func = usbd_get_hr_func(udev);
 
@@ -713,10 +712,10 @@
 	USB_XFER_UNLOCK(xfer);
 
 done:
-	usbd_sr_lock(udev);
+	sx_xunlock(&udev->ctrl_sx);
 
-	if (do_unlock)
-		usbd_enum_unlock(udev);
+	if (usbd_enum_is_locked(udev))
+		usbd_sr_lock(udev);
 
 	if ((mtx != NULL) && (mtx != &Giant))
 		mtx_lock(mtx);
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: Deadlock between device_detach() and usbd_do_request_flags()

[Hans Petter Selasky]

On 09/05/16 12:21, Andriy Voskoboinyk wrote:

Mon, 05 Sep 2016 12:10:34 +0300 було написано Hans Petter Selasky
:

Works fine, thanks!

P.S. Reliable test case:
1) ifconfig wlan1 create wlandev 
2) wpa_supplicant -i wlan1 -c /etc/wpa_supplicant.conf &
   * wait for CTRL-EVENT-CONNECTED event
3) usbconfig -d . power_off


Hi,

Can you test the attached patch? Does it solve your issue?

--HPS




FYI:

https://svnweb.freebsd.org/changeset/base/305421

--HPS
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: Small example program shut down urtwn

[Hans Petter Selasky]

On 09/06/16 06:47, Adrian Chadd wrote:

 missing some bus
barriers for ARM or something?


FYI: Most of the USB control and data memory is coherently allocated and 
don't need barriers. You can try capturing a trace using usbdump, of the 
traffic on your device, and see where it hangs:


usbdump -i usbusX -f Y -s 65536

--HPS
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: Small example program shut down urtwn

[Hans Petter Selasky]

On 09/06/16 18:38, Otacílio wrote:

After a lot of messages this appears:

13:04:40.000436 usbus1.2
DONE-BULK-EP=0081,SPD=HIGH,NFR=1,SLEN=384,IVAL=0,ERR=0
13:04:40.000447 usbus1.2 SUBM-BULK-EP=0081,SPD=HIGH,NFR=1,SLEN=0,IVAL=0
urtwn0: device timeout


Hi,

A USB analyzer would tell for sure. Most likely the USB dongle has 
stopped responding and is NAKing the 0x03 BULK OUT endpoint, which leads 
to the USB_ERR_TIMEOUT. You can try to set .interval = 1, in "struct 
usb_config", to nice the USB OUT transfers.


--HPS
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing

[Hans Petter Selasky]

On 09/19/16 19:43, Adrian Chadd wrote:

hi,

I'll try it out tonight! Is the rtwn repo still "ok" to try as a
standalone thing?

The usbdevs patch is fine standalone - would you like to just commit
this in advance?



Possibly you should also rebuild /etc/devd/usb.conf to automatically 
load the correct .ko . You changed the .ko name - right?


--HPS
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

if_iwm + WLAN + FreeBSD

[Hans Petter Selasky]

Hi,

When using the "reconfigure" command with wpa_cli these errors show up 
in dmesg with the if_iwm driver in 12-current and wlan becomes unusable.


Maybe there is a simple fix?


Jun 10 14:20:56 hps2016 kernel: wlan0: link state changed to DOWN
Jun 10 14:20:56 hps2016 kernel: wlan0: ieee80211_new_state_locked: pending INIT 
-> SCAN transition lost
Jun 10 14:20:58 hps2016 kernel: wlan0: link state changed to UP
Jun 10 14:20:59 hps2016 kernel: wlan0: link state changed to DOWN
Jun 10 14:21:00 hps2016 kernel: wlan0: ieee80211_new_state_locked: pending INIT 
-> SCAN transition lost
Jun 10 14:21:01 hps2016 kernel: wlan0: link state changed to UP


--HPS
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"