Re: Patch to nm-modem-probe

[Valmantas Palikša <walmis gmail com>]

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.

On Sat, 2009-07-25 at 22:33 +0100, Rick Jones wrote:
> Dan
> 
> Thanks for the feedback - see below ...
> 
> --On Thursday, July 23, 2009 15:02:56 -0400 Dan Williams
> <dcbw redhat com> wrote:
> ¦ --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.
> 
> I take the point on built-in modems, but given all the other delays
> and waits involved in opening a connection, is 2 or 3 seconds actually
> significant? If this is happening at boot-up, surely it will all be
> finished by the time the user logs in, even with a few extra seconds.
> 
> ¦ 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.
> 
> One problem here is that if you start sending an init string to the
> ZTE sooner than about 3 secs, it seems to do some strange things. I
> can't remember exactly what was going on, but that was one reason I
> wanted to be able to have a longer initial delay. I can get some log
> output from nm-modem-probe next week if you'd like - I don't have the
> time right now, sorry.
> 
> ¦ 2) get rid of --nocpms.  Lets use the --vid option to special-case
> ZTE
> ¦ and automatically determine what init string to send.
> 
> Are you suggesting hard-coding recognition of the ZTE vid into
> nm-modem-probe? My preference would be to put that kind of thing into
> the .rules file if necessary, and keep compiled code more generic. If
> it turns out that some other device can benefit from the CPMS tweak,
> or there are versions of the ZTE that object to it, it's much easer to
> fix a .rules file, especially by a user as a "get out of trouble" fix.
> That's why I made it a command line option (it could easily of course
> be --cpms so the default is not to send it).
> 
> It would mean updating the .rules file to have two branches, one for
> ZTE and one not (assuming you prefer to send +CPMS only to ZTE
> devices), but two branches might be necessary anyway if ZTEs need a
> longer timeout.
> 
> ¦ "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.
> 
> I've had to infer quite a few things here, but I'm pretty sure of what
> is happening.
> 
> When I was first trying to use the device I would quite often get
> complete system hangs, requiring hard re-boot. When this happened it
> was usually immediately on clicking in the applet menu to make a
> connection (and other users have reported this too). I then started
> looking at the ttyUSB port modes using stty, and they seemed to be
> pretty random. In particular, crashes could be linked with echo mode
> being enabled. If I ran "stty raw -F /dev/ttyUSB2" after the modem was
> plugged in but before connecting, I never got any crashes. By running
> "stty echo ..." I could almost guarantee to crash. My first thought
> was that NM wasn't initialising the port properly, but looking at the
> code it clearly does.
> 
> IIRC, a port doesn't echo its input unless it is open, so prior to a
> connection being made, nothing bad is happening. But the moment it is
> open it will echo, and if there is buffered input to the port then
> this will immediately echo back out. I believe this will happen in the
> window between NM opening the port and setting the termio modes. So
> the combination of a stack of UMs (which the ZTE by default spits out)
> queued up in a USB buffer somewhere, the ttyUSB port suddenly echoing
> them all back, and the modem echoing them back again, etc.... creates
> a snarl up enough to hang the machine. I don't know if it's actually a
> crash/panic, or it simply does something like eat all the interrupts.
> 
> But the fact is that making sure the port is set to raw mode, and left
> that way, totally stops the problem. So the best thing is simply for
> nm-modem-probe not to reset the port after using it!
> 
> It doesn't serve any purpose anyway, because nothing is going to use
> the port in its original mode. I guess those kernel fixes might affect
> it, as it's clearly pretty marginal, as will turning of modem echo in
> nm-modem-probe, and stopping UMs. But I still think the port should be
> left in raw mode after nm-modem-probe has finished - belt & braces.
> 
> ¦ 
> ¦ Thanks for your work on ZTE devices!
> 
> No probs, I just want something that works. I'd probably have saved
> myself a lot of trouble if I'd gone with a carrier who supplies
> Icon :)
> 
> Cheers, Rick 
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list