https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
--- Comment #23 from Eugene Grosbein ---
(In reply to Mason Loring Bliss from comment #22)
Please provide output of "ifconfig igb0" and "ifconfig bridge0" just after boot
when bridge has only single igb0 member.
Then, attach new epair to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
--- Comment #22 from Mason Loring Bliss ---
Linux manages the trick on this same box, so the hardware can manage it
unless there's some critical difference I'm missing. I'd be happy to
explore from either side to shed more light on it. An
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
--- Comment #21 from Alexander Motin ---
Mason, I don't see how this can be fixed without either significantly
complicating the bridge driver to handle TSO/LRO/etc offload in software, or
without making Intel drivers somehow avoid chip res
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122
--- Comment #20 from Mason Loring Bliss ---
The bridge is set up per:
https://wiki.freebsd.org/MasonLoringBliss/JailsEpair
...albeit with igb0 rather than em0 in this case.
So:
cloned_interfaces="bridge0"
ifconfig_bridge0="inet 10.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210726
--- Comment #25 from Bryan C. Mills ---
According to the comment at
https://go-review.googlesource.com/c/go/+/369157/1#message-c6b6ac6857673b20daacd7a25019c8817f6f836f
this fix was included in the 12.2 and 13.0 releases used by the Go proje
I would also like to be on the list of possible beta testers.
On Tue, Dec 7, 2021 at 11:27 AM Santiago Martinez
wrote:
> Hi Neel, it is exciting to see the topic coming alive again.
>
> Once you think is good/ready for testing, or when you require it, i can
> avail hardware , routers and traffi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259645
--- Comment #29 from Arnaud de Prelle ---
(In reply to Mark Johnston from comment #28)
Yes, kernel dumps are enabled imho :
BSD:~ # grep dumpdev /etc/rc.conf | grep -v "^#"
dumpdev="AUTO"
BSD:~ # dumpon -l
ada0s1b
# grep ada0s1b /etc/fsta
Hi Neel, it is exciting to see the topic coming alive again.
Once you think is good/ready for testing, or when you require it, i can
avail hardware , routers and traffic generator to take the stack for a ride.
Count me in for testing, reporting, etc.
Best regards.
Santi
On 12/6/21 18:40, R
On Mon, Dec 06, 2021 at 11:41:27PM +0300, Lev Serebryakov wrote:
> On 19.11.2021 23:16, Lutz Donnerhacke wrote:
>>> * Is porting OpenBSD MPLS to FreeBSD feasible, or are we better off doing
>>> a from-scratch implementation based on netgraph?
>>
>> I'd prefer a netgraph approach, if possible.
>>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259645
--- Comment #28 from Mark Johnston ---
(In reply to Arnaud de Prelle from comment #27)
Do you have kernel dumps configured? What does "dumpon -l" print?
Without some console logs from the time of the reset it's impossible to say
what happ
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259645
--- Comment #27 from Arnaud de Prelle ---
(In reply to Mark Johnston from comment #26)
Hi Mark,
I don't have a core file in /var/crash:
# ls -ltra /var/crash
total 12
-rw-r--r-- 1 root wheel5 Jan 16 2014 minfree
drwxr-x--- 2 roo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259645
Mark Johnston changed:
What|Removed |Added
Summary|crash in_cksumdata |crash in_cksumdata
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259645
--- Comment #26 from Mark Johnston ---
(In reply to Arnaud de Prelle from comment #22)
Can you share the panic string and backtrace? Or a copy of
/var/crash/core.txt. from the crash. The files that you attached do not
tell me anything. T
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260260
--- Comment #3 from Marek Zarychta ---
(In reply to Zhenlei Huang from comment #2)
1. Indeed, bringing up intrefaces this way:
ifconfig_igb0="mtu 9000 -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwtso
-vlanhwcsum up"
ifconfig_igb1="mtu 9000 -vla
Please see the https://reviews.freebsd.org/D33154,
igb driver doesn't honor the interface capabilities like vlanhwtag,
vlan* and etc now. If you want, you can apply the patches from D33154
Regards,
Özkan KIRIK
On Tue, Dec 7, 2021 at 12:06 PM Marek Zarychta
wrote:
>
> W dniu 7.12.2021 o 10:00, Zh
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260260
--- Comment #2 from Zhenlei Huang ---
So it is weird.
If VLANMTU is disabled on parent interface, MTU of VLAN interface will be
limited off by 4 automatically. The MTU of vlans should be 8996 in your case.
Try the following steps:
1. Dis
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200319
--- Comment #32 from Palle Girgensohn ---
I just tried to reproduce the problem on FreeBSD-13.0.RELEASE using the
attached script, but it just runs on smoothly. Is there anything else I need to
add to the mix to reproduce the lock-up?
Than
W dniu 7.12.2021 o 10:00, Zhenlei Huang pisze:
Can you please disable all vlan hardware offloading features and repeat the
test again?
ifconfig igb0 -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwtso -vlanhwcsum
Disabling the capabilities listed above doesn't solve the issue, but assigning
mtu 8996
> On Dec 7, 2021, at 5:39 AM, Marek Zarychta
> wrote:
>
> W dniu 8.11.2021 o 08:13, Zhenlei Huang pisze:
>>> On Nov 7, 2021, at 3:51 PM, Rozhuk Ivan wrote:
>>>
>>> Hi!
>>>
>>>
>>> Why if_vlan allow to set same MTU size or bigger as on parrent nic?
>>>
>>>
>>> Setup:
>>> - workstation wi
19 matches
Mail list logo
