Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Dec 2005 16:41:21 -0700
From:      Scott Long <scottl@samsco.org>
To:        Nate Lawson <nate@root.org>
Cc:        cvs-src@FreeBSD.org, Gleb Smirnoff <glebius@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org
Subject:   Re: cvs commit: src/sys/dev/em if_em.c
Message-ID:  <43B1D121.1080309@samsco.org>
In-Reply-To: <43B1CE9E.1060602@root.org>
References:  <20051222090955.E621416A4D5@hub.freebsd.org> <43B1CE9E.1060602@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Nate Lawson wrote:

> 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.
> 

I can believe your first statement, but not your second.  Hanging the
system on an aborted memory read cycle (as opposed to just throwing a
#SERR) would indicate a highly highly broken chipset.  In any case, if
we ever implement PCI hotplug then we'll have to deal with the effects
of aborted PCI transfers anyways.

Scott




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43B1D121.1080309>