On Wed, Jun 16, 2021 at 11:40:08PM -0600, Gavin Howard wrote:
> Hello,
>
> My name is Gavin Howard. I have developed a new bc(1) and dc(1)
> implementation. [0]
>
> I propose replacing the current implementations with mine.
>
> Advantages:
>
> * Performance. [1]
> * Extensions for ease of
> [1] https://www.gigabyte.com/Motherboard/AORUS-Gaming
> [2] https://www.gigabyte.com/Motherboard/B550-AORUS-ELITE-rev-10/sp#sp
>
> On Fri, Nov 20, 2020 at 9:28 AM Otto Moerbeek wrote:
> >
> > Hi,
> >
> > I got a new Ryzen machine, dmesg below. What I'm observ
On Sun, May 02, 2021 at 02:07:21PM +0200, Mark Kettenis wrote:
> > From: Martijn van Duren
> > Date: Sun, 02 May 2021 13:28:10 +0200
> >
> > Found this while tracing a memory leak in filter-dkimsign, thanks to
> > libcrypto. The mutex in pthread_once_t is never destroyed, so the
> > memory
On Sun, Apr 25, 2021 at 06:41:09PM +0200, Mark Kettenis wrote:
> > Date: Sun, 25 Apr 2021 17:53:31 +0200
> > From: Otto Moerbeek
> >
> > Hi,
> >
> > A local test and jca@ confirm the special casing isn't needed anymore.
> >
> > Two things:
Hi,
A local test and jca@ confirm the special casing isn't needed anymore.
Two things:
- This could do with a ports bulk build to find other offenders
- Would this require a libc bump?
-Otto
Index: hidden/stdlib.h
===
On Fri, Apr 09, 2021 at 07:39:05AM +0200, Theo Buehler wrote:
> On Fri, Apr 09, 2021 at 07:36:35AM +0200, Otto Moerbeek wrote:
> > On Thu, Apr 01, 2021 at 11:23:58AM +0200, Otto Moerbeek wrote:
> >
> > > Hi,
> > >
> > > here's a small malloc diff
On Thu, Apr 01, 2021 at 11:23:58AM +0200, Otto Moerbeek wrote:
> Hi,
>
> here's a small malloc diff. Most important part is an extra internal
> consistency check. I have been running this for a few week already,
ping?
>
> -Otto
>
>
Hi,
here's a small malloc diff. Most important part is an extra internal
consistency check. I have been running this for a few week already,
-Otto
Index: stdlib/malloc.3
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v
On Mon, Mar 22, 2021 at 03:20:37PM +0100, Mischa wrote:
>
>
> > On 22 Mar 2021, at 15:18, Otto Moerbeek wrote:
> >
> > On Mon, Mar 22, 2021 at 03:06:40PM +0100, Mischa wrote:
> >
> >>> On 22 Mar 2021, at 15:05, Dave Voutila wrote:
> >>
On Mon, Mar 22, 2021 at 03:06:40PM +0100, Mischa wrote:
> > On 22 Mar 2021, at 15:05, Dave Voutila wrote:
> > Otto Moerbeek writes:
> >> On Mon, Mar 22, 2021 at 09:51:19AM -0400, Dave Voutila wrote:
> >>> Otto Moerbeek writes:
> >>>> On Mon
On Mon, Mar 22, 2021 at 01:59:17PM +, Stuart Henderson wrote:
> > > I'm more familiar with the vmd(8) codebase than any ffs stuff, but I
> > > don't think the issue is the base image being r/w.
> >
> > AFAIKS, the issue is that if you start a vm modifying the base because it
> > uses it as a
On Mon, Mar 22, 2021 at 09:51:19AM -0400, Dave Voutila wrote:
>
> Otto Moerbeek writes:
>
> > On Mon, Mar 22, 2021 at 01:47:18PM +0100, Mischa wrote:
> >
> >>
> >>
> >> > On 22 Mar 2021, at 13:43, Stuart Henderson wrote:
> >> >
On Mon, Mar 22, 2021 at 01:47:18PM +0100, Mischa wrote:
>
>
> > On 22 Mar 2021, at 13:43, Stuart Henderson wrote:
> >
> >>> Created a fresh install qcow2 image and derived 35 new VMs from it.
> >>> Then I started all the VMs in four cycles, 10 VMs per cycle and waiting
> >>> 240 seconds
On Mon, Mar 22, 2021 at 11:34:25AM +0100, Mischa wrote:
> > On 21 Mar 2021, at 02:31, Theo de Raadt wrote:
> > Otto Moerbeek wrote:
> >> On Fri, Mar 19, 2021 at 04:15:31PM +, Stuart Henderson wrote:
> >>
> >>> On 2021/03/19 17:05, Jan Klemkow wrote
On Sun, Mar 21, 2021 at 02:38:42PM +0100, Florian Obser wrote:
>
> Don't warn that we can't form a temporary address when a router
> deprecates a prefix by sending a pltime of 0, this is normal.
> Continue warning when the pltime is smaller than 5 as this is almost
> certainly a configuration
On Fri, Mar 19, 2021 at 04:15:31PM +, Stuart Henderson wrote:
> On 2021/03/19 17:05, Jan Klemkow wrote:
> > 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.
>
> This panic
On Sat, Mar 13, 2021 at 12:08:52AM -0800, Mike Larkin wrote:
> On Wed, Mar 10, 2021 at 08:30:32PM +0100, Mischa wrote:
> > On 10 Mar at 18:59, Mike Larkin wrote:
> > > On Wed, Mar 10, 2021 at 03:08:21PM +0100, Mischa wrote:
> > > > Hi All,
> > > >
> > > > Currently I am running 6.9-beta on one
On Tue, Mar 09, 2021 at 09:12:03AM +0100, Otto Moerbeek wrote:
> Hi,
>
> I just committed a malloc change that is interesting. It has been in
> snaps already for a while.
>
> It changes the malloc cache to be a little more friendly to the
> kernel, mallocs tendency to sp
Hi,
I just committed a malloc change that is interesting. It has been in
snaps already for a while.
It changes the malloc cache to be a little more friendly to the
kernel, mallocs tendency to split large allocations into page-sized ones
was giving the kernel a hard time in some cases.
By
On Tue, Feb 23, 2021 at 06:23:22PM +1100, Jonathan Gray wrote:
> On Tue, Feb 23, 2021 at 08:10:54AM +0100, Otto Moerbeek wrote:
> > On Mon, Feb 22, 2021 at 08:58:07PM -, Miod Vallat wrote:
> >
> > >
> > > > No problem, real-life often takes precedence.
&g
On Mon, Feb 22, 2021 at 08:58:07PM -, Miod Vallat wrote:
>
> > No problem, real-life often takes precedence.
>
> No way! operator(7) would need an update!
>
What do we do when we see a bug? We fix it! What if it is not fixable?
We document it!
-Otto
Index: operator.7
On Mon, Feb 22, 2021 at 11:09:41AM +0200, Paul Irofti wrote:
> > - investigate the commit you mention above. Sadly I cannot
> >remember the original case that prompted for the caching code to
> > be
> >added.
>
> Sorry I could not reply earlier.
No problem,
On Sat, Feb 20, 2021 at 06:30:23PM +0100, Mark Kettenis wrote:
> > Date: Sat, 20 Feb 2021 18:23:26 +0100
> > From: Otto Moerbeek
> > Cc: tech@openbsd.org, piro...@openbsd.org
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> >
On Fri, Feb 19, 2021 at 05:29:31PM +0100, Mark Kettenis wrote:
> > Date: Fri, 19 Feb 2021 16:43:10 +0100
> > From: Otto Moerbeek
> >
> > On Fri, Feb 19, 2021 at 01:06:43PM +0100, Otto Moerbeek wrote:
> >
> > > On Fri, Feb 19, 2021 at 12:45:58PM +0100, Mar
On Fri, Feb 19, 2021 at 01:06:43PM +0100, Otto Moerbeek wrote:
> On Fri, Feb 19, 2021 at 12:45:58PM +0100, Mark Kettenis wrote:
>
> > > Date: Fri, 19 Feb 2021 10:57:30 +0100
> > > From: Otto Moerbeek
> > >
> > > Hi,
> > >
> > &
On Fri, Feb 19, 2021 at 12:45:58PM +0100, Mark Kettenis wrote:
> > Date: Fri, 19 Feb 2021 10:57:30 +0100
> > From: Otto Moerbeek
> >
> > Hi,
> >
> > working on PowerDNS Recursor, once in a while I'm seeing:
> >
> > #0 0x09fd67
Hi,
working on PowerDNS Recursor, once in a while I'm seeing:
#0 0x09fd67ef09dc in
libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT_COLOR
(this=,
head=0x9fd67efc8e8 , elm=0x9fca04be900)
at
/usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:243
243
On Thu, Feb 18, 2021 at 03:24:36PM -0600, Luke Small wrote:
> However, calloc(ptr, nmemb, size) may have been called using smaller int
> variable types which would overflow when multiplied. Where if the variables
> storing the values passed to nmemb and size are less than or especially
> equal to
On Fri, Feb 12, 2021 at 02:48:34PM +0100, Otto Moerbeek wrote:
> On Fri, Feb 12, 2021 at 02:18:08PM +0100, Otto Moerbeek wrote:
>
> > Hi,
> >
> > Curently, junking is done like this:
> >
> > - for small chunk, the whole chunk junked on free
> >
> &
On Wed, Feb 17, 2021 at 11:05:49AM -0700, Theo de Raadt wrote:
> Luke Small wrote:
>
> > I guess I always thought there'd be some more substantial overflow
> > mitigation.
>
> You have to free with the exact same size as allocation.
Small correction: the size may be smaller than the
On Fri, Feb 12, 2021 at 02:18:08PM +0100, Otto Moerbeek wrote:
> Hi,
>
> Curently, junking is done like this:
>
> - for small chunk, the whole chunk junked on free
>
> - for pages sized and larger, the first half a page is filled
>
> - after a delayed free, the fir
Hi,
Curently, junking is done like this:
- for small chunk, the whole chunk junked on free
- for pages sized and larger, the first half a page is filled
- after a delayed free, the first 32 bytes of small chunks are
validated to not be overwritten
- page sized and larger allocations are not
On Mon, Feb 01, 2021 at 10:24:31PM -0500, Philippe Meunier wrote:
> Anyone?
Fixing a particluar issue is fine, but more important is an assessment
it does not break other things. In particular, does this limit the VM
for data available to any program (which is already quite limited on
i386)?
On Sun, Jan 24, 2021 at 01:01:45PM -0700, Alex Henrie wrote:
> On Sun, Jan 24, 2021 at 10:51 AM Otto Moerbeek wrote:
> >
> > Please stop pushing your diff to this list. So far nobody showed any
> > interest.
>
> I am definitely interested. Bernhard Voelker seemed to
On Sun, Jan 24, 2021 at 07:24:07PM +0100, Florian Obser wrote:
> On Sun, Jan 24, 2021 at 01:06:31PM +0100, Klemens Nanni wrote:
> > On Sun, Jan 24, 2021 at 12:52:50PM +0100, Theo Buehler wrote:
> > > Probably better to sync first with the corresponding unbound commit
> > >
On Sun, Jan 24, 2021 at 01:18:46PM +0100, Alejandro Colomar wrote:
> This is useful for using tee to just write to a file,
> at the end of a pipeline,
> without having to redirect to /dev/null
>
> Example:
>
> echo 'foo' | sudo tee -q /etc/foo;
>
> is equivalent to the old (and ugly)
You keep
On Sat, Jan 23, 2021 at 03:28:01PM +, Stuart Henderson wrote:
> [cc's trimmed]
>
> On 2021/01/23 15:53, Alejandro Colomar wrote:
> > This is useful for using tee to just write to a file,
> > at the end of a pipeline,
> > without having to redirect to /dev/null
> >
> > Example:
> >
> > echo
As reported on misc@
https://marc.info/?l=openbsd-misc=161016188503894=2
-Otto
Index: regular.c
===
RCS file: /cvs/src/usr.bin/cmp/regular.c,v
retrieving revision 1.12
diff -u -p -r1.12 regular.c
--- regular.c 6 Feb 2015
On Mon, Jan 04, 2021 at 05:50:53PM +0100, Otto Moerbeek wrote:
> tOn Mon, Jan 04, 2021 at 01:42:48PM +0100, Theo Buehler wrote:
>
> > > > + return log_sockaddr(addr2sa(addr, 0, ), len);
> > >
> > > Perhaps I haven't yet had enough coffee thi
On Mon, Jan 04, 2021 at 06:03:46PM +0100, Mark Kettenis wrote:
> > Date: Sun, 3 Jan 2021 13:47:45 +0100
> > From: Otto Moerbeek
> >
> > On Thu, Dec 31, 2020 at 05:54:06PM +0100, Alexander Bluhm wrote:
> >
> > > On Tue, Dec 29, 2020 at 04:07:19PM +0100, O
tOn Mon, Jan 04, 2021 at 01:42:48PM +0100, Theo Buehler wrote:
> > > + return log_sockaddr(addr2sa(addr, 0, ), len);
> >
> > Perhaps I haven't yet had enough coffee this year, but I'm unsure
> > whether it is actually guaranteed that addr2sa() is called before the
> > second len in this
On Thu, Dec 31, 2020 at 05:54:06PM +0100, Alexander Bluhm wrote:
> On Tue, Dec 29, 2020 at 04:07:19PM +0100, Otto Moerbeek wrote:
> > This workds better, checking the flags does not work if the thread is
> > already on the road to desctruction.
>
> This diff survived a full
On Thu, Dec 31, 2020 at 10:09:36PM +0100, Mark Kettenis wrote:
> The diff below changes the emulated Linux memory allocation functions
> a bit such that they only use malloc(9) for allocations smaller than a
> page. This reduces pressure on the "interrupt safe" map and hopefully
> will avoid the
On Tue, Dec 29, 2020 at 01:42:57PM +0100, Otto Moerbeek wrote:
> On Tue, Dec 29, 2020 at 12:46:54PM +0100, Mark Kettenis wrote:
>
> > > Date: Tue, 29 Dec 2020 12:21:25 +0100
> > > From: Otto Moerbeek
> > >
> > > Hi,
> > >
&g
On Tue, Dec 29, 2020 at 12:46:54PM +0100, Mark Kettenis wrote:
> > Date: Tue, 29 Dec 2020 12:21:25 +0100
> > From: Otto Moerbeek
> >
> > Hi,
> >
> > this is a continuation from the threads on bugs@
> >
> > This version makes it explicit t
Hi,
this is a continuation from the threads on bugs@
This version makes it explicit to *only* setup "TLS" (which actually
is just a pointer to static data) with the data provided if we're
running single threaded (ie.. no -pthread or -pthread but no pthread
function that triggers multi-threaded
On Wed, Dec 23, 2020 at 12:35:46PM +0800, Kevin Lo wrote:
> Hi,
>
> This diff implements WoL support in rge(4). I can wakeup the machine with WoL
> after suspending it through `zzz` or powering off it through `halt -p`.
Thanks! This works as expected in my testing.
-Otto
>
> Index:
On Sun, Dec 20, 2020 at 02:34:09PM +0100, Claudio Jeker wrote:
> On Sun, Dec 20, 2020 at 01:39:57PM +0100, Otto Moerbeek wrote:
> > Hi,
> >
> > scope is there, just not shown. While there, use proper constants for
> > two sizes.
> >
> >
Hi,
scope is there, just not shown. While there, use proper constants for
two sizes.
-Otto
Index: ktrstruct.c
===
RCS file: /cvs/src/usr.bin/kdump/ktrstruct.c,v
retrieving revision 1.28
diff -u -p -r1.28 ktrstruct.c
---
On Sun, Dec 20, 2020 at 10:48:01AM +0100, Florian Obser wrote:
> On Thu, Dec 17, 2020 at 12:15:16PM +0100, Otto Moerbeek wrote:
> > Hi,
>
> >
> > as noted on misc dig does not like to talk to local link addresses.
> > This fixes that case. While investig
Hi,
as noted on misc dig does not like to talk to local link addresses.
This fixes that case. While investigating I also found another bug:
selecting v6 or v4 addresses only from resolv.conf via the -4 or -6
command line argument does not work as expected.
This fixes both. I did not test binding
On Sun, Dec 06, 2020 at 03:31:19PM +, SW wrote:
> On 06/12/2020 14:32, Otto Moerbeek wrote:
> > On Sun, Dec 06, 2020 at 02:19:05PM +, SW wrote:
> >
> >> Hi,
> >> I've been looking to have syspatch give me a quick indication of whether
> >> a r
On Sun, Dec 06, 2020 at 02:19:05PM +, SW wrote:
> Hi,
> I've been looking to have syspatch give me a quick indication of whether
> a reboot is likely to be required. As a quick and dirty check, I've just
> been treating "Were patches applied?" as the indicator.
>
> The following diff will
tOn Mon, Nov 23, 2020 at 01:53:01PM +0100, Solene Rapenne wrote:
> A common mistake when using dd is to create a file in /dev which
> fills up the space of / and may stay silent until / gets filled up
> by something else that will fail.
>
> Would it be OK to add this in /etc/daily?
>
> find
Hi,
I got a new Ryzen machine, dmesg below. What I'm observing might be a
issue with hw.setperf.
On startsup it shows:
hw.cpuspeed=3800
hw.setperf=100
If I lower hw.setperf to zero, the new state is reflect immediately in
hw.cpuspeed:
hw.cpuspeed=2200
On Fri, Nov 06, 2020 at 01:10:52AM +0100, Jan Klemkow wrote:
> Hi,
>
> bluhm and I make some network performance measurements and kernel
> profiling.
>
> Setup:Linux (iperf) -10gbit-> OpenBSD (relayd) -10gbit-> Linux (iperf)
>
> We figured out, that the kernel uses a huge amount of
On Fri, Oct 30, 2020 at 03:04:03PM +0100, Florian Obser wrote:
Love it,
-Otto
> $ obj/dig @1.1.1.1 dnssec-failed.org
>
> ; <<>> dig 9.10.8-P1 <<>> @1.1.1.1 dnssec-failed.org
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status:
OK?
-Otto
Index: tree.h
===
RCS file: /cvs/src/sys/sys/tree.h,v
retrieving revision 1.29
diff -u -p -r1.29 tree.h
--- tree.h 30 Jul 2017 19:27:20 - 1.29
+++ tree.h 10 Oct 2020 16:36:15 -
@@ -910,25
On Tue, Sep 29, 2020 at 08:17:54AM +0200, Otto Moerbeek wrote:
> Hi,
>
> until now, canary bytes (used by the C olption) were the same as the
> bytes used to junk (0xfd). This means that certain overwrites are not
> detected, like setting the high bit.
>
> This make
Hi,
this fixes an overwrite of spcl.c_addr. Taken form FreeBSD.
See https://marc.info/?l=openbsd-misc=160018252418088=2
-Otto
Index: tape.c
===
RCS file: /cvs/src/sbin/dump/tape.c,v
retrieving revision 1.45
diff -u -p
Hi,
until now, canary bytes (used by the C olption) were the same as the
bytes used to junk (0xfd). This means that certain overwrites are not
detected, like setting the high bit.
This makes the byte value used to write canaries random. I do not want
to complicate the code to handle all
On Mon, Sep 14, 2020 at 03:28:17PM +0200, Jasper Lievisse Adriaanse wrote:
> Hi,
>
> This diff adds support for the '&' and '|' operators, along with
> a new testcase.
>
> OK?
The precedence looks funny
I'd guess you want
%left '|'
%left '&'
%left '+' '-'
%left '/' '*'
To avoid suprises.
On Thu, Sep 03, 2020 at 07:03:14AM +0200, Theo Buehler wrote:
> The memset is not needed as recallocarray(3) does the zeroing already.
> (I also think the a->data == NULL check in the if clause is redundant,
> but I'm just suggesting to remove a bit that confused me)
ok,
-Otto
>
>
On Tue, Sep 01, 2020 at 11:56:36AM +0100, Stuart Henderson wrote:
> On 2020/08/31 08:39, Otto Moerbeek wrote:
> > A question from Theo made me think about realloc and come up with a
> > particular bad case for performance. I do not know if it happens in
> > practice, but
On Mon, Aug 31, 2020 at 11:25:51AM -0600, Theo de Raadt wrote:
> > Taking advantage of the sparse address space is smart and as 64-bit
> > is now the norm, that space is even sparser.
>
> Fundamentally this is moving various forms of pressure to the kernel,
> which does not do the best job yet.
On Mon, Aug 31, 2020 at 08:28:25AM -0400, David Higgs wrote:
> On Mon, Aug 31, 2020 at 2:41 AM Otto Moerbeek wrote:
>
> > Hi,
> >
> > A question from Theo made me think about realloc and come up with a
> > particular bad case for performance. I do not know
Hi,
A question from Theo made me think about realloc and come up with a
particular bad case for performance. I do not know if it happens in
practice, but it was easy to create a test program to hit the case.
We're talking allocation >= a page here. Smaller allocation follow
different rules.
If
On Sat, Aug 22, 2020 at 03:51:48PM +0200, Otto Moerbeek wrote:
> Hi,
>
> At the moment ntpd never goes into unsynced mode if network
> connectivity is lost. The code to do that is only triggered when a
> pakcet is received, which does not happen.
>
> This diff fixes that b
On Tue, Aug 25, 2020 at 07:05:31PM +0200, Matthias Schmidt wrote:
> Hi Otto,
>
> * Otto Moerbeek wrote:
> > Hi,
> >
> > At the moment ntpd never goes into unsynced mode if network
> > connectivity is lost. The code to do that is only triggered when a
&
Hi,
At the moment ntpd never goes into unsynced mode if network
connectivity is lost. The code to do that is only triggered when a
pakcet is received, which does not happen.
This diff fixes that by going into unsynced mode if no time data was
processed for a while.
An earlier version of this
On Wed, Jul 15, 2020 at 09:08:29AM -0500, Scott Cheloha wrote:
> Hi,
>
> adjtime(2) skews the clock at up to 5000ppm per second. The way this
> actually happens is pretty straightforward: at the start of every UTC
> second we call ntp_update_second() from tc_windup() and reset
> th_adjustment.
On Sun, Jul 12, 2020 at 11:07:05AM +0200, Solene Rapenne wrote:
> On Sun, 12 Jul 2020 09:13:47 +0200
> Otto Moerbeek :
>
> > On Mon, Jun 29, 2020 at 02:30:41PM +0200, Otto Moerbeek wrote:
> >
> > > On Sun, Jun 21, 2020 at 03:35:21PM +0200, Otto Moerb
On Mon, Jun 29, 2020 at 02:30:41PM +0200, Otto Moerbeek wrote:
> On Sun, Jun 21, 2020 at 03:35:21PM +0200, Otto Moerbeek wrote:
>
> > Hi,
> >
> > both phase 1 and phase 5 need cylinder group metadata. This diff
> > keeps the cg data read in phase 1 i
On Sun, Jul 12, 2020 at 09:57:02AM +0430, Ali Farzanrad wrote:
> Hi @tech,
>
> I was comparing jsmn.c in acme-client with jsmn.c in FreeBSD [1].
> I found a switch without a default case which is an undefined behavior:
>
> @@ -69,6 +69,8 @@
> case '\t' : case '\r' : case
On Thu, Jul 02, 2020 at 08:27:58PM -0500, Scott Cheloha wrote:
> Hi,
>
> When we recompute the scaling factor during tc_windup() there is an
> opportunity for arithmetic overflow/underflow when we add the NTP
> adjustment into the scale:
>
>649 scale = (u_int64_t)1 << 63;
>650
On Sun, Jun 21, 2020 at 03:35:21PM +0200, Otto Moerbeek wrote:
> Hi,
>
> both phase 1 and phase 5 need cylinder group metadata. This diff
> keeps the cg data read in phase 1 in memory to be used by phase 5 if
> possible. From FreeBSD.
>
> -Otto
>
>
On Thu, Jun 18, 2020 at 11:41:17AM +0200, Otto Moerbeek wrote:
> On Thu, Jun 18, 2020 at 09:57:34AM +0200, Salvatore Cuzzilla wrote:
>
> > Perfect, tnx!
> >
> > On 18.06.2020 07:58, Otto Moerbeek wrote:
> > > On Wed, Jun 17, 2020 at 10:53:54PM +0200, Salvatore
Hi,
both phase 1 and phase 5 need cylinder group metadata. This diff
keeps the cg data read in phase 1 in memory to be used by phase 5 if
possible. From FreeBSD.
-Otto
On an empty 30T fileystem:
$ time obj/fsck_ffs -f /dev/sd3a
2m44.10s real 0m13.21s user 0m07.38s system
On Thu, Jun 18, 2020 at 09:57:34AM +0200, Salvatore Cuzzilla wrote:
> Perfect, tnx!
>
> On 18.06.2020 07:58, Otto Moerbeek wrote:
> > On Wed, Jun 17, 2020 at 10:53:54PM +0200, Salvatore Cuzzilla wrote:
> >
> > > Hi Otto here the logs (multitail
9:23 -ksh ToTo@obsd ~ $
OK, now we're getting somewhere. It always helps to provide lots of
information form the start.
The message is generated by ntpd being stopped. It is harmless,
though it is actually wrong, it's a pip read error.
So nothing to worry about. I'll see if the log level should be
-
And show the log lines, all of them
-Otto
>
> On 17.06.2020 20:51, Otto Moerbeek wrote:
> > On Wed, Jun 17, 2020 at 04:50:46PM +0200, Salvatore Cuzzilla wrote:
> >
> > > Hi Folks,
> > >
> > > when I restart
On Wed, Jun 17, 2020 at 04:50:46PM +0200, Salvatore Cuzzilla wrote:
> Hi Folks,
>
> when I restart ntpd I see this msg in /var/log/daemon:
>
> Jun 17 16:19:41 obsd ntpd[92699]: pipe write error (from main): No suchfile
> or directory
>
> however, time seems to be in sync:
>
>
Hi,
Miod remarked the overwriting of the bootblocks actually is a
regression I introduced. So teintroduce the lost comment and load
ofwboot at 0x6000.
OK?
-Otto
Index: bootblk.fth
===
RCS file:
On Fri, May 29, 2020 at 09:30:04AM +0200, Otto Moerbeek wrote:
> On Thu, May 28, 2020 at 12:54:41PM -0600, Todd C. Miller wrote:
>
> > On Thu, 28 May 2020 20:53:07 +0200, Otto Moerbeek wrote:
> >
> > > Here's the separate diff for the prefcg loops. From F
On Sun, May 31, 2020 at 09:49:34AM +0100, Mark Cave-Ayland wrote:
> On 30/05/2020 10:54, Otto Moerbeek wrote:
>
> > https://cdn.openbsd.org/pub/OpenBSD/snapshots/sparc64/
> > contains the unpatched miniroot.
> >
> > https://www.drijf.net/openbsd/disk.qcow2
&g
On Sat, May 30, 2020 at 10:11:08AM +0100, Mark Cave-Ayland wrote:
> On 30/05/2020 10:03, Otto Moerbeek wrote:
>
> > Hi,
> >
> > thanks for the hints, but an unpatched 6.7 miniroot still fails to
> > boot for me
> >
> > qemu-system-sparc64 -machine sun4
On Sat, May 30, 2020 at 09:29:36AM +0100, Mark Cave-Ayland wrote:
> On 29/05/2020 23:56, Jason A. Donenfeld wrote:
>
> > Oh that's a nice observation about `boot disk -V`. Doing so actually
> > got me booting up entirely:
> >
> > $ qemu-img convert -O qcow2 miniroot66.fs disk.qcow2
> > $
On Thu, May 28, 2020 at 10:11:28AM +0200, Otto Moerbeek wrote:
> On Thu, May 28, 2020 at 01:21:21AM -0600, Jason A. Donenfeld wrote:
>
> > On Thu, May 28, 2020 at 1:19 AM Otto Moerbeek wrote:
> > > Of course.., I was running it from a !wxallowed mount. BTW, qemu is in
&g
On Fri, May 29, 2020 at 09:30:04AM +0200, Otto Moerbeek wrote:
> On Thu, May 28, 2020 at 12:54:41PM -0600, Todd C. Miller wrote:
>
> > On Thu, 28 May 2020 20:53:07 +0200, Otto Moerbeek wrote:
> >
> > > Here's the separate diff for the prefcg loops. From F
On Thu, May 28, 2020 at 12:54:41PM -0600, Todd C. Miller wrote:
> On Thu, 28 May 2020 20:53:07 +0200, Otto Moerbeek wrote:
>
> > Here's the separate diff for the prefcg loops. From FreeBSD.
>
> OK millert@
>
> - todd
>
And here's the updated diff against -current.
On Tue, May 26, 2020 at 04:11:50PM +0200, Otto Moerbeek wrote:
> On Tue, May 26, 2020 at 03:54:15PM +0200, Otto Moerbeek wrote:
>
> > On Tue, May 26, 2020 at 07:51:28AM -0600, Todd C. Miller wrote:
> >
> > > On Tue, 26 May 2020 12:07:21 +0200, Otto Moerbeek wrote
On Thu, May 28, 2020 at 01:21:21AM -0600, Jason A. Donenfeld wrote:
> On Thu, May 28, 2020 at 1:19 AM Otto Moerbeek wrote:
> > Of course.., I was running it from a !wxallowed mount. BTW, qemu is in
> > packages, no need to build it yourself.
>
> Sure, but now I've been
On Thu, May 28, 2020 at 01:05:59AM -0600, Jason A. Donenfeld wrote:
> On Thu, May 28, 2020 at 12:15 AM Otto Moerbeek wrote:
> >
> > On Wed, May 27, 2020 at 11:28:09PM -0600, Jason A. Donenfeld wrote:
> >
> > > Hi Otto,
> > >
> > > On W
On Wed, May 27, 2020 at 11:28:09PM -0600, Jason A. Donenfeld wrote:
> Hi Otto,
>
> On Wed, May 27, 2020 at 4:07 AM Otto Moerbeek wrote:
> > Although I'm not terribly interested in bugs that are only seen (s0
> > far) using emulation, please send me the details on ho
On Wed, May 27, 2020 at 03:14:29AM -0600, Jason A. Donenfeld wrote:
> One interesting quirk in doing this on qemu is that the 6.7 and
> -current kernel both crash:
>
> Loading FCode image...
> Loaded 6882 bytes
> entry point is 0x4000
> Evaluating FCode...
> OpenBSD IEEE 1275 Bootblock 2.0
>
On Tue, May 26, 2020 at 03:54:15PM +0200, Otto Moerbeek wrote:
> On Tue, May 26, 2020 at 07:51:28AM -0600, Todd C. Miller wrote:
>
> > On Tue, 26 May 2020 12:07:21 +0200, Otto Moerbeek wrote:
> >
> > > Apart from the noting the strange Subject: I also like to mention
On Tue, May 26, 2020 at 07:51:28AM -0600, Todd C. Miller wrote:
> On Tue, 26 May 2020 12:07:21 +0200, Otto Moerbeek wrote:
>
> > Apart from the noting the strange Subject: I also like to mention one
> > change in the way cylinder groups are scanned. The current code
On Tue, May 26, 2020 at 11:58:39AM +0200, Otto Moerbeek wrote:
> Hi,
>
> In theory ffs code support a maximum of UINT_MAX inodes, but in
> practice, due to integer overflows in the current code, the limit is
> INT_MAX inodes.
>
> This fixes that, and allows me to creat
Hi,
In theory ffs code support a maximum of UINT_MAX inodes, but in
practice, due to integer overflows in the current code, the limit is
INT_MAX inodes.
This fixes that, and allows me to create and use filesystems with more
than INT_MAX inodes. This is partly from FreeBSD code.
Main change is
On Mon, May 18, 2020 at 06:27:04PM -, Miod Vallat wrote:
>
> > Learning how LDOMs work on this T4-1 and we only create 8 devices
> > (each /dev/ldom* and /dev/ttyV*) by default. The now-commonly-available
> > T4-1 machines can do far more than that pretty easily, so bump up the
> > number
101 - 200 of 852 matches
Mail list logo
