https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #69 from Dobri Dobrev ---
(In reply to Michael Tuexen from comment #68)
Same. Let's continue tomorrow.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #68 from Michael Tuexen ---
Thanks. Need to think when I'm more awake than now...
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #67 from Dobri Dobrev ---
(In reply to Michael Tuexen from comment #66)
(kgdb) frame 12
#12 0x80e11a3b in tcp_m_copym (m=0x0, m@entry=0xf80bc680b500,
off0=1388, plen=, plen@entry=0xfe017fd6282c, seglimit=1,
segl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #66 from Michael Tuexen ---
That was fast...
Let's start with:
frame 12
print *(struct mbuf *)0xf80bc680b500
print *(int32_t *)0xfe017fd6282c
frame 14
print *th
print *tp
--
You are receiving this mail because:
You a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #65 from Dobri Dobrev ---
(In reply to Hans Petter Selasky from comment #63)
So, here it is - I believe this is what we're looking for: "panic: tcp_m_copym,
length > size of mbuf chain"
Unread portion of the kernel message buf
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256882
--- Comment #24 from Alexander V. Chernikov ---
(In reply to Konrad from comment #23)
Great!
I'm going to proceed with the case closure then.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256882
--- Comment #23 from Konrad ---
Yes, system has been working stable since then
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256882
--- Comment #22 from Alexander V. Chernikov ---
(In reply to Konrad from comment #20)
Has the system been stable since?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #64 from Dobri Dobrev ---
(In reply to Hans Petter Selasky from comment #63)
I already installed the new kernel and cleaned all the old dumps (there wasn't
much space left in /).
I'll extract everything again after the next cr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #63 from Hans Petter Selasky ---
It could also be interesting to see the socket state, especially so_snd:
Can you try this:
frame 10
print /x *(tp->t_inpcb->inp_socket)
--HPS
--
You are receiving this mail because:
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #62 from Dobri Dobrev ---
(In reply to Michael Tuexen from comment #61)
Running stable/13-n248688-ecb7f44be90, waiting for a crash.
So far the invariants don't cause issues.
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #61 from Michael Tuexen ---
(In reply to Dobri Dobrev from comment #60)
Thats OK. Lets see what happens.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #60 from Dobri Dobrev ---
(In reply to Hans Petter Selasky from comment #59)
SACK is enabled.
I'm rebuilding the latest available stable/13 kernel with invariants.
When it crashes - I'll start providing data.
Hopefully the sl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #59 from Hans Petter Selasky ---
Hi Dobri,
Can you confirm that SACK is enabled?
sysctl net.inet.tcp.sack.enable
--HPS
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #58 from Michael Tuexen ---
(In reply to Dobri Dobrev from comment #57)
1. During runtime it is slower, since it does additional checking.
2. Downtime is the same.
--
You are receiving this mail because:
You are the assignee f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #57 from Dobri Dobrev ---
(In reply to Michael Tuexen from comment #56)
I can build the kernel with invariants, however...
1. During runtime - is there a noticeable slowdown or anything that would
otherwise interfere with prod
I hope somebody on this list has more insights into this issue below.
NB: I can repeat the rtsol command and error from the command line.
Regards,
Ronald.
Van: Ronald Klop via freebsd-arm
Datum: woensdag, 22 december 2021 14:53
Aan: freebsd-...@freebsd.org
Onderwerp: ipv6 on genet0 + bridge no
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #56 from Michael Tuexen ---
Let us try to use a kernel build with INVARIANTS, let it crash and look at the
core. Don't update the system while we are doing this. And let us focus on one
system and one crash at a time.
--
You a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #55 from Dobri Dobrev ---
(In reply to Hans Petter Selasky from comment #54)
So, Do I hold off installing the kernel/world that I've build today, or install
it, wait for a crash and extract new data?
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #54 from Hans Petter Selasky ---
Let's use the updated machine for now and follow Michael's thread.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #53 from Dobri Dobrev ---
(In reply to Hans Petter Selasky from comment #52)
Hello,
The sbdrop() only appeared once on 1 of the servers, I've since then updated
the kernel there, and have not extracted core dumps / etc from th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #52 from Hans Petter Selasky ---
Hi,
There appears to be multiple dumps with different issues!
Decoding the thread name from the last printout you provided:
td_name = {0x69, 0x66, 0x5f, 0x69, 0x6f, 0x5f, 0x74, 0x71, 0x67, 0x5
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #51 from Dobri Dobrev ---
(In reply to Hans Petter Selasky from comment #50)
(kgdb) frame 10
#10 0x80dcd382 in tcp_do_segment (m=, th=, so=, tp=0xfe0251638870, drop_hdrlen=40,
tlen=, iptos=0 '\000') at /usr/src/sys/
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #50 from Hans Petter Selasky ---
Then see if you can get this working:
frame 10
print /x *(struct thread *)(tp->t_inpcb->inp_lock.rw_lock)
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #49 from Hans Petter Selasky ---
Then see if you can get this working:
frame 10
print /x *(struct thread *)tp->t_inpcb.inp_lock.rw_lock
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #48 from Dobri Dobrev ---
(In reply to Hans Petter Selasky from comment #47)
Here is from frame 10:
(kgdb) frame 10
#10 0x80dcd382 in tcp_do_segment (m=, th=, so=, tp=0xfe0251638870, drop_hdrlen=40,
tlen=, iptos=0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #47 from Hans Petter Selasky ---
Try instead:
frame 10
print /x *tp->t_inpcb
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #46 from Dobri Dobrev ---
(In reply to Hans Petter Selasky from comment #44)
Here is from frame 9:
(kgdb) frame 9
#9 0x80dd5fa9 in tcp_output (tp=) at
/usr/src/sys/netinet/tcp_output.c:1081
warning: Source file is more
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #45 from Dobri Dobrev ---
(In reply to Hans Petter Selasky from comment #44)
(kgdb) where
#0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:399
#2 0xfff
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #44 from Hans Petter Selasky ---
(kgdb) frame 8
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #43 from Dobri Dobrev ---
(In reply to Hans Petter Selasky from comment #42)
>From which frame ?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #42 from Hans Petter Selasky ---
Could you dump the INPCB aswell:
print /x *tp->t_inpcb
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #41 from Hans Petter Selasky ---
I note that in order to reach the sbdrop() where we panic happens we need to
pass:
if (tp->t_state == TCPS_ESTABLISHED)
But:
tp->t_state = 8 (TCPS_LAST_ACK)
So that means there is a race some
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393
--- Comment #40 from Hans Petter Selasky ---
Might be you need to:
make toolchain
first.
--HPS
--
You are receiving this mail because:
You are the assignee for the bug.
34 matches
Mail list logo
