Re: kern/119945: [rum] [panic] rum device in hostap mode, cause kernel core dump.
Synopsis: [rum] [panic] rum device in hostap mode, cause kernel core dump. Responsible-Changed-From-To: freebsd-usb->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Fri Feb 22 12:08:13 UTC 2008 Responsible-Changed-Why: To me, this looks like it might be a -net problem, rather than -usb http://www.freebsd.org/cgi/query-pr.cgi?pr=119945 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Some gre troubles
Hi all! Does somebody can help me with this problem? HOST A: ptf-gw# netstat -rn | grep def default81.16.137.1UGS 166976rl2 ptf-gw# ifconfig gre0 gre0: flags=b051 metric 0 mtu 1476 tunnel inet 87.103.215.125 --> 213.183.100.173 inet 192.168.5.1 --> 192.168.5.2 netmask 0xff00 ptf-gw# ping -c 2 213.183.100.173 PING 213.183.100.173 (213.183.100.173): 56 data bytes 64 bytes from 213.183.100.173: icmp_seq=0 ttl=56 time=92.372 ms 64 bytes from 213.183.100.173: icmp_seq=1 ttl=56 time=69.794 ms --- 213.183.100.173 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 69.794/81.083/92.372/11.289 ms ptf-gw# ping -c 2 192.168.5.2 PING 192.168.5.2 (192.168.5.2): 56 data bytes --- 192.168.5.2 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss ptf-gw# ifconfig ng0 ng0: flags=88d1 metric 0 mtu 1492 inet 87.103.215.125 --> 217.116.130.134 netmask 0x ptf-gw# route add -host 213.183.100.173 217.116.130.134 add host 213.183.100.173: gateway 217.116.130.134 ptf-gw# ping -c 2 213.183.100.173 PING 213.183.100.173 (213.183.100.173): 56 data bytes 64 bytes from 213.183.100.173: icmp_seq=0 ttl=54 time=127.367 ms 64 bytes from 213.183.100.173: icmp_seq=1 ttl=54 time=128.663 ms --- 213.183.100.173 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 127.367/128.015/128.663/0.648 ms ptf-gw# ping -c 2 192.168.5.2 PING 192.168.5.2 (192.168.5.2): 56 data bytes --- 192.168.5.2 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss ptf-gw# ifconfig gre0 gre0: flags=b051 metric 0 mtu 1476 tunnel inet 87.103.215.125 --> 213.183.100.173 inet 192.168.5.1 --> 192.168.5.2 netmask 0xff00 ptf-gw# ping -c 4 192.168.5.2 & && tcpdump -i gre0 -c 4 [1] 59080 PING 192.168.5.2 (192.168.5.2): 56 data bytes tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on gre0, link-type NULL (BSD loopback), capture size 68 bytes 64 bytes from 192.168.5.2: icmp_seq=0 ttl=64 time=131.373 ms 12:44:28.647565 IP 192.168.5.2 > 192.168.5.1: ICMP echo reply, id 51430, seq 0, length 64 12:44:29.517236 IP 192.168.5.1 > 192.168.5.2: ICMP echo request, id 51430, seq 1, length 64 64 bytes from 192.168.5.2: icmp_seq=1 ttl=64 time=136.633 ms 12:44:29.653840 IP 192.168.5.2 > 192.168.5.1: ICMP echo reply, id 51430, seq 1, length 64 12:44:30.518229 IP 192.168.5.1 > 192.168.5.2: ICMP echo request, id 51430, seq 2, length 64 4 packets captured 4 packets received by filter 0 packets dropped by kernel ptf-gw# 64 bytes from 192.168.5.2: icmp_seq=3 ttl=64 time=132.728 ms --- 192.168.5.2 ping statistics --- 4 packets transmitted, 3 packets received, 25.0% packet loss round-trip min/avg/max/stddev = 131.373/133.578/136.633/2.230 ms [1]Done ping -c 4 192.168.5.2 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic in 6.3-RELEASE when multi-cast client exits
Thanks George, we will apply this patch tonight.
On Fri, Feb 22, 2008 at 1:26 AM, <[EMAIL PROTECTED]> wrote:
> FYI this is fixed by a one line change that is about to hit 6-STABLE:
>
> @@ -991,7 +991,6 @@
> * a new record. Otherwise, we are done.
> */
>if (ifma->ifma_protospec != NULL) {
> - if_delmulti_ent(ifma); /* We don't need another reference
> */
>IN_MULTI_UNLOCK();
>IFF_UNLOCKGIANT(ifp);
>return ifma->ifma_protospec;
>
> Sent to me by Stephan Uphoff.
>
> I tested it today.
>
> Best,
> George
>
>
--
Rob Watt
Hudson River Trading
212.479.3954
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: i386/120966: kernel panic with if_rum and WPA encryption
The following reply was made to PR kern/120966; it has been noted by GNATS. From: "Remko Lodder" <[EMAIL PROTECTED]> To: "Oliver Herold" <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: i386/120966: kernel panic with if_rum and WPA encryption Date: Fri, 22 Feb 2008 21:02:32 +0100 (CET) Hello, Thanks for the report, since you got a kernel panic, I would like to visit http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html and follow the instructions listed there. If you have the information, please reply-all on this message, so that it gets properly recorded into the ticket. Without the dump info we cannot do much. Thanks! -- /"\ Best regards, | [EMAIL PROTECTED] \ / Remko Lodder | [EMAIL PROTECTED] Xhttp://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/120966: [rum]: kernel panic with if_rum and WPA encryption
Synopsis: [rum]: kernel panic with if_rum and WPA encryption State-Changed-From-To: open->feedback State-Changed-By: remko State-Changed-When: Fri Feb 22 20:03:18 UTC 2008 State-Changed-Why: i requested feedback http://www.freebsd.org/cgi/query-pr.cgi?pr=120966 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/120966: [rum]: kernel panic with if_rum and WPA encryption
Old Synopsis: kernel panic with if_rum and WPA encryption New Synopsis: [rum]: kernel panic with if_rum and WPA encryption Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Fri Feb 22 20:02:40 UTC 2008 Responsible-Changed-Why: reassign to networking team, I have pending feedback request for more info regarding the dump http://www.freebsd.org/cgi/query-pr.cgi?pr=120966 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/120958: no response to ICMP traffic on interface configured with a link-local address
I looked at this very briefly. It's gnarly because in_canforward() is a candidate for inlining and is a predicate which is being overloaded with different meanings by ip_forward()/ip_input() and icmp_reflect(). So whilst the fix is most likely a 3 liner, it risks making the code look crap. We genuinely don't want to forward 169.254.0.0/16 traffic, however we genuinely need to reply to ICMP which originates from these ranges. [EMAIL PROTECTED] wrote: Synopsis: no response to ICMP traffic on interface configured with a link-local address Responsible-Changed-From-To: bms->freebsd-net Responsible-Changed-By: bms Responsible-Changed-When: Fri 22 Feb 2008 21:23:23 UTC Responsible-Changed-Why: The secretary disavows all knowledge of your actions. ["Responsible" implies "I'll fix it", I said no such thing.. I *MIGHT* get around to it, but "Responsible" implies there's an obligation. Cheeky linimon!] http://www.freebsd.org/cgi/query-pr.cgi?pr=120958 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/120958: no response to ICMP traffic on interface configured with a link-local address
Synopsis: no response to ICMP traffic on interface configured with a link-local address Responsible-Changed-From-To: bms->freebsd-net Responsible-Changed-By: bms Responsible-Changed-When: Fri 22 Feb 2008 21:23:23 UTC Responsible-Changed-Why: The secretary disavows all knowledge of your actions. ["Responsible" implies "I'll fix it", I said no such thing.. I *MIGHT* get around to it, but "Responsible" implies there's an obligation. Cheeky linimon!] http://www.freebsd.org/cgi/query-pr.cgi?pr=120958 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/120966: [rum]: kernel panic with if_rum and WPA encryption
The following reply was made to PR kern/120966; it has been noted by GNATS. From: Oliver Herold <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/120966: [rum]: kernel panic with if_rum and WPA encryption Date: Fri, 22 Feb 2008 23:24:33 +0100 --8P1HSweYDcXXzwPJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I hope this is the proper information. I have a kernel with debug symbols and vmcore files (about 116Mb) in /var/crash. Oliver -- Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 01 fault virtual address =3D 0x12 fault code =3D supervisor read, page not present instruction pointer=3D 0x20:0xc06bb18a stack pointer =3D 0x28:0xef0fabe4 frame pointer =3D 0x28:0xef0fabfc code segment =3D base 0x0, limit 0xf, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process=3D 27 (irq22: ehci0+) trap number=3D 12 panic: page fault cpuid =3D 1 Uptime: 11m30s Physical memory: 3051 MB Dumping 116 MB: 101 85 69 53 37 21 5 #0 doadump () at pcpu.h:195 195pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:195 #1 0xc07557c7 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0755a89 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a48aec in trap_fatal (frame=3D0xef0faba4, eva=3D18) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a48d50 in trap_pfault (frame=3D0xef0faba4, usermode=3D0, eva=3D18) = at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a496d2 in trap (frame=3D0xef0faba4) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0a3004b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc06bb18a in rum_txeof (xfer=3D0xc6f22000, priv=3D0xc6cb0498, status=3DUSBD_NORMAL_COMPLETION) at /usr/src/sys/dev/usb/if_rum.c:843 #8 0xc06d49f5 in usb_transfer_complete (xfer=3D0xc6f22000) at /usr/src/sys/dev/usb/usbdi.c:977 #9 0xc06a75a1 in ehci_softintr (v=3D0xc6c2) at /usr/src/sys/dev/usb/ehci.c:884 #10 0xc06d0572 in usb_schedsoftintr (bus=3D0xc6c2) at /usr/src/sys/dev/usb/usb.c:844 #11 0xc06a8d7e in ehci_intr1 (sc=3D0xc6c2) at /usr/src/sys/dev/usb/ehci.c:603 #12 0xc06a97b5 in ehci_intr (v=3D0xc6c2) at /usr/src/sys/dev/usb/ehci.c:562 #13 0xc07389fb in ithread_loop (arg=3D0xc6c96920) at /usr/src/sys/kern/kern_intr.c:1036 #14 0xc07357f9 in fork_exit (callout=3D0xc0738850 , arg=3D0xc6c96920, frame=3D0xef0fad38) at /usr/src/sys/kern/kern_fork.c:781 #15 0xc0a300c0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 --=20 To refuse praise is to seek praise twice. --8P1HSweYDcXXzwPJ Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAke/S6EACgkQbZFSiGSuUEg2wgCfX+3UDPUS8QeHhJo2ZcBu80kQ 190AniSg3j93qFj2QTCfO+9JtgC6tcIB =jx6o -END PGP SIGNATURE- --8P1HSweYDcXXzwPJ-- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
question about change in inet_ntoa.c
I was looking at the differences between some old FreeBSD code
and the one of 7.0-RC1 and was wondering about a change
in inet_ntoa.c
/* 7.0-RC1 **/
sprintf(buf, "%d.%d.%d.%d",
ucp[0] & 0xff,
ucp[1] & 0xff,
ucp[2] & 0xff,
ucp[3] & 0xff);
/** 4.11-RELEASE ***/
static const char fmt[] = "%u.%u.%u%u";
if ((size_t)snprintf(dst, size, fmt, src[0], src[1], src[2], src[3])
>= size) {
Was there a specific purpose of changing the more easy and simple way
of %u instead of the combination of %d and and-ing with 0xff ??
It essentially gives the same result but increases overhead (i think) in
the more
recent version.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: question about change in inet_ntoa.c
ithilgore wrote:
I was looking at the differences between some old FreeBSD code
and the one of 7.0-RC1 and was wondering about a change
in inet_ntoa.c
/* 7.0-RC1 **/
sprintf(buf, "%d.%d.%d.%d",
ucp[0] & 0xff,
ucp[1] & 0xff,
ucp[2] & 0xff,
ucp[3] & 0xff);
/** 4.11-RELEASE ***/
static const char fmt[] = "%u.%u.%u%u";
if ((size_t)snprintf(dst, size, fmt, src[0], src[1], src[2], src[3])
>= size) {
Was there a specific purpose of changing the more easy and simple way
of %u instead of the combination of %d and and-ing with 0xff ??
It essentially gives the same result but increases overhead (i think)
in the more
recent version.
I just noticed I made a mistake. The second code is libc's version of
inet_ntoa.
But the question still counts. Why not use the plain simpler version of
libc ?
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
