On 8/27/05, Eric Lemoine <[EMAIL PROTECTED]> wrote: > On 8/27/05, Eric Lemoine <[EMAIL PROTECTED]> wrote: > > On 8/26/05, Geoff Levand <[EMAIL PROTECTED]> wrote: > > > This fixes a major bug in the Sun GEM Ether > > > driver's netpoll implementation. When both polled > > > and interrupt driven i/o are used simultaneously, > > > for example when using kgdb over Ether with active > > > NFS mounts, a condition easily arises where the bug > > > is hit. > > > > > > The problem is that gem_poll() expects an rx softnet_data > > > structure to have been allocated (via __netif_rx_schedule()) > > > prior to its being called. The existing gem driver code > > > uses gem_interrupt() to set things up for gem_poll(), > > > but unfortunately, gem_interrupt() doesn't know about > > > this, and so doesn't allocate the required structure > > > when it finds no bits set in the interrupt status > > > register. gem_poll() then move on its way and tries to > > > delete the non-existent softnet_data structure. > > > > I may be missing something here but I don't see how gem_poll() can > > move on its way if __netif_rx_schedule() hasen't been called. Wait... > > in netpoll.c:poll_napi() because bit __LINK_STATE_RX_SCHED is set, > > correct? > > > > To me the bug is that __LINK_STATE_RX_SCHED can be set while > > __netif_rx_schedule() hasen't be called. Why don't fix it in the > > simplest way ? See attached patch (absolutely untested). > > It doesn't even compile :-) > > [new patch attached]
I just realized that my previous patch isn't correct: gem_interrupt() cannot read from GREG_STAT without making sure gem_poll() isn't currently running - gem_poll() must have exclusive access to GREG_STAT. One solution would be to clear __LINK_STATE_RX_SCHED (i.e. reenable polling) before returning IRQ_NONE. See attached patch. -- Eric
sungem-netpoll-patch
Description: Binary data
