On Tue, Jun 01, 2021 at 01:43:32AM +0200, Leon Fischer wrote:
> The mkuboot(8) man page was not updated after this commit:
>
> RCS file: /cvs/src/usr.sbin/mkuboot/mkuboot.c,v
>
> revision 1.7
> date: 2016/12/20 11:27:11; author: jsg; state: Exp; lines: +3 -1;
>
My new Intel Z590-based machine seems to have some different kind of
Intel audio device onboard.
I couldn't find very much online about it (all the usual pci id
databases don't seem to have it yet). The only really useful thing I
found was this:
The mkuboot(8) man page was not updated after this commit:
RCS file: /cvs/src/usr.sbin/mkuboot/mkuboot.c,v
revision 1.7
date: 2016/12/20 11:27:11; author: jsg; state: Exp; lines: +3 -1; commitid:
fELL92HBrGHkYVvc;
Add the u-boot arm64 architecture number and map
On Tue, Jun 01, 2021 at 08:24:10AM +1000, David Gwynne wrote:
>
>
> > On 1 Jun 2021, at 04:17, Patrick Wildt wrote:
> >
> > Hi,
> >
> > this call to sync the DMA mem wants to sync N - 1 number of prpl
> > entries, as the first segment is configured regularly, while the
> > addresses for the
On Tue, Jun 01, 2021 at 08:20:43AM +1000, David Gwynne wrote:
>
>
> > On 1 Jun 2021, at 04:15, Patrick Wildt wrote:
> >
> > Hi,
> >
> > mcx(4) seems to sync the whole mapsize on processing a received packet.
> > As far as I know, we usually only sync the actual size that we have
> > received.
> On 1 Jun 2021, at 04:17, Patrick Wildt wrote:
>
> Hi,
>
> this call to sync the DMA mem wants to sync N - 1 number of prpl
> entries, as the first segment is configured regularly, while the
> addresses for the following segments (if more than 2), are in a
> special DMA memory.
>
> The
> On 1 Jun 2021, at 02:58, Visa Hankala wrote:
>
> This patch enables the pool cache feature on the knote pool to reduce
> the overhead of knote management.
>
> Profiling done by mpi@ and bluhm@ indicate that the potentially needless
> allocation of knotes in kqueue_register() causes
> On 1 Jun 2021, at 04:15, Patrick Wildt wrote:
>
> Hi,
>
> mcx(4) seems to sync the whole mapsize on processing a received packet.
> As far as I know, we usually only sync the actual size that we have
> received. Noticed this when doing bounce buffer tests, seeing that
> it copied a lot
Hello,
On Mon, May 31, 2021 at 02:33:00PM +1000, David Gwynne wrote:
> if you're looking at an ip header, it makes sense to do some checks to
> make sure that the values and addresses make some sense. the canonical
> versions of these checks are in the ipv4 and ipv6 input paths, which
> makes
There is an old fix of SB_MAX, increasing it to 2MB (instead of 256k) makes
TCP scaling factor 6 (instead of 3).
But the comment in the shifting remained with the old values.
Although it's just a comment, it might be very confusing.
diff --git a/sys/netinet/tcp_input.c b/sys/netinet/tcp_input.c
thanks Otto for the dmesg.
I'd like to get one B550 mobo as well. Which version of Gigabyte B550
AORUS ELITE do you have exactly? ATX? mATX ?
Most of them listed here[1] have either RLT8118 or RLT8125 chipset and
re(4) doesn't list them...
Can't find any reference to your model there[1] (RTL8168
Hi,
this call to sync the DMA mem wants to sync N - 1 number of prpl
entries, as the first segment is configured regularly, while the
addresses for the following segments (if more than 2), are in a
special DMA memory.
The code currently removes a single byte, instead of an entry.
This just means
Hi,
mcx(4) seems to sync the whole mapsize on processing a received packet.
As far as I know, we usually only sync the actual size that we have
received. Noticed this when doing bounce buffer tests, seeing that
it copied a lot more data than is necessary.
That's because the RX buffer size is
Hi all,
I've attached a diff to add table_procexec as a table backend
in smtpd(8). This imports the table_procexec from opensmtpd-extras,
which is available upstream but is not present in the port.
I've successfully replaced the standard aliases table
table aliases file:/etc/mail/aliases
with
This patch enables the pool cache feature on the knote pool to reduce
the overhead of knote management.
Profiling done by mpi@ and bluhm@ indicate that the potentially needless
allocation of knotes in kqueue_register() causes slowdown with
kqueue-based poll(2) and select(2).
One approach to fix
On Sat, May 01, 2021 at 06:59:59PM +0200, Martijn van Duren wrote:
> The parameters for ax_oid_cmp are swapped.
> This fixes the few failing regress tests I just committed.
>
> OK?
OK bluhm@
> Index: agentx.c
> ===
> RCS file:
On Mon, May 31, 2021 at 02:33:00PM +1000, David Gwynne wrote:
> this is mostly shuffling the deck chairs, but ipv6 is moved around a bit
> more than ipv4, so some eyes and tests would be appreciated.
Deck shuffling looks correct. OK bluhm@
> +int
> +ip6_input_if(struct mbuf **mp, int *offp, int
Frederic Cambus wrote:
> Does this look reasonable?
>
> If it does and if we want to go this way, I can try to build a release
> and check if MINIROOTSIZE must be bumped on RAMDISK_CD. Then we could do
> the same for i386, armv7 and arm64.
We need to see these results first.
On Mon, May 31, 2021 at 02:33:03PM +0300, Reuven Plevinsky wrote:
> Hi,
> Here is my diff:
> https://github.com/reuvenP/src/commit/db909be68a3b03e68787de55d218388f33c4c4c6
Not everyone wants to read diffs in a browser.
Sending your diff inline will work better, like this:
diff --git
Hi,
Here is my diff:
https://github.com/reuvenP/src/commit/db909be68a3b03e68787de55d218388f33c4c4c6
There is an old fix of SB_MAX, increasing of it to 2MB (instead of 256k)
makes TCP scaling factor 6 (instead of 3).
But the comment in the shifting remained with the old values.
OpenBSD does not use pull requests. Please send your diff, with
explanation, in an email to this mailing list.
--
Sent from a phone, apologies for poor formatting.
On 31 May 2021 11:56:27 Reuven Plevinsky wrote:
https://github.com/reuvenP/src/commit/db909be68a3b03e68787de55d218388f33c4c4c6
> Date: Mon, 31 May 2021 12:21:39 +0200
> From: Frederic Cambus
>
> Hi tech@,
>
> The size of kernel fonts in RAMDISKs has long been a problem on systems
> with large screen resolutions booting via EFI, as currently only the 8x16
> font is built into RAMDISKs. As those systems are becoming more
https://github.com/reuvenP/src/commit/db909be68a3b03e68787de55d218388f33c4c4c6
Hi tech@,
The size of kernel fonts in RAMDISKs has long been a problem on systems
with large screen resolutions booting via EFI, as currently only the 8x16
font is built into RAMDISKs. As those systems are becoming more common, I
would like to revisit the topic.
Currently, we decide which font
24 matches
Mail list logo
