Re: Very strange data loss with jsm driver

[lsorense@csclub.uwaterloo.ca (Lennart Sorensen)]

On Tue, Aug 02, 2011 at 11:49:27AM -0300, Breno Leitao wrote:
> On 08/02/2011 11:22 AM, Lennart Sorensen wrote:
> > On Tue, Aug 02, 2011 at 11:17:52AM -0300, Breno Leitao wrote:
> >> Well, I finally tested it over here, and what I found is:
> >>
> >> If the line has a \r among the first 16 bytes, then the information
> >> is TXed immediately. If there is no \r in the first 16 bytes, then the
> >> information seems to be buffered.
> >
> > Where in the driver is this happening?
> Well, I just found it doing some test cases.
> 
> Enabling the driver debug, I found that ->intr is not being called on
> the "incorrect" case.
> 
> This is the diff of the logs:
> 
>  jsm 0005:02:00.0: finish
>  jsm 0005:02:00.0: start
>  jsm 0005:02:00.0: finish
> -jsm 0005:02:00.0: drivers/tty/serial/jsm/jsm_neo.c:1131 uart_poll: 301
> -jsm 0005:02:00.0: drivers/tty/serial/jsm/jsm_neo.c:1161 port: 0 type: 3
> -jsm 0005:02:00.0: drivers/tty/serial/jsm/jsm_neo.c:750 isr: 2
> -jsm 0005:02:00.0: MOD_STAT: sending to parse_modem_sigs
> -jsm 0005:02:00.0: neo_parse_modem: port: 0 msignals: 0
> -jsm 0005:02:00.0: Port: 0 DTR: 0 RTS: 0 CTS: 0 DSR: 0 RI: 0 CD: 0
>  jsm 0005:02:00.0: start
>  jsm 0005:02:00.0: Close. HUPCL set, dropping DTR/RTS
>  jsm 0005:02:00.0: finish
> -jsm 0005:02:00.0: finish.
> 
> Anyway, I am still debugging it.
> 
> PS: I will look at the stats regression after I fix this one, ok ?

Sure.  I originally thought it might be related, but once I found 2.6.18
had the problem too, I no longer think so.

However having the statistics may very well be helpful while debuging,
at least I thought so.  being able to see how many characters the driver
thinks it has sent versus how many user space asked to send and how many
the receiver has seen might be handy.

-- 
Len Sorensen