[Top] [All Lists]

Re: [PATCH] [RFT] 2.6.4 - epic100 napi

To: Francois Romieu <romieu@xxxxxxxxxxxxx>
Subject: Re: [PATCH] [RFT] 2.6.4 - epic100 napi
From: OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>
Date: Wed, 24 Mar 2004 11:52:09 +0900
Cc: Jeff Garzik <jgarzik@xxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <20040324014140.A16202@xxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <20040320152109.A31118@xxxxxxxxxxxxxxxxxxxxxxxxxx> <405DDDC6.7030007@xxxxxxxxx> <8765cvmyaq.fsf@xxxxxxxxxxxxxxxxxxx> <20040323195119.A14062@xxxxxxxxxxxxxxxxxxxxxxxxxx> <871xnjgwrs.fsf@xxxxxxxxxxxxxxxxxxx> <20040324014140.A16202@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Francois Romieu <romieu@xxxxxxxxxxxxx> writes:

> > Yes, maybe. But, if after spin_lock, it loop may call the twice
> > __netif_rx_schedule(). And netif_rx_complete() doesn't call dev_put().
> > It will leaks the dev->refcnt, I think.
> @$*#!zW
> The following patch should avoid the leak as well as the packet rot
> (untested, 1:33 AM, apply on top of previous serie).
> Multiple invocation of __netif_rx_schedule() in epic_interrupt() while
> epic_poll loops over __netif_rx_complete() leads to serious device
> refcount leak.

Do you care the lost interrupt? If so, I was miss reading it.

IIRC, PCI spec requires the level-trigger. So devices asserts IRQ
signal until the driver clears the pending interrupt. No?
OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>

<Prev in Thread] Current Thread [Next in Thread>