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
