Le 10/02/14 20:19, Dan McDonald a écrit :
On Feb 10, 2014, at 1:17 PM, Richard PALO <[email protected]> wrote:
This is the first time I've come across this:
panic[cpu1]/thread=ffffff02e79e7880:
assertion failed: !IN6_IS_ADDR_V4MAPPED(dst_addr), file:
../../common/inet/ip/ip6.c, line: 1984
ffffff0010671340 genunix:process_type+162480 ()
ffffff0010671440 ip:ip_set_destination_v6+4a9 ()
ffffff0010671500 ip:ip_attr_connect+147 ()
ffffff00106715c0 ip:conn_connect+10f ()
ffffff0010671650 ip:tcp_set_destination+70 ()
ffffff0010671720 ip:tcp_input_listener+c1a ()
ffffff00106717c0 ip:squeue_enter+963 ()
ffffff0010671880 ip:ip_fanout_v6+97f ()
ffffff0010671b00 ip:ire_send_local_v6+44c ()
ffffff0010671b80 ip:conn_ip_output+2bc ()
ffffff0010671bb0 ip:tcp_send_data+80 ()
ffffff0010671c60 ip:tcp_do_connect+430 ()
ffffff0010671d40 ip:tcp_connect+c9 ()
ffffff0010671de0 sockfs:so_connect+fe ()
ffffff0010671e30 sockfs:socket_connect+3c ()
ffffff0010671eb0 sockfs:connect+b1 ()
ffffff0010671f00 unix:brand_sys_syscall32+272 ()
This stack trace is from a connect(3xn/3c/3socket) call. You can/should be
able to figure out the process and to which destination from the core dump.
Are you running a DEBUG kernel or at least a DEBUG IP module? You must be for
an ASSERT() to trip...
ill_t *ill = NULL;
boolean_t multirt = B_FALSE;
ASSERT(!IN6_IS_ADDR_V4MAPPED(dst_addr));
ASSERT(!(ixa->ixa_flags & IXAF_IS_IPV4));
Any clues on what to look for? Anything new in this area that might be suspect?
I'd be very interested to know what the destination IP was, etc. etc.
Dan
Hi Dan, yes this is a DEBUG kernel...
I'll see if I can get into this later this week.
-------------------------------------------
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be
Modify Your Subscription:
https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4
Powered by Listbox: http://www.listbox.com
