Subject: Re: kern/29903 (register data)
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Steve Woodford <scw@netbsd.org>
List: netbsd-bugs
Date: 04/22/2005 20:45:01
The following reply was made to PR kern/29903; it has been noted by GNATS.
From: Steve Woodford <scw@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/29903 (register data)
Date: Fri, 22 Apr 2005 21:43:52 +0100
On Thursday 21 April 2005 13:42, Martin Husemann wrote:
> On Thu, Apr 21, 2005 at 07:52:13AM -0400, Christos Zoulas wrote:
> > Is there any reason not to apply the supplied patch that makes the
> > system stable?
>
> No, but better completely understand what happens before doing so.
>
> As wm_stop already tries to disable the receiver completely by doing
> CSR_WRITE(sc, WMREG_RCTL, 0); - the question remains, why do the
> interrupts happen.
My guess is the WMREG_ICR register contains a stale interrupt status for
whatever reason, even after wm_stop() has been called, and this was the
motivation behind my patch.
Two possible routes into wm_intr() spring to mind:
1) wm_stop() is always called at splnet(). If the card interrupts before
wm_stop() completes its task, there's a fair chance wm_intr() will be
called anyway when spl drops below IPL_NET, *even if* the card is no
longer asserting its interrupt pin by that time (the interrupt will have
already been recorded by the low-level dispatch code).
2) If the wm(4) card is sharing a PCI interrupt line with some other
device then wm_intr() will be called regardless.
Cheers, Steve