Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Weird qemu-nvmm problem
On Sun, 8 Mar 2020 at 22:27, Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
>
> Hi,
>
> On a -current (from today, but has happened before), when running a
> particular nvmm guest (32-bit Windows 10), usually when it is busy
> going through some updates, the host gets into a weird state. I have
> an ssh connection to it with several tmux panes open; I can switch
> between them, so the connection to the host is still ok, but in the
> same time the host does not answer to pings anymore; none of the tmux
> panes themselves accepts any input, with the exception of the one I am
> running the qemu client in; I can interrupt it and after that the host
> comes into normal state. When this happens, I get
>
> [ 7444.602404] coretemp3: workqueue busy: updates stopped
> [ 7474.614306] coretemp0: workqueue busy: updates stopped
> [ 7474.614306] coretemp1: workqueue busy: updates stopped
> [ 7474.614306] coretemp2: workqueue busy: updates stopped
> [ 23591.005414] acpitz4: workqueue busy: updates stopped
> [ 23591.005414] acpibat1: workqueue busy: updates stopped
>
> The machine is not doing anything else at the moment, the temperatures
> are within the expected range.
>
> Any clues?
>
> Chavdar
>
>
> --
> ----
I couldn't even complete the boot of a WindowsNext server this
morning; I lost any remote connection to the host, at the console I
was able to enter the debugger; the trace is (I guess the first part
is the actuall k/b interrupt):
breakpoint() at netbsd:breakpoint+0x5
wskbd_translate() at netbsd:wskbd_translate+0xd9e
wskbd_input() at netbsd:wskbd_input+0xbe
wskbd_input() at netbsd:wskbd_input+0x7f
pckbcintr() at netbsd:pckbcintr+0x72
intr_biglock_wrapper() at netbsd:inter_biglock_wrapper+0x36
Xhandle_ioapic_edge1() at netbsd:Xhandle_ioapic_edge1+0x6d
--- interrupt ---
Xspllower() at netbsd:Xspllower+0xe
nvmm_ioctl() at netbsd:nvmm_ioctl+0xec
sys_ioctl() at netbsd:sys_ioctl+0x59c
syscall() at netbsd:syscall+0x299
--- syscall (number 54) ---
7c1a5e58199a:
db{0}>
I tried to save a dump (reboot 0x104), but got 'Insufficient space',
which perhaps refers to the small swap area (4GB on a 20GB machine).
In both occasions the disk in use by the nvmm quest is a zfs zvol,
though (but all my nvmm guests use those).
--
----
Home |
Main Index |
Thread Index |
Old Index