On Tue, 1 May 2007, Samuel Ortiz wrote:
But I will definitely spend some time this week running my IrDA stack
with this patch applied. I didn't bother to do that earlier as you first
reported some oops with this patch applied.
I think, what I reported was not an Oops, but the race that we're
On Tue, 10 Apr 2007, Samuel Ortiz wrote:
Hi Guennadi,
The patch below schedules irnet_flow_indication() asynchronously. Could
you please give it a try (it builds, but I couldn't test it...) ? :
Ok, your patch (still below) works too (now that I fixed that state
machine race, btw, we still
On Mon, Apr 30, 2007 at 03:24:05PM +0200, Guennadi Liakhovetski wrote:
On Tue, 10 Apr 2007, Samuel Ortiz wrote:
Hi Guennadi,
The patch below schedules irnet_flow_indication() asynchronously. Could
you please give it a try (it builds, but I couldn't test it...) ? :
Ok, your patch
On Tue, 10 Apr 2007, Samuel Ortiz wrote:
The patch below schedules irnet_flow_indication() asynchronously. Could
you please give it a try (it builds, but I couldn't test it...) ? :
I'm afraid, your patch makes it worse - with my patch to ppp_generic it
worked 5 hours before Ir stopped,
Hi Guennadi,
On Sat, Apr 07, 2007 at 03:59:26AM +0300, Samuel Ortiz wrote:
IMHO, irnet_flow_indication() should be called asynchronously by
irttp_run_tx_queue(), through some bottom-half mechanism. That would fix your
locking issues, and that would reduce the time we spend in the IrDA code
Hi Guennadi,
On Thu, Apr 05, 2007 at 12:59:40PM +0200, Guennadi Liakhovetski wrote:
Ok, a simple analysis reveals the recursive spinlock:
On Thu, 5 Apr 2007, Guennadi Liakhovetski wrote:
[bf12b220] (ppp_channel_push+0x0/0xc8 [ppp_generic]) from [bf12bf98]
(ppp_output_wakeup+0x18/0x1c
