Bug#918036: linux: uptime after reboot wrong (kvm-clock related?)
I'm also seeing this issue, also on a Debian Linux 4.19 kernel (on updated Debian unstable VM), also on KVM, straight after rebooting the VM. But without any suspending involved, I just reboot the VM, and as soon as I can log in after rebooting its showing 6+ days of uptime. The uptime jumps *very* early in the boot sequence, at the point that kvm-clock starts reporting, by many days in my case. Of note, the KVM host here is pretty old (Ubuntu 14.04 LTS, on 3.13.0-164-generic kernel, and qemu-kvm 2.0.0+dfsg-2ubuntu1.44). It's also naturally a fairly old CPU (Intel Xeon X3450). So I wonder if part of the trigger is newer (4.19) kernels relying on CPU/hypervisor features that older CPUs / older hypervisors do not provide/initialise. And maybe reading an uninitialised value as a result. From reading the upstream thread, this seems the closest to diagnosis: https://lore.kernel.org/lkml/20190126020410.gb3...@feynman.vault24.org/ around guest clock sources being chosen, and apparently the upstream maintainer has managed to reproduce the issue: https://lore.kernel.org/lkml/20190126161137.gme4vsrz3xmnc...@soleen.tm1wkky2jk1uhgkn0ivaxijq1c.bx.internal.cloudapp.net/ by changing the clock source (to HPET), as of late Jan 2019. Ewen -=- cut here -=- ewen@debian-unstable:~$ uptime 11:21:06 up 6 days, 22:40, 1 user, load average: 0.88, 0.75, 0.52 ewen@debian-unstable:~$ last | head -5 ewen pts/0172.20.254.10Mon Feb 11 11:10 still logged in reboot system boot 4.19.0-2-amd64 Mon Feb 11 11:07 still running ewen ttyS0 Mon Feb 11 11:06 - down (00:00) ewen pts/0172.20.254.10Mon Feb 11 11:06 - down (00:00) reboot system boot 4.19.0-2-amd64 Mon Feb 11 11:05 - 11:06 (00:01) ewen@debian-unstable:~$ date Mon Feb 11 11:21:21 NZDT 2019 ewen@debian-unstable:~$ ewen@debian-unstable:~$ uname -r 4.19.0-2-amd64 ewen@debian-unstable:~$ dpkg -l | grep linux-image ii linux-image-4.19.0-1-amd64 4.19.13-1 amd64Linux 4.19 for 64-bit PCs (signed) ii linux-image-4.19.0-2-amd64 4.19.16-1 amd64Linux 4.19 for 64-bit PCs (signed) ii linux-image-amd644.19+102 amd64Linux for 64-bit PCs (meta-package) ewen@debian-unstable:~$ ewen@debian-unstable:~$ sudo dmesg | grep -A 4 "Hypervisor" [0.00] Hypervisor detected: KVM [0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00 [599207.077513] kvm-clock: cpu 0, msr 117d7001, primary cpu clock [599207.077513] clocksource: kvm-clock: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [599207.077516] tsc: Detected 2659.982 MHz processor ewen@debian-unstable:~$ ewen@debian-unstable:~$ sudo dmesg | head -20 | grep -v BIOS-e820 [0.00] Linux version 4.19.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-14)) #1 SMP Debian 4.19.16-1 (2019-01-17) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-2-amd64 root=UUID=260df8b9-6a61-4f0e-9625-340dcdaf4017 ro console=ttyS0,9600 [0.00] x86/fpu: x87 FPU will use FXSAVE [0.00] BIOS-provided physical RAM map: [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.4 present. [0.00] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [0.00] Hypervisor detected: KVM [0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00 [599207.077513] kvm-clock: cpu 0, msr 117d7001, primary cpu clock [599207.077513] clocksource: kvm-clock: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [599207.077516] tsc: Detected 2659.982 MHz processor [599207.078351] e820: update [mem 0x-0x0fff] usable ==> reserved ewen@debian-unstable:~$ -=- cut here -=- -=- cut here -=- ewen@naosdell:~$ head -5 /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 30 model name : Intel(R) Xeon(R) CPU X3450 @ 2.67GHz ewen@naosdell:~$ -=- cut here -=-
Bug#918036: [PATCH v15 23/26] sched: early boot clock (was Re: Bug#918036: linux: uptime after reboot wrong (kvm-clock related?))
Hi Salvatore, >p.s.: my earlier reply to you seem to have been rejected and never > reached you, hope this one does now. if you sent from Googlemail, it may reach me in the next weeks or never *shrug* they don’t play nice with greylisting. The -submitter or @d.o works, though. I’m following up from my $dayjob address as the issue occurred there (which is also Googlemail, unfortunately). >There was now a followup on this, and if you can I think it's best if >you can followup there. > >https://lore.kernel.org/lkml/ca+ck2bc70pnl0wimb0xt99j4nnfi8w3zuuhgak-jspuop9j...@mail.gmail.com/ OK, doing now: Pavel Tatashin wrote: >Could you please send the config file and qemu arguments that were >used to reproduce this problem. This is from a libvirt-managed system. The arguments as shown by “ps axwww” are: qemu-system-x86_64 -enable-kvm -name ci-busyapps -S -machine pc-1.1,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 09536d92-dd73-8993-78fb-e0c885acf763 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/ci-busyapps.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/dev/vms/ci-busyapps,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:05:6e:fd,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on I’ve attached the kernel configuration; this is a stock Debian unstable/amd64 system, just upgraded. After upgrading the guest, I merely issued a “reboot” in the guest and did not stop/start qemu. The host is Debian jessie/amd64 (Linux 3.16.0-7-amd64 / 3.16.59-1) in case that matters. Thanks, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#918036: linux: uptime after reboot wrong (kvm-clock related?)
Hi Thorsten, On Wed, Jan 02, 2019 at 05:39:39PM +0100, Salvatore Bonaccorso wrote: > Hi Thorsten, > > On Wed, Jan 02, 2019 at 04:08:23PM +, Thorsten Glaser wrote: > > Package: src:linux > > Version: 4.19.13-1 > > Severity: normal > > > > I???ve just rebooted this VM and get: > > > > root@ci-busyapps:~ # uptime > > 16:06:57 up 58 days, 21:22, 1 user, load average: 0.62, 0.98, 0.46 > > > > In syslog, I see this: > > > > Jan 2 15:55:01 ci-busyapps CRON[3287]: (root) CMD (command -v debian-sa1 > > > /dev/null && debian-sa1 1 1) > > Jan 2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max connection > > rate 1/60s for (smtp:172.26.1.40) at Jan 2 15:52:51 > > Jan 2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max connection > > count 1 for (smtp:172.26.1.40) at Jan 2 15:52:51 > > Jan 2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max cache size > > 1 at Jan 2 15:52:51 > > Jan 2 15:57:20 ci-busyapps sensord: sensord stopped > > Jan 2 15:58:05 ci-busyapps dhclient[1031]: DHCPREQUEST of 172.26.1.40 on > > eth0 to 172.26.100.2 port 67 > > Jan 2 15:58:05 ci-busyapps dhclient[1031]: DHCPACK of 172.26.1.40 from > > 172.26.100.2 > > Jan 2 15:58:05 ci-busyapps dhclient[1031]: bound to 172.26.1.40 -- renewal > > in 19447 seconds. > > Jan 2 15:59:04 ci-busyapps shutdown[7314]: shutting down for system reboot > > Jan 2 15:59:05 ci-busyapps init: Switching to runlevel: 6 > > Jan 2 15:59:09 ci-busyapps jenkins: jenkins: client (pid 1579) exited with > > 143 status > > Jan 2 15:59:10 ci-busyapps ntpd[1608]: ntp engine exiting > > Jan 2 15:59:10 ci-busyapps ntpd[1607]: Terminating > > Jan 2 15:59:10 ci-busyapps postfix/master[22032]: terminating on signal 15 > > Jan 2 15:59:18 ci-busyapps syslogd: exiting on signal 15 > > Jan 2 16:00:47 ci-busyapps syslogd (GNU inetutils 1.9.4): restart > > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] Linux version > > 4.19.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian > > 8.2.0-13)) #1 SMP Debian 4.19.13-1 (2018-12-30) > > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] Command line: > > BOOT_IMAGE=/boot/vmlinuz-4.19.0-1-amd64 > > root=/dev/mapper/vg--ci--busyapps-lv--root ro net.ifnames=0 kaslr nomodeset > > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] x86/fpu: x87 FPU will > > use FXSAVE > > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-provided physical > > RAM map: > > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem > > 0x-0x0009fbff] usable > > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem > > 0x0009fc00-0x0009] reserved > > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem > > 0x000f-0x000f] reserved > > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem > > 0x0010-0xdfffdfff] usable > > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem > > 0xdfffe000-0xdfff] reserved > > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem > > 0xfeffc000-0xfeff] reserved > > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem > > 0xfffc-0x] reserved > > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem > > 0x0001-0x00021fff] usable > > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] NX (Execute Disable) > > protection: active > > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] SMBIOS 2.4 present. > > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] DMI: Bochs Bochs, BIOS > > Bochs 01/01/2011 > > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] Hypervisor detected: KVM > > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] kvm-clock: Using msrs > > 4b564d01 and 4b564d00 > > Jan 2 16:00:47 ci-busyapps vmunix: [5087690.332663] kvm-clock: cpu 0, msr > > 3ffd7001, primary cpu clock > > Jan 2 16:00:47 ci-busyapps vmunix: [5087690.332663] clocksource: > > kvm-clock: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: > > 881590591483 ns > > Jan 2 16:00:47 ci-busyapps vmunix: [5087690.332665] tsc: Detected 3064.488 > > MHz processor > > As a datapoint: This sounds familiar in the sense that it was reported > earlier https://lore.kernel.org/lkml/20181106054212.GA31768@nautica/ . There was now a followup on this, and if you can I think it's best if you can followup there. https://lore.kernel.org/lkml/ca+ck2bc70pnl0wimb0xt99j4nnfi8w3zuuhgak-jspuop9j...@mail.gmail.com/ Regards, Salvatore p.s.: my earlier reply to you seem to have been rejected and never reached you, hope this one does now.
Bug#918036: linux: uptime after reboot wrong (kvm-clock related?)
Hi Thorsten, On Wed, Jan 02, 2019 at 04:08:23PM +, Thorsten Glaser wrote: > Package: src:linux > Version: 4.19.13-1 > Severity: normal > > I’ve just rebooted this VM and get: > > root@ci-busyapps:~ # uptime > 16:06:57 up 58 days, 21:22, 1 user, load average: 0.62, 0.98, 0.46 > > In syslog, I see this: > > Jan 2 15:55:01 ci-busyapps CRON[3287]: (root) CMD (command -v debian-sa1 > > /dev/null && debian-sa1 1 1) > Jan 2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max connection > rate 1/60s for (smtp:172.26.1.40) at Jan 2 15:52:51 > Jan 2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max connection > count 1 for (smtp:172.26.1.40) at Jan 2 15:52:51 > Jan 2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max cache size 1 > at Jan 2 15:52:51 > Jan 2 15:57:20 ci-busyapps sensord: sensord stopped > Jan 2 15:58:05 ci-busyapps dhclient[1031]: DHCPREQUEST of 172.26.1.40 on > eth0 to 172.26.100.2 port 67 > Jan 2 15:58:05 ci-busyapps dhclient[1031]: DHCPACK of 172.26.1.40 from > 172.26.100.2 > Jan 2 15:58:05 ci-busyapps dhclient[1031]: bound to 172.26.1.40 -- renewal > in 19447 seconds. > Jan 2 15:59:04 ci-busyapps shutdown[7314]: shutting down for system reboot > Jan 2 15:59:05 ci-busyapps init: Switching to runlevel: 6 > Jan 2 15:59:09 ci-busyapps jenkins: jenkins: client (pid 1579) exited with > 143 status > Jan 2 15:59:10 ci-busyapps ntpd[1608]: ntp engine exiting > Jan 2 15:59:10 ci-busyapps ntpd[1607]: Terminating > Jan 2 15:59:10 ci-busyapps postfix/master[22032]: terminating on signal 15 > Jan 2 15:59:18 ci-busyapps syslogd: exiting on signal 15 > Jan 2 16:00:47 ci-busyapps syslogd (GNU inetutils 1.9.4): restart > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] Linux version > 4.19.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian > 8.2.0-13)) #1 SMP Debian 4.19.13-1 (2018-12-30) > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] Command line: > BOOT_IMAGE=/boot/vmlinuz-4.19.0-1-amd64 > root=/dev/mapper/vg--ci--busyapps-lv--root ro net.ifnames=0 kaslr nomodeset > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] x86/fpu: x87 FPU will use > FXSAVE > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-provided physical RAM > map: > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem > 0x-0x0009fbff] usable > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem > 0x0009fc00-0x0009] reserved > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem > 0x000f-0x000f] reserved > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem > 0x0010-0xdfffdfff] usable > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem > 0xdfffe000-0xdfff] reserved > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem > 0xfeffc000-0xfeff] reserved > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem > 0xfffc-0x] reserved > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem > 0x0001-0x00021fff] usable > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] NX (Execute Disable) > protection: active > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] SMBIOS 2.4 present. > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] DMI: Bochs Bochs, BIOS > Bochs 01/01/2011 > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] Hypervisor detected: KVM > Jan 2 16:00:47 ci-busyapps vmunix: [0.00] kvm-clock: Using msrs > 4b564d01 and 4b564d00 > Jan 2 16:00:47 ci-busyapps vmunix: [5087690.332663] kvm-clock: cpu 0, msr > 3ffd7001, primary cpu clock > Jan 2 16:00:47 ci-busyapps vmunix: [5087690.332663] clocksource: kvm-clock: > mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 > ns > Jan 2 16:00:47 ci-busyapps vmunix: [5087690.332665] tsc: Detected 3064.488 > MHz processor As a datapoint: This sounds familiar in the sense that it was reported earlier https://lore.kernel.org/lkml/20181106054212.GA31768@nautica/ . Regards, Salvatore
Bug#918036: linux: uptime after reboot wrong (kvm-clock related?)
Package: src:linux Version: 4.19.13-1 Severity: normal I’ve just rebooted this VM and get: root@ci-busyapps:~ # uptime 16:06:57 up 58 days, 21:22, 1 user, load average: 0.62, 0.98, 0.46 In syslog, I see this: Jan 2 15:55:01 ci-busyapps CRON[3287]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Jan 2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max connection rate 1/60s for (smtp:172.26.1.40) at Jan 2 15:52:51 Jan 2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max connection count 1 for (smtp:172.26.1.40) at Jan 2 15:52:51 Jan 2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max cache size 1 at Jan 2 15:52:51 Jan 2 15:57:20 ci-busyapps sensord: sensord stopped Jan 2 15:58:05 ci-busyapps dhclient[1031]: DHCPREQUEST of 172.26.1.40 on eth0 to 172.26.100.2 port 67 Jan 2 15:58:05 ci-busyapps dhclient[1031]: DHCPACK of 172.26.1.40 from 172.26.100.2 Jan 2 15:58:05 ci-busyapps dhclient[1031]: bound to 172.26.1.40 -- renewal in 19447 seconds. Jan 2 15:59:04 ci-busyapps shutdown[7314]: shutting down for system reboot Jan 2 15:59:05 ci-busyapps init: Switching to runlevel: 6 Jan 2 15:59:09 ci-busyapps jenkins: jenkins: client (pid 1579) exited with 143 status Jan 2 15:59:10 ci-busyapps ntpd[1608]: ntp engine exiting Jan 2 15:59:10 ci-busyapps ntpd[1607]: Terminating Jan 2 15:59:10 ci-busyapps postfix/master[22032]: terminating on signal 15 Jan 2 15:59:18 ci-busyapps syslogd: exiting on signal 15 Jan 2 16:00:47 ci-busyapps syslogd (GNU inetutils 1.9.4): restart Jan 2 16:00:47 ci-busyapps vmunix: [0.00] Linux version 4.19.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-13)) #1 SMP Debian 4.19.13-1 (2018-12-30) Jan 2 16:00:47 ci-busyapps vmunix: [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-1-amd64 root=/dev/mapper/vg--ci--busyapps-lv--root ro net.ifnames=0 kaslr nomodeset Jan 2 16:00:47 ci-busyapps vmunix: [0.00] x86/fpu: x87 FPU will use FXSAVE Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-provided physical RAM map: Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 0x0010-0xdfffdfff] usable Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 0xdfffe000-0xdfff] reserved Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 0xfffc-0x] reserved Jan 2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 0x0001-0x00021fff] usable Jan 2 16:00:47 ci-busyapps vmunix: [0.00] NX (Execute Disable) protection: active Jan 2 16:00:47 ci-busyapps vmunix: [0.00] SMBIOS 2.4 present. Jan 2 16:00:47 ci-busyapps vmunix: [0.00] DMI: Bochs Bochs, BIOS Bochs 01/01/2011 Jan 2 16:00:47 ci-busyapps vmunix: [0.00] Hypervisor detected: KVM Jan 2 16:00:47 ci-busyapps vmunix: [0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00 Jan 2 16:00:47 ci-busyapps vmunix: [5087690.332663] kvm-clock: cpu 0, msr 3ffd7001, primary cpu clock Jan 2 16:00:47 ci-busyapps vmunix: [5087690.332663] clocksource: kvm-clock: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns Jan 2 16:00:47 ci-busyapps vmunix: [5087690.332665] tsc: Detected 3064.488 MHz processor Jan 2 16:00:47 ci-busyapps vmunix: [5087690.334831] e820: update [mem 0x-0x0fff] usable ==> reserved Jan 2 16:00:47 ci-busyapps vmunix: [5087690.334833] e820: remove [mem 0x000a-0x000f] usable Jan 2 16:00:47 ci-busyapps vmunix: [5087690.334837] last_pfn = 0x22 max_arch_pfn = 0x4 Jan 2 16:00:47 ci-busyapps vmunix: [5087690.334862] MTRR default type: write-back Jan 2 16:00:47 ci-busyapps vmunix: [5087690.334863] MTRR fixed ranges enabled: Jan 2 16:00:47 ci-busyapps vmunix: [5087690.334864] 0-9 write-back Jan 2 16:00:47 ci-busyapps vmunix: [5087690.334865] A-B uncachable Jan 2 16:00:47 ci-busyapps vmunix: [5087690.334866] C-F write-protect Jan 2 16:00:47 ci-busyapps vmunix: [5087690.334866] MTRR variable ranges enabled: Jan 2 16:00:47 ci-busyapps vmunix: [5087690.334867] 0 base 00E000 mask FFE000 uncachable Jan 2 16:00:47 ci-busyapps vmunix: [5087690.334868] 1 disabled Jan 2 16:00:47 ci-busyapps vmunix: [5087690.334868] 2 disabled Jan 2 16:00:47 ci-busyapps vmunix: [5087690.334869] 3 disabled Jan 2 16:00:47 ci-busyapps vmunix: [5087690.334869] 4 disabled Jan 2 16:00:47 ci-busyapps
