Re: panic: bufwrite: buffer is not busy???
On 1/30/11 10:31 PM, Eugene Grosbein wrote:
On 15.01.2011 01:37, John Baldwin wrote:
On Friday, January 14, 2011 1:44:19 pm Eugene Grosbein wrote:
On 14.01.2011 18:46, Mike Tancsa wrote:
I'm using mpd 5.5 on three PPPoE routers, each servicing about 300 PPPoE
concurrent sessions. Routers are based on Intel SR1630GP hardware platforms and
runs FreeBSD 7.3-RELEASE.
I'm experiencing stability issues related to Netgraph. None of above routers can
survive more than 20-30 days of uptime under typical load. There are different
flavors of kernel panics, but all are somehow related to netgraph. Typical
backtraces follow
I also have stability issues on RELENG_8.
http://www.freebsd.org/cgi/query-pr.cgi?pr=153497
And for one of my servers (8.2-PRERELEASE/amd64 with 4GB RAM) I just cannot
obtain crashdump,
it cannot finish to write it. For example, it happened an hour ago:
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 04
fault virtual address = 0x20040
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x803cc979
Assuming your kernel is built with debug symbols (which is the default), one
thing you can do to aid in debugging is this:
gdb /boot/kernel/kernel
(gdb) l *0x803cc979
Where the 0xfff bit is the part of the 'instruction pointer' value
above after the colon (:) and then send the output of that in your e-mail to
the list. This allows us to the source line at which the fault occurred.
Yesterday I've got another kernel panic of this kind with RELENG_8 updated 20
January
and it still could not finish writing of crashdump:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 02
fault virtual address = 0x20030
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x803c1315
stack pointer = 0x28:0xff8000130780
frame pointer = 0x28:0xff80001307a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (irq259: em1:rx 0)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 19h41m8s
Dumping 4087 MB (3 chunks)
chunk 0: 1MB (150 pages) ... ok
chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not
busy???
cpuid = 1
Uptime: 19h41m9s
Automatic reboot in 15 seconds - press a key on the console to abort
This time I have all debug symbols handy:
# gdb kernel
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) l *0x803c1315
0x803c1315 is in ng_address_hook
(/home/src/sys/netgraph/ng_base.c:3504).
3499 * Quick sanity check..
3500 * Since a hook holds a reference on it's node, once we know
3501 * that the peer is still connected (even if invalid,) we know
3502 * that the peer node is present, though maybe invalid.
3503 */
3504if ((hook == NULL) ||
3505NG_HOOK_NOT_VALID(hook) ||
3506NG_HOOK_NOT_VALID(peer = NG_HOOK_PEER(hook)) ||
3507NG_NODE_NOT_VALID(peernode = NG_PEER_NODE(hook))) {
3508NG_FREE_ITEM(item);
replace with:
3504if ((hook == NULL) ||
3505NG_HOOK_NOT_VALID(hook) ||
((peer = NG_HOOK_PEER(hook)) == NULL) ||
3506NG_HOOK_NOT_VALID(peer) ||
((peernode = NG_PEER_NODE(hook)) == NULL) ||
3507NG_NODE_NOT_VALID(peernode)) {
if (peer)
kassert((peernode != NULL), ("peer node NULL wile peer
hook exists"));
3508NG_FREE_ITEM(item);
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: panic: bufwrite: buffer is not busy???
On 31.01.2011 14:20, Julian Elischer wrote:
>> # gdb kernel
>> GNU gdb 6.1.1 [FreeBSD]
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB. Type "show warranty" for details.
>> This GDB was configured as "amd64-marcel-freebsd"...
>> (gdb) l *0x803c1315
>> 0x803c1315 is in ng_address_hook
>> (/home/src/sys/netgraph/ng_base.c:3504).
>> 3499 * Quick sanity check..
>> 3500 * Since a hook holds a reference on it's node, once we know
>> 3501 * that the peer is still connected (even if invalid,) we
>> know
>> 3502 * that the peer node is present, though maybe invalid.
>> 3503 */
>> 3504if ((hook == NULL) ||
>> 3505NG_HOOK_NOT_VALID(hook) ||
>> 3506NG_HOOK_NOT_VALID(peer = NG_HOOK_PEER(hook)) ||
>> 3507NG_NODE_NOT_VALID(peernode = NG_PEER_NODE(hook))) {
>> 3508NG_FREE_ITEM(item);
>
>
> replace with:
>
> 3504if ((hook == NULL) ||
> 3505NG_HOOK_NOT_VALID(hook) ||
> ((peer = NG_HOOK_PEER(hook)) == NULL) ||
> 3506NG_HOOK_NOT_VALID(peer) ||
> ((peernode = NG_PEER_NODE(hook)) == NULL) ||
> 3507NG_NODE_NOT_VALID(peernode)) {
> if (peer)
>kassert((peernode != NULL), ("peer node NULL
> wile peer hook exists"));
> 3508NG_FREE_ITEM(item);
>
It does not compile:
/home/src/sys/netgraph/ng_base.c: In function 'ng_address_hook':
/home/src/sys/netgraph/ng_base.c:3511: warning: implicit declaration of
function 'kassert'
/home/src/sys/netgraph/ng_base.c:3511: warning: nested extern declaration of
'kassert'
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
1 error
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Current problem reports assigned to freebsd-net@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/154286 net[netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154284 net[ath] Modern ath wifi cards (such as AR9285) have miss o kern/154255 net[nfs] NFS not responding o kern/154214 net[stf] [panic] Panic when creating stf interface o kern/154169 net[multicast] [ip6] Node Information Query multicast add o kern/154134 net[ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net[netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net[vlan] [patch] change to way of auto-generatation of v o kern/154006 net[tcp] [patch] tcp "window probe" bug on 64bit o kern/153951 net[ixgbe] Intel 10GBase-LR Ethernet card detected as 10G o kern/153938 net[run] [panic] [patch] Workaround for use-after-free pa o kern/153937 net[ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net[ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net[ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net[ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153671 net[em] [panic] 8.2-PRERELEASE repeatable kernel in if_em o kern/153497 net[netgraph] netgraph panic due to race conditions o kern/153454 net[patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net[em] em interface use 100% cpu o kern/153255 net[panic] 8.2-PRERELEASE repeatable kernel panic under h o kern/153244 net[em] em(4) fails to send UDP to port 0x o kern/152893 net[netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net[em] tftpd (and likely other udp traffic) fails over e o kern/152828 net[em] poor performance on 8.1, 8.2-PRE o kern/152569 net[net]: Multiple ppp connections and routing table prob o kern/152360 net[dummynet] [panic] Crash related to dummynet. o kern/152235 net[arp] Permanent local ARP entries are not properly upd o kern/152141 net[vlan] encapsulate vlan in ng_ether before output to i o kern/151690 net[ep] network connectivity won't work until dhclient is o kern/151681 net[nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net[igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net[ixgbe][igb] Panic when packets are dropped with heade o bin/150642 netnetstat(1) doesn't print anything for SCTP sockets o kern/150557 net[igb] igb0: Watchdog timeout -- resetting o kern/150251 net[patch] [ixgbe] Late cable insertion broken o kern/150249 net[ixgbe] Media type detection broken o kern/150247 net[patch] [ixgbe] Version in -current won't build on 7.x o bin/150224 netppp(8) does not reassign static IP after kill -KILL co f kern/149969 net[wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net[ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149786 net[bwn] bwn on Dell Inspiron 1150: connections stall o kern/149643 net[rum] device not sending proper beacon frames in ap mo o kern/149609 net[panic] reboot after adding second default route o kern/149539 net[ath] atheros ar9287 is not supported by ath_hal o kern/149516 net[ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net[realtek/atheros]: None of my network card working o kern/149307 net[ath] Doesn't work Atheros 9285 o kern/149306 net[alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net[inet] [patch] in_pcbbind: redundant test o kern/149086 net[multicast] Generic multicast join failure in 8.1 o kern/148322 net[ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net[ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net[ath] wireless networking stops functioning o kern/147894 net[ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net[ip6] setfb not work with ipv6 o kern/146845 net[libc] close(2) returns error 54 (connection reset by o kern/146792 net[flowtable] flowcleaner 100% cpu's core load o kern/146759 net[cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net[pf] [panic] PF or dumynet kernel panic o kern/146534 net[icmp6] wrong source address in echo reply o kern/146427 net[mwl] Additional
Re: Problem with re0
Pyun YongHyeon (pyu...@gmail.com) [11.01.31 04:08] wrote: > > The RTL8168/8111D sample board I have does not show this kind of > > issue. This happens only when established link is 1000baseT, right? > > I slightly changed PHY's link detection code so would you try that > > patch at the following URL? > > http://people.freebsd.org/~yongari/re/rgephy.link.patch3 > > Previous one had a bug, please update one. > http://people.freebsd.org/~yongari/re/rgephy.link.patch4 no change :( interface continues to flap -- Zeus V. Panchenko IT Dpt., IBS ltdGMT+2 (EET) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: panic: bufwrite: buffer is not busy???
On Mon, 31 Jan 2011, Eugene Grosbein wrote:
On 31.01.2011 14:20, Julian Elischer wrote:
# gdb kernel
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) l *0x803c1315
0x803c1315 is in ng_address_hook
(/home/src/sys/netgraph/ng_base.c:3504).
3499 * Quick sanity check..
3500 * Since a hook holds a reference on it's node, once we know
3501 * that the peer is still connected (even if invalid,) we know
3502 * that the peer node is present, though maybe invalid.
3503 */
3504if ((hook == NULL) ||
3505NG_HOOK_NOT_VALID(hook) ||
3506NG_HOOK_NOT_VALID(peer = NG_HOOK_PEER(hook)) ||
3507NG_NODE_NOT_VALID(peernode = NG_PEER_NODE(hook))) {
3508NG_FREE_ITEM(item);
replace with:
which is essentially what I had suggested in the formerly mentioned PR
already (just remove the first printf macro).
3504if ((hook == NULL) ||
3505NG_HOOK_NOT_VALID(hook) ||
((peer = NG_HOOK_PEER(hook)) == NULL) ||
3506NG_HOOK_NOT_VALID(peer) ||
((peernode = NG_PEER_NODE(hook)) == NULL) ||
3507NG_NODE_NOT_VALID(peernode)) {
if (peer)
kassert((peernode != NULL), ("peer node NULL wile
peer hook exists"));
3508NG_FREE_ITEM(item);
The problem is that it will not help to fix the race; if you go
up in the same file you'll find another similar one of these checks
with a scary rev 1.1. (I think) comment (that you, Julian, should know
very well;-)
The solution that this needs is: proper locking.
It does not compile:
/home/src/sys/netgraph/ng_base.c: In function 'ng_address_hook':
/home/src/sys/netgraph/ng_base.c:3511: warning: implicit declaration of
function 'kassert'
/home/src/sys/netgraph/ng_base.c:3511: warning: nested extern declaration of
'kassert'
yeah KASSERT is upper case.
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
1 error
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
--
Bjoern A. Zeeb You have to have visions!
Going to jail sucks -- All my daemons like it!
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Proposed patch for Port Randomization modifications according to RFC6056
Hello,
I attach the latest version of the port randomization code as a patch
against RELENG_8.
Changelog:
1) sysctl variable names are changed to:
- 'net.inet.ip.portrange.randomalg.version' - representing the
algorithm of choice.
- 'net.inet.ip.portrange.randomalg.alg5_tradeoff' - representing the
Algorithm 5 computational tradeoff value (the 'N' value in the
Algorithm 5 description in the RFC 6056).
2) Code comments are synchronized with the current variable names.
Ivo Vachkov
On Sat, Jan 29, 2011 at 4:27 AM, Doug Barton wrote:
> On 01/28/2011 11:57, Ivo Vachkov wrote:
>>
>> On Fri, Jan 28, 2011 at 9:00 PM, Doug Barton wrote:
>
>>> How does net.inet.ip.portrange.randomalg sound? I would also suggest that
>>> the second sysctl be named net.inet.ip.portrange.randomalg.alg5_tradeoff
>>> so
>>> that one could do 'sysctl net.inet.ip.portrange.randomalg' and see both
>>> values. But I won't quibble on that. :)
>>>
>>
>> I have no objections with this. Since this is my first attempt to
>> contribute something back to the community I decided to see how it's
>> done before. So I found:
>> net.inet.tcp.rfc1323
>> net.inet.tcp.rfc3465
>> net.inet.tcp.rfc3390
>> net.inet.tcp.rfc3042
>> which probably led me in a wrong direction :)
>
> Yeah, I had actually intended to say something to the effect of "there are
> plenty of unfortunate examples in the tree already so your doing it that way
> is totally understandable" but I trimmed it.
>
>> I understand your point and agree with it. However, my somewhat
>> limited understanding of the sysctl internal organization is telling
>> me that tree node does not support values. Am I wrong?
>
> You are likely correct. :) It's an inconvenient fact that often forget
> because that's not the sandbox that I usually play in.
>
>> If my reasoning
>> is correct, maybe I can create the sysctl variables with the following
>> names:
>> - net.inet.ip.portrange.randomalg (Tree Node)
>> - net.inet.ip.portrange.randomalg.alg[orithm] (Leaf Node, to store the
>> selected algorithm)
>
> I would go with "version" to increase the visual distinctiveness. I searched
> the current tree and there doesn't seem to be a clear winner for how to
> portray "this is the current N/M that is in use" but "version" seems to have
> the most representatives.
>
>> - net.inet.ip.portrange.randomalg.alg5_tradeoff (Leaf Node, to store
>> the Algorithm 5 trade-off value)
>
> I'm assuming this is the "N" value mentioned in the RFC. If so, I commend
> you on your choice of "tradeoff" to represent it. :)
>
>
> hth,
>
> Doug
>
> --
>
> Nothin' ever doesn't change, but nothin' changes much.
> -- OK Go
>
> Breadth of IT experience, and depth of knowledge in the DNS.
> Yours for the right price. :) http://SupersetSolutions.com/
>
>
--
"UNIX is basically a simple operating system, but you have to be a
genius to understand the simplicity." Dennis Ritchie
diff -r 0d67f9c982f7 src/sys/netinet/in_pcb.c
--- a/src/sys/netinet/in_pcb.c Mon Jan 31 11:35:24 2011 +0200
+++ b/src/sys/netinet/in_pcb.c Mon Jan 31 14:29:52 2011 +0200
@@ -81,6 +81,8 @@
#include
#endif /* IPSEC */
+#include
+
#include
/*
@@ -109,6 +111,8 @@
VNET_DEFINE(int, ipport_stoprandom); /* toggled by ipport_tick */
VNET_DEFINE(int, ipport_tcpallocs);
static VNET_DEFINE(int, ipport_tcplastcount);
+VNET_DEFINE(u_int, ipport_randomalg_ver) = 1; /* user controlled via sysctl */
+VNET_DEFINE(u_int, ipport_randomalg_alg5_tradeoff) = 500; /* user controlled via sysctl */
#define V_ipport_tcplastcount VNET(ipport_tcplastcount)
@@ -141,7 +145,68 @@
#undef RANGECHK
+/*
+ * Updates V_ipport_randomalg_ver to the provided value
+ * and ensures it is in the supported range (1 - 5)
+ */
+static int
+sysctl_net_randomalg_version_check(SYSCTL_HANDLER_ARGS)
+{
+ u_int algorithm = *(u_int *)arg1;
+ int error;
+
+#ifdef VIMAGE
+ error = vnet_sysctl_handle_uint(oidp, &algorithm, 0, req);
+#else
+ error = sysctl_handle_int(oidp, &algorithm, 0, req);
+#endif
+
+ if (error == 0) {
+ switch (algorithm) {
+ case INP_RFC6056_ALG_1:
+ case INP_RFC6056_ALG_2:
+ case INP_RFC6056_ALG_3:
+ case INP_RFC6056_ALG_4:
+ case INP_RFC6056_ALG_5:
+ V_ipport_randomalg_ver = algorithm;
+ break;
+ default:
+ return (EINVAL);
+ }
+ }
+
+ return (error);
+}
+
+/*
+ * Updates V_ipport_randomalg_alg5_tradeoff to provided value
+ * and ensures it is in the supported range (1 - 65536)
+ */
+static int
+sysctl_net_randomalg_alg5_tradeoff_check(SYSCTL_HANDLER_ARGS)
+{
+ u_int tradeoff = *(u_int *)arg1;
+ int error;
+
+#ifdef VIMAGE
+ error = vnet_sysctl_handle_uint(oidp, &tradeoff, 0, req);
+#else
+ error = sysctl_handle_int(oidp, &tradeoff, 0, req);
+#endif
+
+ if (error == 0) {
+ if (tradeoff < 1 || tradeoff > 65536)
+ return (EINVAL);
+ else
+ V_ipport_randomalg_alg5_tradeoff = tradeoff;
+ }
+
+ return (error);
+}
+
SYSCTL_NODE(_net_inet_ip, IPPROTO_IP, portrange, CTLFLAG_RW, 0, "IP Ports");
+SYSCTL_NODE(_net_in
Re: Netgraph/mpd5 stability issues
On Fri, Jan 14, 2011 at 10:05:31AM +0100, Przemyslaw Frasunek wrote:
P> Hello,
P>
P> I'm using mpd 5.5 on three PPPoE routers, each servicing about 300 PPPoE
P> concurrent sessions. Routers are based on Intel SR1630GP hardware platforms
and
P> runs FreeBSD 7.3-RELEASE.
P>
P> I'm experiencing stability issues related to Netgraph. None of above routers
can
P> survive more than 20-30 days of uptime under typical load. There are
different
P> flavors of kernel panics, but all are somehow related to netgraph. Typical
P> backtraces follow:
P>
P> (kgdb) bt
P> #1 0xc0836ac7 in boot (howto=260) at ../../../kern/kern_shutdown.c:418
P> #2 0xc0836d99 in panic (fmt=Variable "fmt" is not available.
P> ) at ../../../kern/kern_shutdown.c:574
P> #3 0xc0b5ef1c in trap_fatal (frame=0xe7ce6820, eva=152)
P> at ../../../i386/i386/trap.c:950
P> #4 0xc0b5f1a0 in trap_pfault (frame=0xe7ce6820, usermode=0, eva=152)
P> at ../../../i386/i386/trap.c:863
P> #5 0xc0b5fb95 in trap (frame=0xe7ce6820) at ../../../i386/i386/trap.c:541
P> #6 0xc0b42e7b in calltrap () at ../../../i386/i386/exception.s:166
P> #7 0xc5f486b9 in ng_name2noderef (here=0xc62a0b80, name=0xe7ce6894 "ng366")
P> at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:896
P> #8 0xc5f488cc in ng_path2noderef (here=0xc62a0b80,
P> address=0xcc4c2110 "ng366:", destp=0xe7ce6ac8, lasthook=0xe7ce6ac4)
P> at
/usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:1673
P> #9 0xc5f48cc0 in ng_address_path (here=0xc62a0b80, item=0xc5e42ae0,
P> address=0xcc4c2110 "ng366:", retaddr=0)
P> at
/usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3488
P> #10 0xc5f431d3 in ngc_send (so=0xc5b53340, flags=0, m=0xd4c6cb00,
P> addr=0xccac9780, control=0x0, td=0xc65a2b40)
P> at /usr/src/sys/modules/netgraph/socket/../../../netgraph/ng_socket.c:288
P> #11 0xc0894bfa in sosend_generic (so=0xc5b53340, addr=0xccac9780,
P> uio=0xe7ce6be8, top=0xd4c6cb00, control=0x0, flags=0, td=0xc65a2b40)
P> at ../../../kern/uipc_socket.c:1243
P> #12 0xc0890a3f in sosend (so=0xc5b53340, addr=0xccac9780, uio=0xe7ce6be8,
P> top=0x0, control=0x0, flags=0, td=0xc65a2b40)
P> at ../../../kern/uipc_socket.c:1285
P> #13 0xc0897fa6 in kern_sendit (td=0xc65a2b40, s=5, mp=0xe7ce6c64, flags=0,
P> control=0x0, segflg=UIO_USERSPACE) at ../../../kern/uipc_syscalls.c:805
P> #14 0xc089b181 in sendit (td=0xc65a2b40, s=5, mp=0xe7ce6c64, flags=0)
P> at ../../../kern/uipc_syscalls.c:742
P> #15 0xc089b298 in sendto (td=0xc65a2b40, uap=0xe7ce6cfc)
P> at ../../../kern/uipc_syscalls.c:857
P> #16 0xc0b5f4f5 in syscall (frame=0xe7ce6d38) at
../../../i386/i386/trap.c:1101
P> #17 0xc0b42ee0 in Xint0x80_syscall () at ../../../i386/i386/exception.s:262
P> #18 0x0033 in ?? ()
P> (kgdb) frame 7
P> #7 0xc5f486b9 in ng_name2noderef (here=0xc62a0b80, name=0xe7ce6894 "ng366")
P> at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:896
P> 896 LIST_FOREACH(node, &ng_name_hash[hash], nd_nodes) {
P> (kgdb) list
P> 891 }
P> 892
P> 893 /* Find node by name */
P> 894 NG_NAMEHASH(name, hash);
P> 895 mtx_lock(&ng_namehash_mtx);
P> 896 LIST_FOREACH(node, &ng_name_hash[hash], nd_nodes) {
P> 897 if (NG_NODE_IS_VALID(node) &&
P> 898 (strcmp(NG_NODE_NAME(node), name) == 0)) {
P> 899 break;
P> 900 }
P> (kgdb) print node
P> $1 = 0x74
P> (kgdb) print ng_name_hash
P> $3 = {{lh_first = 0xcbab6200}, {lh_first = 0x0}, {lh_first = 0xc6538300}, {
P> lh_first = 0xc67e6400}, {lh_first = 0xc6538700}, {lh_first =
0xca2abc00}, {
P> lh_first = 0xc66d5000}, {lh_first = 0xca8f9200}, {lh_first =
0xca815580}, {
P> lh_first = 0xc62a2180}, {lh_first = 0xca2ab180}, {lh_first =
0xc6af7d00}, {
P> lh_first = 0xcbe09a00}, {lh_first = 0xca81b800}, {lh_first =
0xc5b4e980}, {
P> lh_first = 0xcbc1f080}, {lh_first = 0xca2a5480}, {lh_first =
0xc672b580}, {
P> lh_first = 0xcbdb1e80}, {lh_first = 0xcc772c00}, {lh_first =
0xc6a99980}, {
P> lh_first = 0xc629d600}, {lh_first = 0xc6733000}, {lh_first =
0xca967800}, {
P> lh_first = 0xc5b3b780}, {lh_first = 0xc629c280}, {lh_first =
0xc6396980}, {
P> lh_first = 0xc6a5f300}, {lh_first = 0xc5bf2280}, {lh_first =
0xcc5ebe80}, {
P> lh_first = 0xc5e0a400}, {lh_first = 0xc6608100}, {lh_first =
0xc6520e00}, {
P> lh_first = 0xc6642680}, {lh_first = 0xca8f7b80}, {lh_first =
0xcbd9ce80}, {
P> lh_first = 0xca81b380}, {lh_first = 0x0} , {
P> lh_first = 0xc67b8080}, {lh_first = 0xc6455c80}, {lh_first =
0xc652a380}, {
P> lh_first = 0xc6a74780}, {lh_first = 0xc62d8400}, {lh_first =
0xcc154400}, {
P> lh_first = 0xca852b80}, {lh_first = 0xcc351580}, {lh_first =
0xc6396a80}, {
P> lh_first = 0xc66f9580}, {lh_first = 0xc58c8e00}, {lh_first =
0xcc01a000}, {
P> lh_first = 0xc6614e80}, {lh
Re: Netgraph/mpd5 stability issues
> In this dump, can we seek for where did 0x74 came from? Can you look at
> ng_name_hash[hash]?
(kgdb) print hash
No symbol "hash" in current context.
(kgdb) info all
eax0xff9a -102
ecx0xe7ce6895 -405903211
edx0xff9a -102
ebx0x74 116
esp0xcc28c380 0xcc28c380
ebp0xe7ce6878 0xe7ce6878
esi0xe7ce6894 -405903212
edi0xe7ce6ac8 -405902648
[...]
(kgdb) print ng_name_hash[116]
$4 = {lh_first = 0xcbd6fb00}
(kgdb) print *ng_name_hash[116].lh_first
$5 = {nd_name = "ng357", '\0' , nd_type = 0xc61871a0,
nd_flags = 0, nd_refs = 1, nd_numhooks = 0, nd_private = 0xcc3b5e80,
nd_ID = 454681, nd_hooks = {lh_first = 0x0}, nd_nodes = {
le_next = 0xcbbf7900, le_prev = 0xc5f4fad0}, nd_idnodes = {
le_next = 0xcc061680, le_prev = 0xc5f4f744}, nd_work = {tqe_next = 0x0,
tqe_prev = 0x0}, nd_input_queue = {q_flags = 0, q_mtx = {lock_object = {
lo_name = 0xc5f4e986 "ng_node", lo_type = 0xc5f4e986 "ng_node",
lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0},
lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, queue = 0x0,
last = 0xcbd6fb70, q_node = 0xcbd6fb00}}
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Netgraph/mpd5 stability issues
On Mon, Jan 31, 2011 at 02:40:55PM +0100, Przemyslaw Frasunek wrote:
P> > In this dump, can we seek for where did 0x74 came from? Can you look at
P> > ng_name_hash[hash]?
P>
P> (kgdb) print hash
P> No symbol "hash" in current context.
P> (kgdb) info all
P> eax0xff9a -102
P> ecx0xe7ce6895 -405903211
P> edx0xff9a -102
P> ebx0x74 116
P> esp0xcc28c380 0xcc28c380
P> ebp0xe7ce6878 0xe7ce6878
P> esi0xe7ce6894 -405903212
P> edi0xe7ce6ac8 -405902648
P> [...]
P> (kgdb) print ng_name_hash[116]
P> $4 = {lh_first = 0xcbd6fb00}
P> (kgdb) print *ng_name_hash[116].lh_first
P> $5 = {nd_name = "ng357", '\0' , nd_type = 0xc61871a0,
P> nd_flags = 0, nd_refs = 1, nd_numhooks = 0, nd_private = 0xcc3b5e80,
P> nd_ID = 454681, nd_hooks = {lh_first = 0x0}, nd_nodes = {
P> le_next = 0xcbbf7900, le_prev = 0xc5f4fad0}, nd_idnodes = {
P> le_next = 0xcc061680, le_prev = 0xc5f4f744}, nd_work = {tqe_next = 0x0,
P> tqe_prev = 0x0}, nd_input_queue = {q_flags = 0, q_mtx = {lock_object = {
P> lo_name = 0xc5f4e986 "ng_node", lo_type = 0xc5f4e986 "ng_node",
P> lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0},
P> lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, queue = 0x0,
P> last = 0xcbd6fb70, q_node = 0xcbd6fb00}}
Thanks. Yep, "ng357" also has hash of 116.
Can we look at ng_name_hash[116].lh_first->nd_nodes.le_next and further? Which
one does point to 0x74?
--
Totus tuus, Glebius.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
bwn(4) support for BCM4322 (MacBook WiFi)
I might be fighting a losing battle, but any advice on getting the Broadcom BCM4322 802.11a/b/g/n working? This chip is found in Apple's MacBook and probably elsewhere. I'm currently running amd64 8.2-RC2. As best as I can see, HEAD has nothing that RELENG_8_2 doesn't have, as far as bwn(4) is concerned. As per the bwn(4) man page, I installed the net/bwn-firmware-kmod port. The firmware failed to load, giving a "firmware table full" error. Seems that others had this issue. Bumping the firmware table size FIRMWARE_MAX in sys/kern/subr_firmware.c was the suggested workaround; both modules provided by the port - bwn_v4_lp_ucode.ko and bwn_v4_ucode.ko - now load without error. Loading if_bwn.ko yeilds the following on console: siba_bwn0: mem 0x9310-0x93103fff irq 18 at device 0.0 on pci3 siba_bwn0: warn: multiple PCI(E) cores siba_bwn0: unsupported coreid (USB 2.0 Device) siba_bwn0: unsupported coreid (unknown) siba_bwn0: unsupported coreid (Internal Memory) siba_bwn0: unknown chipid 0x4322 for PLL & PMU init bwn0 on siba_bwn0 bwn0: unsupported PHY type (4) device_attach: bwn0 attach returned 6 siba_bwn0 appears in devinfo(8) output but bwn(4) is nowhere to be found. Any suggestions on how to get the card working? Regards, Fraser pgppBiuGrZoap.pgp Description: PGP signature
Re: bwn(4) support for BCM4322 (MacBook WiFi)
On Monday, January 31, 2011 14:14:01 Fraser Tweedale wrote: > I might be fighting a losing battle, but any advice on getting the > Broadcom BCM4322 802.11a/b/g/n working? This chip is found in > Apple's MacBook and probably elsewhere. > > I'm currently running amd64 8.2-RC2. As best as I can see, HEAD has > nothing that RELENG_8_2 doesn't have, as far as bwn(4) is concerned. > > As per the bwn(4) man page, I installed the net/bwn-firmware-kmod > port. The firmware failed to load, giving a "firmware table full" > error. Seems that others had this issue. Bumping the firmware > table size FIRMWARE_MAX in sys/kern/subr_firmware.c was the > suggested workaround; both modules provided by the port - > bwn_v4_lp_ucode.ko and bwn_v4_ucode.ko - now load without error. > > Loading if_bwn.ko yeilds the following on console: > > siba_bwn0: mem 0x9310-0x93103fff irq 18 at device 0.0 > on pci3 siba_bwn0: warn: multiple PCI(E) cores > siba_bwn0: unsupported coreid (USB 2.0 Device) > siba_bwn0: unsupported coreid (unknown) > siba_bwn0: unsupported coreid (Internal Memory) > siba_bwn0: unknown chipid 0x4322 for PLL & PMU init > bwn0 on siba_bwn0 > bwn0: unsupported PHY type (4) > device_attach: bwn0 attach returned 6 > > siba_bwn0 appears in devinfo(8) output but bwn(4) is nowhere to be > found. > > Any suggestions on how to get the card working? I guess you're out of luck here. Neither bwn(4) nor bwi(4) support the bcm4322 variant afaik (Please correct me if I'm wrong..). The only option left is ndis(4). -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Netgraph/mpd5 stability issues
> (kgdb) print *ng_name_hash[116].lh_first
It looks like this one is corrupted:
(kgdb) print
*ng_name_hash[116].lh_first.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next
$19 = {nd_name = "ng258", '\0' , nd_type = 0xc61871a0,
nd_flags = 0, nd_refs = 1, nd_numhooks = 0, nd_private = 0xccabdbc0,
nd_ID = 454433, nd_hooks = {lh_first = 0x0}, nd_nodes = {
le_next = 0xcc28c380, le_prev = 0xcbadadbc}, nd_idnodes = {
le_next = 0xcc410400, le_prev = 0xc5f4f764}, nd_work = {tqe_next = 0x0,
tqe_prev = 0x0}, nd_input_queue = {q_flags = 0, q_mtx = {lock_object = {
lo_name = 0xc5f4e986 "ng_node", lo_type = 0xc5f4e986 "ng_node",
lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0},
lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, queue = 0x0,
last = 0xc69e16f0, q_node = 0xc69e1680}}
nd_nodes->le_prev is 0xcbadadbc
(kgdb) print
*ng_name_hash[116].lh_first.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next
$20 = {
nd_name = "\b\000\000\000
\000\000\000\005\000\000\000\000\000\000\000\220_q\001\036QĆCcmd5\000\000\000",
nd_type = 0x0, nd_flags = 0, nd_refs = 0,
nd_numhooks = 0, nd_private = 0x0, nd_ID = 0, nd_hooks = {
lh_first = 0x68676972}, nd_nodes = {le_next = 0x74, le_prev = 0x0},
nd_idnodes = {le_next = 0x0, le_prev = 0x0}, nd_work = {tqe_next = 0x0,
tqe_prev = 0x0}, nd_input_queue = {q_flags = 0, q_mtx = {lock_object = {
lo_name = 0x0, lo_type = 0x0, lo_flags = 1, lo_witness_data = {
lod_list = {stqe_next = 0x6}, lod_witness = 0x6}}, mtx_lock = 0,
mtx_recurse = 0}, queue = 0x0, last = 0xcc28c3f0, q_node = 0xcc28c380}}
(kgdb) print
*ng_name_hash[116].lh_first.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next
Cannot access memory at address 0x74
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Netgraph/mpd5 stability issues
> And in this one, can you please show *hook->hk_peer ?
(kgdb) print *hook->hk_peer
$2 = {
hk_name = "\b\000\000\000
\000\000\000\004\000\000\000\001\000\000\000ŐRí\003\003ö\0248cmd4\000\000\000",
hk_private = 0x0, hk_flags = 0, hk_refs = 0,
hk_type = 0, hk_peer = 0x0, hk_node = 0x0, hk_hooks = {le_next = 0x566226,
le_prev = 0x99e79c03}, hk_rcvmsg = 0x38ef45, hk_rcvdata = 0x28d6a8a1}
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Problem with re0
On Monday 31 January 2011 03:07:02 Pyun YongHyeon wrote: > On Sun, Jan 30, 2011 at 05:15:10PM -0800, Pyun YongHyeon wrote: > > On Sun, Jan 30, 2011 at 02:53:15PM +0100, Milan Obuch wrote: > > > On Sunday 30 January 2011 07:40:48 Zeus V Panchenko wrote: > > > > another detail for this nic > > > > > > > > dmidecode > > > > Base Board Information > > > > > > > > Manufacturer: ASUSTeK Computer INC. > > > > Product Name: AT5NM10-I > > > > Version: Rev x.0x > > > > Serial Number: MT7006K15200322 > > > > > > I did not followed this thread closely, but I checked my new board and > > > it is the same. > > > > > > > uname -a > > > > FreeBSD 8.2-PRERELEASE amd64 > > > > > > > > system was cvsup-ed 2011.01.20 > > > > > > > > if_re.c,v 1.160.2.17 2011/01/15 00:32:15 yongari > > > > > > > > dmesg > > > > rgephy0: PHY 1 on miibus0 > > > > rgephy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > > > > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > > > > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > > > > 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: > > > > 20:cf:30:89:5e:95 > > > > re0: [FILTER] > > > > > > > > pciconf -lv > > > > re0@pci0:2:0:0: class=0x02 card=0x83a31043 chip=0x816810ec > > > > rev=0x03 hdr=0x00 vendor = 'Realtek Semiconductor' > > > > > > > > device = 'Gigabit Ethernet NIC(NDIS 6.0) > > > > (RTL8168/8111/8111c)' class = network > > > > subclass = ethernet > > > > > > All details are the same for my board (modulo serial number and MAC, of > > > course), and in my case it works with no problem, but only in 100 Mb > > > switch port. In 1 Gb port I have no link. I must verify my cables, > > > port on switch itself works just fine with another 1 Gb (intel) card. > > > > Would you try a patch at the following URL? > > http://people.freebsd.org/~yongari/re/rgephy.link.patch3 > > Previous one had a bug, please use updated one. > http://people.freebsd.org/~yongari/re/rgephy.link.patch4 > > > > > while connected directly NIC <-> NIC they flaps too > > > > > > I will try this against another 1 Gb card too, just to see what > > > happens... in 100 Mb mode it works just fine, as I mentioned already - > > > running flood ping with 1472 bytes packets for more than an hour I see > > > only four responses missing in more than 21 millions tries... > > > > > > Regards, > > > Milan > I checked my cables and one of them had bad pairing. Worked in 100 Mb mode, but not in 1 Gb mode. After I replaced it I check with flood ping, 1472 bytes packets again and no sign of problem here - one reply missing in almost 21 millions tries. How are your flaps 'visible'? What fails? Ping test is simple, so I could overlooked something, but now it works for in 1 Gb mode, too... Regards, Milan ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Problem with re0
Milan Obuch (freebsd-...@dino.sk) [11.01.31 17:31] wrote: > > I checked my cables and one of them had bad pairing. Worked in 100 Mb mode, > but not in 1 Gb mode. After I replaced it I check with flood ping, 1472 bytes > packets again and no sign of problem here - one reply missing in almost 21 > millions tries. How are your flaps 'visible'? What fails? Ping test is > simple, > so I could overlooked something, but now it works for in 1 Gb mode, too... > while NIC flaps i see switch port on/off and in dmesg: ... re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP ... -- Zeus V. Panchenko IT Dpt., IBS ltdGMT+2 (EET) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: panic: bufwrite: buffer is not busy???
On 1/31/11 4:32 AM, Bjoern A. Zeeb wrote:
On Mon, 31 Jan 2011, Eugene Grosbein wrote:
On 31.01.2011 14:20, Julian Elischer wrote:
# gdb kernel
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License,
and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty"
for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) l *0x803c1315
0x803c1315 is in ng_address_hook
(/home/src/sys/netgraph/ng_base.c:3504).
3499 * Quick sanity check..
3500 * Since a hook holds a reference on it's node,
once we know
3501 * that the peer is still connected (even if
invalid,) we know
3502 * that the peer node is present, though maybe
invalid.
3503 */
3504if ((hook == NULL) ||
3505NG_HOOK_NOT_VALID(hook) ||
3506NG_HOOK_NOT_VALID(peer = NG_HOOK_PEER(hook)) ||
3507NG_NODE_NOT_VALID(peernode =
NG_PEER_NODE(hook))) {
3508NG_FREE_ITEM(item);
replace with:
which is essentially what I had suggested in the formerly mentioned PR
already (just remove the first printf macro).
3504if ((hook == NULL) ||
3505NG_HOOK_NOT_VALID(hook) ||
((peer = NG_HOOK_PEER(hook)) == NULL) ||
3506NG_HOOK_NOT_VALID(peer) ||
((peernode = NG_PEER_NODE(hook)) == NULL) ||
3507NG_NODE_NOT_VALID(peernode)) {
if (peer)
kassert((peernode != NULL), ("peer
node NULL wile peer hook exists"));
3508NG_FREE_ITEM(item);
The problem is that it will not help to fix the race; if you go
up in the same file you'll find another similar one of these checks
with a scary rev 1.1. (I think) comment (that you, Julian, should know
very well;-)
The solution that this needs is: proper locking.
It does not compile:
/home/src/sys/netgraph/ng_base.c: In function 'ng_address_hook':
/home/src/sys/netgraph/ng_base.c:3511: warning: implicit
declaration of function 'kassert'
/home/src/sys/netgraph/ng_base.c:3511: warning: nested extern
declaration of 'kassert'
yeah KASSERT is upper case.
slaps head... kassert is at work
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
1 error
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Netgraph/mpd5 stability issues
On 1/31/11 7:13 AM, Przemyslaw Frasunek wrote:
And in this one, can you please show *hook->hk_peer ?
(kgdb) print *hook->hk_peer
$2 = {
hk_name = "\b\000\000\000
\000\000\000\004\000\000\000\001\000\000\000ŐRí\003\003ö\0248cmd4\000\000\000",
hk_private = 0x0, hk_flags = 0, hk_refs = 0,
hk_type = 0, hk_peer = 0x0, hk_node = 0x0, hk_hooks = {le_next = 0x566226,
le_prev = 0x99e79c03}, hk_rcvmsg = 0x38ef45, hk_rcvdata = 0x28d6a8a1}
that's not supposed to be able to happen.
It's supposed to point to SOMETHING, even if it's the "dead" hook.
does the dead hook point to itself? itprobably should if it doesn't.
(and it should have a name of 'dead' if it doesn't already).
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Netgraph/mpd5 stability issues
On 1/31/11 8:58 AM, Julian Elischer wrote:
On 1/31/11 7:13 AM, Przemyslaw Frasunek wrote:
And in this one, can you please show *hook->hk_peer ?
(kgdb) print *hook->hk_peer
$2 = {
hk_name = "\b\000\000\000
\000\000\000\004\000\000\000\001\000\000\000ŐRí\003\003ö\0248cmd4\000\000\000",
hk_private = 0x0, hk_flags = 0, hk_refs = 0,
hk_type = 0, hk_peer = 0x0, hk_node = 0x0, hk_hooks = {le_next =
0x566226,
le_prev = 0x99e79c03}, hk_rcvmsg = 0x38ef45, hk_rcvdata =
0x28d6a8a1}
that's not supposed to be able to happen.
It's supposed to point to SOMETHING, even if it's the "dead" hook.
does the dead hook point to itself? itprobably should if it doesn't.
(and it should have a name of 'dead' if it doesn't already).
Replying to self.. all these things are in fact true, (just looked at
source) so this is not a pointer
to the dead node. So, how do we get a NULL peer?
unless the hook is destroyed by another thread while we are accessing it,
but I think from memory that that should set it to 'dead' not NULL.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Netgraph/mpd5 stability issues
On 1/31/2011 12:10 PM, Julian Elischer wrote:
> On 1/31/11 8:58 AM, Julian Elischer wrote:
>> On 1/31/11 7:13 AM, Przemyslaw Frasunek wrote:
And in this one, can you please show *hook->hk_peer ?
>>> (kgdb) print *hook->hk_peer
>>> $2 = {
>>>hk_name = "\b\000\000\000
>>> \000\000\000\004\000\000\000\001\000\000\000ŐRí\003\003ö\0248cmd4\000\000\000",
>>>
>>> hk_private = 0x0, hk_flags = 0, hk_refs = 0,
>>>hk_type = 0, hk_peer = 0x0, hk_node = 0x0, hk_hooks = {le_next =
>>> 0x566226,
>>> le_prev = 0x99e79c03}, hk_rcvmsg = 0x38ef45, hk_rcvdata =
>>> 0x28d6a8a1}
>>
>> that's not supposed to be able to happen.
>> It's supposed to point to SOMETHING, even if it's the "dead" hook.
>> does the dead hook point to itself? itprobably should if it doesn't.
>> (and it should have a name of 'dead' if it doesn't already).
>
> Replying to self.. all these things are in fact true, (just looked at
> source) so this is not a pointer
> to the dead node. So, how do we get a NULL peer?
> unless the hook is destroyed by another thread while we are accessing it,
> but I think from memory that that should set it to 'dead' not NULL.
If there is extra debugging code you would like me to add, it does not
take too long for this to happen on my one LNS... 4-5 days.
---Mike
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: panic: bufwrite: buffer is not busy???
On Monday, January 31, 2011 1:31:54 am Eugene Grosbein wrote:
> On 15.01.2011 01:37, John Baldwin wrote:
> > On Friday, January 14, 2011 1:44:19 pm Eugene Grosbein wrote:
> >> On 14.01.2011 18:46, Mike Tancsa wrote:
> >>
> I'm using mpd 5.5 on three PPPoE routers, each servicing about 300
PPPoE
> concurrent sessions. Routers are based on Intel SR1630GP hardware
platforms and
> runs FreeBSD 7.3-RELEASE.
>
> I'm experiencing stability issues related to Netgraph. None of above
routers can
> survive more than 20-30 days of uptime under typical load. There are
different
> flavors of kernel panics, but all are somehow related to netgraph.
Typical
> backtraces follow
> >>>
> >>> I also have stability issues on RELENG_8.
> >>>
> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=153497
> >>
> >> And for one of my servers (8.2-PRERELEASE/amd64 with 4GB RAM) I just
cannot obtain crashdump,
> >> it cannot finish to write it. For example, it happened an hour ago:
> >>
> >> Fatal trap 12: page fault while in kernel mode
> >> cpuid = 2; apic id = 04
> >> fault virtual address = 0x20040
> >> fault code = supervisor read data, page not present
> >> instruction pointer = 0x20:0x803cc979
> >
> > Assuming your kernel is built with debug symbols (which is the default),
one
> > thing you can do to aid in debugging is this:
> >
> > gdb /boot/kernel/kernel
> > (gdb) l *0x803cc979
> >
> > Where the 0xfff bit is the part of the 'instruction pointer' value
> > above after the colon (:) and then send the output of that in your e-mail
to
> > the list. This allows us to the source line at which the fault occurred.
> >
>
> Yesterday I've got another kernel panic of this kind with RELENG_8 updated
20 January
> and it still could not finish writing of crashdump:
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 02
> fault virtual address = 0x20030
> fault code = supervisor read data, page not present
> instruction pointer = 0x20:0x803c1315
> stack pointer = 0x28:0xff8000130780
> frame pointer = 0x28:0xff80001307a0
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 12 (irq259: em1:rx 0)
> trap number = 12
> panic: page fault
> cpuid = 1
> Uptime: 19h41m8s
> Dumping 4087 MB (3 chunks)
> chunk 0: 1MB (150 pages) ... ok
> chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not
busy???
> cpuid = 1
> Uptime: 19h41m9s
> Automatic reboot in 15 seconds - press a key on the console to abort
>
> This time I have all debug symbols handy:
>
>
> # gdb kernel
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> (gdb) l *0x803c1315
> 0x803c1315 is in ng_address_hook
(/home/src/sys/netgraph/ng_base.c:3504).
> 3499 * Quick sanity check..
> 3500 * Since a hook holds a reference on it's node, once we know
> 3501 * that the peer is still connected (even if invalid,) we
know
> 3502 * that the peer node is present, though maybe invalid.
> 3503 */
> 3504if ((hook == NULL) ||
> 3505NG_HOOK_NOT_VALID(hook) ||
> 3506NG_HOOK_NOT_VALID(peer = NG_HOOK_PEER(hook)) ||
> 3507NG_NODE_NOT_VALID(peernode = NG_PEER_NODE(hook))) {
> 3508NG_FREE_ITEM(item);
Hmmm. I think you might have a hardware problem. Notice the fault address,
it is 0x20030. Can you do 'x/i '? I suspect it is
doing a memory access from that has a constant offset of 0x30, in which case
the original pointer was 0x2, meaning it would be NULL except it has a
single-bit error. That would likely be caused by a hardware issue such as
failing RAM, etc.
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Bogus KASSERT() in tcp_output()?
Somewhat related fallout to the bug reported on security@ recently, I think
this KASSERT() in tcp_output() is bogus:
KASSERT(len + hdrlen + ipoptlen == m_length(m, NULL),
("%s: mbuf chain shorter than expected", __func__));
Specifically, just a few lines earlier in tcp_output() we set the packet
header length to just 'len + hdrlen':
/*
* Put TCP length in extended header, and then
* checksum extended header and data.
*/
m->m_pkthdr.len = hdrlen + len; /* in6_cksum() need this */
Also, the ipoptions are stored in a separate mbuf chain in the in pcb
(inp_options) that is passed as a separate argument to ip_output(). Given
that, I would think that m_length() should not reflect ipoptlen since it
should not include IP options in that chain?
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Problem with re0
On Mon, Jan 31, 2011 at 02:15:09PM +0200, Zeus V Panchenko wrote: > Pyun YongHyeon (pyu...@gmail.com) [11.01.31 04:08] wrote: > > > The RTL8168/8111D sample board I have does not show this kind of > > > issue. This happens only when established link is 1000baseT, right? > > > I slightly changed PHY's link detection code so would you try that > > > patch at the following URL? > > > http://people.freebsd.org/~yongari/re/rgephy.link.patch3 > > > > Previous one had a bug, please update one. > > http://people.freebsd.org/~yongari/re/rgephy.link.patch4 > > no change :( > interface continues to flap > Then I have no idea. Does other OS work with your hardware without issues? As last resort, could you try vendor's FreeBSD driver? The vendor's driver applies a bunch of magic DSP fixups which re(4) does not have. I don't know whether it makes difference or not but it would be worth a try. Note, vendor's driver treat your controller as old 8139 such that it disables all offload features and does not work on non-x86 architectures. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/123429: [nfe] [hang] "ifconfig nfe up" causes a hard system lockup in 7.0-RELEASE and 7.0-STABLE-042008
Synopsis: [nfe] [hang] "ifconfig nfe up" causes a hard system lockup in 7.0-RELEASE and 7.0-STABLE-042008 State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Jan 31 21:38:47 UTC 2011 State-Changed-Why: Is it still issue on more recent FreeBSD release? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Jan 31 21:38:47 UTC 2011 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=123429 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free panic
The following reply was made to PR kern/153938; it has been noted by GNATS. From: PseudoCylon To: Juergen Lock Cc: bug-follo...@freebsd.org, Juergen Lock Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free panic Date: Mon, 31 Jan 2011 15:28:25 -0800 (PST) - Original Message > From: Juergen Lock > To: PseudoCylon > Cc: bug-follo...@freebsd.org; Juergen Lock > Sent: Sun, January 30, 2011 2:50:42 PM > Subject: Re: kern/153938: [run] [panic] [patch] Workaround for > use-after-free >panic > > On Sat, Jan 22, 2011 at 11:35:14PM -0800, PseudoCylon wrote: > > > Anyway, I have been testing this version for maybe a week now and it > seems to work at least no worse than the previous one, minus the > deadlock. :) So it probably can go in. > > Thanx! > Juergen > Thanks for testing. I'll submit the patch. AK ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bogus KASSERT() in tcp_output()?
On 02/01/11 04:17, John Baldwin wrote:
> Somewhat related fallout to the bug reported on security@ recently, I think
> this KASSERT() in tcp_output() is bogus:
>
>
> KASSERT(len + hdrlen + ipoptlen == m_length(m, NULL),
> ("%s: mbuf chain shorter than expected", __func__));
>
> Specifically, just a few lines earlier in tcp_output() we set the packet
> header length to just 'len + hdrlen':
>
> /*
>* Put TCP length in extended header, and then
>* checksum extended header and data.
>*/
> m->m_pkthdr.len = hdrlen + len; /* in6_cksum() need this */
>
> Also, the ipoptions are stored in a separate mbuf chain in the in pcb
> (inp_options) that is passed as a separate argument to ip_output(). Given
> that, I would think that m_length() should not reflect ipoptlen since it
> should not include IP options in that chain?
>
There is some relevant prior discussion on src-committers@ for r212803
between Andre and Bjoern.
Cheers,
Lawrence
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bogus KASSERT() in tcp_output()?
On Tue, 1 Feb 2011, Lawrence Stewart wrote:
On 02/01/11 04:17, John Baldwin wrote:
Somewhat related fallout to the bug reported on security@ recently, I think
this KASSERT() in tcp_output() is bogus:
KASSERT(len + hdrlen + ipoptlen == m_length(m, NULL),
("%s: mbuf chain shorter than expected", __func__));
Specifically, just a few lines earlier in tcp_output() we set the packet
header length to just 'len + hdrlen':
/*
* Put TCP length in extended header, and then
* checksum extended header and data.
*/
m->m_pkthdr.len = hdrlen + len; /* in6_cksum() need this */
Also, the ipoptions are stored in a separate mbuf chain in the in pcb
(inp_options) that is passed as a separate argument to ip_output(). Given
that, I would think that m_length() should not reflect ipoptlen since it
should not include IP options in that chain?
There is some relevant prior discussion on src-committers@ for r212803
between Andre and Bjoern.
Yeah and I still have the temporary workaround from
http://p4web.freebsd.org/@@185095?ac=10
I think you are specifically refering to
http://lists.freebsd.org/pipermail/svn-src-head/2010-October/021814.html
I had been pinging people back then, but I am happy to see the
discussion about these TCP changes finally happing now. I'll have to
swap thing back in completly - it's been more than three months. Let
me see later today.
/bz
--
Bjoern A. Zeeb You have to have visions!
Going to jail sucks -- All my daemons like it!
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: panic: bufwrite: buffer is not busy???
On 31.01.2011 22:46, John Baldwin wrote:
>># gdb kernel
>> GNU gdb 6.1.1 [FreeBSD]
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain
> conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB. Type "show warranty" for details.
>> This GDB was configured as "amd64-marcel-freebsd"...
>> (gdb) l *0x803c1315
>> 0x803c1315 is in ng_address_hook
> (/home/src/sys/netgraph/ng_base.c:3504).
>> 3499 * Quick sanity check..
>> 3500 * Since a hook holds a reference on it's node, once we know
>> 3501 * that the peer is still connected (even if invalid,) we
> know
>> 3502 * that the peer node is present, though maybe invalid.
>> 3503 */
>> 3504if ((hook == NULL) ||
>> 3505NG_HOOK_NOT_VALID(hook) ||
>> 3506NG_HOOK_NOT_VALID(peer = NG_HOOK_PEER(hook)) ||
>> 3507NG_NODE_NOT_VALID(peernode = NG_PEER_NODE(hook))) {
>> 3508NG_FREE_ITEM(item);
>
> Hmmm. I think you might have a hardware problem. Notice the fault address,
> it is 0x20030. Can you do 'x/i '?
(gdb) x/i 0x803c1315
0x803c1315 :testb $0x1,0x28(%rdx)
(gdb) x/i *0x803c1315
0x12842f6: Cannot access memory at address 0x12842f6
> I suspect it is
> doing a memory access from that has a constant offset of 0x30, in which case
> the original pointer was 0x2, meaning it would be NULL except it has
> a
> single-bit error. That would likely be caused by a hardware issue such as
> failing RAM, etc.
This is SuperMicro server with ECC RAM. I've already tested it with memtest86+
during long time, no memory problems found.
Eugene Grosbein
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
why use INP_WLOCK instead of INP_RLOCK
Hi All, I am not sure if anybody has asked it before. I could not find answer by doing rough search on Internet, if it is duplicate question, sorry in advance. My question is that, for getting socket options in tcp_ctloutput() in tcp_usrreq.c, why do we need to do lock with INP_WLOCK(inp) as setting socket options does. Why do we just use INP_RLOCK(inp), as it looks not changing anything in tcp control block? Thank you for your kindly answer. Jim ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
taps in rc.config
i want to run a whole bunch of dynamips virtualized ciscos inside a fbsd 8.x server. i want the virtual routers to have some interfaces which are externally visible. so i think i do something like ifconfig tap0 147.28.224.41/30 ifconfig tap1 147.28.224.45/30 ifconfig tap2 147.28.224.49/30 ifconfig tap3 147.28.224.53/30 ifconfig tap4 147.28.224.57/30 ifconfig tap5 147.28.224.61/30 ifconfig tap6 147.28.224.65/30 ifconfig tap7 147.28.224.69/30 ifconfig tap8 147.28.224.73/30 ifconfig tap9 147.28.224.77/30 and then bridge them on to the external ether. but i am a bit confuddled. can someone tell me how to do from command line, and then also how to code in /etc/rc.conf? thanks. randy clueless in tokyo ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: taps in rc.config
> 1/ wow does that (dynamips ciscos) actually run on BSD? yep > 2/ "why?" so we can have a routing research topology testbed of real cisco and real juniper code. > first you need to create them right? > ifconfig tap0 create 192.168.3.1/28 up > > I think you do: > in rc.conf: > cloned_interfaces="tap0 tap1 tap2 tap3" > ifconfig_tap0=192.168.3.1/28 > ifconfig_tap1=192.168.4.1/28 > ifconfig_tap2=192.168.5.1/28 > ifconfig_tap3=192.168.6.1/28 > > but I may not be remembering right. thanks. and what binds them to a particular ether so they respond to arp? randy ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: taps in rc.config
On 1/31/11 11:10 PM, Randy Bush wrote: i want to run a whole bunch of dynamips virtualized ciscos inside a fbsd 8.x server. i want the virtual routers to have some interfaces which are externally visible. so i think i do something like ifconfig tap0 147.28.224.41/30 ifconfig tap1 147.28.224.45/30 ifconfig tap2 147.28.224.49/30 ifconfig tap3 147.28.224.53/30 ifconfig tap4 147.28.224.57/30 ifconfig tap5 147.28.224.61/30 ifconfig tap6 147.28.224.65/30 ifconfig tap7 147.28.224.69/30 ifconfig tap8 147.28.224.73/30 ifconfig tap9 147.28.224.77/30 and then bridge them on to the external ether. but i am a bit confuddled. can someone tell me how to do from command line, and then also how to code in /etc/rc.conf? 1/ wow does that (dynamips ciscos) actually run on BSD? 2/ "why?" first you need to create them right? ifconfig tap0 create 192.168.3.1/28 up I think you do: in rc.conf: cloned_interfaces="tap0 tap1 tap2 tap3" ifconfig_tap0=192.168.3.1/28 ifconfig_tap1=192.168.4.1/28 ifconfig_tap2=192.168.5.1/28 ifconfig_tap3=192.168.6.1/28 but I may not be remembering right. if you just need the functionality and not specifically the ciscos, use vimage based routers. thanks. randy clueless in tokyo ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
