Yes, this is better
Theo Buehler wrote:
> LibreSSL portable uses base64.c. Not everyone has u_char, so this is a
> mild portability annoyance. This means that we can get rid of
> sys/types.h. I also removed stdio.h since that seems unused.
>
> As far as I can see, base64.c directly needs
>
>
On Fri, Oct 22, 2021 at 12:11:54PM +0200, Mark Kettenis wrote:
> > Date: Fri, 22 Oct 2021 05:09:25 +0100
> > From: Theo Buehler
> >
> > LibreSSL portable uses base64.c. Not everyone has u_char, so this is a
> > mild portability annoyance. This means that we can get rid of
> > sys/types.h. I also
On Fri, Oct 22, 2021 at 11:50:03AM +0200, Claudio Jeker wrote:
> flist_gen_dirent() does a fts_read and inside that tries to read the
> symlink information. Now since fts_open did not specifiy FTS_NOCHDIR
> the symlink_read call needs to use ent->fts_accpath instead of f->path
> which was based on
On 22.10.2021. 11:25, Jan Klemkow wrote:
> 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
>
>
This removes the last uses of u_int and u_char from the LibreSSL tree.
Index: chacha/chacha-merged.c
===
RCS file: /cvs/src/lib/libcrypto/chacha/chacha-merged.c,v
retrieving revision 1.9
diff -u -p -r1.9 chacha-merged.c
---
On Thu, Oct 21, 2021 at 04:45:47PM +0100, Stuart Henderson wrote:
> Sometimes I find it useful to list daemons which are set to 'disabled'
> but are actually running. Either those where I have started them by hand
> forgotten to enable in rc.conf.local, or to check for services which
> shouldn't
> Date: Fri, 22 Oct 2021 05:09:25 +0100
> From: Theo Buehler
>
> LibreSSL portable uses base64.c. Not everyone has u_char, so this is a
> mild portability annoyance. This means that we can get rid of
> sys/types.h. I also removed stdio.h since that seems unused.
>
> As far as I can see,
flist_gen_dirent() does a fts_read and inside that tries to read the
symlink information. Now since fts_open did not specifiy FTS_NOCHDIR
the symlink_read call needs to use ent->fts_accpath instead of f->path
which was based on ent->fts_path.
OK?
--
:wq Claudio
Index: flist.c
This diff makes pipe event filters ready to run without the kernel lock.
The code pattern in the callbacks is the same as in sockets. Pipes
have a klist lock already.
So far, pipe event filters have used read-locking. The patch changes
that to write-locking for clarity. This should not be a real
On 22.10.2021. 13:39, Jan Klemkow wrote:
> Hi Hrvoje,
>
> Thats because, you only see this flags, if the checksum offloading is
> enabled for "sending". I'm still working/debugging on the sending side.
> Thus, I just send a diff with the receiving part for now.
>
> You can see if its working
On 22 October 2021 13:55:20 CEST, Stuart Henderson wrote:
>On 2021/10/22 11:25, Jan Klemkow wrote:
>> this diff add hardware checksum offloading for the receive path of
>> ixl(4) interfaces.
>
>Would be good to have this tested with NFS if anyone has a way to do so.
>nics are probably better
We document them as explicitly required, `unwind -dnvf...' spits them
out like this and the last `force' example uses them as well.
OK?
Index: unwind.conf.5
===
RCS file: /cvs/src/sbin/unwind/unwind.conf.5,v
retrieving revision 1.30
On Fri, Oct 22, 2021 at 04:45:09PM +0200, Hrvoje Popovski wrote:
> On 22.10.2021. 16:09, Florian Obser wrote:
> >
> >
> > On 22 October 2021 13:55:20 CEST, Stuart Henderson
> > wrote:
> >> On 2021/10/22 11:25, Jan Klemkow wrote:
> >>> this diff add hardware checksum offloading for the receive
Claudio Jeker wrote:
> For ospfd tests you want to make sure that some of the ospf packets need
> fragmenting. So this needs a sizeable network to hit this.
Yes, as I remember, the problems only related to fragments of large
packets.
These tests are too narrow and the results inconclusive.
On 22.10.2021. 16:53, Claudio Jeker wrote:
> On Fri, Oct 22, 2021 at 04:45:09PM +0200, Hrvoje Popovski wrote:
>> On 22.10.2021. 16:09, Florian Obser wrote:
>>>
>>>
>>> On 22 October 2021 13:55:20 CEST, Stuart Henderson
>>> wrote:
On 2021/10/22 11:25, Jan Klemkow wrote:
> this diff add
Last year we added the new EVFILT_EXCEPT filter type to kqueue in
order to report conditions currently available via POLLPRI/POLLRDBAND
in poll(2) and select(2).
This new filter has been implemented in tty and socket by re-using the
existing kqueue's "read" filter. This has a downside which is
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 22.10.2021. 16:57, Theo de Raadt wrote:
> Claudio Jeker wrote:
>
>> For ospfd tests you want to make sure that some of the ospf packets need
>> fragmenting. So this needs a sizeable network to hit this.
>
> Yes, as I remember, the problems only related to fragments of large
> packets.
>
>
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 "Intel X710 SFP+" rev 0x02: port 1, FW
>
the nfs issues related to fragments being incorrectly labelled as
checksummed. I am vague on whether this was hardware incorrectly indicating
checksum valid in damaged packets. of course, that was nothing compared
to the astoundingly nasty v6 checksum hardware bug in tht(4)...
Hrvoje Popovski
On Fri, Oct 22, 2021 at 02:25:18PM +0100, Martin Pieuchot wrote:
> Last year we added the new EVFILT_EXCEPT filter type to kqueue in
> order to report conditions currently available via POLLPRI/POLLRDBAND
> in poll(2) and select(2).
>
> This new filter has been implemented in tty and socket by
On Thu, Oct 21, 2021 at 03:04:22PM +0300, Vitaliy Makkoveev wrote:
> With this diff the `tdb' dereference after tdb_free() is safe enough and
> I have no objections against your diff.
My diff did not make things worse, it counted the drops earlier.
But I decided to drop that part, I would like
On 22/10/21(Fri) 13:15, Visa Hankala wrote:
> This diff makes pipe event filters ready to run without the kernel lock.
> The code pattern in the callbacks is the same as in sockets. Pipes
> have a klist lock already.
>
> So far, pipe event filters have used read-locking. The patch changes
> that
On Fri, Oct 22, 2021 at 01:39:47PM +0200, Jan Klemkow wrote:
> 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:
> >
Here is another attempt to set klist lock for sockets. This is a revised
version of a patch that I posted in January [1].
Using solock() for the klists is probably the easiest way at the time
being. However, the lock is a potential point of contention because of
the underlying big-lock design.
Stuart Henderson(s...@spacehopper.org) on 2021.10.22 12:55:20 +0100:
> On 2021/10/22 11:25, Jan Klemkow wrote:
> > this diff add hardware checksum offloading for the receive path of
> > ixl(4) interfaces.
>
> Would be good to have this tested with NFS if anyone has a way to do so.
> nics are
On 22.10.2021. 16:09, Florian Obser wrote:
>
>
> On 22 October 2021 13:55:20 CEST, Stuart Henderson
> wrote:
>> On 2021/10/22 11:25, Jan Klemkow wrote:
>>> this diff add hardware checksum offloading for the receive path of
>>> ixl(4) interfaces.
>>
>> Would be good to have this tested with NFS
On 22.10.2021. 16:22, Sebastian Benoit wrote:
> Stuart Henderson(s...@spacehopper.org) on 2021.10.22 12:55:20 +0100:
>> On 2021/10/22 11:25, Jan Klemkow wrote:
>>> this diff add hardware checksum offloading for the receive path of
>>> ixl(4) interfaces.
>>
>> Would be good to have this tested with
On Fri, 22 Oct 2021 14:25:18 +0100, Martin Pieuchot wrote:
> Last year we added the new EVFILT_EXCEPT filter type to kqueue in
> order to report conditions currently available via POLLPRI/POLLRDBAND
> in poll(2) and select(2).
>
> This new filter has been implemented in tty and socket by re-using
On Oct 22, 2021, at 7:55 AM, Stuart Henderson wrote:
>
> On 2021/10/22 11:25, Jan Klemkow wrote:
>> this diff add hardware checksum offloading for the receive path of
>> ixl(4) interfaces.
>
> Would be good to have this tested with NFS if anyone has a way to do so.
> nics are probably better
On 22.10.2021. 13:55, Stuart Henderson wrote:
> On 2021/10/22 11:25, Jan Klemkow wrote:
>> this diff add hardware checksum offloading for the receive path of
>> ixl(4) interfaces.
>
> Would be good to have this tested with NFS if anyone has a way to do so.
> nics are probably better now but I'm
> On 22 Oct 2021, at 18:23, Alexander Bluhm wrote:
>
> On Thu, Oct 21, 2021 at 03:04:22PM +0300, Vitaliy Makkoveev wrote:
>> With this diff the `tdb' dereference after tdb_free() is safe enough and
>> I have no objections against your diff.
>
> My diff did not make things worse, it counted
unwind(8) gives the most preferred resolver strategy a bit more time
(200ms) to answer before trying the next strategy. However, we need to
skip strategies that are not available. In the default configuration,
without a config file, unwind(8) would give DoT 200ms more time, but no
DoT forwarders
On 2021/10/22 12:20, Antoine Jacoutot wrote:
> On Thu, Oct 21, 2021 at 04:45:47PM +0100, Stuart Henderson wrote:
> > Sometimes I find it useful to list daemons which are set to 'disabled'
> > but are actually running. Either those where I have started them by hand
> > forgotten to enable in
On 2021/10/22 11:25, Jan Klemkow wrote:
> this diff add hardware checksum offloading for the receive path of
> ixl(4) interfaces.
Would be good to have this tested with NFS if anyone has a way to do so.
nics are probably better now but I'm pretty sure we have had problems
with NFS and offloading
Mutex and rwlock assertions turn into no-ops when compiling without
the DIAGNOSTIC option, which is the desired outcome. However, in some
peculiar cases, such as klist_mutex_assertlk() and klist_rwlock_assertlk(),
the lock variable insidiously becomes unused in the function. This could
be avoided
On 22/10/21(Fri) 13:11, Visa Hankala wrote:
> Here is another attempt to set klist lock for sockets. This is a revised
> version of a patch that I posted in January [1].
>
> Using solock() for the klists is probably the easiest way at the time
> being. However, the lock is a potential point of
On 17/10/21(Sun) 09:06, Christopher Zimmermann wrote:
> Hi,
>
> on my RK3399, a usb device connected to the USB 3 port is not detected
> during boot because it is in SS_INACTIVE (0x00c0) state:
>
> uhub3 at usb3 configuration 1 interface 0 "Generic xHCI root hub" rev
> 3.00/1.00 addr 1
> uhub3:
Le 22/10/2021 à 13:56, Stuart Henderson a écrit :
On 2021/10/22 12:20, Antoine Jacoutot wrote:
On Thu, Oct 21, 2021 at 04:45:47PM +0100, Stuart Henderson wrote:
Sometimes I find it useful to list daemons which are set to 'disabled'
but are actually running. Either those where I have started
On Fri, Oct 22, 2021 at 06:10:32PM +0200, Florian Obser wrote:
>
> unwind(8) gives the most preferred resolver strategy a bit more time
> (200ms) to answer before trying the next strategy. However, we need to
> skip strategies that are not available. In the default configuration,
> without a
Hi,
I found a m_pullup() down in ah input. As it may free or change
the mbuf, the caller must be careful. All callers do not use the
mbuf, so we are safe. Nevertheless I would like to use a common
pattern to handle this. Pass down an mbuf pointer mp and let
m_pullup() update the pointer in
On Sat, Oct 16, 2021 at 03:13:39PM +0300, Mikhail wrote:
> Hello, I was troubleshooting postgresql not being able to start after
> 'pkill -6 postgres'. The error was:
>
> FATAL: could not create semaphores: No space left on device
> DETAIL: Failed system call was semget(78927, 17, 03600).
> HINT:
On 2021/10/22 12:56, Stuart Henderson wrote:
> On 2021/10/22 12:20, Antoine Jacoutot wrote:
> > On Thu, Oct 21, 2021 at 04:45:47PM +0100, Stuart Henderson wrote:
> > > Sometimes I find it useful to list daemons which are set to 'disabled'
> > > but are actually running. Either those where I have
On Fri, Oct 22, 2021 at 07:27:28PM +0100, Stuart Henderson wrote:
> On 2021/10/22 12:56, Stuart Henderson wrote:
> > On 2021/10/22 12:20, Antoine Jacoutot wrote:
> > > On Thu, Oct 21, 2021 at 04:45:47PM +0100, Stuart Henderson wrote:
> > > > Sometimes I find it useful to list daemons which are set
On Thu, 21 Oct 2021 18:58:53 -0500
Ryan Farley wrote:
> Hello,
>
> Based on the history it seems that the drm code is now used for AMD/ATI
> graphics hardware, leaving those with lowly old nvidia cards (which
> can't be replaced in the case of my powerbook) to rely on xf86-video-nv
> for a
45 matches
Mail list logo
