On Wed, Apr 04, 2007 at 10:10:07PM +, Stephen Hemminger wrote:
>
> > > Yes, you're right. Perhaps we should get the rtnl first before
> > > tg3_full_lock(), or turn irq_sync into an atomic counter that allows
> > > nesting.
>
> When you start reinventing windows locks or the BKL, you know
> y
On Wed, 04 Apr 2007 13:53:47 -0700
Gagan Arneja <[EMAIL PROTECTED]> wrote:
> I like the counting semaphore idea.
>
> --
> Gagan
>
> Michael Chan wrote:
> > On Wed, 2007-04-04 at 13:34 -0700, Gagan Arneja wrote:
> >> Can't this BUG_ON be hit very easily:
> >>
> >> static void tg3_irq_quiesce(stru
I like the counting semaphore idea.
--
Gagan
Michael Chan wrote:
On Wed, 2007-04-04 at 13:34 -0700, Gagan Arneja wrote:
Can't this BUG_ON be hit very easily:
static void tg3_irq_quiesce(struct tg3 *tp)
{
BUG_ON(tp->irq_sync);
...
}
tg3_reset_task could easily be racing with another t
On Wed, 2007-04-04 at 13:34 -0700, Gagan Arneja wrote:
> Can't this BUG_ON be hit very easily:
>
> static void tg3_irq_quiesce(struct tg3 *tp)
> {
> BUG_ON(tp->irq_sync);
> ...
> }
>
> tg3_reset_task could easily be racing with another thread, that calls
> tg3_full_lock(tp, 1); e.g tg3_ch
Can't this BUG_ON be hit very easily:
static void tg3_irq_quiesce(struct tg3 *tp)
{
BUG_ON(tp->irq_sync);
...
}
tg3_reset_task could easily be racing with another thread, that calls
tg3_full_lock(tp, 1); e.g tg3_change_mtu. Maybe I'm missing something
obvious.
--
Gagan
-
To unsubscribe f
