Re: no 3g wan after hibernate
- From: Dan Williams <dcbw redhat com>
- To: Aleksander Morgado <aleksander lanedo com>
- Cc: networkmanager-list gnome org
- Subject: Re: no 3g wan after hibernate
- Date: Thu, 21 Jul 2011 00:17:04 -0500
On Wed, 2011-07-06 at 09:26 +0200, Aleksander Morgado wrote:
> >
> > after hibernation the system asks for the sim pin, which is accepted, but still is unable to connect, see the attached log. I deactivate 3g broadband, then reactivate. After giving it some time, i have it connect to my provider. It then recognizes that it has no SIM PIN available, which is dutifully asked for. After providing, it uses the pin, but obviously to no avail. It asks again. In this log, I aborted it, but I tried before, with every so often specifying the pin, to no avail...
> >
>
> This could probably be fixed if we include pin check process during the
> modem enabling (after power-up for example), instead of just after the
> modem has been detected. In this case modem was detected before the
> hibernation, and after restoring from hibernation the SIM needs the pin
> again.
Part of the problem here is that MM doesn't really handle suspend/resume
here. Most devices actually *go away* when you suspend/resume because
the USB controller is powered down, and that means the serial TTY goes
away, and that makes MM dispose the device and re-init. That's both
good (makes sure state is consistent) and bad (takes longer after resume
to get back online). The only other driver I can think of that does
this is the old 'nozomi' driver for early Option parts.
In this case, the modem has actually reset it's state, presumably
because it's been powered down by the kernel, but the serial TTY has not
disappeared, presumably because the USB controller was only put to sleep
and kept the connection to the device. So MM thinks the device is still
powered up and initialized, while it clearly is not. There's nothing
that has told MM that the device lost initialization state.
MM could listen for suspend/resume events (via udev?) and then assume
that any device still around after wakeup needed reinitialization. Or
we could just throw away every device MM knows about when suspending and
re-initialize the world on resume.
In any case, something does need to be done here.
Dan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]