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
"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
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
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
l
say that login_ldap should have been on the list and IMHO updating them
*all* with "pkg_add -u" is the only sane option.)
Philip Guenther
_ldap command 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
he contents 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
Forwarded with permission.
-- Forwarded message --
Date: Tue, 1 May 2018 12:22:41 -0700
From: Davide Marini
To: Philip Guenther
Subject: Re: Kernel Panic on OpenBSD 6.3 AMD64 // Chrome Related
Hi Philip,
Thank you SO much for the prompt response! I couldn't add a dmesg be
_ using pthread_once() on
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
, 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
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 (&map->lock) @ /usr/src/sys/uvm/uvm_map.c:4433
> 2nd 0xff01
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
that 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
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 intr_legac
7;s from the WITNESS 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 ho
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
>
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 Tue, 24 Jul 2018, Ricardo Mestre wrote:
> Same behaviour here with a Fujitsu Lifebook S752, although it only seems
> to affect RAMDISK_CD and not GENERIC.MP. I compiled both from a fresh
> tree and the latter boots fine, whereas the RD reboots in a loop just as
> shown below.
That was mine:
wngrade
- if we can identify 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
locally.
Thank you for the report! When you say "not easy to reproduce locally",
do you mean you _can_ semireliably reproduce it, such that if we found a
suspicious commit to revert you would be able to be pretty sure whether it
was really fixed? If so, what's your best guess
On Tue, 14 Jun 2016, Stuart Henderson wrote:
> amd64, snap from May 30th with self built kernel, seen when
> fetching a file with sftp:
Already fixed by Ingo that very day:
progressmeter.c
revision 1.44
date: 2016/05/30 18:34:41; author: schwarze; state: Exp; lines
#x27;t collect any other crash info. I will make sure to
> do so when or if it happens again.
Seeing what the other CPUs are doing would be the most useful bit, I
believe.
Philip Guenther
On Tue, 28 Jun 2016, Todd C. Miller wrote:
> I think this needs to be fixed in fts(3) instead. The following diff
> fixes it for me but has only been lightly tested.
As I noted in icb, first chunk looks sufficient to me; the latter chunk is
just optimizing the error case, as fstatat() will alre
:1,3s/^/
>
> and then I keep mashing on the Tab key and nothing happens, with no visual
> output on the screen. However, Tab works normally in insertion mode, as
> well as in other applications.
Workaround: type ^V (control-V) before typing tab.
Philip Guenther
On Sun, 3 Jul 2016, athom...@athompso.net wrote:
> >Synopsis:savecore complains on every boot about bad namelist
...
> >Description:
> With "savecore_flags=-z /var/crash" in /etc/rc.conf.local, on every
> boot, I see these two errors appear on the console:
> Jul 2 22:48:55 mail sa
: 0001
Processor Enabled : 1
[038h 0056 4]Processor UID :
...etc
We currently only support x2APIC for VMs; supporting it for real hardware
requires interrupt mapping support and we're not there yet.
Philip Guenther
On Wed, 6 Jul 2016, Tobias Ulmer wrote:
> On Tue, Jul 05, 2016 at 07:01:11PM +0100, Dimitris Papastamos wrote:
> > On Tue, Jul 05, 2016 at 02:14:57PM +0200, Martin Pieuchot wrote:
> > > Without more information it's hard to find what could be the reason
> > > for this crash. Being able to reproduc
> output below.
>
> --- interrupt ---
> srp_enter() at srp_enter+0x5c
> art_table_walk() at art_table_walk+0x197
In ddb, can you snag the output of "show reg", or at least the %rax, %rsi,
and %rdx values?
Philip Guenther
On Tue, 26 Jul 2016, f...@cock.li wrote:
> I was getting odd behavior with printf(1) when using ' or " with a value
> of 128 or more, but only on some systems.
...
> This patch adds casts to unsigned char to avoid problems when char is
> signed. With this patch applied the correct values of 80,
pi0
> C2: state 6: substate 8 >= num 3
> C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS
> acpicpu2 at acpi0
> C2: state 6: substate 8 >= num 3
> C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS
> acpicpu3 at acpi0
> C2: state 6: substate 8 >= num 3
> C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS
Harumph. Can you install the "cpuid" package and show the output of
"cpuid 5"? Run as a normal user should be fine.
Philip Guenther
mp;try, hostname) == 0 &&
> - memcmp((void *)&try, (void *)e, sizeof(try)) == 0) {
> + memcmp((void *)&try, (const void *)e, sizeof(try)) == 0) {
Isn't it simpler and better to completely delete both those casts?
Philip Guenther
ing EINTR by looping in a poll() for
writability; not sure if that would be simpler but it would allow WINCH
processing to occur during the connect...
Philip Guenther
On Mon, 8 Aug 2016, Todd C. Miller wrote:
> POSIX says connect(2) does not restart so we need to do the same kind of
> dance as async connect(2).
Untested, but the obvious port from the other BSDs to have connect() leave
the connect running asynchronously.
Philip
Index: uipc_syscalls.c
===
On Mon, 8 Aug 2016, Philip Guenther wrote:
> On Mon, 8 Aug 2016, Todd C. Miller wrote:
> > POSIX says connect(2) does not restart so we need to do the same kind of
> > dance as async connect(2).
>
> Untested, but the obvious port from the other BSDs to have connect() leave
On Sat, 3 Sep 2016, Eivind Eide wrote:
> Some more info: Did ddb trace now with 3. sept. snapshot kernel
> (handwritten, in case of typos)
>
> (...snip...)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (AGP_)
> acpiprt2 at acpi0: bus 2 (PC
d broken quirks and installation stopped. I tried:
> ftp.openbsd.org, ftp.spline.de, openbsd.cs.fau.de and ftp.bytemine.net -
> all the same result.
>
> It seems like the quirks file is corrupt.
What was the EXACT error message? Cut-n-paste from the shell window.
Philip Guenther
te 04/15/2015
...
> C2: state 6: substate 8 >= num 3: C3(10@1500 mwait.1@0x52), C1(1000@1
> mwait.1), PSS
You may want to check with your laptop(?) vendor to see if they have a
BIOS update available...like not providing ACPI data that tries to do
things that the CPU doesn't support.
Philip Guenther
1, tried to attach.
It looks like we need to make sure cpus are attached before acpicpu is
attached. I'm not sure how to do that, so in the mean time, Johan, can
you try applying the diff below and rebuilding the kernel and
On Sat, 10 Sep 2016, Eivind Eide wrote:
> 2016-09-08 14:54 GMT+02:00 Eivind Eide :
...
> > This fixed issue for me. Machine boots fine.
>
> Will this patch be necessary in the foreseeable future for these old
> dell latitudes, or will there be a fix in the tree...?
It'll get fixed at some point i
not negate the
argument.
(And how iked shuts down should probably be simplified; I believe the
modern preference is to close the imsg sockets or pipes between process
and let them take that as the indication to exit cleanly.)
Philip Guenther
On Sun, 25 Sep 2016, Sami wrote:
> Hello! I encountered a problem (kernel trap) when I was installing
> OpenBSD 6.0 to an old computer that has AMD AM486DX2 as a CPU. OpenBSD
> 5.9 works fine. When I compiled the kernel with GENERIC config but only
> the pctr driver commented out from the config
explanation above. :-)
> Is the process for building a release what everyone uses for hacking on
> OpenBSD?
Yes.
The challenge for you is how you would diagnose the problem yourself.
The compiler is reporting an error: did you examine the input files for
correctness? Compare the system includes to those from the install tgz
files? Figuring out and understanding *exactly* how the bug you created
would cause that failure would be a good
Philip Guenther
ut" wait channel; are the mii
flags not set right that it's taking the tsleep() path instead of
timeout_* path?
Philip Guenther
t be directly applied to some other syscalls where
cancellation is required by something wrapping the syscall.
(The syscall stubs are in ASM, c.f. libc/sys/Makefile.inc and libc/arch/*)
Philip Guenther
t; compiler and libc, and I do wonder why that's not happening here.
Making libpthread work makes the obvious thing wrong.
> I guess what I'm asking is whether that practice has been incorporated
> into some standard, mutilated by some standard, or simply assumed to be
> the
e should add check to the code to catch
this sort of setup by checking the cpuid_level variable before using the
higher CPUID leafs.
Can you try applying the diff below, temporarily re-enable that BIOS
option, then report the resulting dmesg and verify that ping works
properly?
Philip Guenther
Ind
On Tue, 2 Feb 2016, Philip Guenther wrote:
...
> Currently we seem to assume that the presence of certain CPU features like
> AVX implies that CPUID supports the related leaf; that BIOS option breaks
> that assumption, resulting in the bogus fpu_save_len sizing you hit.
> From t
e bad part of the change
I had made (I assumed the %cr4 register is always present, but it isn't on
"most 486s"), so it'll stay fixed in 5.9.
Philip Guenther
aking a look at this tomorrow.
Philip Guenther
g unstorable in ustar, so I'm
planning on committing the slightly tweaked version of your diff seen
below.
Thank you for investigating this and tracking down the underlying issue.
Nice job!
Philip Guenther
Index: tar.c
===
R
op or mishandle those others cases; I need to generate
some bogus archives to check.
It laso looks like handling of doubled slashes in the middle of paths is
also less than ideal, resulting in duplicated checks when they could be
skipped over, though changes for that will probably be too invasive to get
in before release.
Philip Guenther
On Sun, 14 Feb 2016, Philip Guenther wrote:
> On Sun, 14 Feb 2016, Nicolas Bedos wrote:
...
> > >Fix:
> > I did some digging and it seems pax gets stuck in a loop after
> > calling node_creat (file_subs.c) to create /tmp/foo/bar:
> ...
> > The first
On Mon, 15 Feb 2016, Vadim Zhukov wrote:
> > @@ -613,6 +614,17 @@ chk_path(char *name, uid_t st_uid, gid_t
>
> Hello, Philip.
>
> I think we should change "if" to "while" in this function, too...
> After that, okay zhuk@.
...
> /*
>* watch out for paths with nodes stored directly in
acpiec.c's sci handling will need to be taught how to use that 3rd
register for this hardware to be supported...
Philip Guenther
On Tue, 8 Mar 2016, Mike Larkin wrote:
> On Tue, Mar 08, 2016 at 11:32:02PM -0800, Philip Guenther wrote:
...
> > I guess acpiec.c's sci handling will need to be taught how to use that 3rd
> > register for this hardware to be supported...
>
> Nice find. I didn't
ng destroyed by *_destroy(). I belive that to
implement that synchronization in the presence of signals would require
the core of *_wait() to be a syscall and have the kernel do all the
tracking. Even futexes aren't enough for that.
Philip Guenther
On Mon, 4 Apr 2016, patrick keshishian wrote:
> I will look for a BIOS update. Last time I looked there were none.
>
> This laptop came with some version of Windows (I forget now which), it
> had no issues with sleep/wake/hibernate/etc. Assuming the issue is with
> broken AML and the BIOS, then
etter--delete everything under /usr/obj/
The patches assume you have a 5.9 source tree without objects from a
non-5.9 build hanging around. If you're doing cvs updates you're expected
to be following the general "building from source" directions in the
FAQ, which include "rm -rf /usr/obj/*"
Philip Guenther
esn't show the 'PERF' flag, so this frequency measurement is from
the rdtsc() bits in cpu_tsc_freq(). At this point in the startup, delay()
should be using i8254_delay(). The second CPU will do its calculation
using lapic_delay(); could there be an error in how we handle the i8254
stuff?
Philip Guenther
On Sun, 24 Apr 2016, Kári Tristan Helgason wrote:
> Any interest in this patch?
>
> Would tech perhaps be a more appropriate list to post this to?
tedu@ committed one of the diffs that had been bouncing around; if there's
further changes to make then a fresh diff will be neces
On Tue, 3 May 2016, Mark Kettenis wrote:
> I think the answer is that we should set CPUF_PRIMARY earlier. In fact
> we can set it in the initializer of cpu_info_primary. I'll need to
> check i386 as well.
Beware, i386 is weird: quoting i386/machdep.c:
* Note that identifycpu() is called twic
On Sat, 7 May 2016, Andrew Fresh wrote:
> While this does correctly point out that the return value in scalar mode
> is incorrect and fixes calling in scalar context, it breaks error
> handling in list context as you can see if you run the test.
>
> This minor addition to the patch keeps the exi
On Tue, 10 May 2016, cheeky.m wrote:
> console said
>
> login: uvm_fault(0x8190d900, 0x815c5370, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at fd_getfile+0x17:movq0(%rax,%rdx,8),%rax
> ddb{4}> trace
> fd_getfile() at fd_getfile+0x17
> getsock() at gets
Just updated src, with a few local diffs but nothing changed since last
happy build. New kernels now fault right after the "root on" line.
macpcc:
root on wd0a...
panic: trap type 300 at 3c957c (uvm_fault+0x234) lr 3c9538
Stopped at Debugger+0x10: lwz r0,36(r1)
Debugger() at Debugger+0xc
On Sun, 22 May 2016, Philip Guenther wrote:
> Just updated src, with a few local diffs but nothing changed since last
> happy build. New kernels now fault right after the "root on" line.
Everything happy again after reverting the uvm_amap.c diff; revert
committed.
Philip
On Sat, 25 Apr 2015, Danilo Falcão wrote:
> There's a typo in the original pf.conf (OpenBSD 5.6)
>
> - Original /etc/pf.conf
>
> *# By default, do not permit remote connections to X11*
> *block return in on ! lo0 proto tcp to port 6000:6010*
>
> - Result (nmap)
>
> rembrandt:~ root# nmap -P0 ju
ort. As far as we could tell, there was a single
cause to all three cases in the supplied proof-of-concept code; a fix for
that has been committed to -current.
Philip Guenther
guent...@openbsd.org
;.
This sounds like the source tar.gz files were extracted from / instead of
/usr/src.
Does everything work fine *before* you extract those? *Exactly* what
steps did you perform when extracting them?
Philip Guenther
implementable without
kernel changes, so we believe this is an error in the RETURN VALUES
section of the standard and do not feel this is a bug in our
implementation.
Philip Guenther
On Mon, 25 May 2015, Tim Chase wrote:
> On 2015-05-25 09:32, skin...@britvault.co.uk wrote:
> > $ mkdir -p /tmp/foo/bar
> > $ ls -dF /tmp/foo/bar
> > /tmp/foo/bar/
> > $ find /tmp/foo -type d -empty -ls
> > 31751 4 drwx-- 2 craig wheel 512 May 25 09:06 /tmp/foo/bar
> >
> > $ find /tmp/foo -typ
herwise via the -prune option.
(-empty doesn't imply -prune, as you could invoke a command that creates a
file in the target directory, in which case find would need to evaluate
the condition on that file.)
Philip Guenther
ng to get the lock on "/mnt"
I think we need to change sys_mount() to not use LOCKLEAF the first time,
not do most of the checks at the start but rather look up the path again
with LOCKLEAF _after_ the VFS_MOUNT() call, error if it's changed from the
first time, and do the previous checks now that all the requisite paths
are resolved in a safe order.
This will take a bit of work...
Philip Guenther
On Fri, 31 Jul 2015, david.a.b...@gmail.com wrote:
> >Description:
> After upgrading 5.7-stable to the latest (Jul 30) snapshot on my ASUS
> 1215N laptop,
> I am consistently getting a page fault on boot, just as root is
> mounted. Bug only
> affects GENERIC.MP. GENERIC (singl
On Fri, 31 Jul 2015, David A. Baer wrote:
> The patch resolved the issue. Thank you! Believe it or not, this is
> the latest BIOS available from the vendor (2011-05-05), so I don't have
> much hope there, but there's no harm in asking...
Well, if you do so you can point them to the ACPI 5.0 spec
ll in future versions of OpenBSD.
The default for PermitRootLogin was changed to prohibit-password back in
July.
Philip Guenther
On Sun, 20 Sep 2015, Jason Barbier wrote:
> To add to this it asks you if you wish to permit root login over SSH,
> suggest that you say no, and tells you the default is no. So you had to
> implicitly tell it root logon was allowed at install, or explicitly edit
> the config file to allow for ro
On Tue, 22 Sep 2015, Ted Unangst wrote:
> Aaron Poffenberger wrote:
> > > Synopsis:System Hangs when Quitting X11 on Lenovo T450s
> > > Category:X11
> > > Environment:
> > System : OpenBSD 5.8
> > Details : OpenBSD 5.8-current (GENERIC.MP) #1374: Sun Sep 20
> >
On Sat, 10 Oct 2015, Ted Unangst wrote:
> The program below, when run without arguments, prints connect failed,
> invalid argumemt. Apparently connect() does not expect to be passed a
> full sized sockaddr_storage.
>
> 1. This is annoying. The sin_len has already been filled in, etc. Why
> does
On Mon, 12 Oct 2015, Philip Guenther wrote:
> Rule: standard APIs CANNOT assume userland has set s*_len correctly.
>
> This is simply fallout of the fact that s*_len were added late, in BSD
> 4.4. As a result, calls have to deal with the possibility that it may
> contain rando
of
how some pledge bits were handled, so we're now polishing the involved
changes.
Philip Guenther
On Thu, 29 Oct 2015, Todd C. Miller wrote:
> On Thu, 29 Oct 2015 21:38:07 -0400, "Ted Unangst" wrote:
>
> > fc -e - | -s [-g] [old=new] [prefix]
> >
> > 1. What does fc stand for? The manual doesn't tell me.
>
> According to bash it is "fix command" though I thought it was "find
> command". Who
On a cold boot, I have no problems entering my passphrase for crypto
softraid.
On a warm reboot, efiboot seems to drop characters I type quite a bit.
This makes typing my passphrase practically impossible. Typing at boot>
shows space to be particularly affected. This affects both the built-
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 of
rying to do with iperf...
Pratik, did you say you tried recompiling all libpthread with gcc?
Philip Guenther
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 o
1.205
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 t
maybe we should just pass the option
explicitly in the kernel Makefiles and not push it on all of userland.
Philip Guenther
ocate the reported issue but it missed that case then
you should review why.)
...
> One of the possible solutions is to parse the inode number from the CF
> file using a 64-bit accumulator variable instead of “i”, or to declare
> “i” as unsigned long long.
Simply removing the i
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
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, th
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 a
. Bob and I are
testing a diff to do so.
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
g
on amd64, so there doesn't seem to be a need to fix this before the
opengroup discussion is resolved.
Philip Guenther
you used to 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
mbination of patches in
testing. That seems to have been resolved; if you have problems with
builds after that one, please let us know.
Sorry about the headache, and please keep up the excellent exercising of
snaps!
Philip Guenther
On Sun, 11 May 2014, RD Thrush wrote:
> login: atascsi_passthru_done, timeout
> stopping package daemons: apcupsd dbus_daemon.
> uvm_fault(0xd0b8b8e0, 0xefffe000, 0, 1) -> d
Weird: that's an EACCES error. Writing to a non-existent page (no
mapping) gives you EFAULT, so that's writing to a read-o
On Mon, 12 May 2014, RD Thrush wrote:
> I use this box mostly w/amd64 -current. I boot in i386 appx. weekly to
> do a partial dpb bulk build. I don't use tmpfs (or mfs) in i386 mode.
> I do the dpb builds (both i386 and amd64) w/ chroot. This is the first
> time I've encountered this problem
On Mon, 12 May 2014, Stuart Henderson wrote:
> The thing I have some recollection of (though not any specifics) was
> some old tests espie did switching filesystems between ro and rw
> as an alternative to using systrace to notice writes outside the work
> directory. Do you remember any more detail
ernel's sysctl logic. A
previous attempt to fix this created other locking issues and was
reverted. I've almost got exit1() cleaned up enough that we might be able
to take a second stab at this...
Philip Guenther
1 - 100 of 249 matches
Mail list logo
