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