On Tue, 26 Mar 2024, Peter Fraser wrote:
> Ls fault with symbols
>
> lldb /usr/src/bin/ls/ls
> (lldb) target create "/usr/src/bin/ls/ls"
> Current executable set to '/usr/src/bin/ls/ls' (x86_64).
> (lldb) run -l
> run -l
> Process 88451 launched: '/usr/src/bin/ls/ls' (x86_64)
> total 2176
>
as well happen with some other device interrupting the ACPI
processing.
If there isn't a newer BIOS that resolves this, I would tend to return the
box as not suitable.
Phlip Guenther
nel which allocates more pages
per thread for its kernel stack by bumping the UPAGES #define
in /usr/src/sys/arch/amd64/include/param.h and building a new kernel. It's
really only the ACPI thread that needs this, but we don't currently have
code to control that on a per-thread basis.
Philip Guenther
===
> RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
> retrieving revision 1.666
> diff -u -p -r1.666 machdep.c
> --- sys/arch/i386/i386/machdep.c 9 Aug 2023 00:01:44 - 1.666
> +++ sys/arch/i386/i386/machdep.c 16 Aug 2023 06:26:24 -
> @@ -1863,7 +1863,8 @@ identifycpu(struct cpu_info *ci)
> uint64_t level = 0;
> uint32_t dummy;
>
> - if (strcmp(cpu_vendor, "AuthenticAMD") == 0) {
> + if (strcmp(cpu_vendor, "AuthenticAMD") == 0 &&
> + ci->ci_family >= 0x0f) {
All the ucode they publish is for that family and up?
ok guenther@
g PS_SUGID in its ps_flags
* the process doing ptrace(PT_ATTACH) holds the kernel lock across the
check you quoted, so it can't see target_ruid==my_ruid without also
seeing PS_SUGID set
What am I missing?
Philip Guenther
ize_t, as an int.
Instead, just return 1 if there is a difference.
Found by lint.
OK millert.
----
Best wishes.
Philip Guenther
sh -ic 'echo before=$-; echo foo_first=$- | { echo second=$-; cat & tr o e
; }'
before=himBHc
second=himBHc
foo_first=himBHc
$
Philip Guenther
uot; to get a shell,
from which "exit" will return you back to that prompt.
---
So, you can use '!' to get a shell where you enter the necessary ifconfig
command, and you can of course tweak the install before rebooting.
Philip Guenther
and maybe you'll be able to get some more use
out of that USB stick, but I wouldn't trust it for anything important.
Philip Guenther
ops where F5 and F6 have the brightness - and + markings, so if
the "function lock" isn't activated I get those behaviors instead of the
F5/F6 keys.
Does your F4 have the brightness- marking? Is there some sort of
"function lock" in the keyboard that selects whether to do F4 or
brightness-?
Philip Guenther
On Thu, 10 Feb 2022, Jan Stary wrote:
> > > When you build a kernel with this, do please add ACPI_DEBUG to your
> > > kernel
> > > config, so we can see more details about what the firmware is telling us.
> >
> > Full dmesg below, without ACPI_DEBUG.
> >
> > Also below, full /var/log/messages
would be useful test change to see if it
results in notifications being reported on this T420 that affect the
presence of C2.
When you build a kernel with this, do please add ACPI_DEBUG to your kernel
config, so we can see more details about what the firmware is telling us.
Philip Guenther
On Wed, 2 Feb 2022, Alexander Bluhm wrote:
> On Wed, Feb 02, 2022 at 07:53:59PM +, Miod Vallat wrote: > > Hi, > > > >
> On my sparc64 machine
> regress/lib/libpthread triggers a panic. It > > happend with Feb 1 and Jan 31
> snapshot. Jan 29 snapshot paniced >
>
>
> On Wed, Feb 02, 2022 at
ge
in the pmap layer in multiple months. The areas of concern IMO are DRM
and (because it was the last thing mentioned) iwm, but the former seems
_much_ more likely.
Philip Guenther
...
> sd2 at scsibus4 targ 1 lun 0:
> sd2: 1953513MB, 512 bytes/sector, 4000795775 sectors
> root
On Sun, 26 Dec 2021, Philip Guenther wrote:
> Installed snap from Friday on my X1 extreme and it's no longer able to
> resume from hibernation, even when hibernation was done right after
> boot+login, showing 16 "hibernate_block_io open failed" before showing
>
Unable to resume hibernated image
That length seems completely bogus, of course.
If I'm reading my /var/log/daemon and /var/log/messages correctly, my
successful resume on Dec 25th was with a kernel I built on Dec 3rd. :-/
Philip Guenther
OpenBSD 7.0-current (GENERIC.MP) #200: Fri Dec 24 22:15:0
On Sat, 20 Nov 2021, Dave Voutila wrote:
> Philip Guenther writes:
>
> > On Wed, 17 Nov 2021, Josh Grosse wrote:
> > ...
> >> vmm_handle_cpuid: function 0x0a (arch. perf mon) not supported
> >> vmx_handle_cr: mov to cr0 @ 100149e, data=0x80010031
> &g
On Wed, 17 Nov 2021, Josh Grosse wrote:
...
> vmm_handle_cpuid: function 0x0a (arch. perf mon) not supported
> vmx_handle_cr: mov to cr0 @ 100149e, data=0x80010031
> vmx_handle_wrmsr: wrmsr exit, msr=0x8b, discarding data written from
> guest=0x0:0x0
> vmx_handle_wrmsr: wrmsr exit, msr=0x8b,
On Tue, 1 Dec 2020, Otto Moerbeek wrote:
> On Tue, Dec 01, 2020 at 08:00:18PM +0100, Otto Moerbeek wrote:
> > On Tue, Dec 01, 2020 at 10:13:29AM -0800, guent...@openbsd.org wrote:
...
> > The man page is lacking or even wrong in this respect. It explicitly
> > talks about how to do deallocation.
value(s) that are within the range of that stack. In particular, the
region of memory cannot be
freed, nor can it be later specified as the stack for another thread.
Note that last sentence.
Philip Guenther
, I
guess that fine, but it's not a way to architect an overall system.
Philip
On Tue, 27 Oct 2020, Luke Small wrote:
> Thanks Guenther for the well thought out answer!
>
> I figured I could take yet another step to sloppiness
> which is may actually be more efficient like not ca
er is "nope, you've chosen a problem too complicated for a simple
answer". Good luck!
Philip Guenther
On Tue, 27 Oct 2020, Luke Small wrote:
> from man _exit:
>
> All open file descriptors in the calling process are closed. This
> may entail delays; for
xit(3), such as flushing stdio buffers.
You should follow up with whatever documentation that suggested you should
call _exit(2) in the child, so that it can be corrected.
Philip Guenther
consistent and mangling a different set of messages.
If you need a format that doesn't mangle this sort of content, then Don't
Use UNIX mailbox format.
Philip Guenther
Unix Email Greybeard
** it's sometimes called the BSD format, but it predates BSD
ff when you select
an environment before locale_t was added
b) our header needs to broaden its conditional to go ahead and
provide locale_t (and the functions?) when in a C++ environment that
should have them
Philip Guenther
On Sat, 21 Dec 2019, Steffen Nurpmeso wrote:
> Philip Guenther wrote in :
> |On Sat, 21 Dec 2019, Steffen Nurpmeso wrote:
...
> |> /* There are problems with dup()ing of file-descriptors for child \
> |> processes.
> |>* We have to somehow accomplish that t
On Sat, 21 Dec 2019, Steffen Nurpmeso wrote:
> I was struggling with a pre-release problem of my mailer, which has an
> increasing test coverage, and was head banging on OpenBSD. (And i was
> wondering whether i should have Cc:'d Philip Guenther for this exact
> problem, but i lo
On Tue, 17 Dec 2019, Mark Kettenis wrote:
...
> > However, thos "vmmaplk" instances really are different classes. In
> > the sys_mlock codepath it is a lock for a userland vmmap whereas the
> > other codepath is dealing with a kernel vmmap. So there isn't
> > actually a lock order reversal.
>
On Sun, 17 Nov 2019, Theo de Raadt wrote:
> >I think sa_len has written extensively on this before, that sa_len is
> ^^ -- guenther
Shit, my superhero identity has been revealed and now the SysV minions
will put my family in peril!
Philip
On Thu, 7 Nov 2019, Theo Buehler wrote:
...
> and other tests run as expected. It has a more decently sized random
> section:
>
> OPENBSD_RANDOM 0x01185000 0x01185000 0x01185000
>0x7d28 0x7d28 RW 8
A 97.3% reduction in
On Thu, 7 Nov 2019, Theo Buehler wrote:
> On Thu, Nov 07, 2019 at 03:32:48PM -0700, Theo de Raadt wrote:
> > > kern.version=OpenBSD 6.6-current (GENERIC.MP) #433: Thu Nov 7 10:41:08
> > > MST 2019
> >
> > That is too old and does not contain the solution.
>
> I obtained a different binary with
On Thu, 7 Nov 2019, Theo Buehler wrote:
> I was trying to debug a WIP port, so I compiled it with '-g -O0' on my
> amd64 laptop. When trying to execute the binary, I got
>
> $ ./lean
> ksh: ./lean: Cannot allocate memory
>
> mpi was able to pinpoint this to the following check in exec_elf.c:
>
On Wed, 6 Nov 2019, Landry Breuil wrote:
> playing with ltrace, trying to see what functions are called by firefox,
> it works fine in many situations:
>
> ltrace -i -ulibnspr4 /usr/local/bin/firefox
> ltrace -i -u:NSS* /usr/local/bin/firefox
>
> *but* for some reason it doesnt seem to work with
On Sun, 3 Nov 2019, Matthieu Herrb wrote:
> On Sun, Nov 03, 2019 at 12:50:07AM +0100, Klemens Nanni wrote:
> > My workstation consists of a X230 with docking station featuring two
> > DisplayPort as well as two DVI-D connectors. I used to use one external
> > monitor over DVI-D with a resolution
s quality (sc->sc_tc->tc_quality) downward while that's the
case? I'm not sure if that would be enough, but you could try
implementing that.
Lacking that, I guess you'll want to have KVM stop the guest before you
suspend the host, and then on resume wait a bit until the clock
settles--not sure how long that takes or how you would know--before
restarting the guest.
Philip Guenther
> drive? I was using this same hard drive with Linux and I don't remember
> having issues. I am going to disable softdep to see if things get
> better.
That should help with the panics. Watch your dmesg for additional reports
of I/O errors that might indicate failures of the drive itself.
Philip Guenther
. Congrats, that's legal
according to Intel (reportedly, Windows will use SSE(!) instructions to
read LAPIC registers), so this seems like a bug in Bhyve.
Philip Guenther
s to put what you're exporting on its own
filesystem.
Philip Guenther
e ..
> i put kern.witness.watch=3 in sysctl.conf so now i'm in ddb and will
> leave it like this if something is needed
>From pguent...@proofpoint.com Sat Jun 1 13:25:04 2019
Date: Sat, 1 Jun 2019 13:25:00 -0700
From: Philip Guenther
To: Antoine Jacoutot
Cc: hack...@openbsd.org
Subject: R
On Sat, 2 Mar 2019, Visa Hankala wrote:
> On Sat, Mar 02, 2019 at 11:41:21PM -0700, Theo de Raadt wrote:
> > We previously decided that the dprintf family is as safe as
> > snprintf+write, and we are preferring dprintf in various places,
> > such as signal-safe.
> >
> > Can you explain why it not
e_load() could
copy the chunk from machdep.c...or someone could add a global and do the
check once, early...
Philip Guenther
ariables (see below).
Your code looks correct to me; seems incorrect.
oks for the diff below?
Philip Guenther
Index: inttypes.h
===
RCS file: /data/src/openbsd/src/include/inttypes.h,v
retrieving revision 1.11
diff -u -p -r1.11 i
On Tue, 20 Nov 2018, Josh Elsasser wrote:
> The test suite for lang/sbcl has uncovered a race between pthread_join()
> and the exiting thread: it may return before it's safe to unmap a custom
> thread stack.
>
> In the exiting thread:
> 1) pthread_exit() calls _thread_release() via the
On Sat, 17 Nov 2018, Adam Stouffer wrote:
> On 11/17/2018 10:58 AM, Peter Hessler wrote:
> >
> > Yes, the fix is "don't use a single root partition" and instead
> > "partition your damn disk as intended".
>
> So what is the maximum root partition size or don't you know because
> this is an
r and step through the frames to see
what the last output displayed before reboot is?
Philip Guenther
lways be placed first in the declaration. C11 declared
"placement of a storage-class specifier other than at the beginning of the
declaration specifiers in a declaration" to be an obsolescent feature.
Philip Guenther
n process _before_ you encountered the
problem?
It's such a broad warning that I can't believe it'll be generally
effective except as a post-facto "we told you so!"...which is not often
appreciated. :(
Philip Guenther
I had attached the umodem serial console of my OD1000 to the free USB port
on my cubox and it had worked just fine when I upgraded the OD1000 to the
July 19 snapshot. The cubox was running this at that time:
OpenBSD 6.3-current (GENERIC) #40: Fri May 25 13:29:14 MDT 2018
Now, the
GB root partition? Does it work with a sanely sized root partition?
Philip Guenther
oader there would be more space available but it
appears to not be using EFI so it's more limited in the memory available
to it and such large disk blocks might push the loader beyond what it can
support.
Philip Guenther
On Sun, 21 Oct 2018, Dr.Boutari wrote:
> Original Message
> On 21 Oct 2018, 22:52, Philip Guenther wrote:
>
> > I downloaded bsd.mp from a mirror and booted it first with acpi enabled.
> > It crashed as usual at about the same point where the crash o
On Sun, 21 Oct 2018, Dr.Boutari wrote:
> Original Message
> On 21 Oct 2018, 01:55, Philip Guenther wrote:
>
> IMHO, if you want assistance from the OpenBSD developers in making this
> machine function better, you need to go back to the original problem: when
>
.." output plus the
output of "machine memory" at the boot prompt.
Philip Guenther
is the sequence of events leading to the crash (boot? shutdown?)
- what is the output before the crash?
- if it drops into ddb, then gather the crash or panic message and the
other information requested at https://www.openbsd.org/ddb.html
Philip Guenther
The only odd thing I can think of with this system is the installation
> is on the second hard drive. The first hard drive is disabled in the
> BIOS.
The kernel doesn't access the drive until later while probing the device
tree, so I don't think that's the issue.
Philip Guenther
In
addition, when an MP install panics, you should follow the "Note for SMP
systems" section at https://www.openbsd.org/ddb.html and capture the
backtraces from _all_ the CPUs.
Philip Guenther
- acpidump(8) output
If it includes all of those, then email it to
If it doesn't include those, then don't bother emailing it in, as without
those we can only guess what the problem is...and no one is going to waste
their time trying to guess what the problem is.
Philip Guenther
programming forums such as stackexchange, where these sorts of queries
have already been answered.
Philip Guenther
diff that added support without adding
clutter to the headers it's plausible it would be accepted, but it would
have to be _really_ simple.
...or just go with your workaround. ;-)
Philip Guenther
ddressing instead of with absolute addresses.
If you _must_ have a non-PIE program (perhaps on your way to understanding
how to write PIE assembly), you can link a non-PIE program by passing ld
the -nopie option.
Philip Guenther
On Fri, 5 Oct 2018, Mark Kettenis wrote:
> > Date: Fri, 5 Oct 2018 00:34:02 -0700
> > From: Philip Guenther
...
> > Now, perhaps the smt values returned by cpuid are misleading on this
> > CPU: it appears that the combination of smt and core is unique
> > _acr
this CPU:
it appears that the combination of smt and core is unique _across_
packages: maybe we should instead enable the CPU with the lowest smt value
for each package and core.
Philip Guenther
a code for this unless it can be made race-proof (IMHO).
Unfortunately, it looks like perl's opendir() doesn't have an fdopendir(3)
variant, so I'm not convinced the race can be completely closed from the
script itself.)
Philip Guenther
On Mon, 24 Sep 2018, Sven Wolf wrote:
> last weekend I've updated two computers to the amd64 current snapshot.
> At every restart of the computer (after the keyboard mapping is set and
> before the network gets started) following message is displayed:
> /etc/rc[430]: > 0: unexpected '>'
>
> On
Known bug in my PCID diff in the snaps. The snap building right now
should fix this.
Philip
On Sun, 16 Sep 2018, Karel Gardas wrote:
> snapshot obtained from spline.de, build from Sep 14 stops booting
> (bsd.rd) on Fujitsu Primergy TX 1320 M1. The machine BIOS/BMC firmware
> was updated June/July 2018. The output of boot looks:
Yep: bug in my PCID diff in the snaps. The snap building
d and the other even.
Yell at the vendor for a firmware update...
Philip Guenther
tify an increase in stack use in an interrupt path, we
should fix that
- making aml_parse() iterative instead of recursive...by tracking frames
of AML state in an explict stack...would be annoying, more complex to
maintain, and probably inefficient. Maybe it's time to let kernel
threads request a larger than default stack size and have acpi_thread
request another page or so?
- if all else fails, there's always increasing UPAGES...
Philip Guenther
On Thu, 19 Jul 2018, j...@securebytes.org wrote:
...
> >How-To-Repeat:
>
> >Fix:
>
Since you didn't mention a problem, should we understand that everything
is working 100% fine and that you meant this to go to dm...@openbsd.org?
On Mon, 16 Jul 2018, sc...@datagenic.com wrote:
> >Synopsis:newaliases(8) segmentation fault
> >Category:newaliases(8) segmentation fault
> >Environment:
> System : OpenBSD 6.3
> Details : OpenBSD 6.3-current (GENERIC.MP) #80: Sun Jul 1 12:22:16
> MDT 2018
>
NESS work and not part of the xcr0 problem.
> vmm_fpurestore: guest attempted to set invalid bits in xcr0 (guest
> %xcr0=0x1, host mask=0x)
Oh, duh: this box doesn't have XSAVE at all but we init guests as if it
does. Try this diff on the host.
Philip Guenther
Ind
On Thu, 7 Jun 2018, Mike Larkin wrote:
> Is this a panic inside the guest in vmm, or is this the host panicing when
> you're doing something while a VM is running in vmm on that host?
>
> Can't really tell from the trace here...
This was a guest panicing. visa@ thinks this is the same
shouldn't lead to a witness panic either.)
(The weird "show witness" output for scsi_base.c mutexes is because
they're on the stack and need to be unlinked from witness before
returning; that *might* be causing the problem here, but I doubt it. I'm
starting on a diff for that part..
ked correctly?
That'll narrow down when the regression occurred.
Depending on how long a range of time+builds that is, there are various
strategies for identifying the source of the failure...
Philip Guenther
On Sat, 2 Jun 2018, Christophe Prévotaux wrote:
> This a witness report I got on boot with snapshot Jun 1st amd64
>
> root on sd0a (9b49e3196b9bfae8.a) swap on sd0b dump on sd0b
> lock order reversal:
> 1st 0xff021cdac180 vmmaplk (>lock) @ /usr/src/sys/uvm/uvm_map.c:4433
> 2nd
4e8, 0, 1) -> e
> fatal page fault in supervisor mode
> type type 6 code 0 rip 811ca1fc cs 8 rflags 10002 cr2 4e8 cpl d rsp
> 7f7ec9d0
> panic: trap type 6, code=0. pc=811ca1fc
This is mine. I may poke you to try a diff later...
Philip Guenther
2018-03-17!
Wherever that login_ldap was compiled was a broken system. If that broken
version came from the official packages builds then we need to make sure
the involved ports build systems are being updated correctly.
Philip Guenther
Forwarded with permission.
-- Forwarded message --
Date: Tue, 1 May 2018 12:22:41 -0700
From: Davide Marini <dmar...@inkbit.xyz>
To: Philip Guenther <pguent...@proofpoint.com>
Subject: Re: Kernel Panic on OpenBSD 6.3 AMD64 // Chrome Related
Hi Philip,
Thank
s of /var/run/dmesg from this box, with
the complete dmesg output. (Rule of thumb: when reporting *any* problem,
include the dmesg from the box so we have some idea of the set up of the
involved machine.)
Philip Guenther
ommand and the answer should be of
the form /usr/lib/libc.so.X.Y
# What's the output of
# nm /path/to/the/reported/libc.so | grep pthread_once ?
You should run nm on that libc, *not* libcrypto.
Philip Guenther
ldap should have been on the list and IMHO updating them
*all* with "pkg_add -u" is the only sane option.)
Philip Guenther
On Sat, 28 Apr 2018, Otto Moerbeek wrote:
> On Fri, Apr 27, 2018 at 09:12:36PM -0400, Rupert Gallagher wrote:
>
> > The lack of information originates from "mountd -d". When it terminates
> > because of an error, it should log the name of the last function and its
> > parameters.
>
> Wrap your
On Tue, 24 Apr 2018, Jeremie Courreges-Anglas wrote:
...
> We took a quick look yesterday, the crash happens in dtors, the cause of
> the crash looks like a use after free. I'm not a BIO_* hacker, here's
> a stack trace on amd64, curl rebuilt with DEBUG=-g:
>
> Program received signal SIGBUS, Bus
"sendbug" and fill in the detail there, and send the
generated message to bugs@openbsd.org. Doing that automatically includes
output of the dmesg, acpidump, and pcidump commands, all of which are
possibly relevant to the problem you're experiencing.
Philip Guenther
formation or not. But at least,
> ENOTCONN is wrong: socketpair(2) returns connected sockets.
That's a bug, IMO: socketpair(2) should support use of getpeereid(3).
Philip Guenther
o allocate to /var/tmp should just be combined into your /tmp.
This has been the behavior since November 2014 and the OpenBSD 5.7
release.
Philip Guenther
On Wed, 13 Dec 2017, Jeremy Evans wrote:
> I think this may be a bug. I'm guessing either:
>
> 1) fcntl(fd,F_SETFL, O_NONBLOCK) shouldn't fail, because
>open("/dev/zero", O_NONBLOCK) doesn't fail; or
Yes.
> After more testing, it appears any fcntl/F_SETFL call on /dev/zero
> fails, even if
sting a diff to do so.
Philip Guenther
On Sun, 12 Nov 2017, Otto Moerbeek wrote:
> On Sun, Nov 12, 2017 at 08:12:26PM +0100, Mark Kettenis wrote:
...
> > It certainly doesn't make sense to have touch(1) do the checks.
> >
> > Note that POSIX says that futimens(2) shall faill if:
> >
> > [EINVAL]
> > A new file timestamp would be
On Wed, 4 Oct 2017, Paul de Weerd wrote:
...
> which bumps dev/usb/umcs.c to revision 1.5 with commit message:
>
> "Deactivate the device if I/O fails in attach.
>
> Coverity CID 1453399; ok deraadt@"
>
> reverting this makes the device work again, but since there's a
> Coverity CID attached,
gt; argument to fall back on.
> >How-To-Repeat:
> $ echo test | install /dev/stdin /tmp/bug
> install: /dev/stdin: Inappropriate file type or format
That's not a documented and supported use of install(1). "Not a bug"
"What problem are you trying to solve"
Philip Guenther
nsigned long long.
Simply removing the intermediate variables seems to be the simplest
solution in both cases.
Philip Guenther
<guent...@openbsd.org>
Index: lpd/printjob.c
===
RCS file: /data/src/openbsd/src/usr.sbi
5
dmesg of boot with rev 1.205 below.
Philip Guenther
OpenBSD 6.1-current (LOCAL) #10: Wed Aug 16 21:11:41 PDT 2017
guenther@corwin.local:/usr/src/sys-lock0/arch/amd64/compile/LOCAL
real mem = 8458018816 (8066MB)
avail mem = 8127426560 (7750MB)
mpath0 at root
scsibus0 at mpath0: 256 target
On Sun, 13 Aug 2017, Ayaka Koshibe wrote:
> > It sounded like this isn't difficult to reproduce, or at least you've done
> > so a couple times already. I suggest rebuilding libpthread with gcc
> > instead of clang and see if it's equally reproducible. If not, well, you
> > can get done what you
you say you tried recompiling all libpthread with gcc?
Philip Guenther
On Sat, 12 Aug 2017, Stuart Henderson wrote:
> On 2017/07/13 17:16, Stuart Henderson wrote:
> > I've seen this a lot recently (14 = EFAULT)
> >
> > 2017-07-13T16:05:57.935Z symphytum /bsd: coredump of Xorg(62706), write
> > failed: errno 14
> > 2017-07-13T16:05:57.993Z symphytum /bsd: coredump
On Sat, 8 Jul 2017, Mike Cole wrote:
> I can't use sendbug because it only boots to ddb. This is OpenBSD 6.1 with
> latest syspatch 14 running in byhve under FreeBSD.
This is a bug in bhyve. c.f.
http://marc.info/?t=14913605473=1=3
Philip Guenther
r.
Note that kevent() EVFILT_PROC filters don't reap zombies, so your program
is accumulating zombie children until you reach your process limit.
As for the behavior of EVFILT_PROC on an already exited process, I look
forward to your sendbug report.
Philip Guenther
On Sun, 16 Apr 2017, Martin Natano wrote:
> The issue here is, that pledge("tape") does not allow to perform
> MTIOCGET on tty devices. So we should call isatty() beforehand and
> shortcut ioctl() in case the file descriptor is a tty.
ok guenther@
>Synopsis: X fails on Macbook with 6.1 snap
>Category: system
>Environment:
System : OpenBSD 6.1
Details : OpenBSD 6.1 (GENERIC) #2: Fri Mar 31 00:00:16 MDT 2017
dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC
1 - 100 of 261 matches
Mail list logo
