https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #69 from jja...@gmail.com ---
OK, that's weird
I just got nailed by a pfsync_defer_tmo while I was typing this up.
It should be fixed in 13.1-STABLE source?
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xf
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264179
Eric Joyner changed:
What|Removed |Added
CC||e...@freebsd.org
--- Comment #7 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266442
--- Comment #9 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=1da7a8a066150bf132b3e1a48fad009212a0010a
commit 1da7a8a066150bf132b3e1a48fad009212a0010a
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266442
--- Comment #10 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=351f2f68852ac3e1d0ef745dc024dd745b07a34f
commit 351f2f68852ac3e1d0ef745dc024dd745b07a34f
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266442
Cy Schubert changed:
What|Removed |Added
Status|In Progress |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264179
--- Comment #8 from Yasuhiro Kimura ---
Created attachment 240039
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=240039&action=edit
Output of dmesg(8) command
(In reply to Eric Joyner from comment #7)
I modified e1000_osdep.h,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264179
--- Comment #9 from Eric Joyner ---
Comment on attachment 240039
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=240039
Output of dmesg(8) command
I see this now:
PHY Initialization Error
em1: Setup of Shared code failed, error
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264179
--- Comment #10 from Eric Joyner ---
Was your home server still using 13.1-RELEASE before you tried installing an
image based on CURRENT?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264179
--- Comment #11 from Yasuhiro Kimura ---
(In reply to Eric Joyner from comment #9)
Sorry, it was typo. Following is screenshot of first time.
https://people.freebsd.org/~yasu/Alderlake-GbE-failure-to-detect.jpg
As you can see, error code
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #70 from Kristof Provost ---
(In reply to jjasen from comment #68)
Okay, excellent. I think we've figured out what's going on here.
I also think I see why I can't reproduce it yet. It's interpreting the IPv6
header as an IPv4 h
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #5 from Kevin Bowling ---
(In reply to Daniel Duerr from comment #4)
1) Clone FreeBSD src, check out 12.4:
pkg install git-lite
git clone https://git.freebsd.org/src.git /usr/src
cd /usr/src
git checkout releng/12.4
2) Start t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #6 from Kevin Bowling ---
Correction for step 9, before running 'git checkout ', perform 'git
bisect reset' to clear the repo out of bisecting.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #71 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #70)
Yeah, according to the EOL schedule, 13.1 has maybe six months to live. Thanks
for reminding me.
--
You are receiving this mail because:
You are the a
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and ob
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #72 from Kristof Provost ---
I'm still failing to reproduce, but this should be close to a real fix:
diff --git a/sys/netpfil/pf/if_pfsync.c b/sys/netpfil/pf/if_pfsync.c
index 47c3217f399c..4ebd304b1c13 100644
--- a/sys/netpfil
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #7 from Daniel Duerr ---
(In reply to Kevin Bowling from comment #5)
Thank you for the detailed instructions, Kevin. Makes sense.
FWIW, after completing step I got an error on step #2:
[root@nfs src]# git bisect start releng
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #73 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #72)
I speculate cooking up a case where an IPv4 attempt from the firewall fails, it
reverts to IPv6, and attempts to insert that state.
I am able to repro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #8 from Daniel Duerr ---
(In reply to Kevin Bowling from comment #5)
Hi Kevin, sorry to say I'm having a difficult time getting the kernel to
compile. I have a pretty decent amount of experience building custom kernels,
but can
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #74 from jja...@gmail.com ---
Ooopsie! Did I goof up?
mno-avx -std=iso9899:1999 -c /root/usr/src/sys/netpfil/pf/if_pfsync.c -o
if_pfsync.o
/root/usr/src/sys/netpfil/pf/if_pfsync.c:2368:48: error: implicit declaration
of functio
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #75 from Kristof Provost ---
(In reply to jjasen from comment #74)
Did the patch apply fully? The ip6_output() prototype should be in `#include
`.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #76 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #75)
No. I stuffed it in manually.
Was this against clean -stable or against what we were working on?
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #77 from Kristof Provost ---
(In reply to jjasen from comment #76)
Yeah, that's against stable/13.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #9 from Kevin Bowling ---
(In reply to Daniel Duerr from comment #8)
Try one of the methods from
https://groups.google.com/g/bsdmailinglist/c/Wz3lSE20hWU, either using
WITHOUT_SYSTEM_COMPILER=yes or cherry-picking the format com
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #10 from Daniel Duerr ---
(In reply to Kevin Bowling from comment #9)
Thanks Kevin. I did manage to get myself unblocked but forgot to respond back
to you here. I needed to do a `make buildworld` and now `make kernel` works as
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #11 from Kevin Bowling ---
You can save some time by avoiding buildworld, we are only interested in the
e1000 driver changes in the kernel
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #78 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #77)
OK. I compiled a kernel with this in. I need to add the pfsync_defer_tmo patch
as well.
On the upside, I was able to generate traffic on this system
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #79 from jja...@gmail.com ---
(In reply to jjasen from comment #78)
defer_tmo patch added as well, started test bombardment.
So far, no issues.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #80 from jja...@gmail.com ---
Good news. We may have fixed pfsyncintr.
Bad news. I don't think we defeated pfsync_defer_tmo
Want the usual bt, frame and prints?
--
You are receiving this mail because:
You are the assignee fo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #81 from Kristof Provost ---
Yes. Also show me what code you have for that function, so we’re sure we’re
looking at the same thing.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #82 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #81)
I'm using this:
https://cgit.freebsd.org/src/commit/?id=8edf0b52c40762d64b3d4318235b58ae5d4eff58
Other stuff up shortly.
--
You are receiving this m
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #83 from jja...@gmail.com ---
BT:
#0 __curthread () at /root/usr/src/sys/amd64/include/pcpu_aux.h:55
#1 dump_savectx () at /root/usr/src/sys/kern/kern_shutdown.c:394
#2 0x80c38ae8 in dumpsys (di=0x0) at
/root/usr/src/
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #12 from Daniel Duerr ---
(In reply to Kevin Bowling from comment #3)
Ok, I completed the bisect process you outlined above -- thanks again for the
great instructions. Here's the output:
6486e9dd8d24b0195facd23d8ca82e17e180cf
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
Franco Fichtner changed:
What|Removed |Added
CC||fra...@opnsense.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #14 from Daniel Duerr ---
(In reply to Franco Fichtner from comment #13)
Thank you, Franco. I tested what you suggested here but I do not see a change.
Here's my `ifconfig` output before (the PROMISC flag is missing as you
sugg
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #15 from Franco Fichtner ---
Could be required additionally or just in lagg, certainly worth a try in those
combinations.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #16 from Daniel Duerr ---
(In reply to Franco Fichtner from comment #15)
Thanks. Unfortunately I cannot get any change in behavior with this flag.
[root@nfs dd]# ifconfig
igb0: flags=28943
metric 0 mtu 9000
options=800
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #17 from Franco Fichtner ---
Well, before this patch igb was defaulting to promisc even if it didn't report
it to ifconfig. It was debuggable using a VM asking for privileged network
access during boot in those early 12.x days.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #18 from Daniel Duerr ---
(In reply to Franco Fichtner from comment #17)
Thanks Franco. I agree that whatever I am experiencing here seems a little
different than what you were talking about. I've tried more combinations of
`if
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #19 from Kevin Bowling ---
As a sanity check, can you revert 6486e9dd8d24b0195facd23d8ca82e17e180cffb or
manually change the em_if_set_promisc() call back as it was on the top of 12.4?
--
You are receiving this mail because:
Y
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #84 from Kristof Provost ---
Ah, that's the same issue, but in the tmo function now.
Try this:
diff --git a/sys/netpfil/pf/if_pfsync.c b/sys/netpfil/pf/if_pfsync.c
index 47c3217f399c..fd5be82367aa 100644
--- a/sys/netpfil/pf/i
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #85 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=9a1cab6d79b7286e5f650f57ed95625e6ddb8e4b
commit 9a1cab6d79b7286e5f650f57ed95625e6ddb8e4b
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #20 from Daniel Duerr ---
(In reply to Kevin Bowling from comment #19)
Sure. I started with an up to date `releng/12.4` branch with no changes. The
`git revert 6486e9dd8d24b0195facd23d8ca82e17e180cffb` command could not apply
c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #21 from Franco Fichtner ---
Can you go to your good early kernel state and apply the patch in question?
If it's good there in any case you will have to do a bisect, but apply the
patch on top every time to find the underlying
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #22 from Daniel Duerr ---
(In reply to Franco Fichtner from comment #21)
Sure. To clarify, you are asking me to do another `git bisect` like I did
before, but this time to apply this latest patch to each subsequent version --
t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
m...@sentex.net changed:
What|Removed |Added
CC||m...@sentex.net
--- Comment #23 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #24 from Franco Fichtner ---
Hi Daniel,
Yes, at least once in your original state to verify the commit you found
unmasks the real cause of the degradation. If that is the case the initial old
commit you started the bisect on w
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #25 from Daniel Duerr ---
(In reply to mike from comment #23)
Thanks Mike. In line with your points, I was able to work around this issue on
all my other servers with 12.4-RELEASE by removing the use of vlan and just
running st
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #26 from Daniel Duerr ---
(In reply to Franco Fichtner from comment #24)
Thanks, I think I understand. Would it be acceptable to just checkout the first
"bad" commit from my bisect above and then apply the patch to that and tes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #27 from Franco Fichtner ---
Not the first bad commit, the first commit you started the bisect on which is
the one that has reliably good performance.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #28 from Daniel Duerr ---
(In reply to Franco Fichtner from comment #27)
Ok, thanks. So you want me to go back to the first good commit (which already
works without any patches) and then you want me to apply the patch to that
v
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #86 from jja...@gmail.com ---
(In reply to Kristof Provost from comment #84)
Compiling now.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #87 from jja...@gmail.com ---
(In reply to jjasen from comment #86)
iterative tests started. Fingers crossed!
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #88 from jja...@gmail.com ---
(In reply to jjasen from comment #87)
So far, we held together overnight without any issue!
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269643
Graham Perrin changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
Keyword
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269643
Mike Karels changed:
What|Removed |Added
CC||kar...@freebsd.org
--- Comment #2 fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269643
--- Comment #3 from Mike Karels ---
See also ip6addrctl, which shows and modifies the address selection policy; you
can make IPv4 preferred.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269643
Marek Zarychta changed:
What|Removed |Added
CC||zarych...@plan-b.pwste.edu.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269643
--- Comment #5 from crypt47 ---
> Perhaps your script should use ping -4. btw, ping6 is just ping -6.
I understand the nature of the problem, but the idea is not to change scripts
because of changes in OS. (AND having two pings both of wh
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269643
--- Comment #6 from crypt47 ---
p.s.
Yes, it's not obvious to enable something IPv6 (ip6addrctl_enable="YES")
related to disable it (ip6addrctl_policy="ipv4_prefer").
--
You are receiving this mail because:
You are the assignee for the b
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and ob
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
Thomas Steen Rasmussen / Tykling changed:
What|Removed |Added
CC||tho...@gibfest.d
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165059
Tristin Stagg changed:
What|Removed |Added
CC||tristinst...@protonmail.com
--- Co
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #29 from Kevin Bowling ---
I think the intention there is to try and figure out what coincidental commit
could be at fault because the offending commit is just enabling functionality
but is not necessarily a smoking gun. I'm no
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and ob
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257709
--- Comment #3 from Henrich Hartzer ---
I think this would be a great idea to get in for 13.2.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257709
--- Comment #4 from Zhenlei Huang ---
RFC 4620 is still experimental then I thinks it is safe to set
`net.inet6.icmp6.nodeinfo` default to 0 .
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assigne
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257709
--- Comment #5 from Pawel Biernacki ---
Making it into 13.2-R is out of question because it:
1) changes default in minor release
2) it's too late as the RC1 is behind the corner
14.0 is a good target release for this change. It'd require
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #90 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=dacffdd4dc511ae73e8fd3eb19f9efe4ecb26ba1
commit dacffdd4dc511ae73e8fd3eb19f9efe4ecb26ba1
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
--- Comment #91 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=3dec62eded04eaf431bf0948f4e6412deede87d5
commit 3dec62eded04eaf431bf0948f4e6412deede87d5
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246
Kristof Provost changed:
What|Removed |Added
Status|In Progress |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237477
--- Comment #2 from p5b2ea8...@t-online.de ---
Almost four (4) years later: When will this be fixed?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237477
--- Comment #3 from Kristof Provost ---
(In reply to p5B2EA84B3 from comment #2)
When someone cares enough to fix it. My todo list is endless, and I don't
consider this to be a priority.
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269908
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269908
--- Comment #3 from franklin.s...@gmail.com ---
Details:
Machine 1:
Physical MAC: 00:50:56:a7:0f:7f
IP Address: 10.10.4.17
Machine 2:
Physical MAC: 00:50:56:a7:e3:41
IP Address: 10.10.4.18
CARP:
Virtual MAC: 00:00
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269908
--- Comment #4 from franklin.s...@gmail.com ---
Created attachment 240549
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=240549&action=edit
tcpdump files from Machine1
--
You are receiving this mail because:
You are the assigne
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269908
--- Comment #5 from franklin.s...@gmail.com ---
Created attachment 240550
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=240550&action=edit
tcpdump files from Machine2
--
You are receiving this mail because:
You are the assigne
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269908
--- Comment #6 from franklin.s...@gmail.com ---
There appears to be another race condition and could be similar to one of the
earlier issues fixed.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191832
--
You are receiving this mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264179
--- Comment #12 from Yasuhiro Kimura ---
Created attachment 240579
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=240579&action=edit
Output of dmesg(8) command with installer of 13.2-RC1
I tried boot with installer of 13.2-RC1 a
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and ob
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269908
--- Comment #7 from franklin.s...@gmail.com ---
https://lists.freebsd.org/pipermail/freebsd-net/2006-November/012476.html
This list seems to be talking about the same problem.
--
You are receiving this mail because:
You are the assignee
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245981
Juraj Lutter changed:
What|Removed |Added
CC||o...@freebsd.org
--- Comment #33 fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270083
Marek Zarychta changed:
What|Removed |Added
CC||n...@freebsd.org
--- Comment #1 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270083
Mark Linimon changed:
What|Removed |Added
CC|n...@freebsd.org |
Assignee|b...@freebsd.o
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and ob
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270163
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--- Comment #4 fro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270163
--- Comment #5 from Timothy Pearson ---
Created attachment 240807
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=240807&action=edit
Kernel output with debugging enabled
Here is a capture of the kernel log with debugging enabled.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270163
Zhenlei Huang changed:
What|Removed |Added
CC||z...@freebsd.org
--- Comment #6 fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270163
--- Comment #7 from Timothy Pearson ---
(In reply to Zhenlei Huang from comment #6)
Yes, I'll just need a bit of time to shuffle the configuration around.
Two other data points:
An Intel I340-T4 I had available to test with appears to wo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270163
--- Comment #8 from Timothy Pearson ---
OK, looks like it's on data transmission, CARP was just the first transmission
on the device when it was set up. With CARP disabled, the log looks similar,
everything looks OK then it dies somewhere
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270163
--- Comment #9 from Timothy Pearson ---
(In reply to Timothy Pearson from comment #8)
Note that when the device is firewalled, every access returns 0xff, so the
reference to a driver lock is probably just the relevant bit being returned as
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269908
--- Comment #8 from Zhenlei Huang ---
(In reply to franklin.s...@gmail.com from comment #3)
> Steps followed:
> 1. Configure CARP on Machine 1.
> ifconfig nic0 vhid 1 pass testing alias 10.10.4.19/28 advskew 10
> This box becomes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #30 from Daniel Duerr ---
(In reply to Kevin Bowling from comment #29)
Thanks Kevin. I'm happy to do whatever is needed here, I'm just unclear on
exactly what you guys are asking me to do here. I don't understand what change
I'
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268490
--- Comment #31 from Kevin Bowling ---
(In reply to Daniel Duerr from comment #30)
The idea is to bisect in somewhat of a reverse fashion where you introduce the
one line change on during each bisection step:
- em_if_set_promisc(ctx,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270163
--- Comment #10 from Piotr Kubaj ---
I have tested the card I have (dual-port Intel(R) PRO/1000 PT 82571EB/82571GB
(Copper)) with both big-endian and little-endian systems on Talos II and it
seems to work correctly. The only difference woul
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270285
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270285
Michael Tuexen changed:
What|Removed |Added
CC||tue...@freebsd.org
--- Comment #1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270285
--- Comment #2 from Marcus Haarmann ---
Yes, packet also looks ok for me, the question is why the traffic forwarded to
the client includes these two 0 bytes in the middle of the payload.
(pfsense/freebsd reorders the traffic and as a result
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270285
Richard Scheffenegger changed:
What|Removed |Added
CC||rsch...@freebsd.org
--- Co
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270285
Kristof Provost changed:
What|Removed |Added
CC||k...@freebsd.org
--- Comment #4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270285
--- Comment #5 from Marcus Haarmann ---
reproduced some minutes ago, without haproxy, direct call to fetch:
The following frame was received:
a0 36 9f 5f 90 42 e2 84 72 d3 14 5c 08 00 45 00
0010 00 2d cb 45 40 00 40 06 bc 08 c0 a8
901 - 1000 of 13467 matches
Mail list logo
