Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #62935 > unrolled thread

Bug#918036: linux: uptime after reboot wrong (kvm-clock related?)

Started bySalvatore Bonaccorso <carnil@debian.org>
First post2019-01-02 17:50 +0100
Last post2019-01-04 08:50 +0100
Articles 3 — 2 participants

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#918036: linux: uptime after reboot wrong (kvm-clock related?) Salvatore Bonaccorso <carnil@debian.org> - 2019-01-02 17:50 +0100
    Bug#918036: linux: uptime after reboot wrong (kvm-clock related?) Salvatore Bonaccorso <carnil@debian.org> - 2019-01-04 06:40 +0100
      Bug#918036: [PATCH v15 23/26] sched: early boot clock (was Re: Bug#918036: linux: uptime after reboot wrong (kvm-clock related?)) Thorsten Glaser <t.glaser@tarent.de> - 2019-01-04 08:50 +0100

#62935 — Bug#918036: linux: uptime after reboot wrong (kvm-clock related?)

FromSalvatore Bonaccorso <carnil@debian.org>
Date2019-01-02 17:50 +0100
SubjectBug#918036: linux: uptime after reboot wrong (kvm-clock related?)
Message-ID<xbRSq-BP-9@gated-at.bofh.it>
Hi Thorsten,

On Wed, Jan 02, 2019 at 04:08:23PM +0000, 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.000000] Linux version 4.19.0-1-amd64 (debian-kernel@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.000000] 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.000000] x86/fpu: x87 FPU will use FXSAVE
> Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-provided physical RAM map:
> Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
> Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
> Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
> Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000dfffdfff] usable
> Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-e820: [mem 0x00000000dfffe000-0x00000000dfffffff] reserved
> Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
> Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
> Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000021fffffff] usable
> Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] NX (Execute Disable) protection: active
> Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] SMBIOS 2.4 present.
> Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] DMI: Bochs Bochs, BIOS Bochs 01/01/2011
> Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] Hypervisor detected: KVM
> Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] 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: 0xffffffffffffffff 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

[toc] | [next] | [standalone]

#62970

FromSalvatore Bonaccorso <carnil@debian.org>
Date2019-01-04 06:40 +0100
Message-ID<xcqn7-4NK-3@gated-at.bofh.it>
In reply to#62935
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 +0000, 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.000000] Linux version 4.19.0-1-amd64 (debian-kernel@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.000000] 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.000000] x86/fpu: x87 FPU will use FXSAVE
> > Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-provided physical RAM map:
> > Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
> > Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
> > Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
> > Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000dfffdfff] usable
> > Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-e820: [mem 0x00000000dfffe000-0x00000000dfffffff] reserved
> > Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
> > Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
> > Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000021fffffff] usable
> > Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] NX (Execute Disable) protection: active
> > Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] SMBIOS 2.4 present.
> > Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] DMI: Bochs Bochs, BIOS Bochs 01/01/2011
> > Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] Hypervisor detected: KVM
> > Jan  2 16:00:47 ci-busyapps vmunix: [    0.000000] 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: 0xffffffffffffffff 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-jsPuOP9jpHA@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.

[toc] | [prev] | [next] | [standalone]

#62973 — Bug#918036: [PATCH v15 23/26] sched: early boot clock (was Re: Bug#918036: linux: uptime after reboot wrong (kvm-clock related?))

FromThorsten Glaser <t.glaser@tarent.de>
Date2019-01-04 08:50 +0100
SubjectBug#918036: [PATCH v15 23/26] sched: early boot clock (was Re: Bug#918036: linux: uptime after reboot wrong (kvm-clock related?))
Message-ID<xcsoV-5Xl-5@gated-at.bofh.it>
In reply to#62970
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-jsPuOP9jpHA@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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web