Re: Patch to nm-modem-probe

[Dan Williams <dcbw redhat com>]

On Thu, 2009-07-23 at 18:06 +0100, Rick Jones wrote:
> Dan
> 
> As a result of keeping trying to get these darned ZTE devices to work
> reliably, I've come up with some tweaks to nm-modem-probe. Patch file
> is attached, plus text explaining the reasons for the changes.

Makes a bit hard to respond inline, but...

--delay was originally meant to be an overall timeout, but I optimized
that later on to fast-path modems that responded to something before
that 5 seconds was up.  Many modems (especially built-in devices that
boot long before udev starts up) will respond immediately and the hard 3
second timeout was really unecessary.  Other modems do require that
timeout.

Your patch will actually make all modems wait timeout_ms before being
probed, so it does increase the probe latency quite a bit.  Additional
to that, it adds a 1s latency right before sending the init command.

What I'd recommend is the following:

1) get rid of --initwait, and just use --delay.  After the initial 500ms
wait that the original code had, send the init string every second until
you get some response, or until the timeout expires.  That preserves the
fastpath that built-in modems can take to get recognized much more
quickly, but rightfully penalizes the ZTE device for being, well, dumb.

2) get rid of --nocpms.  Lets use the --vid option to special-case ZTE
and automatically determine what init string to send.

"there is a short window where the buffered data can be echoed back to
the modem before this happens."

Could you describe that issue in a bit more detail?  I don't quite
understand what's going on there.

WRT to the kernel issues, they are kernel issues and need to get fixed.
Some of the issues were caused by NM incorrectly setting up the serial
port (793cc30b5d20d728719c568f5bfac98f3bca3dca) or double-opening it
when a PIN was used (a918ae6e9f881fdbb8d92ed12bfbc70716bd099e and
364ab2f86d6ebdf9552b7cc6b197b2c76ea3b8aa).  Plus, the low_latency
patches to usb-serial should be applied to the kernel, this was causing
a lot of issues with 2.6.29 and the low_latency scrubbing patches fix
that.  There's a limited amount of kernel work-arounds that I'd be
willing to do in NM, but when there's a clear fix available, I tend to
leave that kernel patching up to distributors to push in their updates
and keep the upstream NM clean of hacks for fixable kernel bugs.   (same
reason I don't hack around binary wifi drivers like wl.o...)

I'd be curious to see if those patches help the "echo loop" problem.

Thanks for your work on ZTE devices!

Dan


> This makes a big difference between the ZTE being still flaky and
> solidly reliable. I don't think these changes should have a negative
> impact on other modems, but there are new command options to switch
> the behaviour where it might be modem-specific.
> 
> I hope this is useful.
> 
> -- 
> Cheers
> Rick