Search Linux Wireless

Re: [PATCH] rtl8xxxu: increase polling timeout for firmware startup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Daniel Lenski <dlenski@xxxxxxxxx> writes:
> I tried various versions of running rtl8xxxu_init_device in a loop, with
> delays in between retries, and did not have any success.
>
> If the device doesn't want to start on the first load after boot, running
> various parts of init over and over just doesn't fix it. But unloading the
> driver and reloading does seem to fix it.
>
> So then I wondered...
>
> - Why does the firmware always (?) start on the *second try* of
>   loading rtl8xxxu, even if it failed to load after thousands of loops on
>   the first load attempt.
> - What would be the difference between the two cases?
> - As far as I understand it, the main effect on the hardware of unloading
>   the driver and then reloading it is that the device is power-cycled
>   (rtl8xxxu_power_off in rtl8xxxu_disable_device).
> - Is it possible that the device sometimes starts up in an unknown state
>   after a cold boot?
> - Hypothesis: since the rtl8xxxu driver does not explicitly power off the
>   device before attempting to power it on, if it boots up in an unknown
>   state, it will remain in this state until explicitly power-cycled.
>
> So then I tried powering off the device for 500ms after a failure in
> rtl8xxxu_init_device, before a retry:
>
>        for (retry=5; retry>=0; retry--) {
>                ret = rtl8xxxu_init_device(hw);
>                if (ret==0) {
>                        break;
>                } else {
>                        dev_err(&udev->dev, "Failed to init device,
> will retry %d more times.\n", retry);
>                        if (retry==0)
>                                goto exit;
>                        else {
>                                /* power off for 500 ms before retry */
>                                rtl8xxxu_power_off(priv);
>                                msleep(500);
>                        }
>                }
>        }
>
> So far, this always seems to work on the second try, even with a very
> short firmware_poll_max (50).
>
> I even tried forcing 50 power-cycles and inits in a row, and the firmware
> still starts up on the 51st cycle, and everything works fine.
>
> I don't understand *why* this works, but it seems like it might be a
> more reliable solution, since it addresses the experience common to
> the multiple bug reports, wherein the failure is only on the first attempt
> after cold boot.

Interesting, so if I understand you correctly, if you run
rtl8xxxu_power_off() once, the driver comes up correctly?

It is possible that rtl8xxxu_power_off() resets something that isn't being
initialized normally in the init sequence. It would be interesting to
try to break it down to find out which piece of the _power_off() code
we're missing.

Nice work!

Cheers,
Jes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux