On Tuesday, July 16, 2002 1:10 AM, Song Bo Run [mailto:[EMAIL PROTECTED]] wrote: > Hello, Guy > > Here we are encountering almost exactly the same problem as you are, > except that we are using OpenBSD. We have ported Luigi's polling code > to OpenBSD 2.9 and are using fxp driver. Our testing attack is just ping > -f with 65500 bytes data. > > We notice that mclfree is bad when the system crashes. It seems that the > card write to a freed cluster, because the mclfree is always 0xa020xxxx > when crash. 0xa0 is exactly (FXP_RFA_STATUS_OK|FXP_RFA_STATUS_C). > > We can 100% crash the system if we boot the system while doing the > attack. > So we guess that under heavy system bus usage (we guess that during > system startup, VM system must be very busy faulting) the Intel NIC will > do something wrong. > > Has your problem solved under FreeBSD 4.6-Release? I just test 4.6, it > does not crash. Maybe the attack is not strong enough. I'll do more test > later.
Over the past few days I have been testing polling with fxp on FreeBSD 4.6-stable (as of a week ago) and it has not crashed at all under the various heavy loads under which 4.5 would crash. Before 4.6-RELEASE, Luigi mentioned to me in an email that he had received a patch from someone that fixed the problem and that he hoped to check it in before 4.6 was released. I didn't notice anything in the CVS logs but Luigi might have committed that fix. > Guy Helmer wrote: > > > > I am encountering a problem in the fxp driver that seems to be exposed by > > enabling polling under high packet load (~12000pps). I have been > > corresponding with Luigi regarding this problem but would like to see if > > anyone else might have any ideas that could help. > > > > I'm using FreeBSD 4.5-stable kernels on two completely different hardware > > platforms, a P-III 800 Intel ISP1100 and a homebrew Celeron with an Intel > > EtherExpress Pro-100B. Both machines panic with the same results. The > > machines panic with a kernel page fault, usually right after I enable > > polling but sometimes the machines will keep running until I do some other > > I/O-intensive tasks or run "top". > > > > There usually isn't an IP address on the fxp interface, but the interface is > > UP and listening to packets in promiscuous mode. I have verified that the > > crashes do occur when there is an IP address on the interface and when the > > interface is not in promiscuous mode. > > > > I noticed that after the kernel page fault trap occurs, fxp0 is sending the > > same bogus frame (containing junk) every millisecond or so. I don't > > understand why fxp0 is sending anything because the machine shouldn't be > > transmitting anything on that interface. I have the exact same code running > > on a system that has a SIS interface, and that system runs fine. > > > > The crash occurs in line 1847 of if_fxp.c: MCLGET(m, M_DONTWAIT) (in the > > expansion of MCLALLOC()). It looks like there is a bad index generated by > > mtocl(_mp) when "mclrefcnt[mtocl(_mp)]++;" is performed. mclfree is > > 0xc0306524 and mbutl is 0xc0306578 after the crash. I think there is some > > free mbuf list corruption triggered somewhere else in the driver, but I > > can't find anything in if_fxp.c that looks suspicious. > > > > Backtrace: > > fxp_add_rfabuf(c04e1400, c04e2900) at fxp_add_rfabuf+0x9f > > fxp_intr_body(c04e1400, e0, 3, 0, 5) at fxp_intr_body+0xd8 > > fxp_poll(c04e1400, 0, 5) at fxp_poll+0x9a > > netisr_poll(c026b4cf, bfbf002f, bfbf002f, bfbf002f) at netisr_poll+0x16b > > swi_net_next() at swi_net_next > > > > Registers: > > eax: 0x01bfb12 > > ecx: 0xa026b000 > > edx: 0xc04d7000 > > ebx: 0xc052ae00 > > esp: 0xc3cdbf1c > > ebp: 0xc3cdbf2c > > esi: 0x660c00 > > edi: 0xc052ae00 > > eip: 0xc0137d87 > > cs: 0x8 > > ds: 0xc0190010 > > es: 0xc3cd0010 > > fs: c04e0010 > > ss: 0x10 > > > > ... > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
