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

[Scott Long]

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