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..
2014-05-22 13:51 GMT+02:00 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;
>
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 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..
2014-05-22 8:29 GMT+02:00 Hans Petter Selasky : > > Hi, > > Try this: > > http://svnweb.freebsd.org/changeset/base/266535 > > --HPS That is much better, thanks. As in: the panics are gone, although wpa_supplicant won't bring IP up: ugen3.3: at usbus3 rsu0: on usbus3 rsu_do_request: Control request failed, USB_ERR_TIMEOUT (retrying) 29:81:00:00:a9:16:00:00:da:0b:71:81:90:85:62:9c:06:00:00:e0:4c:04:52:a3:17:03:4d:61:6e:75:66:61:63:74:75:72:65:72:20:52:65:61:6c:74:65:6b:20:18:03:52:54:4c:38:31:38:38:53:20:57:4c:41:4e:20:41:64:61:70:74:65:72:20:00:00:00:00:00:00:00:00:00:02:05:00:00:00:27:27:27:1b:1b:1b:28:29:29:2d:2d:2d:2d:2d:2d:2d:2d:2d:44:12:00:00:09:0d:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00: rsu0: MAC/BB RTL8712 cut 3 rsu0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps rsu0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wlan2: bpf attached wlan2: bpf attached wlan2: Ethernet address: wlan2: start running, 0 vaps running wlan2: ieee80211_start_locked: up parent rsu0 rsu_do_request: Control request failed, USB_ERR_TIMEOUT (retrying) firmware: 'rsu-rtl8712fw' version 120: 122328 bytes loaded at 0x820551e0 rsu_load_firmware: FW V4588 05-30 16:53 rsu_fw_loadsection: starting transfer 0xfe0005ff47d8 (output abbreviated) rsu_bulk_tx_callback_sub: submitting transfer 0xfe0005ff47d8 rsu_bulk_tx_callback_sub: transfer done 0xfe0005ff47d8 (output abbreviated) rsu_bulk_tx_callback_sub: empty pending queue sc 0xfe0005ff2000 rsu_fw_loadsection: starting transfer 0xfe0005ff42f8 (output abbreviated) rsu_bulk_tx_callback_sub: submitting transfer 0xfe0005ff42f8 rsu_bulk_tx_callback_sub: transfer done 0xfe0005ff42f8 (output abbreviated) rsu0: timeout waiting for EMEM transfer wlan2: start running, 1 vaps running May 22 13:14:07 machete wpa_supplicant[822]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Device not configured ugen3.3: at usbus3 (disconnected) rsu0: at uhub1, port 2, addr 3 (disconnected) wlan2: stop running, 1 vaps running rsu_newstate: INIT -> INIT May 22 13:14:19 machete last message repeated 12 times May 22 13:14:19 machete wpa_supplicant[822]: ioctl[SIOCS80211, op=25, val=0, arg_len=0]: Device not configured May 22 13:14:19 machete wpa_supplicant[822]: ioctl[SIOCS80211, op=95, val=208, arg_len=0]: Device not configured May 22 13:14:19 machete wpa_supplicant[822]: ioctl[SIOCS80211, op=17, val=0, arg_len=0]: Device not configured May 22 13:14:19 machete wpa_supplicant[822]: ioctl[SIOCS80211, op=26, val=0, arg_len=0]: Device not configured May 22 13:14:19 machete wpa_supplicant[822]: ioctl[SIOCS80211, op=95, val=208, arg_len=0]: Device not configured May 22 13:14:19 machete wpa_supplicant[822]: ioctl[SIOCS80211, op=17, val=0, arg_len=0]: Device not configured May 22 13:14:19 machete wpa_supplicant[822]: ioctl[SIOCS80211, op=26, val=0, arg_len=0]: Device not configured May 22 13:14:19 machete wpa_supplicant[822]: ioctl[SIOCS80211, op=16, val=1, arg_len=0]: Device not configured ___ 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 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..
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 ___ 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..
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..
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->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_
Re: if_rsu hardware causes a kernel panic on removal..
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 ___ 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 : 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-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. ___ 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 : > 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..
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..
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:05 GMT+02:00 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 Hi, Certainly, here it is: http://ra.openbios.org/~idwer/freebsd/core.txt.9_fbsd_10-stable_rsu-panic-on-insertion 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..
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..
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? ___ 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/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..
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. > > --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..
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"
