Date: Thu, 22 May 2014 20:34:58 +0200 From: Idwer Vollering <vidwer@gmail.com> To: Hans Petter Selasky <hps@selasky.org> Cc: freebsd-wireless@freebsd.org, freebsd-usb@freebsd.org Subject: Re: if_rsu hardware causes a kernel panic on removal.. Message-ID: <CAPp9OrkSHzwmMOhPXDo2Hab0_XgMpa1kQwMzOCimHMSzf8hbdw@mail.gmail.com> In-Reply-To: <537DE4DF.1060703@selasky.org> References: <CAPp9Or=6ryhXzLCE07xOKywwQLkJ7FQ-1w8ePru6p0Cfr0FcJQ@mail.gmail.com> <537AEC79.6080406@selasky.org> <CAPp9Ork4H=v%2BudbteJgjOCS9HeGUgMSCFdMOm84x8i0jr4%2BJ=w@mail.gmail.com> <537B497E.8070701@selasky.org> <CAPp9Or=yUXU2adQP5qppjwWJDJA3q-Ns%2BabRi=bRmwKtg9qaHw@mail.gmail.com> <537B6F44.6070905@selasky.org> <CAPp9Or=xuKzsa3zydfvfbjNxJh0m48q9RnHdg2YEnXAExQUhTQ@mail.gmail.com> <537B9D78.3030103@selasky.org> <CAPp9Ork1NUxMwZJyPGsN__X9p%2BMiwM4qxB7YMAZK1WzrTqJ07w@mail.gmail.com> <537C4712.908@selasky.org> <CAPp9Orks1MCdDW2J%2B5CWe6GX9qBujvEFzazffstmHZtO9_FA0g@mail.gmail.com> <537CC4CF.9030509@selasky.org> <537CE3C9.7090807@selasky.org> <CAPp9OrnAUU%2Bnm0e_0Uq9V=mPiC8y8zavQCCFsA5AYRCcEed%2BbA@mail.gmail.com> <537D9955.3070001@selasky.org> <CAPp9Orn4AttGuR93V8h-ErWALHpbGN0JzshK24mKYtUdYgYevw@mail.gmail.com> <537DE4DF.1060703@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2014-05-22 13:51 GMT+02:00 Hans Petter Selasky <hps@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPp9OrkSHzwmMOhPXDo2Hab0_XgMpa1kQwMzOCimHMSzf8hbdw>