Hi, It seems that fxp(4) has a long standing races between controller and driver. The exotic RFD handling of controller is race prone as we had seen old ethernet controllers. I could easily reproduce this by rebooting system while netperf 64bytes UDP test is in progress. If heavy RX frames hit the controller while interface UP is in progress, controller started DMAing to freed mbufs such that "Memory modified after free" message showed up. Based on OpenBSD's patch I made a patch which seems to fix the issue. If you saw this type of issue please give it try and let me how it goes on your box. The patch has effect only on interrupt mode so if you're using polling(4) you would have no effects. You can get download the patch at the following URL. http://people.freebsd.org/~yongari/fxp/fxp.rx.race.patch After applying the patch you may see somewhat increased RNR counter value from sysctl node(dev.fxp.0.rnr). Previously fxp(4) might have lower RNR counter value but that fake value came from DMAing to freed mbufs which was completely wrong. Thanks.Received on Sun Apr 04 2010 - 23:01:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:02 UTC