On Nov 30, 2006, at 12:07, Maciej W. Rozycki wrote:
On Mon, 23 Oct 2006, Maciej W. Rozycki wrote:
I'm not too enthusiastic about requiring the ethernet drivers to
call
phy_disconnect in a separate thread after "close" is called.
Assuming there's
not some sort of "squash work queue" functi
On Mon, 23 Oct 2006, Maciej W. Rozycki wrote:
> > I'm not too enthusiastic about requiring the ethernet drivers to call
> > phy_disconnect in a separate thread after "close" is called. Assuming
> > there's
> > not some sort of "squash work queue" function that can be invoked with
> > rtnl_lock h
On Fri, 20 Oct 2006, Andy Fleming wrote:
> I've been trying to figure out this problem since you posted this, and I'm not
> sure I understand it fully (And I apologize profusely for the horror that is
> the PHY interrupt handling code. I'd love to rewrite it if there's some
First of all I don't
On Fri, 20 Oct 2006 16:40:20 -0500
Andy Fleming <[EMAIL PROTECTED]> wrote:
> >The solution is to ignore phy_interrupt() calls if the reported
> > device
> >has already been halted and calling flush_scheduled_work() from
> >phy_stop_interrupts() (but guarded with current_is_keventd()
On Oct 3, 2006, at 10:18, Maciej W. Rozycki wrote:
Hello,
This patch fixes a couple of problems discovered with interrupt
handling
in the phylib core, namely:
1. The driver uses timer and workqueue calls, but does not include
nor .
Good catch.
2. The driver uses schedule_work()
On Mon, 16 Oct 2006, Andrew Morton wrote:
> Vaguely. Why doesn't it deadlock if !current_is_keventd()? I mean,
> whether or not the caller is keventd, the flush_scheduled_work() caller
> will still be dependent upon rtnl_lock() being acquirable.
This !current_is_keventd() condition is just wha
On Mon, 16 Oct 2006 15:50:55 +0100 (BST)
"Maciej W. Rozycki" <[EMAIL PROTECTED]> wrote:
> Andrew,
>
> > I don't get it. If some code does
> >
> > rtnl_lock();
> > flush_scheduled_work();
> >
> > and there's some work scheduled which does rtnl_lock() then it'll deadlock.
> >
> > But it
Andrew,
> I don't get it. If some code does
>
> rtnl_lock();
> flush_scheduled_work();
>
> and there's some work scheduled which does rtnl_lock() then it'll deadlock.
>
> But it'll deadlock whether or not the caller of flush_scheduled_work() is
> keventd.
>
> Calling flush_schedul
On Fri, 6 Oct 2006 12:26:22 +0100 (BST)
"Maciej W. Rozycki" <[EMAIL PROTECTED]> wrote:
> On Thu, 5 Oct 2006, Andrew Morton wrote:
>
> > > 2. The driver uses schedule_work() for handling interrupts, but does not
> > >make sure any pending work scheduled thus has been completed before
> > >
On Thu, 5 Oct 2006, Andrew Morton wrote:
> > 2. The driver uses schedule_work() for handling interrupts, but does not
> >make sure any pending work scheduled thus has been completed before
> >driver's structures get freed from memory. This is especially
> >important as interrupts m
On Tue, 3 Oct 2006 16:18:35 +0100 (BST)
"Maciej W. Rozycki" <[EMAIL PROTECTED]> wrote:
>
> 2. The driver uses schedule_work() for handling interrupts, but does not
>make sure any pending work scheduled thus has been completed before
>driver's structures get freed from memory. This is e
Hello,
This patch fixes a couple of problems discovered with interrupt handling
in the phylib core, namely:
1. The driver uses timer and workqueue calls, but does not include
nor .
2. The driver uses schedule_work() for handling interrupts, but does not
make sure any pending work sche
12 matches
Mail list logo
