Re: panic: bufwrite: buffer is not busy???
On 02.02.2011 00:50, Gleb Smirnoff wrote:
>
> This looks like ng_pppoe_disconnect() was called with NULL argument.
>
> Can you add KDB_TRACE option to kernel? Your boxes for some reason can't
> dump core, but with this option we will have at least trace.
>
Same box, new panic today with new trace.
Still no crashdump because of second panic while dumping core.
It seems the source of the problem is still somewhere in NETGRAPH.
This time it looks as garbage and not NULL...
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 04
fault virtual address = 0x34646dc7
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x803d3e20
stack pointer = 0x28:0xff8fc8d0
frame pointer = 0x28:0xff8fc910
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 (irq256: em0:rx 0)
trap number = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
X_db_sym_numargs() at 0x801a227a = X_db_sym_numargs+0x15a
kdb_backtrace() at 0x8033d547 = kdb_backtrace+0x37
panic() at 0x8030b567 = panic+0x187
dblfault_handler() at 0x804c0ca0 = dblfault_handler+0x330
dblfault_handler() at 0x804c107f = dblfault_handler+0x70f
trap() at 0x804c155f = trap+0x3df
calltrap() at 0x804a8de4 = calltrap+0x8
--- trap 0xc, rip = 0x803d3e20, rsp = 0xff8fc8d0, rbp =
0xff8fc910 ---
ng_address_hook() at 0x803d3e20 = ng_address_hook+0x190
ng_rmnode_self() at 0x803daf65 = ng_rmnode_self+0x1c95
ng_rmnode_self() at 0x803db43d = ng_rmnode_self+0x216d
ip_fastforward() at 0x80406356 = ip_fastforward+0x7e6
ether_demux() at 0x803c1841 = ether_demux+0x131
ether_vlanencap() at 0x803c1c2d = ether_vlanencap+0x27d
ata_sii_chipinit() at 0x801e725a = ata_sii_chipinit+0xe50a
ata_sii_chipinit() at 0x801e75d4 = ata_sii_chipinit+0xe884
intr_event_execute_handlers() at 0x802e4c44 =
intr_event_execute_handlers+0x104
swi_add() at 0x802e62f5 = swi_add+0x285
fork_exit() at 0x802e26d8 = fork_exit+0x118
fork_trampoline() at 0x804a92ae = fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff8fccf0, rbp = 0 ---
Uptime: 4d1h33m30s
Dumping 4087 MB (3 chunks)
chunk 0: 1MB (150 pages) ... ok
chunk 1: 3575MB (915088 pages)Sleeping thread (tid 100034, pid 12) owns a
non-sleepable lock
sched_switch() at 0x80330819 = sched_switch+0xf9
mi_switch() at 0x80313ac6 = mi_switch+0x176
sleepq_timedwait() at 0x803478a2 = sleepq_timedwait+0x42
_sleep() at 0x80314041 = _sleep+0x301
ucom_attach() at 0x8029756b = ucom_attach+0x129b
ucom_attach() at 0x802976a4 = ucom_attach+0x13d4
ucom_attach() at 0x8029772b = ucom_attach+0x145b
iicbus_release_bus() at 0x80230b88 = iicbus_release_bus+0x16f8
sc_puts() at 0x80263bec = sc_puts+0x24c
sc_attach_unit() at 0x8026698c = sc_attach_unit+0x56c
cncheckc() at 0x802cbd55 = cncheckc+0x65
dumpsys() at 0x804f2865 = dumpsys+0x4d5
isa_nmi() at 0x804f228c = isa_nmi+0x76c
dumpsys() at 0x804f2623 = dumpsys+0x293
kproc_shutdown() at 0x8030ac39 = kproc_shutdown+0x1d9
kproc_shutdown() at 0x8030b120 = kproc_shutdown+0x6c0
panic() at 0x8030b551 = panic+0x171
dblfault_handler() at 0x804c0ca0 = dblfault_handler+0x330
dblfault_handler() at 0x804c107f = dblfault_handler+0x70f
trap() at 0x804c155f = trap+0x3df
calltrap() at 0x804a8de4 = calltrap+0x8
--- trap 0xc, rip = 0x803d3e20, rsp = 0xff8fc8d0, rbp =
0xff8fc910 ---
ng_address_hook() at 0x803d3e20 = ng_address_hook+0x190
ng_rmnode_self() at 0x803daf65 = ng_rmnode_self+0x1c95
ng_rmnode_self() at 0x803db43d = ng_rmnode_self+0x216d
ip_fastforward() at 0x80406356 = ip_fastforward+0x7e6
ether_demux() at 0x803c1841 = ether_demux+0x131
ether_vlanencap() at 0x803c1c2d = ether_vlanencap+0x27d
ata_sii_chipinit() at 0x801e725a = ata_sii_chipinit+0xe50a
ata_sii_chipinit() at 0x801e75d4 = ata_sii_chipinit+0xe884
intr_event_execute_handlers() at 0x802e4c44 =
intr_event_execute_handlers+0x104
swi_add() at 0x802e62f5 = swi_add+0x285
fork_exit() at 0x802e26d8 = fork_exit+0x118
fork_trampoline() at 0x804a92ae = fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff8fccf0, rbp = 0 ---
panic: sleeping thread
cpuid = 2
(gdb) l *0x803d3e20
0x803d3e20 is in ng_address_hook (netgraph.h:191).
186 int line);
187
188 static __inline void
189 _chkhook(hook_p hook, char *file, int line)
190 {
191 if (hook->hk_magic != HK_MAGIC) {
192
option RADIX_MPATH, RT_LINK_IS_UP() and interface routes.
Hello, A quick glance through sys/netinet/ip_output.c shows that interface routes are short-circuited and not checked for RT_LINK_IS_UP as gateway routes are. Consider the following scenario : A pair of redundant routers : RTR1 and RTR2. Each having dedicated uplink to some ISP and both run BGP, and they also have a dedicated cross-connection. On the LAN side, they share a IP using CARP. Uplink1Uplink2 | | | | +--+ +--+ | RTR1 |---| RTR2 | +--+ +--+ | | | | +---+--+---+ | LAN| +--+ Now, if the cable on RTR1 connecting it to the LAN is disconnected, RTR2 will become carp master and will start receiving packets from clients on LAN and they will be routed ok. But form the ISP point of view the best path to the network is via RTR1, so the incoming traffic will still be routed thru RTR1 because it's Uplink1 interface is UP and the BGP session established. This will cause the packets destined to the LAN to be effectively blackholed, because of the interface route on RTR1. When using kernel with RADIX_MPATH and ospf on both routers RTR1 will have two routes to the LAN, one interface and one via the crossconnect to RTR2 but still, the interface route will be consen, regardless of link state up or down. I'm thinking about checking for RT_LINK_IS_UP on interface routes, or clear the RTF_UP flag on those routes when interface goes link down. Any other solutions/ideas? Cheers, Nikolay ___ 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: option RADIX_MPATH, RT_LINK_IS_UP() and interface routes.
On 2/12/2011 11:36 AM, Nikolay Denev wrote: Hello, A quick glance through sys/netinet/ip_output.c shows that interface routes are short-circuited and not checked for RT_LINK_IS_UP as gateway routes are. Consider the following scenario : A pair of redundant routers : RTR1 and RTR2. Each having dedicated uplink to some ISP and both run BGP, and they also have a dedicated cross-connection. On the LAN side, they share a IP using CARP. Uplink1Uplink2 | | | | +--+ +--+ | RTR1 |---| RTR2 | +--+ +--+ | | | | +---+--+---+ | LAN| +--+ Now, if the cable on RTR1 connecting it to the LAN is disconnected, RTR2 will become carp master and will start receiving packets from clients on LAN and they will be routed ok. But form the ISP point of view the best path to the network is via RTR1, so the incoming traffic will still be routed thru RTR1 because it's Uplink1 interface is UP and the BGP session established. This will cause the packets destined to the LAN to be effectively blackholed, because of the interface route on RTR1. When using kernel with RADIX_MPATH and ospf on both routers RTR1 will have two routes to the LAN, one interface and one via the crossconnect to RTR2 but still, the interface route will be consen, regardless of link state up or down. I'm thinking about checking for RT_LINK_IS_UP on interface routes, or clear the RTF_UP flag on those routes when interface goes link down. Any other solutions/ideas? You could try sysutils/heartbeat which is similar in concept with CARP, but runs in userspace and gives you the ability to run scripts in case of a change. It can also ping any IP address to monitor a link's health, that is, "if I cannot get replies from hosta in my LAN, something must be wrong with me, I'll notify the backup host and change my status to backup". Heartbeat wikipedia article: http://en.wikipedia.org/wiki/Linux-HA HTH, Nikos ___ 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/154667: [fxp] link stage change on multicast join/leave
Synopsis: [fxp] link stage change on multicast join/leave State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Sat Feb 12 23:10:20 UTC 2011 State-Changed-Why: Would you try patch at the following URL? http://people.freebsd.org/~yongari/fxp/fxp.mcast.diff Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Sat Feb 12 23:10:20 UTC 2011 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=154667 ___ 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/154676: [netgraph] [panic] HEAD, 8.1-RELEASE panic after some play with netgraph
Old Synopsis: HEAD, 8.1-RELEASE panic after some play with netgraph New Synopsis: [netgraph] [panic] HEAD, 8.1-RELEASE panic after some play with netgraph Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Feb 13 02:20:33 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=154676 ___ 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/154676: [netgraph] [panic] HEAD, 8.1-RELEASE panic after some play with netgraph
The following reply was made to PR kern/154676; it has been noted by GNATS. From: Arnaud Lacombe To: bug-follo...@freebsd.org, sergey.dya...@gmail.com Cc: Subject: Re: kern/154676: [netgraph] [panic] HEAD, 8.1-RELEASE panic after some play with netgraph Date: Sun, 13 Feb 2011 02:03:34 -0500 Playing a bit with that bug; an INVARIANTS-enabled kernel (9-CURRENT) crashes with: panic: ng_snd_item: no mbuf packet header! because the mbuf returned by soreceive() does not have M_PKTHDR set, while the expected data is present in the mbuf. 7.1 does set the flag: Adding an m_print() right after soreceive() in ng_ksocket_incoming2() gives: FreeBSD -current (on 127.0.0.1:25): mbuf: 0xc1d7b200 len: 81, next: 0, 0, 32-32-30-... FreeBSD 7.1 (on 127.0.0.1:22) mbuf: 0xc6d47400 len: 40, next: 0, 2, 53-53-48-... both stack uses soreceive_generic(), ___ 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"
