Re: Patch to nm-modem-probe

[Dan Williams <dcbw redhat com>]

On Wed, 2009-07-29 at 14:11 +0100, Rick Jones wrote:
> --On Wednesday, July 29, 2009 11:57:39 +0300 ValmantasPalikša
> <walmis gmail com> wrote:
> 
> > Also if the buffer from ttyUSB1 is not flushed or read regularly the
> > device crashes. I'm guessing that the modem buffers data internally
> and
> > if that data is not read, the buffer overflows and the firmware
> crashes.
> > If +ZUSIMR UMs are disabled it will take longer to crash because it
> > still sends +ZPASR UMs which indicate network type.
> 
> That's both interesting and alarming! I've noticed that my modem will
> sometimes just shutdown and disconnect - as if unplugged - if left
> idle. It's usually after about 15 mins, and I was thinking that the
> device has perhaps got an idle timeout. But maybe it's the effect you
> describe.
> 
> I have some helper scripts I usually run while using the modem, one of
> which displays a slightly filtered output of the monitor port, so I
> guess this stops it crashing while connected.
> 
> How can we get NM to do that?
> 
> If NM could also keep the modem port flushed while disconnected this
> would help with another issue, which is that the device nearly always
> fails to connect first time. This is because when there are UMs
> waiting to be read, they block responses to valid AT commands. I.e.
> consider the initialisation sequence of:
>         send ATinitstring - read response 
> When there are buffered UMs, they come back in the response, but there
> is no response to the AT command itself. The sequence has to be:
>         read output until idle - send ATinitstring - read response
> 
> The ideal is for NM to just act as a null sink for the port until it
> is ready to start the conversation. Maybe this will be possible with
> 0.8 and ModemManager.

It would be possible with MM and 0.8.  Not so much with NM 0.7.  The
problem is that the AT port isn't opened until its needed with NM 0.7.
We don't necessarily want to start opening and reading all those ports,
because (a) that means we can auto-suspend the devices for power saving
reasons, (b) it's a pretty large behavior change for a "stable" series,
and (c) if you unplug the modem with kernel versions < 2.6.31 when NM
holds the port open, you might get kernel panics.

> Is this just another bizarre problem with ZTEs, or do UMs interfere
> with commands on other modems?

I think it's just ZTE being bizarre.

Dan