On 3/22/21 10:19 PM, Klemens Nanni wrote:
> On Mon, Mar 22, 2021 at 08:18:45PM +0100, Klemens Nanni wrote:
>> I was too stupid to look at `wsconsctl' output (which needs root) and
>> only looked here.
>>
>> Mailing the diff for my lack of better wording, plus the knob atually
>> takes three values
Fine with me.
The malloc'd memory is not identical to bss memory, but this still matches
the spirit of the test.
Brent Cook wrote:
> In the next version of Linux glibc, SIGSTKSZ is defined at runtime if
> source is built with _GNU_SOURCE. On LibreSSL-portable, this is set to
> bring in asprintf
In the next version of Linux glibc, SIGSTKSZ is defined at runtime if
source is built with _GNU_SOURCE. On LibreSSL-portable, this is set to
bring in asprintf/vasprintf, which causes the explicit_bzero test to
fail to compile since the size of SIGSTKSZ is no longer known at compile
time. This adjus
On Mon, Mar 22, 2021 at 08:18:45PM +0100, Klemens Nanni wrote:
> I was too stupid to look at `wsconsctl' output (which needs root) and
> only looked here.
>
> Mailing the diff for my lack of better wording, plus the knob atually
> takes three values which I have yet to decode by reading wsconsctl(
On Mon, Mar 22, 2021 at 08:18:45PM +0100, Klemens Nanni wrote:
> I was too stupid to look at `wsconsctl' output (which needs root) and
> only looked here.
>
> Mailing the diff for my lack of better wording, plus the knob atually
> takes three values which I have yet to decode by reading wsconsctl(
Hi,
By specifying an invalid offset when reading /dev/kmem it is easy
to crash the kernel from userland. sysctl kern.allowkmem=0 prevents
this per default
kernel: protection fault trap, code=0
Stopped at copyout+0x53: repe movsq (%rsi),%es:(%rdi)
ddb> trace
copyout() at copyout+0x53
So I've really wanted to try OpenBSD in a non-server configuration
where I'm not installing over the internet on a remote server but on
the local machine, but to my knowledge the OpenBSD installation media
has no accessibility functionality whatsoever. (I'm not even sure if
the installed system or
I was too stupid to look at `wsconsctl' output (which needs root) and
only looked here.
Mailing the diff for my lack of better wording, plus the knob atually
takes three values which I have yet to decode by reading wsconsctl(8)
code.
Anyone with a better text for the example so grepping "mouse" o
On Fri, Mar 19, 2021 at 10:44:24AM +0100, Theo Buehler wrote:
> On Thu, Mar 18, 2021 at 05:06:53PM -0400, Dave Voutila wrote:
> >
> > Preben Guldberg writes:
> >
> > > In "vmctl status", VMs that are being stopped but are still running
> > > will simply show up as "running".
> > >
> > > The diff
> Date: Mon, 22 Mar 2021 19:07:23 +0100
> From: Klemens Nanni
>
> On Mon, Mar 22, 2021 at 06:19:14PM +0100, Mark Kettenis wrote:
> > > @@ -167,7 +167,7 @@ cwfg_attach(struct device *parent, struc
> > > free(batinfo, M_TEMP, len);
> > >
> > > sc->sc_monitor_interval = OF_getpropint(sc->sc_no
On Mon, Mar 22, 2021 at 06:19:14PM +0100, Mark Kettenis wrote:
> > @@ -167,7 +167,7 @@ cwfg_attach(struct device *parent, struc
> > free(batinfo, M_TEMP, len);
> >
> > sc->sc_monitor_interval = OF_getpropint(sc->sc_node,
> > - "cellwise,monitor-interval", CWFG_MONITOR_INTERVAL_DEFAU
> Date: Mon, 22 Mar 2021 17:48:56 +0100
> From: Klemens Nanni
>
> Using our dtb package's blobs cwfg(4) won't attach on the Pinebook Pro
> since linux changed it:
>
> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml
>
> Thanks to k
On Mon, Mar 22, 2021 at 05:48:56PM +0100, Klemens Nanni wrote:
> Using our dtb package's blobs cwfg(4) won't attach on the Pinebook Pro
> since linux changed it:
>
> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml
>
> Thanks to kett
Better diff at the end thanks to jca's eyeballing, see comments inline.
kettenis: I see room for improvement in our subsystems and their
interactions, but I don't think the current situation is bad enough to
leave those bits out for now.
Feedback? OK?
On Mon, Mar 22, 2021 at 01:21:02AM +0100, J
Using our dtb package's blobs cwfg(4) won't attach on the Pinebook Pro
since linux changed it:
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml
Thanks to kettenis and patrick for pointing this out.
This diff makes the sensor attach
> On 22 Mar 2021, at 15:23, Otto Moerbeek wrote:
> 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:
> Otto Moerbeek w
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:
> >>> Otto Moerbeek writes:
> On Mon, Mar 22, 2021 at 09
On Mon, Mar 22, 2021 at 01:33:34PM +, Raf Czlonka wrote:
> On Mon, Mar 22, 2021 at 07:08:32AM GMT, Jason McIntyre wrote:
> > On Sun, Mar 21, 2021 at 10:58:02PM +, Raf Czlonka wrote:
> > >
> > > Hi Laurie,
> > >
> > > I'd simply use the existing wording, without getting into details.
> > >
> 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:
>>> Otto Moerbeek writes:
On Mon, Mar 22, 2021 at 09:51:19AM -0400, Dave Voutila wrote:
> Otto Moerbeek writes:
>> On
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, Mar 22, 2021 at 01:47:18PM +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, 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: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
Otto Moerbeek writes:
> 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:
>> >> >
>> >> >>> Created a fresh instal
> > 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 regular image, that r/o open for the other vms does not
> matter a lot,
vmd
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:
> >> >
> >> >>> Created a fresh install qcow2 image and derived 35 new VMs
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:
>> >
>> >>> 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 w
> On 22 Mar 2021, at 14:30, Otto Moerbeek 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 p
On Mon, Mar 22, 2021 at 07:08:32AM GMT, Jason McIntyre wrote:
> On Sun, Mar 21, 2021 at 10:58:02PM +, Raf Czlonka wrote:
> >
> > Hi Laurie,
> >
> > I'd simply use the existing wording, without getting into details.
> >
> > While there, "braces" dominate the manual page, with a single
> > occ
> On 22 Mar 2021, at 14:27, Bryan Steele 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 VM
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 after
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 after
> 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 after each cycle.
>>> Similar to the staggered start based on the amount of
> > 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 after each cycle.
> > Similar to the staggered start based on the amount of CPUs.
> For me this is not enough info to even try to rep
> Date: Sun, 21 Mar 2021 16:56:47 +0100
> From: Martin Pieuchot
>
> On 21/03/21(Sun) 13:42, Mark Kettenis wrote:
> > > Date: Sat, 20 Mar 2021 13:10:17 +0100
> > > From: Martin Pieuchot
> > >
> > > On SP systems, like bluhm@'s armv7 regression machine, the kern/ptrace2
> > > test is failing due
> On 22 Mar 2021, at 13:08, Otto Moerbeek wrote:
> 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 Kl
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:
> Hi,
>
> I had the same
> Date: Mon, 22 Mar 2021 11:29:52 +0100
> From: Martin Pieuchot
>
> Convert the last MI uvm_km_zalloc(9) to km_alloc(9), ok?
Also needs some careful testing on multiple architectures.
> Index: uvm/uvm_page.c
> ===
> RCS file: /cvs/
> Date: Mon, 22 Mar 2021 11:27:40 +0100
> From: Martin Pieuchot
>
> Diff below convert a use of uvm_km_zalloc(9) to km_alloc(9), this memory
> is never released, ok?
This will need some careful testing on multiple architectures.
> Index: kern/kern_malloc.c
>
> 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:
Hi,
I had the same issue a few days ago a server hardware of mine. I just
ran 'cvs up'
Convert the last MI uvm_km_zalloc(9) to km_alloc(9), ok?
Index: uvm/uvm_page.c
===
RCS file: /cvs/src/sys/uvm/uvm_page.c,v
retrieving revision 1.155
diff -u -p -r1.155 uvm_page.c
--- uvm/uvm_page.c 19 Jan 2021 13:21:36 -
Diff below convert a use of uvm_km_zalloc(9) to km_alloc(9), this memory
is never released, ok?
Index: kern/kern_malloc.c
===
RCS file: /cvs/src/sys/kern/kern_malloc.c,v
retrieving revision 1.144
diff -u -p -r1.144 kern_malloc.c
--- k
Hi,
The following diff tries to simplify a bit the entanglement of namei
data and execve(2) syscall.
Currently, when called, sys_execve() might doing recursive calls of
check_exec() with a shared `struct nameidata' (`ep_ndp' inside
`struct exec_package').
I would like to disassociate them, and m
The top frame is always `witness_checkorder', at least on amd64. Diff
below makes use of stacktrace_save_at() to skip it.
Previous output:
lock order "&map->lock"(rwlock) -> "&amap->am_lock"(rwlock) first seen at:
#0 witness_checkorder+0x4d7 [/home/os/openbsd/sys/sys/stacktrace.h:0]
On 2021/03/22 00:20, Martijn van Duren wrote:
> There's two things I'd like to know before going further with this:
>
> 1) according to RFC2578 section 3.6:
> (1) registration: the definition of a particular item is registered as
> a particular OBJECT IDENTIFIER value, and associated with a
On Sun, Mar 21, 2021 at 10:58:02PM +, Raf Czlonka wrote:
>
> Hi Laurie,
>
> I'd simply use the existing wording, without getting into details.
>
> While there, "braces" dominate the manual page, with a single
> occurrence of "brackets" so let's change that too, for consistency.
>
> Regards,
45 matches
Mail list logo
