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] [thread-next>] [day] [month] [year] [list]
Message-ID: <504D922C.1030407@c-s.fr>
Date:	Mon, 10 Sep 2012 09:09:32 +0200
From:	leroy christophe <christophe.leroy@....fr>
To:	Alan Cox <alan@...ux.intel.com>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Vitaly Bordug <vitb@...nel.crashing.org>,
	Marcelo Tosatti <marcelo@...ck.org>,
	linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH] Powerpc 8xx CPM_UART delay in receive

Le 16/08/2012 17:21, Alan Cox a écrit :
>> MAX_IDL: Maximum idle characters. When a character is received, the
>> receiver begins counting idle characters. If MAX_IDL idle characters
>> are received before the next data character, an idle timeout occurs
>> and the buffer is closed,
>> generating a maskable interrupt request to the core to receive the
>> data from the buffer. Thus, MAX_IDL offers a way to demarcate frames.
>> To disable the feature, clear MAX_IDL. The bit length of an idle
>> character is calculated as follows: 1 + data length (5–9) + 1 (if
>> parity is used)
>> + number of stop bits (1–2). For 8 data bits, no parity, and 1 stop
>> bit, the character length is 10 bits
>
> So if you have slightly bursty high speed data as its quite typical
> before your change you would get one interrupt per buffer of 32 bytes,
> with it you'll get a lot more interrupts.
>
> You have two available hints about the way to set this - one of them is
> the baud rate (low baud rates mean the fifo isn't a big win and the
> latency is high), the other is the low_latency flag if the driver
> supports the low latency feature (and arguably you can still use a
> request for it as a hint even if you refuse the actual feature).
>
> So I think a reasonable approach would be set the idle timeout down for
> low baud rates or if low_latency is requested.
>
>> generated if there is at least one word in the FIFO and for a time
>> equivalent to the transmission of four characters
> Which is a bit more reasonable than one, although problematic at low
> speed (hence the fifo on/off).
>
What would then thing about:
* a value of 1 for all rates below 2400 (On 8250, fifo is set to 1 for 
such rates)
* a value of 2 for 2400 and 4800
* a value of 4 for 9600 (which is the default on the 8250 for all rates 
above 2400)
* a value of 8 for 19200
* a value of 16 for 38400 and above (on UCC_UART, maxidl is set to 16, 
never 32)

Christophe
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ