[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: merge bouyer-xenpvh to HEAD
Don't have time to look at that immediately, but after a very quick glance,
it seems clear the problem is in the definition of struct cpu_info. There
is an early #ifdef XEN that is true in the kernel but false in the module,
leading to serious bugs. Try compiling the module with CFLAGS+=-DXEN, you'll
probably see it works.
The ifdef should be moved to the end of the structure, like the rest.
Thanks for forwarding
Le 27/04/2020 à 12:53, Chavdar Ivanov a écrit :
---------- Forwarded message ---------
From: Chavdar Ivanov <ci4ic4%gmail.com@localhost>
Date: Mon, 27 Apr 2020 at 11:51
Subject: Re: merge bouyer-xenpvh to HEAD
To: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
Cc: port-xen <port-xen%netbsd.org@localhost>
On Mon, 27 Apr 2020 at 11:16, Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
On Sun, 26 Apr 2020 at 20:18, Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
On Sun, 26 Apr 2020 at 20:01, Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
On Sun, Apr 26, 2020 at 07:56:40PM +0100, Chavdar Ivanov wrote:
I'll try that in a moment; now I am getting
panic: kernel diagnostic assertion "(pg->flags & PG_RDONLY) == 0 ||
!blockalloc" failed: file ... genfs/genfs_io.c, line 408
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x178
kern_assert() at netbsd:kern_assert+0x48
genfs_getpages() at netbsd:genfs_getpages+0xa9f
VOP_GETPAGES() at netbsd:VOP_GETPAGES+0x6b
uvn_get() at netbsd:uvn_get+0x57
ubc_alloc_direct() at netbsd:ubc_alloc_direct+0x15b
ubc_uiomove_direct() at netbsd:ubc_uiomove_direct+0x11d
ubc_uiomove() at netbsd_uiomove+0x192
when I try to login as non-root user only - local or over ssh, su from
root to user works ok. Repeatable.
I think it's a known issue. ubc_direct has been disabled again a few hours ago
I think I saw that. My userland is 9.99.59 HEAD from 24th, the kernel
is 9.99.59 from today's branch of yours; I guess is time to update.
I rebuilt from HEAD overnight, seeing that the merge has taken place.
No more panics as mentioned above, so things are looking good.
There is one problem, though.
The new GENERIC killed nvmm for me. You can load the module, but as
soon as you start an nvmm guest, the machine grinds to a halt, it
stops every disk access, although you can still switch between the
tmux sessions in my case or type on the console window; the commands
entered never return anything back. Interrupt into ddb shows again
only the idle loop.
So in this shape GENERIC is probably not usable. Although one will
never run the same machine as a XEN giuest and qemu-nvmm host, the
kernel breaks the latter.
Obviously I still have to specify the root and swap devices on my GPT
installation, but this is not a problem - I will reinstall an MBR
X also works, but I can't get the mouse to work yet.
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |