On Wed, Sep 17, 2014 at 02:13:03PM +0200, Frans Klaver wrote:
On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
On 09/16/2014 04:50 AM, Frans Klaver wrote:
On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
On 09/15/2014 11:39 AM, Peter Hurley wrote:
On
On 09/23/2014 04:24 AM, Frans Klaver wrote:
On Wed, Sep 17, 2014 at 02:13:03PM +0200, Frans Klaver wrote:
On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
On 09/16/2014 04:50 AM, Frans Klaver wrote:
On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
On 09/15/2014 11:39
On 23 September 2014 19:17:20 CEST, Peter Hurley pe...@hurleysoftware.com
wrote:
On 09/23/2014 04:24 AM, Frans Klaver wrote:
On Wed, Sep 17, 2014 at 02:13:03PM +0200, Frans Klaver wrote:
On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
On 09/16/2014 04:50 AM, Frans Klaver wrote:
* Frans Klaver franskla...@gmail.com [140923 11:12]:
On 23 September 2014 19:17:20 CEST, Peter Hurley pe...@hurleysoftware.com
wrote:
I would've thought the first 2 patches had already been picked up
because
they fix div-by-zero faults.
I've had no confirmation of that happening so far.
On Tue, Sep 23, 2014 at 8:38 PM, Tony Lindgren t...@atomide.com wrote:
* Frans Klaver franskla...@gmail.com [140923 11:12]:
On 23 September 2014 19:17:20 CEST, Peter Hurley pe...@hurleysoftware.com
wrote:
I would've thought the first 2 patches had already been picked up
because
they fix
On 09/16/2014 04:50 AM, Frans Klaver wrote:
On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
On 09/15/2014 11:39 AM, Peter Hurley wrote:
On 09/15/2014 10:00 AM, Frans Klaver wrote:
At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within
On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
On 09/16/2014 04:50 AM, Frans Klaver wrote:
On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
On 09/15/2014 11:39 AM, Peter Hurley wrote:
On 09/15/2014 10:00 AM, Frans Klaver wrote:
At 3.6Mbaud, with slightly over
On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
On 09/15/2014 11:39 AM, Peter Hurley wrote:
On 09/15/2014 10:00 AM, Frans Klaver wrote:
At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt
At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
this to about 170 overflows in 10 minutes.
In practice this therefore reduces the need for hardware flow control,
meaning the sending side
On 09/15/2014 10:00 AM, Frans Klaver wrote:
At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling
reduces
this to about 170 overflows in 10 minutes.
Why is the threadirqs kernel boot option not
On 09/15/2014 11:39 AM, Peter Hurley wrote:
On 09/15/2014 10:00 AM, Frans Klaver wrote:
At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling
reduces
this to about 170 overflows in 10 minutes.
Why
At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
this to about 170 overflows in 10 minutes.
In practice this therefore reduces the need for hardware flow control,
meaning the sending side
On Wed, Aug 20, 2014 at 11:06:05AM -0500, Felipe Balbi wrote:
On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
At 3.6Mbaud, with slightly over 2Mbit/s
Hi,
On Thu, Aug 21, 2014 at 11:41:17PM +0200, Frans Klaver wrote:
On Wed, Aug 20, 2014 at 11:06:05AM -0500, Felipe Balbi wrote:
On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
On Tue, Aug 19, 2014 at 02:14:47PM
On August 21, 2014 11:48:40 PM CEST, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Aug 21, 2014 at 11:41:17PM +0200, Frans Klaver wrote:
On Wed, Aug 20, 2014 at 11:06:05AM -0500, Felipe Balbi wrote:
On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
On Tue, Aug 19, 2014 at
On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling
reduces
this to
On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30
At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
this to about 170 overflows in 10 minutes.
In practice this therefore reduces the need for hardware flow control,
meaning the sending side
On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling
reduces
this to about 170 overflows in 10 minutes.
Can you try Sebastian Siewior's
19 matches
Mail list logo
