On Wed, Aug 22, 2018 at 12:12:10AM +0200, Remi Locherer wrote:
> On Tue, Aug 21, 2018 at 05:54:18PM +0100, Stuart Henderson wrote:
> > On 2018/08/21 17:16, Remi Locherer wrote:
> > > Hi tech,
> > >
> > > recently we had a short outage in our network. A script started an
> > > additional
> > > osp
On Thu, Aug 23, 2018 at 08:16:06AM +0200, Anton Lindqvist wrote:
> Hi.
> Currently kcov is enabled on a per process (pid) basis. A process with
> multiple threads therefore share the same coverage buffer which leads to
> non-deterministic results. Instead, kcov should be enabled on a per
> thread b
Hi,
I think the diff should be brought to arm64 as well. ok?
On Thu, 23 Aug 2018 11:21:57 +0900 (JST)
YASUOKA Masahiko wrote:
> On Mon, 20 Aug 2018 13:50:13 +0200
> Theo Buehler wrote:
>> On Thu, Aug 16, 2018 at 09:51:32PM +0200, Frank Groeneveld wrote:
>>> I haven't been able to type the pass
Penned by Theo de Raadt on 20180823 14:22.46, we have:
| Mike Larkin wrote:
|
| > On Thu, Aug 23, 2018 at 11:05:40AM -0500, Todd T. Fries wrote:
| > > This makes me wonder. Does it make sense to support booting a kernel
without
| > > disks? Some people have heard of the p
On Thu, Aug 23, 2018 at 10:59:58PM +0200, Mark Kettenis wrote:
> > Date: Tue, 21 Aug 2018 23:34:38 +0200 (CEST)
> > From: Mark Kettenis
> >
> > If firmware doesn't initialize the device, the BAR will be zero and
> > mapping that address leads to "interesting" issues on many machines.
> > This BAR
> Date: Tue, 21 Aug 2018 23:34:38 +0200 (CEST)
> From: Mark Kettenis
>
> If firmware doesn't initialize the device, the BAR will be zero and
> mapping that address leads to "interesting" issues on many machines.
> This BAR is a bit special since we don't want to immediately map it.
> So we have t
Mike Larkin wrote:
> On Thu, Aug 23, 2018 at 11:05:40AM -0500, Todd T. Fries wrote:
> > This makes me wonder. Does it make sense to support booting a kernel without
> > disks? Some people have heard of the phrase 'diskless' ;-)
> >
> > Penned by Reyk Floeter on 20180822 13:35.23, we have:
> > |
Two recently disclosed hardware bugs affected Intel cpus:
- TLBleed
- T1TF (the name "Foreshadow" refers to 1 of 3 aspects of this
bug, more aspects are surely on the way)
Solving these bugs requires new cpu microcode, a coding workaround,
*AND* the disabling o
On Thu, Aug 23, 2018 at 11:05:40AM -0500, Todd T. Fries wrote:
> This makes me wonder. Does it make sense to support booting a kernel without
> disks? Some people have heard of the phrase 'diskless' ;-)
>
> Penned by Reyk Floeter on 20180822 13:35.23, we have:
> | Hi,
> |
> | vmctl doesn't allow
On Thu, Aug 23, 2018 at 11:05:40AM -0500, Todd T. Fries wrote:
> This makes me wonder. Does it make sense to support booting a kernel without
> disks? Some people have heard of the phrase 'diskless' ;-)
We already do:
$ head -n4 /etc/vm.conf
vm "rd" {
disable
On Tue, Aug 14, 2018 at 03:11:47PM -0500, Scott Cheloha wrote:
> This patch is ok cheloha@ and I can commit if someone else
> is ok, too.
1 week bump. Anyone else ok?
> On Tue, Aug 14, 2018 at 10:47:07PM +0300, Lauri Tirkkonen wrote:
> > [...]
> >
> > diff --git a/bin/md5/md5.c b/bin/md5/md5.c
This makes me wonder. Does it make sense to support booting a kernel without
disks? Some people have heard of the phrase 'diskless' ;-)
Penned by Reyk Floeter on 20180822 13:35.23, we have:
| Hi,
|
| vmctl doesn't allow to boot VMs with only a CDROM. I see no reason
| for it and vmd already all
Perhaps...
I will warn you that the "running YP" case can be really surprising
for "getpw", since it opens up partial "inet" holes. By that I mean
YP support can get subtly broken completely accidentally.
I do intend to circle back one day and change the underlying YP
mechanism (in a similar way
On Thu, 23 Aug 2018 10:43:21 +0100, Ricardo Mestre wrote:
> After pledge(2) is called there are no getpw* associated functions that
> get called so we can drop the promise.
>
> Although we manipulate files associated with getpw all the remaining
> code is kept happy with "rpath wpath cpath fattr f
Hi,
After pledge(2) is called there are no getpw* associated functions that get
called so we can drop the promise.
Although we manipulate files associated with getpw all the remaining code is
kept happy with "rpath wpath cpath fattr flock", this has been tested directly
and also via vipw(8).
OK?
> The -Wshadow warning was briefly enabled, but it turned out to break vax
> builds with gcc3. Among other things, this warning helps catching stupid
> mistakes in refactoring early, so I was wondering whether we could
> re-enable it. The commit that disabled it also mentions gcc3, so I'm
> unsur
16 matches
Mail list logo
