https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
Michael Tuexen changed:
What|Removed |Added
Summary|Kernel panic in SCTP/IpV6 |[sctp] Kernel panic in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #28 from Michael Tuexen ---
(In reply to Mark Johnston from comment #27)
OK, great. I think reducing the stack space worth the effort. It is not that
hard, will improve also the handling of pathological parameter configurations.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
Mark Johnston changed:
What|Removed |Added
Resolution|Overcome By Events |---
Status|Closed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #26 from Michael Tuexen ---
(In reply to Mark Johnston from comment #25)
Increasing the stack size is a workaround. The plan was to rewrite the handling
such that only one buffer is needed. That is why I left the bug open. Since
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
Mark Johnston changed:
What|Removed |Added
CC||ma...@freebsd.org
Resoluti
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
Rodney W. Grimes changed:
What|Removed |Added
CC||freebsd-net@FreeBSD.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
Michael Tuexen changed:
What|Removed |Added
Assignee|freebsd-net@FreeBSD.org |tue...@freebsd.org
St
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #24 from Michael Tuexen ---
OK, I'll reduce the stack usage...
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
http
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #23 from Michael Tuexen ---
(In reply to Shreesh Holla from comment #22)
I tried to install gnome3 and xorg according to the FreeBSD handbook, but gnome
doesn't start. It complains about not finding the default font "fixed". I
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #22 from Shreesh Holla ---
(In reply to Michael Tuexen from comment #21)
Here is what I may have which just be causing it. I backed out my change from
loader.conf and it went into panic immediately when I made an sctp connection
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #21 from Michael Tuexen ---
I'm using VMWare Fusion. The VM uses a single processor core and 256MB of RAM.
I installed FreeBSD from FreeBSD-11.1-RELEASE-i386-dvd1.iso.
Let me know what you find...
--
You are receiving this mai
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #20 from Shreesh Holla ---
(In reply to Michael Tuexen from comment #19)
That's strange. That's exactly what I did for the panic. So maybe there is
something else on my systems. I am using vm's too of vmware desktop. I will try
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #19 from Michael Tuexen ---
OK, I setup a Release 11.1 i386 VM and a HEAD i386 VM and installed nmap. Using
ncat --sctp -l IPv6_address on these VMs I can NOT reproduce the issue. I used
::1 and a client on the same VM, used a g
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #18 from commit-h...@freebsd.org ---
A commit references this bug:
Author: cem
Date: Mon Dec 11 04:32:37 UTC 2017
New revision: 326758
URL: https://svnweb.freebsd.org/changeset/base/326758
Log:
i386: Bump KSTACK_PAGES default
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #17 from Shreesh Holla ---
(In reply to Conrad Meyer from comment #16)
I agree with @eugene. The generally accepted case should just work. And special
configurations are well special configurations and they can tune accordingly.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #16 from Conrad Meyer ---
(In reply to Eugene Grosbein from comment #13)
(In reply to Shreesh Holla from comment #14)
Yeah, just bumping i386 KSTACK_PAGES will at least give parity with amd64.
That's reasonable. It seems kind
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #15 from Michael Tuexen ---
OK, so it is a problem in i386. Haven't tested that for ages... One problem we
ran into in the past was that the stack grew due to inline compilation. Not
sure what is the case here. I can try to nail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #14 from Shreesh Holla ---
(In reply to Conrad Meyer from comment #12)
@conrad - I see what you mean since i386 => 32 bit. And yes definitely fixing
the SCTP stack to not use that much stack is the right one. From what I saw it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #13 from Eugene Grosbein ---
There are no reasons to keep kstack_pages<4 for i386 with exception of very
specific load pattern when you have enormous number of threads in the system.
--
You are receiving this mail because:
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #12 from Conrad Meyer ---
(In reply to Shreesh Holla from comment #11)
Well, pointers and native words *are* smaller on i386, so it isn't totally
unreasonable for the stack size to be smaller than amd64. Also, i386-only
devices
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #11 from Shreesh Holla ---
(In reply to Eugene Grosbein from comment #10)
Yes. This did do the trick. Adding to loader.conf as Eugene suggested.
Also @Michael - as a FYI - I am using global IPV6 addresses.
That bug that Eugene
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
Eugene Grosbein changed:
What|Removed |Added
Status|New |Open
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #9 from Conrad Meyer ---
@Michael, one other thing to consider is that Shreesh is running i386, which
uses a smaller KSTACK_PAGES default (2) than amd64 (4). Double fault is
consistent with overrunning the end of the stack. It
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #8 from Michael Tuexen ---
(In reply to Shreesh Holla from comment #7)
Is it a global IPv6 address or a link local one? I have been testing with link
local addresses...
--
You are receiving this mail because:
You are the assig
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #7 from Shreesh Holla ---
(In reply to Michael Tuexen from comment #6)
Oh I mentioned in the bug report right in the beginning. Here it is again:
ncat --sctp -l
--
You are receiving this mail because:
You are the assignee fo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #6 from Michael Tuexen ---
(In reply to Shreesh Holla from comment #5)
Can you please state the arguments you use on the server side for starting
ncat?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #5 from Shreesh Holla ---
The issue seems to be if you use an actual IPV6 address i.e. not ::1. Well I
could not connect from an external machine when listener was on ::1. So the
listener should be listening on the local IPv6 ad
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
Michael Tuexen changed:
What|Removed |Added
CC||tue...@freebsd.org
--- Comment #4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #3 from Shreesh Holla ---
The stacktrace from the vmcore is:
Fatal double fault:
eip = 0xc06dcf21
esp = 0xeeafbfd8
ebp = 0xeeafc1b8
cpuid = 1; apic id = 02
panic: double fault
cpuid = 1
KDB: stack backtrace:
#0 0xc0bc1b3e at kdb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #2 from Shreesh Holla ---
Created attachment 188676
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=188676&action=edit
Crash info file
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
Conrad Meyer changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org
Hi Joe,
are you able to provide enough information such that I can reproduce
this problem?
Best regards
Michael
On Aug 22, 2008, at 4:20 PM, Joseph Mays wrote:
Hello.
We've recently written an extensive software system that uses SCTP
as a critical component. We've started to run into an
Joe Mays wrote:
Just thought I'd put this out there again. Is there anyone who was
involved in the SCTP installation on list?
yes, [EMAIL PROTECTED] is but I think he's "away" for a while.
Hello.
We've recently written an extensive software system that uses SCTP
as a
critical component.
Just thought I'd put this out there again. Is there anyone who was
involved in the SCTP installation on list?
> Hello.
>
> We've recently written an extensive software system that uses SCTP
as a
> critical component. We've started to run into an issue where the box
kenel
> panics after throwing an
Hello.
We've recently written an extensive software system that uses SCTP as a
critical component. We've started to run into an issue where the box kenel
panics after throwing an error message from sctp_timer.c that says "Our list
is out of order? Out of order list". Can anyone here shed light
35 matches
Mail list logo
