2020 at 20:21, Maxime Villard wrote:
Le 05/05/2020 à 21:01, Chavdar Ivanov a écrit :
On Mon, 4 May 2020 at 21:21, Chavdar Ivanov wrote:
Hi,
netbsd-GENERIC_KASLR from yesterday fails to pass the prekern stage
with a frightening message in red 'Page fault'. I've never seen this
before, no idea
Le 05/05/2020 à 21:01, Chavdar Ivanov a écrit :
On Mon, 4 May 2020 at 21:21, Chavdar Ivanov wrote:
Hi,
netbsd-GENERIC_KASLR from yesterday fails to pass the prekern stage
with a frightening message in red 'Page fault'. I've never seen this
before, no idea if I can get any further info.
This
Le 11/03/2020 à 21:44, Chavdar Ivanov a écrit :
> On Wed, 11 Mar 2020 at 17:45, Maxime Villard wrote:
>>
>> Please CC me for issues related to NVMM, there is a number of lists where
>> I'm not subscribed.
>
> I thought about it, but my presumption was that the pr
Please CC me for issues related to NVMM, there is a number of lists where
I'm not subscribed.
My understanding is that this commit is the cause (CC ad@):
https://mail-index.netbsd.org/source-changes/2019/12/06/msg111617.html
NVMM reschedules the thread when the SPCF_SHOULDYIELD flag is
Le 03/11/2019 à 07:52, Maxime Villard a écrit :
Le 01/11/2019 à 14:46, David Brownlee a écrit :
On Mon, 28 Oct 2019 at 14:58, Maxime Villard wrote:
Le 22/10/2019 à 22:34, Maxime Villard a écrit :
I will soon commit a set of changes in NVMM, which will require a full
rebuild
Le 01/11/2019 à 14:46, David Brownlee a écrit :
On Mon, 28 Oct 2019 at 14:58, Maxime Villard wrote:
Le 22/10/2019 à 22:34, Maxime Villard a écrit :
I will soon commit a set of changes in NVMM, which will require a full
rebuild and reinstallation of: the kernel NVMM driver, the libnvmm API
First of all, you should not change the permissions of /dev/nvmm. It should
remain 640 root:nvmm.
Then:
(1) How did you launch qemu-nvmm before I added the "nvmm" group? You
were launching it as root, right? Overall you should not launch a program
like Qemu as root, that's precisely why I added
Le 22/10/2019 à 22:34, Maxime Villard a écrit :
[I am not subscribed to this list, so if you want to answer, make sure to
CC me.]
I will soon commit a set of changes in NVMM, which will require a full
rebuild and reinstallation of: the kernel NVMM driver, the libnvmm API,
the libnvmm ATF tests
[I am not subscribed to this list, so if you want to answer, make sure to
CC me.]
I will soon commit a set of changes in NVMM, which will require a full
rebuild and reinstallation of: the kernel NVMM driver, the libnvmm API,
the libnvmm ATF tests, and the qemu-nvmm package if you're using it.
Le 17/10/2019 à 14:45, Maxime Villard a écrit :
Le 17/10/2019 à 14:07, Joerg Sonnenberger a écrit :
On Thu, Oct 17, 2019 at 12:43:48PM +0200, Rhialto wrote:
On Thu 17 Oct 2019 at 11:07:44 +0200, Maxime Villard wrote:
I guess we whould disable the messages on this particular file for now
Le 17/10/2019 à 14:07, Joerg Sonnenberger a écrit :
On Thu, Oct 17, 2019 at 12:43:48PM +0200, Rhialto wrote:
On Thu 17 Oct 2019 at 11:07:44 +0200, Maxime Villard wrote:
I guess we whould disable the messages on this particular file for now as
the others have suggested, and file a PR in LLVM
I guess we whould disable the messages on this particular file for now as
the others have suggested, and file a PR in LLVM/GCC, because apart from
a compiler bug I don't see what it could be.
Le 17/10/2019 à 09:22, J. Hannken-Illjes a écrit :
Any chance we can build x86 kernels without
Le 14/10/2019 à 01:01, Chavdar Ivanov a écrit :
My amd64 build also failed with
...
src/tests/lib/libnvmm/h_mem_assist.c:178:2: error: missing initializer
for field 'off' of 'const struct test'
[-Werror=missing-field-initializers]
...
(and many more).
Ah yes, I was doing local builds of it,
8.99.51 crash:
panic: pr_find_pagehead: [npfcn4pl] item 0x98a0b89491b8 poolid 182 != 181
cpu1: Begin traceback...
vpanic() at netbsd:vpanic+0x160
snprintf() at netbsd:snprintf
pool_put() at netbsd:pool_put+0x6b9
pool_cache_invalidate_groups() at netbsd:pool_cache_invalidate_groups+0x71
Le 17/12/2018 à 08:10, Thomas Klausner a écrit :
On Mon, Dec 17, 2018 at 08:06:36AM +0100, Maxime Villard wrote:
Le 16/12/2018 à 09:09, Thomas Klausner a écrit :
[ 16674.534547] panic: pmap_get_physpage: out of memory
Well, out of memory means out of memory. KASAN consumes a bit more than
1
Le 16/12/2018 à 09:09, Thomas Klausner a écrit :
[ 16674.534547] panic: pmap_get_physpage: out of memory
Well, out of memory means out of memory. KASAN consumes a bit more than
1/8 of the KVA. So if in normal times your system would use 8GB of ram,
KASAN adds an extra ~1.1GB.
: sysutils/lsof stopped working for non-root user]
Date : Tue, 25 Sep 2018 14:16:03 +0200
De : Maxime Villard
Pour : Martin Husemann
Le 25/09/2018 à 13:19, Martin Husemann a écrit :
Sounds like your kernel pointer changes?
I've checked, and indeed, lsof retrieves kern.proc2 via KVM, and expects
I've deeply investigated this, and I don't see what's wrong. The issue I was
talking about yesterday is apparently unrelated.
It seems that our i386/xen code somehow does not tolerate having a pa allocated
before the LDT. In fact, it has nothing to do with lapic and all the things
I've committed;
Le 21/12/2016 à 15:37, Manuel Bouyer a écrit :
> Hello,
> recent i386 Xen kernels don't boot any more, they fails to start init,
> as can be seen here:
> http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/
> (I also tested a 201612200210Z kernel, with the same result)
After re-reading the code,
Le 15/12/2016 à 09:21, Paul Goyette a écrit :
>> Module Name:src
>> Committed By: maxv
>> Date: Sun Dec 11 08:31:53 UTC 2016
>>
>> Modified Files:
>> src/sys/arch/amd64/amd64: machdep.c
>> src/sys/arch/i386/i386: machdep.c
>> src/sys/arch/x86/x86: pmap.c
>>
Le 02/10/2016 à 09:21, Thomas Klausner a écrit :
Hi!
I just had a new panic with a 7.99.39/amd64. Light load, just some
network + disk.
panic: kernel diagnostic assertion "onfault == kcopy_fault || rcr2() <
VM_MAXUSER_ADDRESS" failed: file ".../src/sys/arch/amd64/amd64/trap.c", line 314
Le 04/07/2016 à 08:51, Martin Husemann a écrit :
On Mon, Jul 04, 2016 at 09:53:21AM +0800, Paul Goyette wrote:
vapnic + 0x140
cd_play_msf +0x0
kauth_cred_geteuid + 0x50
There is something wrong here: kauth_cred_geteuid can't ever call cd_play_msf.
Maybe a bogus module loader fixup? Module VA
Yay!
That's KMEM_SIZE. Great.
It means that it caught a memory corruption somewhere.
That being said, I don't think I can help without a trace...
Le 31/10/2014 22:01, Petri Laakso a écrit :
Hi
I'd got panic when doing 7.0_BETA file system resize for raspberry pi after
install. I compiled
Le 27/09/2014 00:19, Christos Zoulas a écrit :
In article ffa0a432ddbd95e6cf119c2b5fab4...@mail.marples.name,
Roy Marples r...@marples.name wrote:
On 2014-09-26 19:27, Maxime Villard wrote:
I permit myself to ping, since I sent this more than a month ago, and
it
is still not fixed.
From
Le 23/08/2014 15:03, Maxime Villard a écrit :
Le 23/08/2014 13:00, Martin Husemann a écrit :
On Fri, Aug 22, 2014 at 10:13:14PM +0200, Maxime Villard wrote:
- Wondering if it is a specific issue I reboot on Linux, and try to install the
USB image and the ISO in a VM. It does not seem
Le 26/09/2014 21:44, Roy Marples a écrit :
On 2014-09-26 19:27, Maxime Villard wrote:
I permit myself to ping, since I sent this more than a month ago, and it
is still not fixed.
From the NetBSD-daily amd64 live shell:
# dhclient
Shared object libgssapi.so.10 not found
Does dhcpcd work
Le 23/08/2014 13:00, Martin Husemann a écrit :
On Fri, Aug 22, 2014 at 10:13:14PM +0200, Maxime Villard wrote:
- Wondering if it is a specific issue I reboot on Linux, and try to install
the
USB image and the ISO in a VM. It does not seem to complain about
installboot,
but now
Le 17/07/2014 03:25, William D. Jones a écrit :
Hello all,
I am not sure whether this is user error or a legitimate bug, so I will post
here before filing a PR. The following thread may be related:
http://mail-index.netbsd.org/current-users/2013/12/21/msg023935.html
I don't think it is,
My mistake; committed great shit, sorry. However, the fix from njoly in
linux32/common/linux32_exec_elf32.c should be
KASSERT(len = LINUX32_ELF_AUX_ENTRIES * sizeof(Aux32Info));
instead of
KASSERT(len = LINUX32_ELF_AUX_ENTRIES * sizeof(AuxInfo));
Le 23/02/2014 12:38, Thomas
Le 21/12/2013 18:45, Kurt Schreiner a écrit :
On Sat, Dec 21, 2013 at 06:37:26PM +0100, J. Hannken-Illjes wrote:
On Dec 21, 2013, at 6:21 PM, Kurt Schreiner k...@ub.uni-mainz.de wrote:
a kernel compiled from source cvs updated some minutes ago can't exec elf
binaries anymore; seen on i386 and
Le 31/10/2013 02:03, Mindaugas Rasiukevicius a écrit :
It is not a bug, but it is potentially error-prone. I adjusted the code:
http://mail-index.netbsd.org/source-changes/2013/10/31/msg048829.html
Ok. While I'm at it: tmpfs_read() returns EISDIR when the file
is not regular, but a
On 08/27/13 10:44, Martin Husemann wrote:
On Tue, Aug 27, 2013 at 04:37:30AM -0400, Christos Zoulas wrote:
Useful or not, it currently works :-)
Yes, and if we need it for compat: fine. Out of curiosity: why does linux
produce some binaries with ET_DYN and other with ET_EXEC? We only seem
On 08/26/13 16:58, Eric Haszlakiewicz wrote:
On Sun, Aug 25, 2013 at 03:31:42PM +0200, Maxime Villard wrote:
Hi,
here is a patch for some tweaks in kern/exec_elf.c.
* Typo in a comment
* elf_check_header() already ensures eh.e_phnum MAXPHNUM
How about also moving the check
Hi,
here is a patch for some tweaks in kern/exec_elf.c.
* Typo in a comment
* elf_check_header() already ensures eh.e_phnum MAXPHNUM
* Put is_dyn before. It's just a small optimization:
elf_check_header(eh, ET_EXEC) is always called before checking
is_dyn, so if we invert the two things
Hi,
fstat() returns -1 on error, not 0.
Index: ftpd.c
===
RCS file: /cvsroot/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.199
diff -u -r1.199 ftpd.c
--- ftpd.c 3 Jul 2013 14:16:01 - 1.199
+++ ftpd.c 31 Jul 2013
35 matches
Mail list logo
