[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130522151146.3d2595be@stein>
Date: Wed, 22 May 2013 15:11:46 +0200
From: Stefan Richter <stefanr@...6.in-berlin.de>
To: stephan.gatzka@...il.com
Cc: linux1394-devel@...ts.sourceforge.net, peter@...leysoftware.com,
linux-kernel@...r.kernel.org, Tejun Heo <tj@...nel.org>
Subject: Re: function call fw_iso_resource_mange(..) (core-iso.c) does not
return
On May 22 Stephan Gatzka wrote:
[I wrote:]
> > Wait a minute --- I seem to be reading of Xenomai RT extensions for the
> > first time in this thread. Has the problem been reproduced on a mainline
> > kernel too? (Mainline plus Ralf's firewire upper layer driver maybe, but
> > without any other 3rd party stuff please. Actually the issue should be
> > reproducible even without an upper layer driver performing
> > fw_iso_resource_manage in fw_workqueue context, shouldn't it?)
>
> Unfortunately it's not that easy. While I agree that it should be
> reproducible just with mainline stuff, we have to force our system into
> the situation that it "thinks" it's under memory pressure to hand over
> the work to the rescuer thread. It looks that a simple printk from a
> different driver might lead to that situation on our system.
[...]
I retract my request to get it retested with mainline since a) the
analysis has clearly shown that a mainline bug is at the root of the
problem, and b) Ralf confirmed now that one of the possible fixes (using
two queues) does in fact work for him like the theory says how it should
work for mainline.
--
Stefan Richter
-=====-===-= -=-= =-==-
http://arcgraph.de/sr/
--
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