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 _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
