bug#33106: "make check-system TESTS=basic" fails on master

[Chris Marusich <cmmarusich@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4315 bytes --]

Hi,

I've reconfigured my system after running "guix pull":

    root@garuda ~# guix describe
    Generation 6	Oct 23 2018 19:29:12	(current)
      guix a89f731
        repository URL: https://git.savannah.gnu.org/git/guix.git
        commit: a89f731b1506b3b560f4a179da2889408dfa881d

    GUIX_PACKAGE_PATH="/home/marusich/custom-guix-packages"
    root@garuda ~# 

The problem still occurs, but now there are no 9p-related errors:

--8<---------------cut here---------------start------------->8---
loading kernel modules...
[    1.350969] usbcore: registered new interface driver usb-storage
[    1.366341] usbcore: registered new interface driver uas
[    1.385533] hidraw: raw HID events driver (C) Jiri Kosina
[    1.389538] usbcore: registered new interface driver usbhid
[    1.391152] usbhid: USB HID core driver
[    1.443626] isci: Intel(R) C600 SAS Controller Driver - version 1.2.0
[    1.480467] PCI Interrupt Link [LNKC] enabled at IRQ 11
[    1.510120] PCI Interrupt Link [LNKD] enabled at IRQ 10
[    1.539737] PCI Interrupt Link [LNKA] enabled at IRQ 10
[    1.569364] PCI Interrupt Link [LNKB] enabled at IRQ 11
[    1.618251] virtio_blk virtio4: [vda] 143360 512-byte logical blocks (73.4 MB/70.0 MiB)
[    1.667705] random: fast init done
[    1.669014] random: crng init done
[    1.671153] FS-Cache: Loaded
[    1.677011] 9pnet: Installing 9P2000 support
[    1.679743] 9p: Installing v9fs 9p2000 file system support
[    1.681353] FS-Cache: Netfs '9p' registered for caching
In gnu/build/linux-boot.scm:
   516:13  2 (_)
    367:8  1 (mount-root-file-system "/dev/vda1" "ext4" # _)
In unknown file:
           0 (mount "/dev/vda1" "/real-root" "ext4" 1 #<undefined>)
In procedure mount: No such file or directory
[    1.727459] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
[    1.727459] 
[    1.728372] CPU: 0 PID: 1 Comm: init Not tainted 4.18.16-gnu #1
[    1.728372] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org 04/01/2014
[    1.728372] Call Trace:
[    1.728372]  dump_stack+0x63/0x85
[    1.728372]  panic+0xe4/0x244
[    1.728372]  do_exit+0xb1a/0xb20
[    1.728372]  ? wake_up_state+0x10/0x20
[    1.728372]  do_group_exit+0x43/0xb0
[    1.728372]  __x64_sys_exit_group+0x18/0x20
[    1.728372]  do_syscall_64+0x5a/0x120
[    1.728372]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[    1.728372] RIP: 0033:0x5ecce6
[    1.728372] Code: Bad RIP value.
[    1.728372] RSP: 002b:00007ffcd54c8318 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
[    1.728372] RAX: ffffffffffffffda RBX: 0000000000812ff0 RCX: 00000000005ecce6
[    1.728372] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
[    1.728372] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffffb0
[    1.728372] R10: 00007f8613be5f88 R11: 0000000000000246 R12: 0000000000a63818
[    1.728372] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000003
[    1.728372] Kernel Offset: 0x27000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    1.728372] Rebooting in 1 seconds..
--8<---------------cut here---------------end--------------->8---

I took a closer look at my dmesg output.  I now notice that the
following line gets emitted when the error occurs moments before the
error occurs in the test:

[  909.759703] kvm [1279]: vcpu0, guest rIP: 0xffffffffb1068bec disabled perfctr wrmsr: 0xc2 data 0xffff

I'm not sure exactly what it means, or if it's bad.  Both the QEMU and
the dmesg output seem to mention a RIP value, and they both occur close
in time, so it seems suspicious.  Looking back in my /var/log/messages,
which I haven't rotated or truncated in quite some time, it seems there
are many entries like this.  The earliest such entry appears to be from
March 20th of 2017.  I don't know if I ran the system tests successfully
after that point in time on this machine.

ludo@gnu.org (Ludovic Courtès) writes:

> Did it work before on this machine?  I have a vague recollection that
> there were KVM issues on the X200.  This is x86_64?

This is x86_64, and the test did pass in the past (but I'm not sure when
I was last able to do so successfully).

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]