On Wed, Oct 18, 2023 at 08:53:44PM +0200, Alexander Bluhm wrote:
> On Wed, Oct 18, 2023 at 08:19:29PM +0200, Mischa wrote:
> > It's indeed something like that: ix -> vlan (tagged) -> veb
>
> When vlan is added to veb, kernel should disable LRO on ix.
> All testing before release did not find this
Hi,
This diff implements TCP Segmentation Offloading for ixl(4). I tested
it successfully on amd64 and sparc64 with Intel X710. It should
increase the TCP bulk performance to 10 Gbit/s. On sparc64 I got an
increase from 600 MBit/s to 2.000 Gbit/s.
Further testing is welcome.
bye,
Jan
Index:
Hi,
I missed the vlan-tag size in the mss calculation of lro packets in
ix(4). This diff add vlan-header detection in ether_extract_headers()
and uses this information to calculate the right mss.
This fixes forwarding of vlan tagged lro packets.
ok?
bye,
Jan
Index: dev/pci/if_ix.c
Hi,
there is an issue with the admin queue of ixl(4) which leads into the
following panic when the link state changes:
uvm_fault(0x818005f8, 0x18, 0, 2) -> e
kernel: page fault trap, code=0
Stopped at ixl_intr0+0xca: movq%rdx,0x18(%rax)
TIDPIDUID PRFLAGS
On Sat, Jul 08, 2023 at 05:15:26PM +0300, Alexander Bluhm wrote:
> I am not aware of any more limitations when enabling LRO for TCP
> in the network drivers. The feature allows to receive agregated
> packets larger than the MTU. Receiving TCP streams becomes much
> faster.
>
> As the network
On Thu, Jul 06, 2023 at 10:19:21PM +0300, Alexander Bluhm wrote:
> On Thu, Jul 06, 2023 at 08:49:03PM +0200, Jan Klemkow wrote:
> > > @@ -109,6 +109,9 @@
> > > #include
> > > #include
> > > #include
> >
> > I think is a merge b
On Mon, Jul 03, 2023 at 08:04:11PM +0300, Alexander Bluhm wrote:
> As final step before making LRO (Large Receive Offload) the default,
> we have to fix path MTU discovery when forwarding.
>
> The drivers, currently ix(4) and lo(4) only, record an upper bound
> of the size of the original packets
Hi,
bluhm pointed out that the ether_brport_isset() check it just allowed on
ethernet devices. Thus, I put an additional ethernet check in the
condition. This also fixes EBUSY errors of "ifconfig lo0 tcplro" calls
in my setup.
ok?
bye,
Jan
Index: net/if.c
On July 2, 2023 2:33:41 PM GMT+02:00, Claudio Jeker
wrote:
>On Sun, Jul 02, 2023 at 02:28:17PM +0200, Alexander Bluhm wrote:
>> anyone?
>
>Was not able to test yet but I like the diff.
>Right now this is a noop since LRO is not on by default for lo(4).
>Because of that OK claudio@
The diff
On Fri, Jun 16, 2023 at 12:06:08PM +0200, Alexander Bluhm wrote:
> On Mon, Jun 12, 2023 at 03:46:28PM +0200, Alexander Bluhm wrote:
> > I found a little inconsistency in IPv6 forwarding with TSO.
> >
> > Sending with TSO should only done if the large packet does not fit
> > in the interface MTU.
On Fri, Jun 09, 2023 at 06:59:57PM +0200, Jan Klemkow wrote:
> On Fri, Jun 09, 2023 at 06:11:38PM +0200, Jan Klemkow wrote:
> > TSO packets are limited to MAXMCLBYTES (64k). Thus, we don't need to
> > allocate IXGBE_TSO_SIZE (256k) per packet for the transmit buffers.
> >
On Fri, Jun 09, 2023 at 06:11:38PM +0200, Jan Klemkow wrote:
> TSO packets are limited to MAXMCLBYTES (64k). Thus, we don't need to
> allocate IXGBE_TSO_SIZE (256k) per packet for the transmit buffers.
>
> This saves 3/4 of the memory and allows me to pack over 8 ix(8) ports
> i
Hi,
TSO packets are limited to MAXMCLBYTES (64k). Thus, we don't need to
allocate IXGBE_TSO_SIZE (256k) per packet for the transmit buffers.
This saves 3/4 of the memory and allows me to pack over 8 ix(8) ports
into one machine. Otherwise I run out of devbuf in malloc(9).
ok?
bye,
Jan
On Wed, Jun 07, 2023 at 02:49:07PM +0300, Vitaliy Makkoveev wrote:
> On Wed, Jun 07, 2023 at 01:29:09PM +0200, Alexander Bluhm wrote:
> > On Wed, Jun 07, 2023 at 12:59:11PM +0300, Vitaliy Makkoveev wrote:
> > > On Wed, Jun 07, 2023 at 10:19:32AM +1000, David Gwynne wrote:
> > > >
> > > >
> > > >
On Tue, Jun 06, 2023 at 09:37:22AM -0700, Chris Cappuccio wrote:
> Jan Klemkow [j.klem...@wemelug.de] wrote:
> > On Tue, Jun 06, 2023 at 05:54:31PM +0300, Vitaliy Makkoveev wrote:
> > > On Tue, Jun 06, 2023 at 02:31:52PM +0200, Alexander Bluhm wrote:
> > > > I wo
On Tue, Jun 06, 2023 at 05:54:31PM +0300, Vitaliy Makkoveev wrote:
> On Tue, Jun 06, 2023 at 02:31:52PM +0200, Alexander Bluhm wrote:
> > I would suggest to rename ifconfig tcprecvoffload to tcplro. Maybe
> > it's just because I had to type that long name too often.
> >
> > With that we have
On Tue, Jun 06, 2023 at 02:31:52PM +0200, Alexander Bluhm wrote:
> I would suggest to rename ifconfig tcprecvoffload to tcplro. Maybe
> it's just because I had to type that long name too often.
>
> With that we have consistent naming:
> # ifconfig ix0 tcplro
> # sysctl net.inet.tcp.tso=1
>
>
On Wed, May 24, 2023 at 08:50:26PM +0200, Stefan Fritsch wrote:
> I forgot to mention that no stress test is necessary. If it boots and the
> virtio devices work at all, that should be enough.
Works for me on Linux/KVM with the following devices:
vga1 at pci0 dev 2 function 0 "Qumranet Virtio
On Wed, May 24, 2023 at 05:28:58PM +0200, Alexander Bluhm wrote:
> On Tue, May 23, 2023 at 02:14:57PM +0200, Jan Klemkow wrote:
> > Hi,
> >
> > This diff sets needed offloading flags and the calculated mss to LRO
> > mbufs in ix(4). Thus, we can forward this p
Hi,
This diff sets needed offloading flags and the calculated mss to LRO
mbufs in ix(4). Thus, we can forward this packets and process them via
tcp_if_output_tso(). This diff also uses tcp_if_output_tso() in
ip6_forward().
I tested the ip6_forward path via the address family transition in pf:
Hi,
We use the wrong interface and mtu in tcp_mss() to calculate the mss if
the destination address points is a local address. In ip_output() we
use the correct interface and its mtu.
This limits the mss to 1448 if the mtu of the interface it 1500,
instead of using a local 32k mss.
The bigger
On Thu, May 18, 2023 at 12:01:44AM +0200, Alexander Bluhm wrote:
> On Tue, May 16, 2023 at 09:11:48PM +0200, Jan Klemkow wrote:
> > @@ -412,6 +412,10 @@ tcp_stats(char *name)
> > p(tcps_outhwtso, "\t\t%u output TSO packet%s hardware processed\n");
> > p(tcp
Hi,
This diff introduces new counters for LRO packets, we get from the
network interface. It shows, how many packets the network interface has
coalesced into LRO packets.
In followup diff, this packet counter will also be used to set the
ph_mss variable to valid value. So, the stack is able to
On Mon, May 15, 2023 at 11:40:20AM +0200, Alexander Bluhm wrote:
> On Mon, May 15, 2023 at 09:34:21AM +0200, Jan Klemkow wrote:
> > @@ -251,12 +251,16 @@ struct if_status_description {
> > #defineIFCAP_VLAN_HWTAGGING0x0020 /* hardware VLAN tag
> > su
On Sat, May 13, 2023 at 04:44:18PM +0200, Christian Weisgerber wrote:
> Jan Klemkow:
>
> > This diff introduces separate flags for TCP offloading. We split this
> > into LRO (large receive offloading) and TSO (TCP segmentation
> > offloading). Thus, we are able to t
On Thu, May 11, 2023 at 09:17:37PM +0200, Hrvoje Popovski wrote:
> is it possible to change "ifconfig: SIOCSIFFLAGS: device not configured"
> message that it has an interface name in it, something like:
> ifconfig pfsync0: SIOCSIFFLAGS: device not configured <- in my case.
>
> I have many vlans
On Wed, May 10, 2023 at 11:13:04AM -0600, Todd C. Miller wrote:
> On Wed, 10 May 2023 19:03:58 +0200, Jan Klemkow wrote:
> > This diff introduces separate flags for TCP offloading. We split this
> > into LRO (large receive offloading) and TSO (TCP segmentation
> > offloading
Hi,
This diff introduces separate flags for TCP offloading. We split this
into LRO (large receive offloading) and TSO (TCP segmentation
offloading). Thus, we are able to turn it on/off separately.
For ifconfig(8) we use "tcprecvoffload" and "tcpsendoffload". So, the
user has a better insight
On Tue, May 09, 2023 at 09:56:36AM +0200, Alexander Bluhm wrote:
> On Sun, May 07, 2023 at 09:00:31PM +0200, Alexander Bluhm wrote:
> > Not sure if I addressed all corner cases already. I think IPsec
> > is missing.
>
> Updated diff:
> - parts have been commited
> - works with IPsec now
Thanks
On Fri, Apr 14, 2023 at 10:26:14AM +0800, Kevin Lo wrote:
> On Thu, Apr 13, 2023 at 01:30:36PM -0500, Brian Conway wrote:
> > Reviving this thread, apologies for discontinuity in mail readers:
> > https://marc.info/?t=16564219358
> >
> > After rebasing on 7.3, my results have mirrored
On Fri, Mar 24, 2023 at 10:02:05PM +0100, Theo Buehler wrote:
> > Thus, I would suggest to set this constant to ELAST. So, we will avoid
> > useless unknown error strings and a non-zero errno after tls_init().
>
> ELAST isn't portable. It's under __BSD_VISIBLE in sys/errno.h.
>
> It would seem
Hi,
after tls_init() and OPENSSL_init_ssl() errno is always set to EINVAL.
This is caused by a routine that tries to prefetch all error strings
up to 127 from strerror(3). But, strerror(3) sets EINVAL for unknown
values of error.
Thus, I would suggest to set this constant to ELAST. So, we will
On Mon, Feb 06, 2023 at 09:47:57PM +0100, Christian Weisgerber wrote:
> Christian Weisgerber:
>
> > I also switched over em(4) to this and have successfully used it
> > for a full 30-hour package build on the four amd64 ports machines
> > with their I350 interfaces. Additionally, I've done some
On Tue, Jan 31, 2023 at 09:12:51PM +0100, Christian Weisgerber wrote:
> Jan Klemkow:
>
> > - I turned the KASSERTS to returns.
> > - Check if the mbuf is large enough for an ether header.
> > - additionally #ifdef'd INET6 around the ip6_hdr in the new struct
>
On Fri, Jan 27, 2023 at 04:44:36PM +0100, Christian Weisgerber wrote:
> > The ether_extract_headers() diff was reverted, because is wrong for the
> > cases other than tcp/udp/icmp. We need to fix it and recommit again
> > before continue.
>
> I think (TCP or) UDP fragments are the problem.
On Thu, Jan 26, 2023 at 02:06:28PM +0300, Vitaliy Makkoveev wrote:
> On Thu, Jan 26, 2023 at 11:37:51AM +0100, Christian Weisgerber wrote:
> > Jan Klemkow:
> >
> > > we have several drivers which have to parse the content of mbufs. This
> > > diff s
On Tue, Jan 24, 2023 at 05:40:55PM +0300, Vitaliy Makkoveev wrote:
> On Tue, Jan 24, 2023 at 03:14:36PM +0100, Jan Klemkow wrote:
> > On Tue, Jan 24, 2023 at 09:32:53PM +1000, David Gwynne wrote:
> > > On Mon, Jan 23, 2023 at 09:25:34AM +0100, Jan Klemkow wrote:
> > > &
On Tue, Jan 24, 2023 at 09:32:53PM +1000, David Gwynne wrote:
> On Mon, Jan 23, 2023 at 09:25:34AM +0100, Jan Klemkow wrote:
> > On Wed, Jan 18, 2023 at 03:49:25PM -0700, Theo de Raadt wrote:
> > > Jan Klemkow wrote:
> > > > On Wed, Jan 18, 2023 at 10:50:25AM
Hi,
ifconfig doesn't print ipv6 addresses if its used with media option.
# ifconfig -A
vio0: flags=8843 mtu 1500
...
inet 10.0.1.65 netmask 0xff00 broadcast 10.0.1.255
inet6 fe80::5054:ff:fe6a:b6fd%vio0 prefixlen 64 scopeid 0x1
inet6 fc00:1::1 prefixlen 64
On Thu, Jan 19, 2023 at 02:55:29PM +0300, Vitaliy Makkoveev wrote:
> On Thu, Jan 19, 2023 at 10:40:52AM +0100, Jan Klemkow wrote:
> > On Thu, Jan 19, 2023 at 12:02:29PM +0300, Vitaliy Makkoveev wrote:
> > > On Thu, Jan 19, 2023 at 01:55:57AM +0300, Vitaliy Makkoveev wrote:
> &
On Thu, Jan 19, 2023 at 12:02:29PM +0300, Vitaliy Makkoveev wrote:
> On Thu, Jan 19, 2023 at 01:55:57AM +0300, Vitaliy Makkoveev wrote:
> > > On 19 Jan 2023, at 01:39, Jan Klemkow wrote:
> > >
> > > On Wed, Jan 18, 2023 at 10:50:25AM +0300, Vitaliy Makkoveev wrot
On Wed, Jan 18, 2023 at 10:50:25AM +0300, Vitaliy Makkoveev wrote:
> On Tue, Jan 17, 2023 at 11:09:17PM +0100, Jan Klemkow wrote:
> > we have several drivers which have to parse the content of mbufs. This
> > diff suggest a central parsing function for this. Thus, we can reduc
On Tue, Jan 17, 2023 at 11:02:07PM +0100, Theo Buehler wrote:
> > at least this tool works for me:
>
> Surely you have kern.allowkmem=1 set.
This diff should phrase it correctly.
ok?
Thanks,
Jan
Index: man4.alpha/mem.4
===
RCS
On Tue, Jan 17, 2023 at 11:02:07PM +0100, Theo Buehler wrote:
> > at least this tool works for me:
>
> Surely you have kern.allowkmem=1 set.
Yes, I do.
Hi,
we have several drivers which have to parse the content of mbufs. This
diff suggest a central parsing function for this. Thus, we can reduce
redundant code.
I just start with ix(4) and ixl(4) because it was easy to test for me.
But, this could also improve em(4), igc(4), ale(4) and oce(4).
On Tue, Jan 17, 2023 at 04:23:48PM -0500, Bryan Steele wrote:
> On Tue, Jan 17, 2023 at 09:37:24PM +0100, Jan Klemkow wrote:
> > Hi,
> >
> > This diff adjust the manpage of mem(4) to be more accurate. You can
> > open(2) mem(4) in securelevel 1 in readonly mode, but
Hi,
This diff adjust the manpage of mem(4) to be more accurate. You can
open(2) mem(4) in securelevel 1 in readonly mode, but not writable.
kern/spec_vnops.c:
if (ap->a_cred != FSCRED && (ap->a_mode & FWRITE)) {
...
/*
* When running in
Hi,
if you build the kernel without IPSEC it will run into several compiler
and linker errors. This diff add some missing #ifdefs to fix this.
ok?
bye,
jan
Index: net/if_pfsync.c
===
RCS file:
Hi,
We have a lot of redundant code on the network device driver layer, that
parses the content of mbufs for ethernet, ip and tcp header. This diff
introduces a new function if_parse_packet() to centralize this feature.
It just refactors ix(4) and ixl(4) code because, I could test this cards
and
On Wed, Jan 12, 2022 at 05:54:07PM +0100, Mark Kettenis wrote:
> > Date: Wed, 12 Jan 2022 17:45:57 +0100
> > From: Jan Klemkow
> >
> > On Wed, Jan 12, 2022 at 05:36:01PM +0100, Mark Kettenis wrote:
> > > > Date: Wed, 12 Jan 2022 17:02:03 +0100
> >
Hello,
This diff harmonises the indentation of struct members and comments in
several manpages. Also fixes line wraps of comments on 80 column
terminals. General uses tabs for general indentation and 4 spaces on
tight spots. Also uses extra space to align pointers and non-pointers
as we do
On Tue, Oct 26, 2021 at 05:17:55PM +1000, Jonathan Matthew wrote:
> First of all, thanks for looking at this, I forgot we hadn't done offloads
> for ixl(4) yet.
You're welcome.
> In the case of ixl(4), the driver has to tell the nic the length of each of
> the
> packet headers, so it should
On Fri, Oct 22, 2021 at 03:39:01PM +0200, Hrvoje Popovski wrote:
> On 22.10.2021. 13:39, Jan Klemkow wrote:
> > Thats because, you only see this flags, if the checksum offloading is
> > enabled for "sending". I'm still working/debugging on the sending side.
>
Hi,
this diff add hardware checksum offloading for the receive path of
ixl(4) interfaces.
Tested on:
ixl1 at pci3 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 1, FW 6.0.48442
API 1.7, msix, 8 queues, address 40:a6:b7:02:38:3d
OK?
Index: dev/pci/if_ixl.c
On Fri, Oct 22, 2021 at 12:01:41PM +0200, Hrvoje Popovski wrote:
> On 22.10.2021. 11:25, Jan Klemkow wrote:
> > this diff add hardware checksum offloading for the receive path of
> > ixl(4) interfaces.
> >
> > Tested on:
> > ixl1 at pci3 dev 0 function 1 "
On Thu, Apr 15, 2021 at 08:43:02PM +0200, Alexander Bluhm wrote:
> I found another regression with Jan's TCP diff that sends less ACK
> packets. relayd run-args-http-slow-consumer.pl fails on i386 due
> to his commit. This test writes a lot of data from the http server,
> but blocks receive for
Hi,
The card and cables don't have the signaling lines, that getty to use it
as com(4). But with "local" in ttys(5) it works. I have this driver in
productive use for about 5 years now.
OK?
bye,
Jan
Index: arch/amd64/conf/GENERIC
On Fri, Aug 06, 2021 at 12:06:04PM +0200, Patrick Wildt wrote:
> On Fri, Aug 06, 2021 at 11:05:53AM +0200, Patrick Wildt wrote:
> > Am Thu, Aug 05, 2021 at 02:33:01PM +0200 schrieb Jan Klemkow:
> > > Hi,
> > >
> > > The following diff removes useless code from
Hi,
The following diff removes useless code from the driver. As discussed
here [1] and committed there [2], the hypervisor doesn't do anything
with the data structures. We even just set NULL to the pointer since
the initial commit of vmx(4). So, I guess it better to remove all of
these. The
Hi,
This calculation of the receive window has a logic error:
If win is 0 it will be overwritten by (rcv_adv - rcv_nxt). Thus, win
will be (rcv_adv - rcv_nxt) even if its below (sb_hiwat / 4).
We could just remove the dead (sb_hiwat / 4) code, or reorder the
conditions to keep the original
Hi,
Convert K function definitions to modern C.
OK?
bye,
Jan
Index: ftpcmd.y
===
RCS file: /cvs/src/libexec/ftpd/ftpcmd.y,v
retrieving revision 1.72
diff -u -p -r1.72 ftpcmd.y
--- ftpcmd.y23 May 2021 17:01:21 - 1.72
ping?
On Thu, May 13, 2021 at 04:44:56PM +0200, Jan Klemkow wrote:
> ping?
>
> On Tue, May 04, 2021 at 10:50:50AM +0200, Jan Klemkow wrote:
> > Hi,
> >
> > The following diff adds some missing consts for char * to the internal
> > program functions.
&
ping?
On Thu, May 13, 2021 at 04:44:23PM +0200, Jan Klemkow wrote:
> ping?
>
> On Wed, May 05, 2021 at 04:42:49PM +0200, Jan Klemkow wrote:
> > Hi,
> >
> > The function lreply() already calls fflush(3) on stdout. So, this calls
> > are useless.
> >
>
ping?
On Thu, May 13, 2021 at 04:45:14PM +0200, Jan Klemkow wrote:
> ping?
>
> On Sat, May 01, 2021 at 11:19:56AM +0200, Jan Klemkow wrote:
> > Hi,
> >
> > This cleanup diff, removes a useless if islower(3) from the loop. It is
> > guarantee by toupper(3)
On Fri, May 07, 2021 at 04:18:50PM +0200, Martijn van Duren wrote:
> When moving the traphandler to the snmpe process I overlooked the fact
> that "type" is being saved inside the switch statement under the
> sm_context name. RFC3411 talks about pduType, and the name context means
> something
Hi,
This diff removes the useless FILE* parameter of get_line(). In every
call this parameter is always "stdin". Thus, we can replace ever use of
the variable iop with stdin.
Like every other diff, I tested this diff with the ftpd regression
tests.
OK?
bye,
Jan
Index: extern.h
On Thu, May 13, 2021 at 10:40:40AM -0600, Theo de Raadt wrote:
> + if (pledge("stdio rpath inet recvfd sendfd "
> + "wpath cpath proc tty getpw", NULL) == -1)
>
> Please change the order:
>
> stdio rpath wpath cpath inet recvfd
ping?
On Tue, May 04, 2021 at 10:50:50AM +0200, Jan Klemkow wrote:
> Hi,
>
> The following diff adds some missing consts for char * to the internal
> program functions.
>
> OK?
>
> bye,
> Jan
>
> Index: extern.h
> ==
ping?
On Sat, May 01, 2021 at 11:19:56AM +0200, Jan Klemkow wrote:
> Hi,
>
> This cleanup diff, removes a useless if islower(3) from the loop. It is
> guarantee by toupper(3) that no character will be changed if its not a
> lower one.
>
> man toupper(3):
> The
ping?
On Wed, May 05, 2021 at 04:42:49PM +0200, Jan Klemkow wrote:
> Hi,
>
> The function lreply() already calls fflush(3) on stdout. So, this calls
> are useless.
>
> OK?
>
> bye,
> Jan
>
> Index: ftpd.c
>
Hi,
This is the first attempt to bring pledge into ftpd. The Main ftpd
process can't use pledge for now because of possible chroot(2) calls.
But, the two forks after user login are pledged with this diff.
I tested it manually and with the ftpd's regression tests.
OK?
bye,
Jan
Index:
On Thu, May 06, 2021 at 11:09:03AM -0600, Theo de Raadt wrote:
> Jan Klemkow wrote:
>
> > > > > I'm working on a diff to bring ftps with libtls into our ftpd(8).
> > > > > There
> > > > > is a "getaddrinfo(NULL, "ftps", ,
On Thu, May 06, 2021 at 06:36:52PM +0200, Mark Kettenis wrote:
> > From: "Theo de Raadt"
> > Date: Thu, 06 May 2021 10:26:31 -0600
> >
> > Jan Klemkow wrote:
> >
> > > On Wed, May 05, 2021 at 12:18:43PM -0600, Theo de Raadt wrote:
> >
tcp, 32 of the 512 are locked out.
> For udp, 19.
>
> What software is actually using these ports?
>
> Is that software irrelevant these days?
I'm working on a diff to bring ftps with libtls into our ftpd(8). There
is a "getaddrinfo(NULL, "ftps", , )" call, which uses
Hi,
The function lreply() already calls fflush(3) on stdout. So, this calls
are useless.
OK?
bye,
Jan
Index: ftpd.c
===
RCS file: /cvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.229
diff -u -p -r1.229 ftpd.c
--- ftpd.c
On Wed, May 05, 2021 at 11:09:12AM +0100, Stuart Henderson wrote:
> On 2021/05/04 12:07, Jan Klemkow wrote:
> > Add missing ftps defaults ports to servies(5).
> >
> > Index: services
> > ===
> >
Hi,
Add missing ftps defaults ports to servies(5).
OK?
bye,
Jan
Index: services
===
RCS file: /cvs/src/etc/services,v
retrieving revision 1.99
diff -u -p -r1.99 services
--- services18 Feb 2021 02:30:29 - 1.99
+++
Hi,
The following diff adds some missing consts for char * to the internal
program functions.
OK?
bye,
Jan
Index: extern.h
===
RCS file: /cvs/src/libexec/ftpd/extern.h,v
retrieving revision 1.21
diff -u -p -r1.21 extern.h
---
Hi,
This cleanup diff, removes a useless if islower(3) from the loop. It is
guarantee by toupper(3) that no character will be changed if its not a
lower one.
man toupper(3):
The toupper() and toupper_l() functions convert a lower-case letter
to the corresponding upper-case letter.
Hi,
If you want to boot OpenBSD on an HP EliteBook 830 G7/G8, the bootloader
will hang while loading the kernel. Because, the UEFI loads the
bootloader on the same place in memory, where the bootloader will copy
the kernel. We are unable to load the kernel on arbitrary memory.
Thus, the
Hi,
I had the same issue a few days ago a server hardware of mine. I just
ran 'cvs up'. So, it looks like a generic bug in FFS and not related to
vmm.
OpenBSD 6.9-beta (GENERIC.MP) #396: Thu Mar 11 19:15:56 MST 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
ping
On Tue, Mar 09, 2021 at 03:49:32PM +0100, Jan Klemkow wrote:
> Hi,
>
> The verification of the https://ugos.ugm.ac.id certificate contains 2032
> subject alt names which leads to the following error in LibreSSL.
>
> # openssl s_client -connect ugos.ugm.ac.id:443
> ...
On Mon, Mar 15, 2021 at 01:35:28AM -0600, Theo de Raadt wrote:
> My comments are about the "text name", which goes into every kernel
> anyone compiles.
>
> It should be as short as possible.
Sorry, I missed that point.
> But the reason why 10G is incorrect is because surely the port can
>
On Sun, Mar 14, 2021 at 12:39:42PM -0600, Theo de Raadt wrote:
> > +product INTEL X710_10G_SFP_2 0x104e X710 10G SFP+
>
> You only need:
>
> X710 SFP+
>
> Adding 10G is incorrect.
OK?
Thanks,
Jan
Index: if_ixl.c
===
RCS file:
Hi,
This diff attaches the Intel x710 10G SFP+ NIC in ixl(4).
ixl2 at pci11 dev 0 function 2 "Intel X710 10G SFP+" rev 0x02: port 1, FW
8.1.63299 API 1.12, msix, 8 queues, address 3c:ec:ef:1f:c3:bc
ixl3 at pci11 dev 0 function 3 "Intel X710 10G SFP+" rev 0x02: port 3, FW
8.1.63299 API 1.12,
On Fri, Mar 12, 2021 at 11:56:00AM +0100, Mark Kettenis wrote:
> I believe this is what ark.intel.com calls a "Intel SSD DC P4510
> Series" part. Is that correct?
Yes, that is correct.
On Fri, Mar 12, 2021 at 10:00:54PM +1100, Jonathan Gray wrote:
> On Fri, Mar 12, 2021 at 11
Hi,
This diff add a missing PCI ID of an Intel NVMe disk. The disk works
after my last fix [1].
OK?
bye,
Jan
[1]: https://marc.info/?l=openbsd-tech=161418460303831
Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
Hi,
The verification of the https://ugos.ugm.ac.id certificate contains 2032
subject alt names which leads to the following error in LibreSSL.
# openssl s_client -connect ugos.ugm.ac.id:443
...
verify error:num=17:out of memory
...
The following diff sets the maximum number of SANs to the next
On Fri, Mar 05, 2021 at 09:22:28AM -0700, Theo de Raadt wrote:
> Fix dump() to convert subclass == NULL into something else, or maybe the
> fix should be in pci_subclass() itself.
My initial mistake was to use zero in an empty list. This leads to one
element in the list, which causes wrong list
On Fri, Mar 05, 2021 at 04:13:53PM +0100, Mark Kettenis wrote:
> > Date: Fri, 5 Mar 2021 12:05:38 +0100
> > From: Jan Klemkow
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> >
> > Hi,
> >
> > this diff adds the mis
Hi,
this diff adds the missing PCI classes Accelerator and Instrumentation.
Thus, we can replace a few unknown in its output:
- 0x0008: Class: 13 (unknown), Subclass: 00 (unknown),
+ 0x0008: Class: 13 Instrumentation, Subclass: 00 (null),
Both Classes have vendor specific APIs. So,
Hi,
The diff below adds a missing PCI device ID for an X710 10GBase NIC into
the ixl(4) driver. The interfaces attach and run properly with this
diff.
ixl0 at pci11 dev 0 function 0 "Intel X710 10GBaseT" rev 0x02: port 0, FW
8.1.63299 API 1.12, msix, 8 queues, address 3c:ec:ef:1f:c3:ba
ixl1 at
On Wed, Feb 24, 2021 at 09:21:56PM +0100, Theo Buehler wrote:
> On Wed, Feb 24, 2021 at 09:00:05PM +0100, Theo Buehler wrote:
> > On Wed, Feb 24, 2021 at 06:47:00AM +0100, Jan Klemkow wrote:
> > > another co-worker of mine has found an other regress in the LibreSSL
> > &g
Hi,
While attaching the following disks, the nvme driver runs into a NULL
dereference in nvme_scsi_capacity16() and nvme_scsi_capacity().
nvme0 at pci1 dev 0 function 0 vendor "Intel", unknown product 0x0a54 rev 0x00:
msix, NVMe 1.2
nvme0: INTEL SSDPE2KX040T8, firmware VDV10170, serial
lib/libcrypto/expcert/expcrt.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/libcrypto/expcert/expcrt.c 24 Feb 2021 05:27:46 -
@@ -0,0 +1,218 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2021 Jan Klemkow
+ * Copyright (c) 2021 Anton Borowka
+ *
+ * Permission to use, copy, modify, and di
On Tue, Feb 16, 2021 at 04:36:59AM +1100, Joel Sing wrote:
> On 21-02-15 14:49:46, Jan Klemkow wrote:
> > On Sat, Feb 13, 2021 at 03:53:48PM +0100, Theo Buehler wrote:
> > > On Sat, Feb 13, 2021 at 11:58:04AM +0100, Jan Klemkow wrote:
> > > > A coworker of mine h
On Tue, Feb 16, 2021 at 04:36:59AM +1100, Joel Sing wrote:
> On 21-02-15 14:49:46, Jan Klemkow wrote:
> > +create-libressl-test-certs: create-libressl-test-certs.pl
> > + ${PERL} ${.CURDIR}/$@.pl
>
> We can see how this goes, however we may end up wanting to genera
On Sat, Feb 13, 2021 at 03:53:48PM +0100, Theo Buehler wrote:
> On Sat, Feb 13, 2021 at 11:58:04AM +0100, Jan Klemkow wrote:
> > A coworker of mine has made tests with LibreSSL [1] and found some
> > regressions. I took his test descriptions and created the following
> > auto
Hi,
A coworker of mine has made tests with LibreSSL [1] and found some
regressions. I took his test descriptions and created the following
automated regression test. In the repository he described his findings
in detail. I kept the numbers of the files and subtests in the target
names for now.
On Mon, Feb 08, 2021 at 03:42:54PM +0100, Alexander Bluhm wrote:
> On Wed, Feb 03, 2021 at 11:20:04AM +0100, Claudio Jeker wrote:
> > Just commit it. OK claudio@
> > If people see problems we can back it out again.
>
> This has huge impact on TCP performance.
>
>
1 - 100 of 247 matches
Mail list logo
