Kernel panic at m_copym/m_copydata
Hi I am using mpd5.5 with FreeBSD from 7.2-STABLE ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201001/FreeBSD-7.2-STABLE-201001-i386-disc1.iso to 7.3-RELEASE and 7.3-STABLE, 8.0-STABLE and every 1-2 day server kernel panic with kernel trap 12 Few people have the same error. This error in the code was entered presumably in early January 2010. In 7.2-RELEASE so no this problem. (kgdb) bt #0 doadump () at pcpu.h:196 #1 0x807f9c67 in boot (howto=260) at /usr/src/sys/kern/kern_ shutdown.c:418 #2 0x807f9f39 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0x80b156ec in trap_fatal (frame=0x8e6b0438, eva=12) at /usr/src/sys/i386/i386/trap.c:950 #4 0x80b15970 in trap_pfault (frame=0x8e6b0438, usermode=0, eva=12) at /usr/src/sys/i386/i386/trap.c:863 #5 0x80b16365 in trap (frame=0x8e6b0438) at /usr/src/sys/i386/i386/trap.c:541 #6 0x80af964b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0x8084cdf8 in m_copydata (m=0x0, off=0, len=164, cp=0x8f67095c "ЪЗЪёsЖoїEй╒nв\233tр\206XьAYci\006\031г\aИw╡э<,\236К\0041l\204\207\0028pX~\nбЮ4ПdрL\032Iц\2178>\201\004: \021\001а\036\2155\237╡NД!╧\022\006ЮґЇШ\1775©АШвЧ\21 6іВ") at /usr/src/sys/kern/uipc_mbuf.c:815 #8 0x808ef068 in ip_forward (m=0x8f37bb00, srcrt=0) at /usr/src/sys/netinet/ip_input.c:1307 #9 0x808f0813 in ip_input (m=0x8f37bb00) at /usr/src/sys/netinet/ip_input.c:609 #10 0x808a88b5 in netisr_dispatch (num=2, m=0x8f37bb00) at /usr/src/sys/net/netisr.c:185 #11 0x8f50cdc5 in ng_iface_rcvdata (hook=0x8fdbf300, item=0x8f411030) at /usr/src/sys/modules/netgraph/iface/../../../netgraph/ng_iface.c:777 #12 0x8f2ea7e4 in ng_apply_item (node=0x8f83cb00, item=0x8f411030, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #13 0x8f2e97ec in ng_snd_item (item=0x8f411030, flags=Variable "flags" is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #14 0x8f2ea7e4 in ng_apply_item (node=0x8fc8b580, item=0x8f411030, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #15 0x8f2e97ec in ng_snd_item (item=0x8f411030, flags=Variable "flags" is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #16 0x8f55a266 in ng_car_rcvdata (hook=0x8fca7180, item=0x8f411030) at /usr/src/sys/modules/netgraph/car/../../../netgraph/ng_car.c:367 #17 0x8f2ea7e4 in ng_apply_item (node=0x8f891e00, item=0x8f411030, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #18 0x8f2e97ec in ng_snd_item (item=0x8f411030, flags=Variable "flags" is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #19 0x8f2ea7e4 in ng_apply_item (node=0x8fc8b580, item=0x8f411030, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #20 0x8f2e97ec in ng_snd_item (item=0x8f411030, flags=Variable "flags" is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #21 0x8f2ea7e4 in ng_apply_item (node=0x8fcde100, item=0x8f411030, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #22 0x8f2e97ec in ng_snd_item (item=0x8f411030, flags=Variable "flags" is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 ---Type to continue, or q to quit--- #23 0x8f516ca0 in ng_ppp_proto_recv (node=0x8faba400, item=0x8f411030, proto=Variable "proto" is not available. ) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:934 #24 0x8f517995 in ng_ppp_rcvdata (hook=0x8f8fd880, item=0x8f411030) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:1509 #25 0x8f2ea7e4 in ng_apply_item (node=0x8faba400, item=0x8f411030, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #26 0x8f2e97ec in ng_snd_item (item=0x8f411030, flags=Variable "flags" is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #27 0x8f2ea7e4 in ng_apply_item (node=0x8f7c7580, item=0x8f411030, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #28 0x8f2e97ec in ng_snd_item (item=0x8f411030, flags=Variable "flags" is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #29 0x8f2ea7e4 in ng_apply_item (node=0x8f0b4c80, item=0x8f411030, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #30 0x8f2e97ec in ng_snd_item (item=0x8f411030, flags=Variable "flags" is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2254 #31 0x8f3de8bc in ng_ksocket_incoming2 (node=0x8f7bbe00, hook=0x0, arg1=0x8fae3820, arg2=0) at /usr/src/sys/modules/netgraph/ksocket/../../../netgraph/ng_ksocket.c:1143 #32 0x8f2ea91b in ng_apply_item (node=0x8f7bbe00, item=0x8f568810, rw=1) at /usr/src/sys/modules/netgraph/net
mpd5.5+CoA=kernel panic every 2-33 days
I have VPN servers on mpd5.5 FreeBSD vpn3 8.0-STABLE FreeBSD 8.0-STABLE #2 r207058M: Thu Apr 22 15:40:40 EEST 2010 ad...@vpn3:/usr/obj/usr/src/sys/GENERICVPN i386 and every 5-10 minutes my billing system send mpd-limit CoA message to mpd. Every 2-3 day server go into kernel panic: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 07 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x20:0x8a04c9e4 stack pointer = 0x28:0xee67386c frame pointer = 0x28:0xee673aa4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 871 (mpd5) trap number = 12 panic: page fault cpuid = 3 Uptime: 2d7h39m7s Physical memory: 2035 MB Dumping 390 MB: 375 359 343 Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 06 fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0x8a04c7cb stack pointer = 0x28:0xee65590c frame pointer = 0x28:0xee655924 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 890 (ng_queue2) trap number = 12 (kgdb) backtrace #0 doadump () at pcpu.h:246 #1 0x8089dd47 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0x8089e039 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0x80bcfe3c in trap_fatal (frame=0xee67382c, eva=36) at /usr/src/sys/i386/i386/trap.c:938 #4 0x80bd00c0 in trap_pfault (frame=0xee67382c, usermode=0, eva=36) at /usr/src/sys/i386/i386/trap.c:851 #5 0x80bd0a05 in trap (frame=0xee67382c) at /usr/src/sys/i386/i386/trap.c:533 #6 0x80bb2adb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0x8a04c9e4 in ng_path2noderef (here=0x89f85c00, address=0x9700d660 "mpd871-B-2-lim:1-0-m", destp=0xee673ac0, lasthook=0xee673abc) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:1757 #8 0x8a04cd40 in ng_address_path (here=0x89f85c00, item=0x8a639a40, address=0x9700d660 "mpd871-B-2-lim:1-0-m", retaddr=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3522 #9 0x8a0464f2 in ngc_send (so=0x889ed80c, flags=0, m=0x89ce6d00, addr=0x94caa1e0, control=0x0, td=0x8889a6f0) at /usr/src/sys/modules/netgraph/socket/../../../netgraph/ng_socket.c:296 #10 0x808ff0d5 in sosend_generic (so=0x889ed80c, addr=0x94caa1e0, uio=0xee673be8, top=0x89ce6d00, control=0x0, flags=0, td=0x8889a6f0) at /usr/src/sys/kern/uipc_socket.c:1257 #11 0x808fb1ef in sosend (so=0x889ed80c, addr=0x94caa1e0, uio=0xee673be8, ---Type to continue, or q to quit--- top=0x0, control=0x0, flags=0, td=0x8889a6f0) at /usr/src/sys/kern/uipc_socket.c:1301 #12 0x80902ae1 in kern_sendit (td=0x8889a6f0, s=5, mp=0xee673c5c, flags=0, control=0x0, segflg=UIO_USERSPACE) at /usr/src/sys/kern/uipc_syscalls.c:788 #13 0x80902d11 in sendit (td=0x8889a6f0, s=5, mp=0xee673c5c, flags=0) at /usr/src/sys/kern/uipc_syscalls.c:724 #14 0x80902e28 in sendto (td=0x8889a6f0, uap=0xee673cf8) at /usr/src/sys/kern/uipc_syscalls.c:840 #15 0x80bd03b3 in syscall (frame=0xee673d38) at /usr/src/sys/i386/i386/trap.c: #16 0x80bb2b40 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #17 0x0033 in ?? () ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel: arpresolve: can't allocate llinfo
I am upgraded to FreeBSD vpn3 8.0-STABLE FreeBSD 8.0-STABLE #2 r207058M: Thu Apr 22 15:40:40 EEST 2010 ad...@vpn3:/usr/obj/usr/src/sys/GENERICVPN i386 but memory still leak: after 1 day uptime: vmstat -m | grep lltable lltable 24966 3158K -57483 128,256 mpd5.5 provide real IP address, may be create script if-down.sh to clear link in arp lltable? 2010/4/21 Bjoern A. Zeeb > On Wed, 21 Apr 2010, Bjoern A. Zeeb wrote: > > On Wed, 21 Apr 2010, Denis Lamanov wrote: >> >> Hi, >> >> vmstat -m | grep lltable >>> every 3 minutes increases :( >>> lltable 16938 2149K -17779 128,256 >>> >> >> I'll MFC the patches to fix that the next couple of days, maybe >> tommorow morning. In case you want to try them, you'd need >> SVN r206469,206470,206481 applied to 8-STABLE. >> > > > Actually I just merged them. If you wait an hour or two for the > changes to show up on your local mirror 8-STABLE should be fine. > > Please note that if you are using option FLOWTABLE you will still see > the leak. I haven't gotten around to update my patches for that. > I'll try to remember to post them once done. > > > /bz > > -- > Bjoern A. Zeeb It will not break if you know what you are doing. > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel: arpresolve: can't allocate llinfo
I am not using option FLOWTABLE and disable in kernel with compile after install FreeBSD8. If i upgrades today to STABLE patches will apply? 2010/4/21 Bjoern A. Zeeb > On Wed, 21 Apr 2010, Bjoern A. Zeeb wrote: > > On Wed, 21 Apr 2010, Denis Lamanov wrote: >> >> Hi, >> >> vmstat -m | grep lltable >>> every 3 minutes increases :( >>> lltable 16938 2149K -17779 128,256 >>> >> >> I'll MFC the patches to fix that the next couple of days, maybe >> tommorow morning. In case you want to try them, you'd need >> SVN r206469,206470,206481 applied to 8-STABLE. >> > > > Actually I just merged them. If you wait an hour or two for the > changes to show up on your local mirror 8-STABLE should be fine. > > Please note that if you are using option FLOWTABLE you will still see > the leak. I haven't gotten around to update my patches for that. > I'll try to remember to post them once done. > > > /bz > > -- > Bjoern A. Zeeb It will not break if you know what you are doing. > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel: arpresolve: can't allocate llinfo
vmstat -m | grep lltable every 3 minutes increases :( lltable 16938 2149K -17779 128,256 2010/4/21 Alexander Petrovsky > Hello! > > I have some problem. Every day/ > > # cat /var/log/debug.log > Apr 21 05:58:26 troll kernel: arpresolve: can't allocate llinfo for > 84.*.23.36 > Apr 21 05:58:56 troll kernel: arpresolve: can't allocate llinfo for > 84.*.23.36 > Apr 21 06:10:31 troll kernel: arpresolve: can't allocate llinfo for > 84.*.23.36 > Apr 21 16:28:13 troll kernel: arpresolve: can't allocate llinfo for > 84.*.23.36 > ... etc. > > # ifconfig > em0: flags=8843 metric 0 mtu 1500 > > options=1db > ether 00:0a:e4:0a:78:f5 > inet 84.*.23.36 netmask 0xffc0 broadcast 84.*.23.63 > media: Ethernet autoselect (100baseTX ) > status: active > rl0: flags=8843 metric 0 mtu 1500 > options=48 > ether 00:14:d1:14:62:63 > inet 84.*.22.3 netmask 0xff80 broadcast 84.*.22.127 > ... > inet 84.*.22.16 netmask 0xff80 broadcast 84.*.22.127 > media: Ethernet autoselect (100baseTX ) > status: active > rl1: flags=8843 metric 0 mtu 1500 > options=48 > ether 00:40:f4:cc:d2:98 > inet 192.168.47.3 netmask 0xff00 broadcast 192.168.47.255 > ... > inet 192.168.47.16 netmask 0xff00 broadcast 192.168.47.255 > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > > # uname -a > FreeBSD * 8.0-STABLE FreeBSD 8.0-STABLE #0 r199880: Thu Dec 3 13:35:21 > IRKT 2009 alexan...@*:/usr/obj/usr/src/sys/WEBKERNEL i386 > > what could be the problem? > > 2010/4/21 Denis Lamanov > >> Hi! I am ukranian and bad speak english :( >> I have VPN servers with mpd5.5 and FreeBSD 8.0 >> upgrade it to 8.0-STABLE #1 r206493 >> all servers have real static IP address >> in mpd enabled proxy-arp and mpd provide real static IP address into >> pptp/l2tp tunnels. >> Periodic in console and /var/log/debug.log writes: >> kernel: arpresolve: can't allocate llinfo for 155.xx.xx.1 >> kernel: arpresolve: can't allocate llinfo for 155.xx.xx.123 >> kernel: arpresolve: can't allocate llinfo for 155.xx.xx.456 >> >> and after server kernel panic/trap 12 with current proccess: ng_queue >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > > > > -- > Петровский Александр / Alexander Petrovsky, > > ICQ: 350342118 > Jabber: ju...@jabber.ru > Phone: +7 914 8 820 815 > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
kernel: arpresolve: can't allocate llinfo
Hi! I am ukranian and bad speak english :( I have VPN servers with mpd5.5 and FreeBSD 8.0 upgrade it to 8.0-STABLE #1 r206493 all servers have real static IP address in mpd enabled proxy-arp and mpd provide real static IP address into pptp/l2tp tunnels. Periodic in console and /var/log/debug.log writes: kernel: arpresolve: can't allocate llinfo for 155.xx.xx.1 kernel: arpresolve: can't allocate llinfo for 155.xx.xx.123 kernel: arpresolve: can't allocate llinfo for 155.xx.xx.456 and after server kernel panic/trap 12 with current proccess: ng_queue ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related)
Yes, PCIX BCM5704 FreeBSD vpn2 8.0-STABLE FreeBSD 8.0-STABLE #1 r204028: Thu Feb 18 08:29:42 EET 2010 ad...@vpn2:/usr/obj/usr/src/sys/GENERIC i386 2010/2/22 Pyun YongHyeon > On Mon, Feb 22, 2010 at 03:17:17PM +0200, Denis Lamanov wrote: > > I see same trouble (lost packets after 4 day uptime and reboot) :( > > > > dev.bge.0.stats.rx.FCSErrors: 18 > > > > You also have PCIX BCM5704 controller? What FreeBSD version do you > use? > > > 2010/2/19 Slawa Olhovchenkov > > > > > On Fri, Feb 19, 2010 at 12:06:47PM -0800, Pyun YongHyeon wrote: > > > > > > > > > > > > dev.bge.1.stats.rx.Fragments: 1 > > > > > > > > You received a frame that is less than 64 bytes with a bad FCS. > > > > > > > > > dev.bge.1.stats.rx.UcastPkts: 2956515 > > > > > dev.bge.1.stats.rx.MulticastPkts: 0 > > > > > dev.bge.1.stats.rx.FCSErrors: 18 > > > > > > > > You have a lot of FCS errors here. > > > > Please double check cabling. If the statistics counter is right, > > > > sender is guilty or you have bad cabling issues here. > > > > > > 1. lost packets much more 18. I think hundreds, or thousands. > > > 2. packets lost on both (bge0 & bge1) interfaces > > > 3. packets don't lost on sources at Aug'09 > > > ___ > > > freebsd-stable@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > > To unsubscribe, send any mail to " > freebsd-stable-unsubscr...@freebsd.org" > > > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related)
vpn2# sysctl dev.bge.0.stats dev.bge.0.stats.FramesDroppedDueToFilters: 0 dev.bge.0.stats.DmaWriteQueueFull: 0 dev.bge.0.stats.DmaWriteHighPriQueueFull: 0 dev.bge.0.stats.NoMoreRxBDs: 0 dev.bge.0.stats.InputDiscards: 0 dev.bge.0.stats.InputErrors: 0 dev.bge.0.stats.RecvThresholdHit: 36622 dev.bge.0.stats.DmaReadQueueFull: 17 dev.bge.0.stats.DmaReadHighPriQueueFull: 0 dev.bge.0.stats.SendDataCompQueueFull: 0 dev.bge.0.stats.RingSetSendProdIndex: 116130 dev.bge.0.stats.RingStatusUpdate: 79240 dev.bge.0.stats.Interrupts: 79240 dev.bge.0.stats.AvoidedInterrupts: 0 dev.bge.0.stats.SendThresholdHit: 0 dev.bge.0.stats.rx.Octets: 132390898 dev.bge.0.stats.rx.Fragments: 0 dev.bge.0.stats.rx.UcastPkts: 117696 dev.bge.0.stats.rx.MulticastPkts: 1 dev.bge.0.stats.rx.FCSErrors: 41 dev.bge.0.stats.rx.AlignmentErrors: 0 dev.bge.0.stats.rx.xonPauseFramesReceived: 0 dev.bge.0.stats.rx.xoffPauseFramesReceived: 0 dev.bge.0.stats.rx.ControlFramesReceived: 0 dev.bge.0.stats.rx.xoffStateEntered: 0 dev.bge.0.stats.rx.FramesTooLong: 0 dev.bge.0.stats.rx.Jabbers: 0 dev.bge.0.stats.rx.UndersizePkts: 0 dev.bge.0.stats.rx.inRangeLengthError: 0 dev.bge.0.stats.rx.outRangeLengthError: 0 dev.bge.0.stats.tx.Octets: 125971311 dev.bge.0.stats.tx.Collisions: 0 dev.bge.0.stats.tx.XonSent: 0 dev.bge.0.stats.tx.XoffSent: 0 dev.bge.0.stats.tx.flowControlDone: 0 dev.bge.0.stats.tx.InternalMacTransmitErrors: 0 dev.bge.0.stats.tx.SingleCollisionFrames: 0 dev.bge.0.stats.tx.MultipleCollisionFrames: 0 dev.bge.0.stats.tx.DeferredTransmissions: 0 dev.bge.0.stats.tx.ExcessiveCollisions: 0 dev.bge.0.stats.tx.LateCollisions: 0 dev.bge.0.stats.tx.UcastPkts: 115417 dev.bge.0.stats.tx.MulticastPkts: 0 dev.bge.0.stats.tx.BroadcastPkts: 0 dev.bge.0.stats.tx.CarrierSenseErrors: 0 dev.bge.0.stats.tx.Discards: 0 dev.bge.0.stats.tx.Errors: 0 2010/2/19 Pyun YongHyeon > On Fri, Feb 19, 2010 at 11:13:59PM +0300, Slawa Olhovchenkov wrote: > > On Fri, Feb 19, 2010 at 12:06:47PM -0800, Pyun YongHyeon wrote: > > > > > > > > > dev.bge.1.stats.rx.Fragments: 1 > > > > > > You received a frame that is less than 64 bytes with a bad FCS. > > > > > > > dev.bge.1.stats.rx.UcastPkts: 2956515 > > > > dev.bge.1.stats.rx.MulticastPkts: 0 > > > > dev.bge.1.stats.rx.FCSErrors: 18 > > > > > > You have a lot of FCS errors here. > > > Please double check cabling. If the statistics counter is right, > > > sender is guilty or you have bad cabling issues here. > > > > 1. lost packets much more 18. I think hundreds, or thousands. > > 2. packets lost on both (bge0 & bge1) interfaces > > If you see the MAC statistics counter, you have the following > number of status updates and interrupts. Both numbers are same > which means the controller didn't lost interrupts for state > updates. > dev.bge.0.stats.RingStatusUpdate: 950302 > dev.bge.0.stats.Interrupts: 950302 > and > dev.bge.1.stats.RingStatusUpdate: 5518912 > dev.bge.1.stats.Interrupts: 5518912 > > You received 582767 unicast packets and lost 0 packet for bge0. > dev.bge.0.stats.rx.UcastPkts: 582767 > And you also received 2956515 unicast packets and lost 19 packets > for bge1. > dev.bge.1.stats.rx.Fragments: 1 > dev.bge.1.stats.rx.UcastPkts: 2956515 > dev.bge.1.stats.rx.FCSErrors: 18 > I don't see such a large number packet drops from these MAC > statistics unless upper stack drops received packets. > I fixed some counter updates which were ignored in previous > releases so you may happen to see lost counters in recent version. > > Normally you should not have any FCS errors, it could be related > with signal quality and these errors might not be correctly > counted. > > > 3. packets don't lost on sources at Aug'09 > > Since I don't have BCM5704 hardware it's hard to find which > revision may affect to this issue. Could you narrow down which > revision number started showing the issue? > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related)
I see same trouble (lost packets after 4 day uptime and reboot) :( dev.bge.0.stats.rx.FCSErrors: 18 2010/2/19 Slawa Olhovchenkov > On Fri, Feb 19, 2010 at 12:06:47PM -0800, Pyun YongHyeon wrote: > > > > > > dev.bge.1.stats.rx.Fragments: 1 > > > > You received a frame that is less than 64 bytes with a bad FCS. > > > > > dev.bge.1.stats.rx.UcastPkts: 2956515 > > > dev.bge.1.stats.rx.MulticastPkts: 0 > > > dev.bge.1.stats.rx.FCSErrors: 18 > > > > You have a lot of FCS errors here. > > Please double check cabling. If the statistics counter is right, > > sender is guilty or you have bad cabling issues here. > > 1. lost packets much more 18. I think hundreds, or thousands. > 2. packets lost on both (bge0 & bge1) interfaces > 3. packets don't lost on sources at Aug'09 > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
