The jiffies patch plus the patch in uvm_meter worked for me. It even booted a
little faster than normal.
On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev w
On Sat, Jul 29, 2023 at 11:16:14AM +0200, Claudio Jeker wrote:
> proc0 aka the swapper does not do anything. So there is no need to wake it
> up. Now the problem is that last time this was tried some inteldrm systems
> did hang during bootup because the drm code unexpectedly depended on this
> wake
Hello. The diff in this email removes dead code in uvm_pmr_getpages().
This had bothered me for a bit because I had intuitively believed it wasn't
necessary, but had never bothered to fully convince myself. Since I have now,
I'll share the reasoning.
This diff concerns the following bit of code:
There was a diff a while back (4 Dec 2019) that fixed a bad offset
calculation in this function, but it seems to me that it made a couple
other lines of code incorrect as a result. The diff below tweaks the
lines so that they have their original intent (based on looking at the
diff from when the fu
On Sun, Oct 23, 2022 at 05:51:41PM +0300, Mikhail wrote:
> On Sun, Oct 23, 2022 at 08:32:47AM -0600, Chris Waddey wrote:
> > So I've been following the work on this because I have a lenovo laptop
> > as well and the first patch you sent in I applied and have had
> >
Ping.
On Sun, Oct 09, 2022 at 08:01:01AM +0200, Martijn van Duren wrote:
> Bit focused on other things atm and not familiar with this part of the
> code, but some comments.
>
> On Sat, 2022-10-08 at 12:18 -0600, Chris Waddey wrote:
>> A message with a single successful re
On Sun, Oct 09, 2022 at 08:01:01AM +0200, Martijn van Duren wrote:
> Bit focused on other things atm and not familiar with this part of the
> code, but some comments.
>
> On Sat, 2022-10-08 at 12:18 -0600, Chris Waddey wrote:
>> A message with a single successful recipient
A message with a single successful recipient but with a failed
rcpt to: command afterward generates an incorrect Received: header.
The following produces the bug:
thief$ nc localhost 25
220 thief.private ESMTP OpenSMTPD
ehlo thief.private^M
250-thief.private Hello thief.private [127.0.0.1], pleas
new kernel with it, and everything seems to be working
okay. The locnamp array could definitely be compressed more, but at
least it's correct now.
Thank you,
Chris Waddey
Index: gram.y
===
RCS file: /cvs/src/usr.sbin/confi
I doubt this will ever matter, but I think this is correct. I hope this
isn't an annoying patch. Just trying to get my feet wet in the kernel.
It compiled and ran on my machine for what it's worth.
Chris Waddey
Ind
Except my the &'s in the diff are supposed to be &'s.
Index: pass2.c
===
RCS file: /cvs/src/sbin/fsck_ext2fs/pass2.c,v
retrieving revision 1.15
diff -u -p -r1.15 pass2.c
--- pass2.c 28 Apr 2016 12:17:15 - 1.15
+++ pass2.c
Hello all.
I while back I put an ext2 rev1 filesystem on my disk (not sure why
any more, but oh well). Whenever fsck ran, it stopped during pass2 with
the error message "wrong type to dirscan 0".
Long story short, it seems that a call to memset was writing zeros over
the curino structure because
Hello all.
I know this isn't necessary for quite a while, but in anticipation of
OpenBSD 10.0, I suggest the following diff to sysupgrade.sh:
Index: sysupgrade.sh
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
retrievi
13 matches
Mail list logo
