linux-kernel - Re: Very strange data loss with jsm driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 2 Aug 2011 10:52:50 -0400
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	Breno Leitao <leitao@...ux.vnet.ibm.com>
Cc:	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Very strange data loss with jsm driver

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/