cvs commit: src/sys/dev/em if_em.c

[M. Warner Losh]

In message: <43B1CE9E.1060602 at root.org>
            Nate Lawson <nate at root.org> writes:
: Gleb Smirnoff wrote:
: > glebius     2005-12-22 09:09:39 UTC
: > 
: >   FreeBSD src repository
: > 
: >   Modified files:
: >     sys/dev/em           if_em.c 
: >   Log:
: >   Add a quirk to fix resume on some laptops.
: >   
: >   Reported by:    joe
: >   Reported by:    Huang wen hui <huang gddsn.org.cn>
: >   Reported by:    Jacques Garrigue <garrigue math.nagoya-u.ac.jp>
: >   PR:             kern/89825
: >   
: >   Revision  Changes    Path
: >   1.94      +9 -0      src/sys/dev/em/if_em.c
: > 
: > 
: > Index: src/sys/dev/em/if_em.c
: > diff -u src/sys/dev/em/if_em.c:1.93 src/sys/dev/em/if_em.c:1.94
: > --- src/sys/dev/em/if_em.c:1.93	Sun Dec 18 18:24:26 2005
: > +++ src/sys/dev/em/if_em.c	Thu Dec 22 09:09:39 2005
: > @@ -1048,6 +1048,15 @@
: >  		else if (reg_icr == 0)
: >  			break;
: >  
: > +		/*
: > +		 * XXX: some laptops trigger several spurious interrupts
: > +		 * on em(4) when in the resume cycle. The ICR register
: > +		 * reports all-ones value in this case. Processing such
: > +		 * interrupts would lead to a freeze. I don't know why.
: > +		 */
: > +		if (reg_icr == 0xffffffff)
: > +			break;
: > +
: >  		if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
: >  			em_process_receive_interrupts(adapter, -1);
: >  			em_clean_transmit_interrupts(adapter);
: 
: This probably means that the PCI memory space isn't fully initialized 
: but an interrupt has been triggered.  If you then go and try to poke the 
: hardware, then you can hang the system.

Most of the other drivers explicitly turn off their interrupt handler
or mark their softc as 'suspended' until the resume code gets to run.
Those that mark the softc as suspended exit the ISR immediately w/o
touching the hardware.  The em driver doesn't seem to do either of
these things.

Warner