summary refs log tree commit diff stats
path: root/results/classifier/accel-gemma3:12b/kvm/2184
blob: 8c8043b0fbc8f876f07e823667a20bb84a113409 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
NVMe differences between QEMU v4.1.0 and v8.2.1
Description of problem:
We are currently upgrading QEMU from v4.1.0 to v8.2.1. In order to keep compatibility between the two QEMUs, we are adding ``-machine pc-q35-4.1``. One of our test is to ensure a guest that has hibernated on the previous QEMU is able to resume on the new one.

When resuming, we get the following error:

```
[    7.394709] nvme nvme0: Device not ready; aborting reset, CSTS=0x1
[    7.926188] nvme nvme0: Device not ready; aborting reset, CSTS=0x1
[    7.938235] Read-error on swap-device (259:0:4874880)
[    7.938237] Read-error on swap-device (259:0:4620184)
[    7.938240] Read-error on swap-device (259:0:5536464)
[    7.938311] Read-error on swap-device (259:0:5006840)
[    7.938316] Read-error on swap-device (259:0:5791888)
[    7.938386] Read-error on swap-device (259:0:6579728)
[    7.938391] Read-error on swap-device (259:0:5536680)
[    7.938431] Read-error on swap-device (259:0:4877384)
[    7.938434] Read-error on swap-device (259:0:5005376)
[    7.938457] Read-error on swap-device (259:0:5269328)
[    7.939200] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0
[    7.939267] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0
[    7.946359] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0
[    8.063186] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0
[    8.069556] Aborting journal on device nvme0n1p1-8.
[    8.069561] Buffer I/O error on dev nvme0n1p1, logical block 262144, lost sync page write
[    8.069564] JBD2: Error -5 detected when updating journal superblock for nvme0n1p1-8.
[    8.081218] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0
[    8.081242] Buffer I/O error on dev nvme0n1p1, logical block 0, lost sync page write
[    8.081247] EXT4-fs (nvme0n1p1): I/O error while writing superblock
[    8.147693] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0
[    8.147753] Buffer I/O error on dev nvme0n1p1, logical block 0, lost sync page write
[    8.163478] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0
[    8.174179] EXT4-fs (nvme0n1p1): I/O error while writing superblock
[    8.198741] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:2: reading directory lblock 0
[    8.214483] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0
[    8.230322] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:2: reading directory lblock 0
[    8.246249] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    8.246269] Core dump to |/usr/share/apport/apport pipe failed
[    8.246291] Core dump to |/usr/share/apport/apport pipe failed
[    8.246336] Core dump to |/usr/share/apport/apport pipe failed
[    8.246826] Core dump to |/usr/share/apport/apport pipe failed
[    8.249232] Core dump to |/usr/share/apport/apport pipe failed
[    8.249320] Core dump to |/usr/share/apport/apport pipe failed
[    8.249880] Core dump to |/usr/share/apport/apport pipe failed
```

Digging throw the NVMe code, I have found one [patch](https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg04202.html) changing the BAR layout. It doesn't look like there is a way to select the previous BAR layout.

When selecting the ``-machine``, I was expecting that the underlying HW (including devices) would not change. Can you clarify if hibernating from QEMU A and resuming to QEMU B is meant to be supported?
Steps to reproduce:
1. Start the guest with qemu v4.1.0 and an NVME disk
2. Hibernate the OS
3. Resume the guest with qemu v8.2.1