Deal with 'NotOpened' errors?

[Dan Williams]

On Mon, 2014-02-24 at 14:47 +0100, Bjørn Mork wrote:
> Aleksander Morgado <aleksander at aleksander.es> writes:
> 
> > On Mon, Feb 24, 2014 at 9:39 AM, Bjørn Mork <bjorn at mork.no> wrote:
> >>
> >>
> >> I triggered this by *hibernating* the laptop with MM managing the MC7710
> >> inside.  I have no clue how this actually works, but it seems that the
> >> USB core then restores the USB device to the exact same state on resume
> >> - as seen from the OS.  The only problem is of course that power to the
> >> module was cut, so all internal state in the modem is lost.
> >>
> >> I don't blame MM for not catching that the modem was powered off behind
> >> the curtain.  It seems the kernel hides this fact completely for
> >> userspace, which maybe is something we should fix as well?  But I still
> >> think that MM could handle the 'NotOpened' error better....
> >>
> >> There doesn't seem to be any other way out of this than restarting MM to
> >> have the modem rediscovered and reinitialized.
> >
> >
> > Oh, that's pretty unfortunate indeed. Aren't we supposed to get udev
> > events for this case?
> 
> No, I don't think so.  The idea is that we skip unplug/replug completely
> if the device doesn't change during suspend.  This is all described in 
> Documentation/usb/persist.txt and I should have known...
> 
> I'm not sure how to handle this though.  It's designed primarily for
> disks, where all device internal state is preserved over a power loss,
> but where an OS hotplug event will be catastrophic to any mounted file
> system.
> 
> As you probably understand from the confused description above, all this
> suspend/resume stuff is black magic to me...  I'll try to do a bit of
> driver debugging to see if we can work around the issue in the drivers,
> without messing up composite devices with both a modem and a SD card
> slot. 
> 
> > Just re-opening the MBIM port is not enough very
> > likely as we would need to re-send PIN at least... If we detect this,
> > we should likely mark the modem as invalid and re-start probing from
> > scratch, so that we keep a sane state within MM.
> 
> Yes.  This seems pretty straight forward for MBIM modems, where
> NotOpened will mean that everything must be reinitialized.
> 
> But I guess similar issues will affect all types of USB attached modems.
> So MM should really handle "modem amnesia" regardless of modem driver.
> If USB power is removed and the USB core decides to apply the "persist
> feature", then you will see this as a modem forgetting every volatile
> configuration command you have sent it.

Perhaps the kernel provides some kind of "we're suspending now" signal
that MM can use to selectively invalidate modems.  But I'm not sure it
does, as all that appears to currently be handled in userspace with
stuff like pm-utils, upower, or systemd.  We could track the monotonic
timer by setting up a 2 or 3 second poll and see if it changes *more*
than 2 or 3 seconds, but that's a hack.

Dan