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
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 à 22:18, Kamil Rytarowski a écrit :
> On 11.03.2020 21:44, Chavdar Ivanov wrote:
>>> The test program below shows the difference. On NetBSD-9 you have many
>>> "resched", as expected. On NetBSD-current you have none.
>> As you say, I don't get any output from your program on -current
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 t
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 s
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 and
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.
Yo
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 as
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 DIAGNOSTI
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, not
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
pool_ca
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.
e: [ci4...@gmail.com: 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.proc
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
crash
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
Le 06/11/2014 08:28, Michael van Elst a écrit :
petri.laa...@asd.fi (Petri Laakso) writes:
On Fri, 31 Oct 2014, Maxime Villard wrote:
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...
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 s
Le 27/09/2014 00:19, Christos Zoulas a écrit :
In article ,
Roy Marples 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 the NetBSD-daily amd64 live shell:
# dhclient
Shared object
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 d
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 to
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 compla
I've been trying to install a new system for three hours now, but I just can't.
I've tried two USB disk images and one ISO, in a VM and on a physical system.
I report these issues just to say they exist, but I've wasted enough time with
this, so I'll just wait for things to be magically fixed.
-
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
In man 7 tests I read:
"aids developers in catching bugs and regressions in the code when
they performing modifications to..."
^^^
I guess it's "they are performing", right?
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 wrote:
a kernel compiled from source cvs updated some minutes ago can't exec elf
binaries anymore; seen on i386 and arm, screenshot of i
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 non-regula
Hi,
I have a question regarding the function tmpfs_alloc_node() in
fs/tmpfs/tmpfs_subr.c. When alloc'ing the area for symlinks,
there's this code:
l.171
nnode->tn_size = strlen(target);
if (nnode->tn_size == 0) {
nnode->tn_spec.tn_lnk.tn_link = NULL;
On 08/27/13 01:28, tsugutomo.en...@jp.sony.com wrote:
> Maxime Villard writes:
>
>> * 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 we avoid ca
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 se
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 > MAX
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
Le 04/07/2013 04:54, Christos Zoulas a écrit :
> In article <51d46245.5090...@m00nbsd.net>,
> Maxime Villard wrote:
>> Hi,
>> here is a patch for tftpd.
>>
>> - - CVS
>> The functions tsize_handler()/timeout_handler()/blk_handler() are
>> given a
Hi,
here is a patch for tftpd.
- - CVS
The functions tsize_handler()/timeout_handler()/blk_handler() are
given a pointer 'ec' that they are *supposed* to change when an error
occurs. Also, they are *supposed* to return -1 to indicate that an
error occured. But, actually, they never change 'ec' and
u%c", 0,
- tftp_tsize, 0)))
+ tftp_tsize, 0)) > 0)
alen += l;
}
oack_h = (struct tftphdr *) oackbuf;
- -
Le 28/06/2013 11:10, Maxime Villard a écrit :
> Hi,
> one week
Hi,
here is a small patch for ftpd.
1. If one of these stat() fail, st1 and/or st2 are not initialized.
2. Since fatal() calls _exit(), 'ng' is useless.
3. 'b' will be defined in the if{}/elseif{}/else{}.
4. 'errno' is already initialized above.
Ok/Comments?
Index: cmds.c
==
Hi,
one week ago, I was comparing OpenBSD's TFTPD with NetBSD's one when
I stumbled across several buffer overflows that may occur when dealing
with specially crafted packets. I'm gonna explain quickly what it
consists in.
- - src/libexec/tftpd/tftpd.c - -
Let's say you send this packet:
Hi,
I've been making a code scanner for a while, and I recently launched it
on NetBSD's source tree to test some new rules. It found 16 potential
bugs that I've summed up here:
http://M00nBSD.net/ae123a9bae03f7dde5c6d654412daf5a.html
I do not provide patches as I don't always know what's
47 matches
Mail list logo