Re: if_rsu hardware causes a kernel panic on removal..
On 05/21/14 23:23, Idwer Vollering wrote: 2014-05-21 19:35 GMT+02:00 Hans Petter Selasky h...@selasky.org: 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..
2014-05-22 13:51 GMT+02:00 Hans Petter Selasky h...@selasky.org:
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;
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
___
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..
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: if_rsu hardware causes a kernel panic on removal..
On 05/21/14 00:16, Idwer Vollering wrote: 2014-05-20 20:22 GMT+02:00 Hans Petter Selasky h...@selasky.org: 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..
2014-05-21 8:26 GMT+02:00 Hans Petter Selasky h...@selasky.org: 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 ___ 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..
On 05/21/14 16:23, Idwer Vollering wrote:
2014-05-21 8:26 GMT+02:00 Hans Petter Selasky h...@selasky.org:
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-ni);
- data-ni = NULL;
- ifp-if_oerrors++;
}
+
+ STAILQ_REMOVE_HEAD(sc-sc_tx_active[which], next);
+ rsu_txeof(xfer, data);
+ STAILQ_INSERT_TAIL(sc-sc_tx_inactive, data, next);
+
+ ifp-if_oerrors++;
+
if (error != USB_ERR_CANCELLED) {
usbd_xfer_set_stall(xfer);
Re: if_rsu hardware causes a kernel panic on removal..
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..
2014-05-21 19:35 GMT+02:00 Hans Petter Selasky h...@selasky.org: 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 ___ 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..
2014-05-20 7:47 GMT+02:00 Hans Petter Selasky h...@selasky.org: 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. --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..
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..
2014-05-20 17:56 GMT+02:00 Hans Petter Selasky h...@bitfrost.no: Hi, Is your kernel built clean with modules? --HPS Yes; earlier I passed -DNO_CLEAN, but build time is below ten minutes I'm compiling without that option. I've applied the patch you sent, expect results soon. Idwer ___ 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..
2014-05-20 20:22 GMT+02:00 Hans Petter Selasky h...@selasky.org: 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. ___ 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
