] Passed.
./2023/2023.07.07.20.19.08/test.log.gz:timerfd_block: [1.081552s] Passed.
6. My own amd64 testbed running on real hardware shows no failures in
205 runs.
7. My own i386 testbed using "qemu -accel kvm" on Linux shows no
failures in 359 runs.
--
Andreas Gustafsson, g...@netbsd.org
o_file
> ./lib/libc/stdlib/t_mktemp:mktemp_large_template
> ./lib/libc/sys/t_stat:stat_chflags
> ./usr.bin/ztest/t_ztest:assert
--
Andreas Gustafsson, g...@gson.org
nothing about pmap, and the -current version uses PTE_P and PTE_PS
> while the -8 version uses PG_V/nothing.
It's probably easier to revert src/sys/arch/x86/x86/db_memrw.c 1.6.
--
Andreas Gustafsson, g...@gson.org
Edgar Fuß wrote:
> Real hardware (AMD64), 8.2_STABLE from yesterday, custom config.
This looks like PR 53311. The commit where that problem started
(src/sys/arch/x86/x86/db_memrw.c 1.6) was pulled up to to the -8
branch, and apparently the commits that fixed it were not.
--
Andreas Gustafs
Hauke Fath wrote:
> On Tue, 29 Sep 2020 11:09:25 +0300, Andreas Gustafsson wrote:
> > I have now committed the code to log the message, without rate
> > limiting. If a consensus should arise that rate limiting the message
> > is a good idea, the code to do that should be
I have now committed the code to log the message, without rate
limiting. If a consensus should arise that rate limiting the message
is a good idea, the code to do that should be committed by someone in
favor of it.
--
Andreas Gustafsson, g...@gson.org
h the ad hominem attacks and focus on the technical issues.
--
Andreas Gustafsson, g...@gson.org
hang for you?
If PR 55659 is fixed, there will be more cases where the message is
logged (at least ssh-keyegn), but still only one per blocking process.
--
Andreas Gustafsson, g...@gson.org
nd both block
immediately, it would be helpful to get messages identifying both of
them.
--
Andreas Gustafsson, g...@gson.org
, you can do "sysctl -w kern.entropy.depletion=1", but
there's no good reason to ever do that outside of testing.
--
Andreas Gustafsson, g...@gson.org
Manuel Bouyer wrote:
> If you run a dd on /dev/random I guess the system will run out of
> entropy pretty fast.
In -current, entropy does not run out.
--
Andreas Gustafsson, g...@gson.org
amming the console about it is doing the administrator a
favor.
--
Andreas Gustafsson, g...@gson.org
was killed:
orphaned traced process", but I'm sure there are many others.
--
Andreas Gustafsson, g...@gson.org
curproc->p_pid, curproc->p_comm);
+
if (ISSET(flags, ENTROPY_SIG)) {
error = cv_wait_sig(>cv, >lock);
if (error)
--
Andreas Gustafsson, g...@gson.org
1 using blocks of up to 64 bytes for the RT5370 only:
https://www.gson.org/netbsd/patches/run-faster.patch
OK to commit?
--
Andreas Gustafsson, g...@gson.org
0.03.22.00.56.45/test.log
--
Andreas Gustafsson, g...@gson.org
ble (even though it would seem that the changes of the
> sys call having worked by accident seem to be not very high).
I agree that this sounds plausible. Also, the tests never failing for
Christos might then be explained by him running them in an environment
that has a different number of file descri
update?
--
Andreas Gustafsson, g...@gson.org
rd, 202 steps back):
http://www.gson.org/netbsd/bugs/build/amd64-baremetal/commits-2020.04.html#2020.04.02.21.36.03
There have also been other commits since the previous run, so these
changes in test outcomes may not all be due to your sbin/route commits.
--
Andreas Gustafsson, g...@gson.org
s...@franklin.netbsd.org:/home/netbsd/8/amd64/obj/sys/arch/amd64/compile/BABYLON5
amd64
NetBSD guido.araneus.fi 9.0 NetBSD 9.0 (GENERIC) #0: Fri Feb 14 00:06:28 UTC
2020 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
--
Andreas Gustafsson, g...@gson.org
01.39/test.html#net_if_gif_t_gif_gif_basic_ipv4overipv4
> 3. The rest of the tests (I've sampled 5 of them) don't fail for me.
If you do a full release build from scratch, install the release, and
run the tests in the installed release like the testbeds do, I bet
they will fail for you, too.
--
Andreas Gustafsson, g...@gson.org
/03/23/msg038127.html
which identified both the commits and the developer responsible for
the breakage.
--
Andreas Gustafsson, g...@gson.org
contexts.
They already do, they're just formatted differently.
--
Andreas Gustafsson, g...@gson.org
Hi all,
I have this patch to replace the debug printfs in sys/dev/usb/if_urtwn.c
by usbhist calls, roughly modelled after the use of usbhist in if_axe.c:
https://www.gson.org/netbsd/patches/urtwn-usbhist.patch
OK to commit?
--
Andreas Gustafsson, g...@gson.org
Maxime Villard wrote:
> How about _onestep()? Or _nosplit()?
Or just conclude that there are no good options and we might as well
call it _once() to be compatible with other OSes.
--
Andreas Gustafsson, g...@gson.org
t; is all that is needed.
I guess we also need to bump these definitions in the Makefile?
SAMISCCPPFLAGS+= -DHEAP_START=0x1 -DHEAP_LIMIT=0x3
--
Andreas Gustafsson, g...@gson.org
increase it?
--
Andreas Gustafsson, g...@gson.org
ors for a
living. What I'm proposing here could in theory either increase or
decrease the demand for my products - I'm not sure which.
--
Andreas Gustafsson, g...@gson.org
t; usleeps less than i/HZ possibly managing an error-budget. I haven't
> looked into qemu at all, but an error of a factor 2 looks suspicious.
I fully agree.
--
Andreas Gustafsson, g...@gson.org
7/07/02/msg022024.html
- Make qemu deal better with hosts unable to sleep for short
periods of time, or
- Make the guest system deal better with missed timer interrupts.
--
Andreas Gustafsson, g...@gson.org
restricting it to root instead.
It's ASLR that's broken, not rdtsc, and I strongly object to
restricting the latter just to that people can continue to gain
a false sense of security from the former.
--
Andreas Gustafsson, g...@gson.org
Emmanuel Dreyfus wrote:
> In case it rings a bell for someone: Trying latest netbsd-7 XEN3PAE_DOM0
> build for i386, I get a reproductible crash when attaching agp:
PR 50446 may be related.
--
Andreas Gustafsson, g...@gson.org
Martin Husemann wrote:
I have another evbarm machine now hanging as well, so it is not just alpha.
The sparc test runs on babylon5 are affected, too. I just committed a
fix, let's see if it works.
--
Andreas Gustafsson, g...@netbsd.org
working now; the kernel debugging I've done since then
has been using qemu's built-in gdb stub instead, as described in
https://wiki.netbsd.org/kernel_debugging_with_qemu/.
--
Andreas Gustafsson, g...@gson.org
will be quite happy with
either a 32bit of 64bit result.
Not if it is expecting the other one.
--
Andreas Gustafsson, g...@netbsd.org
the buffer dynamically using the size given by an initial
sysctl() call with oldp = NULL.
If the original types of the sysctl variables are restored, this
work-around will no longer serve a purpose, and I'm asking for it
to be removed.
Opinions?
--
Andreas Gustafsson, g...@netbsd.org
Index
Thor Lancelot Simon wrote:
I don't actually know of any code that hands over a wrong-size
buffer and will therefore break, though. Do you?
No, but I think we should aim for correctness, not just works for me.
--
Andreas Gustafsson, g...@netbsd.org
37 matches
Mail list logo
