Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #59754 > unrolled thread
| Started by | Marc Haber <mh+debian-bugs@zugschlus.de> |
|---|---|
| First post | 2017-12-25 14:20 +0100 |
| Last post | 2018-02-23 09:20 +0100 |
| Articles | 12 — 4 participants |
Back to article view | Back to linux.debian.kernel
Bug#885166: instability with 4.14 regarding KVM virtualization Marc Haber <mh+debian-bugs@zugschlus.de> - 2017-12-25 14:20 +0100
Bug#885166: instability with 4.14 regarding KVM virtualization Ben Hutchings <ben@decadent.org.uk> - 2017-12-25 23:10 +0100
Bug#885166: instability with 4.14 regarding KVM virtualization Marc Haber <mh+debian-bugs@zugschlus.de> - 2017-12-27 12:30 +0100
Bug#885166: instability with 4.14 regarding KVM virtualization Jonathan Nieder <jrnieder@gmail.com> - 2017-12-27 18:40 +0100
Bug#885166: instability with 4.14 regarding KVM virtualization Ben Hutchings <ben@decadent.org.uk> - 2017-12-27 20:50 +0100
Bug#885166: instability with 4.14 regarding KVM virtualization Marc Haber <mh+debian-bugs@zugschlus.de> - 2018-01-08 10:00 +0100
Bug#885166: instability with 4.14 regarding KVM virtualization Marc Haber <mh+debian-bugs@zugschlus.de> - 2018-02-11 14:50 +0100
Bug#885166: instability with 4.14 regarding KVM virtualization Salvatore Bonaccorso <carnil@debian.org> - 2018-02-18 10:20 +0100
Bug#885166: instability with 4.14 regarding KVM virtualization Marc Haber <mh+debian-bugs@zugschlus.de> - 2018-02-18 11:40 +0100
Bug#885166: instability with 4.14 regarding KVM virtualization Salvatore Bonaccorso <carnil@debian.org> - 2018-02-19 06:40 +0100
Bug#885166: instability with 4.14 regarding KVM virtualization Marc Haber <mh+debian-bugs@zugschlus.de> - 2018-02-21 16:10 +0100
Bug#885166: instability with 4.14 regarding KVM virtualization Marc Haber <mh+debian-bugs@zugschlus.de> - 2018-02-23 09:20 +0100
| From | Marc Haber <mh+debian-bugs@zugschlus.de> |
|---|---|
| Date | 2017-12-25 14:20 +0100 |
| Subject | Bug#885166: instability with 4.14 regarding KVM virtualization |
| Message-ID | <v0APD-4bT-1@gated-at.bofh.it> |
Package: src:linux
Version: 4.14.2-1
Severity: normal
Tags: upstream
Hi,
starting with kernel 4.14, the majority of mv KVM virtualization hosts
has become unstable. This behavior has been present in every 4.14
kernel, regardless of self-compiled or the Debian kernel. I am reporting
this in Debian in hope that I can get more input here than I got on the
linux-kernel mailing list.
The issue happens on various Debian stable hosts (didn't try unstable
yet) with AMD and Intel CPUs, including:
- Model name: AMD GX-412TC SOC
- Model name: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
- Model name: Quad-Core AMD Opteron(tm) Processor 1389
- Model name: Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
The symptoms appear more often when the system is under tight memory
conditions and/or KSM is enabled. Disabling KSM decreases the frequency
of the issue happening, but doesn't make it stop. Going back to a 4.13
kernel makes all machines rock-stable again. I also see this behavior in
4.15 release candidates kernels up to -rc4 (-rc5 test still pending).
Symptoms are (choose any combination).
- VMs hanging completely: no ping, no reaction on serial console
- VMs losing their storage: machine still pings, login not possible,
no "password" prompt after entering user name on serial console
- reliable and reproducible segfault of certain binaries in the VM
until the VM is restarted
- VM file systems being re-mounted r/o
- VM file systems being corrupted so that external fsck is necessary
- virsh shutdown not working for affected VM
- sometimes, even virsh destroy not working (hanging for minutes until
Ctrl-C, sometimes error message, unfortunately not written down)
- host not rebooting cleanly, needing hardware reset
I tried bisecting the kernel between 4.13 and 4.14, but the results are
inconclusive to me:
- 569dbb88e80deb68974ef6fdd6a13edb9d686261 is good
- ddf720f86efe38cb3ef88b2eaad9ea8ad7c6f798 is bad
- ddf720f86efe38cb3ef88b2eaad9ea8ad7c6f798 was the result of the kernel
bisect between 4.13 and 4.14, but is a one-character typo fix in a
comment.
- I am also confused that ddf720f86efe38cb3ef88b2eaad9ea8ad7c6f798 is in
4.13-rc7, therefore earlier than the "good" 4.13 relese
In the second try, I tried bisecting between those two commits. This
quickly results in:
The merge base cc4a41fe5541a73019a864883297bd5043aa6d98 is bad.
This means the bug has been fixed between
cc4a41fe5541a73019a864883297bd5043aa6d98 and
[569dbb88e80deb68974ef6fdd6a13edb9d686261].
569dbb88e80deb68974ef6fdd6a13edb9d686261 is Linux 4.13 and is good
cc4a41fe5541a73019a864883297bd5043aa6d98 is Linux 4.13-rc7 and is bad.
Bisecting between those ends up in:
[6/4993]mh@fan:~/linux/git/bisect/linux ((v4.13) *|BISECTING) $ git
bisect good
Some good revs are not ancestors of the bad rev.
git bisect cannot work properly in this case.
Maybe you mistook good and bad revs?
git [5/4992]mh@fan:~/linux/git/bisect/linux ((v4.13) *|BISECTING) $ git
bisect log
git bisect start
# bad: [cc4a41fe5541a73019a864883297bd5043aa6d98] Linux 4.13-rc7
git bisect bad cc4a41fe5541a73019a864883297bd5043aa6d98
What am I doing wrong here? Any idea what to do here?
Greetings
Marc
-- Package-specific info:
** Version:
Linux version 4.14.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 7.2.0 (Debian 7.2.0-16)) #1 SMP Debian 4.14.2-1 (2017-11-30)
** Command line:
BOOT_IMAGE=/vmlinuz-4.14.0-1-amd64 root=/dev/mapper/heel-root ro net.ifnames=1
** Not tainted
** Kernel log:
[ 10.160061] [drm] Driver supports precise vblank timestamp query.
[ 10.160422] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 10.169463] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input8
[ 10.196551] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[ 10.200499] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: discard
[ 10.235958] systemd-journald[467]: Received request to flush runtime journal from PID 1
[ 10.237138] [drm] Initialized i915 1.6.0 20170818 for 0000:00:02.0 on minor 0
[ 10.239282] 8021q: 802.1Q VLAN Support v1.8
[ 10.240463] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: discard
[ 10.249705] ACPI: Video Device [VID] (multi-head: yes rom: no post: no)
[ 10.252137] acpi device:00: registered as cooling_device5
[ 10.252233] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input9
[ 10.253318] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: discard
[ 10.265969] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 10.448215] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 10.492251] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready
[ 10.492477] IPv6: ADDRCONF(NETDEV_UP): int181: link is not ready
[ 10.492685] IPv6: ADDRCONF(NETDEV_UP): int182: link is not ready
[ 10.492885] IPv6: ADDRCONF(NETDEV_UP): int188: link is not ready
[ 10.493076] IPv6: ADDRCONF(NETDEV_UP): int189: link is not ready
[ 10.493284] IPv6: ADDRCONF(NETDEV_UP): int191: link is not ready
[ 10.493473] IPv6: ADDRCONF(NETDEV_UP): int192: link is not ready
[ 10.493663] IPv6: ADDRCONF(NETDEV_UP): int193: link is not ready
[ 10.493851] IPv6: ADDRCONF(NETDEV_UP): int198: link is not ready
[ 10.494051] IPv6: ADDRCONF(NETDEV_UP): int199: link is not ready
[ 10.603477] Adding 8388604k swap on /dev/mapper/heel-swap0. Priority:-2 extents:1 across:8388604k SSDscFS
[ 10.634874] snd_hda_codec_conexant hdaudioC0D0: CX20590: BIOS auto-probing.
[ 10.635351] snd_hda_codec_conexant hdaudioC0D0: autoconfig for CX20590: line_outs=1 (0x1f/0x0/0x0/0x0/0x0) type:speaker
[ 10.635356] snd_hda_codec_conexant hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[ 10.635359] snd_hda_codec_conexant hdaudioC0D0: hp_outs=2 (0x1c/0x19/0x0/0x0/0x0)
[ 10.635362] snd_hda_codec_conexant hdaudioC0D0: mono: mono_out=0x0
[ 10.635364] snd_hda_codec_conexant hdaudioC0D0: inputs:
[ 10.635367] snd_hda_codec_conexant hdaudioC0D0: Internal Mic=0x23
[ 10.635370] snd_hda_codec_conexant hdaudioC0D0: Mic=0x1b
[ 10.635374] snd_hda_codec_conexant hdaudioC0D0: Dock Mic=0x1a
[ 10.636905] iTCO_vendor_support: vendor-support=0
[ 10.637304] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[ 10.637352] iTCO_wdt: Found a Cougar Point TCO device (Version=2, TCOBASE=0x0460)
[ 10.637386] snd_hda_codec_conexant hdaudioC0D0: Enable sync_write for stable communication
[ 10.637470] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[ 10.656050] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10
[ 10.657054] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input11
[ 10.657130] input: HDA Intel PCH Dock Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input12
[ 10.657203] input: HDA Intel PCH Dock Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input13
[ 10.657272] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input14
[ 10.657342] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input15
[ 10.657707] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input16
[ 10.657775] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input17
[ 10.658210] fbcon: inteldrmfb (fb0) is primary device
[ 10.669387] br189: port 1(int189) entered blocking state
[ 10.669389] br189: port 1(int189) entered disabled state
[ 10.669493] device int189 entered promiscuous mode
[ 10.669494] device enp0s25 entered promiscuous mode
[ 10.670140] IPv6: ADDRCONF(NETDEV_UP): br199: link is not ready
[ 10.670722] IPv6: ADDRCONF(NETDEV_UP): br189: link is not ready
[ 10.675379] Process accounting resumed
[ 10.721245] EXT4-fs (dm-15): mounted filesystem with ordered data mode. Opts: (null)
[ 10.784908] br199: port 1(int199) entered blocking state
[ 10.784909] br199: port 1(int199) entered disabled state
[ 10.784993] device int199 entered promiscuous mode
[ 11.832166] Console: switching to colour frame buffer device 240x67
[ 11.863051] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 13.402134] e1000e: enp0s25 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[ 13.405923] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s25: link becomes ready
[ 13.409960] IPv6: ADDRCONF(NETDEV_CHANGE): int181: link becomes ready
[ 13.411170] IPv6: ADDRCONF(NETDEV_CHANGE): int182: link becomes ready
[ 13.412547] IPv6: ADDRCONF(NETDEV_CHANGE): int188: link becomes ready
[ 13.413903] IPv6: ADDRCONF(NETDEV_CHANGE): int189: link becomes ready
[ 13.415056] br189: port 1(int189) entered blocking state
[ 13.416123] br189: port 1(int189) entered forwarding state
[ 13.417198] IPv6: ADDRCONF(NETDEV_CHANGE): int191: link becomes ready
[ 13.418536] IPv6: ADDRCONF(NETDEV_CHANGE): int192: link becomes ready
[ 13.420283] IPv6: ADDRCONF(NETDEV_CHANGE): int193: link becomes ready
[ 13.421942] IPv6: ADDRCONF(NETDEV_CHANGE): int198: link becomes ready
[ 13.423559] IPv6: ADDRCONF(NETDEV_CHANGE): int199: link becomes ready
[ 13.425176] br199: port 1(int199) entered blocking state
[ 13.426766] br199: port 1(int199) entered forwarding state
[ 13.428434] IPv6: ADDRCONF(NETDEV_CHANGE): br189: link becomes ready
[ 13.430128] IPv6: ADDRCONF(NETDEV_CHANGE): br199: link becomes ready
[ 13.449551] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 13.533077] Ebtables v2.0 registered
[ 14.650857] tun: Universal TUN/TAP device driver, 1.6
[ 14.814768] device-mapper: core: qemu-system-x86: sending ioctl 5326 to DM device without required privilege.
[ 15.117614] device-mapper: core: qemu-system-x86: sending ioctl 5326 to DM device without required privilege.
[ 15.346348] device-mapper: core: qemu-system-x86: sending ioctl 5326 to DM device without required privilege.
[ 15.536058] br199: port 2(vnet0) entered blocking state
[ 15.537210] br199: port 2(vnet0) entered disabled state
[ 15.538532] device vnet0 entered promiscuous mode
[ 15.573994] br199: port 2(vnet0) entered blocking state
[ 15.575842] br199: port 2(vnet0) entered forwarding state
[ 15.680043] br189: port 2(vnet1) entered blocking state
[ 15.681870] br189: port 2(vnet1) entered disabled state
[ 15.684089] device vnet1 entered promiscuous mode
[ 15.708440] br189: port 2(vnet1) entered blocking state
[ 15.710211] br189: port 2(vnet1) entered forwarding state
[ 15.776677] device-mapper: core: qemu-system-x86: sending ioctl 5326 to DM device without required privilege.
[ 16.370283] device-mapper: core: qemu-system-x86: sending ioctl 5326 to DM device without required privilege.
[ 16.820270] device-mapper: core: qemu-system-x86: sending ioctl 5326 to DM device without required privilege.
[ 17.412162] device-mapper: core: qemu-system-x86: sending ioctl 5326 to DM device without required privilege.
[ 17.414757] device-mapper: core: qemu-system-x86: sending ioctl 5326 to DM device without required privilege.
** Model information
sys_vendor: LENOVO
product_name: 4243F53
product_version: ThinkPad T520
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: 8AET65WW (1.45 )
board_vendor: LENOVO
board_name: 4243F53
board_version: Not Available
** Loaded modules:
vhost_net
tun
vhost
macvtap
macvlan
tap
ebtable_filter
ebtables
ip6table_filter
ip6_tables
iptable_filter
snd_hda_codec_hdmi
iTCO_wdt
iTCO_vendor_support
snd_hda_codec_conexant
snd_hda_codec_generic
wmi_bmof
nls_ascii
nls_cp437
vfat
fat
8021q
garp
mrp
bridge
stp
llc
intel_rapl
x86_pkg_temp_thermal
intel_powerclamp
coretemp
kvm_intel
snd_hda_intel
kvm
irqbypass
crct10dif_pclmul
efi_pstore
crc32_pclmul
i915
snd_hda_codec
ghash_clmulni_intel
snd_hda_core
intel_cstate
joydev
thinkpad_acpi
snd_hwdep
intel_uncore
evdev
snd_pcm
pl2303
intel_rapl_perf
nvram
snd_timer
drm_kms_helper
serio_raw
efivars
pcspkr
lpc_ich
usbserial
mfd_core
wmi
shpchp
snd
sg
drm
mei_me
soundcore
rfkill
i2c_algo_bit
mei
battery
ac
button
video
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
fscrypto
ecb
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid1
raid0
multipath
linear
md_mod
dm_mod
sd_mod
crc32c_intel
ahci
i2c_i801
libahci
sata_sil24
e1000e
aesni_intel
aes_x86_64
crypto_simd
psmouse
cryptd
glue_helper
ehci_pci
ptp
ehci_hcd
sdhci_pci
libata
sdhci
mmc_core
scsi_mod
usbcore
pps_core
usb_common
thermal
** Network interface configuration:
auto int181
iface int181 inet manual
vlan_raw_device enp1s0
auto int189
iface int189 inet manual
vlan_raw_device enp1s0
auto int199
iface int199 inet manual
vlan_raw_device enp1s0
auto int192
iface int192 inet manual
vlan_raw_device enp1s0
auto int182
iface int182 inet manual
vlan_raw_device enp1s0
auto int193
iface int193 inet manual
vlan_raw_device enp0s25
auto int188
iface int188 inet manual
vlan_raw_device enp0s25
** Network status:
*** IP interfaces and addresses:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether f0:de:f1:b9:12:fe brd ff:ff:ff:ff:ff:ff
inet6 fe80::f2de:f1ff:feb9:12fe/64 scope link
valid_lft forever preferred_lft forever
3: br199: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 0a:b7:1b:86:d0:21 brd ff:ff:ff:ff:ff:ff
inet6 fe80::8b7:1bff:fe86:d021/64 scope link
valid_lft forever preferred_lft forever
4: br189: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether d6:63:76:58:e4:b4 brd ff:ff:ff:ff:ff:ff
inet6 fe80::d463:76ff:fe58:e4b4/64 scope link
valid_lft forever preferred_lft forever
5: int191@enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether f0:de:f1:b9:12:fe brd ff:ff:ff:ff:ff:ff
inet 192.168.191.96/24 brd 192.168.191.255 scope global int191
valid_lft forever preferred_lft forever
inet6 2a01:238:4071:3291:f2de:f1ff:feb9:12fe/64 scope global deprecated mngtmpaddr noprefixroute dynamic
valid_lft 86345sec preferred_lft 0sec
inet6 2a01:238:4071:3291::60:100/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::f2de:f1ff:feb9:12fe/64 scope link
valid_lft forever preferred_lft forever
6: int199@enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br199 state UP group default qlen 1000
link/ether f0:de:f1:b9:12:fe brd ff:ff:ff:ff:ff:ff
inet6 fe80::f2de:f1ff:feb9:12fe/64 scope link
valid_lft forever preferred_lft forever
7: int198@enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether f0:de:f1:b9:12:fe brd ff:ff:ff:ff:ff:ff
inet6 fe80::f2de:f1ff:feb9:12fe/64 scope link
valid_lft forever preferred_lft forever
8: int182@enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether f0:de:f1:b9:12:fe brd ff:ff:ff:ff:ff:ff
inet6 fe80::f2de:f1ff:feb9:12fe/64 scope link
valid_lft forever preferred_lft forever
9: int189@enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br189 state UP group default qlen 1000
link/ether f0:de:f1:b9:12:fe brd ff:ff:ff:ff:ff:ff
inet6 fe80::f2de:f1ff:feb9:12fe/64 scope link
valid_lft forever preferred_lft forever
10: int193@enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether f0:de:f1:b9:12:fe brd ff:ff:ff:ff:ff:ff
inet6 fe80::f2de:f1ff:feb9:12fe/64 scope link
valid_lft forever preferred_lft forever
11: int192@enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether f0:de:f1:b9:12:fe brd ff:ff:ff:ff:ff:ff
inet6 fe80::f2de:f1ff:feb9:12fe/64 scope link
valid_lft forever preferred_lft forever
12: int181@enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether f0:de:f1:b9:12:fe brd ff:ff:ff:ff:ff:ff
inet6 fe80::f2de:f1ff:feb9:12fe/64 scope link
valid_lft forever preferred_lft forever
13: int188@enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether f0:de:f1:b9:12:fe brd ff:ff:ff:ff:ff:ff
inet6 fe80::f2de:f1ff:feb9:12fe/64 scope link
valid_lft forever preferred_lft forever
14: macvtap0@int181: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 500
link/ether 52:54:00:ba:00:d0 brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:feba:d0/64 scope link
valid_lft forever preferred_lft forever
15: macvtap1@int181: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 500
link/ether 52:54:00:fb:de:4d brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:fefb:de4d/64 scope link
valid_lft forever preferred_lft forever
16: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br199 state UNKNOWN group default qlen 1000
link/ether fe:54:00:25:ab:54 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fe25:ab54/64 scope link
valid_lft forever preferred_lft forever
17: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br189 state UNKNOWN group default qlen 1000
link/ether fe:54:00:e2:f2:cb brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fee2:f2cb/64 scope link
valid_lft forever preferred_lft forever
18: macvtap2@int181: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 500
link/ether 52:54:00:93:ff:c8 brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:fe93:ffc8/64 scope link
valid_lft forever preferred_lft forever
19: macvtap3@int181: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 500
link/ether 52:54:00:c5:8b:c0 brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:fec5:8bc0/64 scope link
valid_lft forever preferred_lft forever
20: macvtap4@int181: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 500
link/ether 52:54:00:b4:b8:00 brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:feb4:b800/64 scope link
valid_lft forever preferred_lft forever
21: macvtap5@int181: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 500
link/ether 52:54:00:71:2a:63 brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:fe71:2a63/64 scope link
valid_lft forever preferred_lft forever
*** Device statistics:
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
int199: 0 0 0 0 0 0 0 0 312317 7090 0 0 0 0 0 0
vnet1: 5943671 13178 0 0 0 0 0 0 9986199 38600 0 0 0 0 0 0
lo: 5694 63 0 0 0 0 0 0 5694 63 0 0 0 0 0 0
int182: 57755 208 0 0 0 0 0 206 898 10 0 0 0 0 0 0
macvtap2: 133724 734 0 0 0 0 0 501 111506 240 0 0 0 0 0 0
int189: 9442265 38574 0 0 0 0 0 189 5945467 13198 0 0 0 0 0 0
vnet0: 310349 7068 0 0 0 0 0 0 7394 67 0 0 0 0 0 0
enp0s25: 13376956 44595 0 0 0 0 0 1456 8529999 24732 0 0 0 0 0 0
int193: 53674 189 0 0 0 0 0 189 898 10 0 0 0 0 0 0
macvtap1: 611216 1185 0 0 0 0 0 507 911975 532 0 0 0 0 0 0
macvtap4: 132816 730 0 0 0 0 0 495 115570 233 0 0 0 0 0 0
int191: 1534500 1987 0 0 0 0 0 194 312907 1377 0 0 0 0 0 0
int198: 28009 95 0 0 0 0 0 95 898 10 0 0 0 0 0 0
macvtap5: 129604 704 0 0 0 0 0 467 122586 261 0 0 0 0 0 0
macvtap0: 100238 684 0 0 0 0 0 400 187663 382 0 0 0 0 0 0
br189: 55978 220 0 0 0 0 0 0 898 10 0 0 0 0 0 0
int181: 1120110 2444 0 0 0 0 0 174 1590948 2250 0 0 0 0 0 0
macvtap3: 585862 1078 0 0 0 0 0 501 140750 592 0 0 0 0 0 0
int188: 53650 189 0 0 0 0 0 189 898 10 0 0 0 0 0 0
br199: 211369 7067 0 0 0 0 0 0 3994 46 0 0 0 0 0 0
int192: 55789 206 0 0 0 0 0 206 898 10 0 0 0 0 0 0
*** Protocol statistics:
Ip:
Forwarding: 2
826 total packets received
11 with invalid addresses
0 forwarded
0 incoming packets discarded
203 incoming packets delivered
135 requests sent out
Icmp:
8 ICMP messages received
0 input ICMP message failed
ICMP input histogram:
destination unreachable: 8
8 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 8
IcmpMsg:
InType3: 8
OutType3: 8
Tcp:
10 active connection openings
2 passive connection openings
2 failed connection attempts
0 connection resets received
1 connections established
1601 segments received
1256 segments sent out
8 segments retransmitted
0 bad segments received
8 resets sent
Udp:
44 packets received
8 packets to unknown port received
0 packet receive errors
52 packets sent
0 receive buffer errors
0 send buffer errors
IgnoredMulti: 10
UdpLite:
TcpExt:
3 TCP sockets finished time wait in fast timer
6 delayed acks sent
670 packet headers predicted
172 acknowledgments not containing data payload received
612 predicted acknowledgments
TCPTimeouts: 3
TCPLossProbes: 1
4 connections reset due to unexpected data
TCPRcvCoalesce: 100
TCPOFOQueue: 3
TCPAutoCorking: 73
TCPSynRetrans: 8
TCPOrigDataSent: 860
TCPHystartTrainDetect: 1
TCPHystartTrainCwnd: 19
IpExt:
InMcastPkts: 24
OutMcastPkts: 5
InBcastPkts: 10
InOctets: 331319
OutOctets: 9032
InMcastOctets: 822
OutMcastOctets: 230
InBcastOctets: 3280
InNoECTPkts: 831
** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09)
Subsystem: Lenovo 2nd Generation Core Processor Family DRAM Controller [17aa:21cf]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0
Capabilities: <access denied>
00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 00 [VGA controller])
Subsystem: Lenovo 2nd Generation Core Processor Family Integrated Graphics Controller [17aa:21cf]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 29
Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 5000 [size=64]
[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: i915
Kernel modules: i915
00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)
Subsystem: Lenovo 6 Series/C200 Series Chipset Family MEI Controller [17aa:21cf]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 28
Region 0: Memory at f2425000 (64-bit, non-prefetchable) [size=16]
Capabilities: <access denied>
Kernel driver in use: mei_me
Kernel modules: mei_me
00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04)
Subsystem: Lenovo 82579LM Gigabit Network Connection [17aa:21ce]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 26
Region 0: Memory at f2400000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at f242b000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at 5080 [size=32]
Capabilities: <access denied>
Kernel driver in use: e1000e
Kernel modules: e1000e
00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 04) (prog-if 20 [EHCI])
Subsystem: Lenovo 6 Series/C200 Series Chipset Family USB Enhanced Host Controller [17aa:21cf]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 0: Memory at f242a000 (32-bit, non-prefetchable) [size=1K]
Capabilities: <access denied>
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci
00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller [8086:1c20] (rev 04)
Subsystem: Lenovo 6 Series/C200 Series Chipset Family High Definition Audio Controller [17aa:21cf]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 30
Region 0: Memory at f2420000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b4) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 16
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 00002000-00002fff
Memory behind bridge: dfa00000-dfbfffff
Prefetchable memory behind bridge: 00000000dfc00000-00000000dfdfffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.3 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 [8086:1c16] (rev b4) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin D routed to IRQ 19
Bus: primary=00, secondary=05, subordinate=0c, sec-latency=0
I/O behind bridge: 00004000-00004fff
Memory behind bridge: f1c00000-f23fffff
Prefetchable memory behind bridge: 00000000f0400000-00000000f0bfffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.4 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 [8086:1c18] (rev b4) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Bus: primary=00, secondary=0d, subordinate=0d, sec-latency=0
I/O behind bridge: 00003000-00003fff
Memory behind bridge: f1400000-f1bfffff
Prefetchable memory behind bridge: 00000000f0c00000-00000000f13fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1d.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 [8086:1c26] (rev 04) (prog-if 20 [EHCI])
Subsystem: Lenovo 6 Series/C200 Series Chipset Family USB Enhanced Host Controller [17aa:21cf]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 0: Memory at f2429000 (32-bit, non-prefetchable) [size=1K]
Capabilities: <access denied>
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci
00:1f.0 ISA bridge [0601]: Intel Corporation QM67 Express Chipset Family LPC Controller [8086:1c4f] (rev 04)
Subsystem: Levo QM67 Express Chipset Family LPC Controller [17aa:21cf]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Capabilities: <access denied>
Kernel driver in use: lpc_ich
Kernel modules: lpc_ich
00:1f.2 SATA controller [0106]: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller [8086:1c03] (rev 04) (prog-if 01 [AHCI 1.0])
Subsystem: Lenovo 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller [17aa:21cf]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 27
Region 0: I/O ports at 50a8 [size=8]
Region 1: I/O ports at 50bc [size=4]
Region 2: I/O ports at 50a0 [size=8]
Region 3: I/O ports at 50b8 [size=4]
Region 4: I/O ports at 5060 [size=32]
Region 5: Memory at f2428000 (32-bit, non-prefetchable) [size=2K]
Capabilities: <access denied>
Kernel driver in use: ahci
Kernel modules: ahci
00:1f.3 SMBus [0c05]: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller [8086:1c22] (rev 04)
Subsystem: Lenovo 6 Series/C200 Series Chipset Family SMBus Controller [17aa:21cf]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin C routed to IRQ 18
Region 0: Memory at f2424000 (64-bit, non-prefetchable) [size=256]
Region 4: I/O ports at efa0 [size=32]
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801
05:00.0 RAID bus controller [0104]: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller [1095:3132] (rev 01)
Subsystem: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller [1095:7132]
Physical Slot: 1
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at f1c04000 (64-bit, non-prefetchable) [size=128]
Region 2: Memory at f1c00000 (64-bit, non-prefetchable) [size=16K]
Region 4: I/O ports at 4000 [size=128]
Expansion ROM at f1c80000 [disabled] [size=512K]
Capabilities: <access denied>
Kernel driver in use: sata_sil24
Kernel modules: sata_sil24
0d:00.0 System peripheral [0880]: Ricoh Co Ltd MMC/SD Host Controller [1180:e822] (rev 08) (prog-if 01)
Subsystem: Lenovo MMC/SD Host Controller [17aa:21cf]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at f1400000 (32-bit, non-prefetchable) [size=256]
Capabilities: <access denied>
Kernel driver in use: sdhci-pci
Kernel modules: sdhci_pci
USB devices:
not available
-- System Information:
Debian Release: 9.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages linux-image-4.14.0-1-amd64 depends on:
ii initramfs-tools [linux-initramfs-tool] 0.130
ii kmod 23-2
ii linux-base 4.5
Versions of packages linux-image-4.14.0-1-amd64 recommends:
pn apparmor <none>
pn firmware-linux-free <none>
pn irqbalance <none>
Versions of packages linux-image-4.14.0-1-amd64 suggests:
pn debian-kernel-handbook <none>
ii grub-efi-amd64 2.02~beta3-5
pn linux-doc-4.14 <none>
Versions of packages linux-image-4.14.0-1-amd64 is related to:
pn firmware-amd-graphics <none>
pn firmware-atheros <none>
pn firmware-bnx2 <none>
pn firmware-bnx2x <none>
pn firmware-brcm80211 <none>
pn firmware-cavium <none>
pn firmware-intel-sound <none>
pn firmware-intelwimax <none>
pn firmware-ipw2x00 <none>
pn firmware-ivtv <none>
pn firmware-iwlwifi <none>
pn firmware-libertas <none>
pn firmware-linux-nonfree <none>
pn firmware-misc-nonfree <none>
pn firmware-myricom <none>
pn firmware-netxen <none>
pn firmware-qlogic <none>
pn firmware-realtek <none>
pn firmware-samsung <none>
pn firmware-siano <none>
pn firmware-ti-connectivity <none>
pn xen-hypervisor <none>
-- no debconf information
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
[toc] | [next] | [standalone]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2017-12-25 23:10 +0100 |
| Message-ID | <v0J6x-1pO-19@gated-at.bofh.it> |
| In reply to | #59754 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, 2017-12-25 at 14:15 +0100, Marc Haber wrote: [...] > I tried bisecting the kernel between 4.13 and 4.14, but the results are > inconclusive to me: > > - 569dbb88e80deb68974ef6fdd6a13edb9d686261 is good > - ddf720f86efe38cb3ef88b2eaad9ea8ad7c6f798 is bad > - ddf720f86efe38cb3ef88b2eaad9ea8ad7c6f798 was the result of the kernel > bisect between 4.13 and 4.14, but is a one-character typo fix in a > comment. > - I am also confused that ddf720f86efe38cb3ef88b2eaad9ea8ad7c6f798 is in > 4.13-rc7, therefore earlier than the "good" 4.13 relese [...] It's on a branch that started at 4.13-rc7 but wasn't merged into mainline until after 4.13. Comparing the two of them, 569dbb88e80d has the addition of commit fb1522e099f0 "KVM: update to new mmu_notifier semantic v2". So I would guess that what you landed on is a different bug than the one you were looking for. Given that commit fb1522e099f0 was merged after -rc7 I assume it's an important fix, though the commit message doesn't spell that out. So I think that whenever bisect asks you to test a version that doesn't contain it, you should cherry-pick it first to avoid the other bug. (I think you will then need to use 'git bisect good|bad HEAD^' after testing, rather than implicitly flagging the current head commit.) Ben. -- Ben Hutchings The world is coming to an end. Please log off.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+debian-bugs@zugschlus.de> |
|---|---|
| Date | 2017-12-27 12:30 +0100 |
| Message-ID | <v1i4i-Qd-5@gated-at.bofh.it> |
| In reply to | #59761 |
On Mon, Dec 25, 2017 at 10:02:48PM +0000, Ben Hutchings wrote: > It's on a branch that started at 4.13-rc7 but wasn't merged into > mainline until after 4.13. Comparing the two of them, 569dbb88e80d has > the addition of commit fb1522e099f0 "KVM: update to new mmu_notifier > semantic v2". So I would guess that what you landed on is a different > bug than the one you were looking for. Ouch. Two bugs with such similiar behavior in a single kernel release? > Given that commit fb1522e099f0 was merged after -rc7 I assume it's an > important fix, though the commit message doesn't spell that out. So I > think that whenever bisect asks you to test a version that doesn't > contain it, you should cherry-pick it first to avoid the other bug. (I > think you will then need to use 'git bisect good|bad HEAD^' after > testing, rather than implicitly flagging the current head commit.) Would git show fb1522e099f0 | patch -p1 build/test git reset --hard git bisect good|bad be the same thing? I would feel much more comfortable with that. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
[toc] | [prev] | [next] | [standalone]
| From | Jonathan Nieder <jrnieder@gmail.com> |
|---|---|
| Date | 2017-12-27 18:40 +0100 |
| Message-ID | <v1nQl-4Lw-5@gated-at.bofh.it> |
| In reply to | #59777 |
Marc Haber wrote: > On Mon, Dec 25, 2017 at 10:02:48PM +0000, Ben Hutchings wrote: >> Given that commit fb1522e099f0 was merged after -rc7 I assume it's an >> important fix, though the commit message doesn't spell that out. So I >> think that whenever bisect asks you to test a version that doesn't >> contain it, you should cherry-pick it first to avoid the other bug. (I >> think you will then need to use 'git bisect good|bad HEAD^' after >> testing, rather than implicitly flagging the current head commit.) > > Would > git show fb1522e099f0 | patch -p1 > build/test > git reset --hard > git bisect good|bad > be the same thing? I would feel much more comfortable with that. Yes. (The main advantage of 'git cherry-pick' over that is that it performs rename detection, but that shouldn't be relevant here. You can similarly do git cherry-pick --no-commit fb1522e099f0 build/test git reset --hard git bisect good|bad ) Thanks, Jonathan
[toc] | [prev] | [next] | [standalone]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2017-12-27 20:50 +0100 |
| Message-ID | <v1pSa-68n-7@gated-at.bofh.it> |
| In reply to | #59777 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, 2017-12-27 at 12:18 +0100, Marc Haber wrote: > On Mon, Dec 25, 2017 at 10:02:48PM +0000, Ben Hutchings wrote: > > It's on a branch that started at 4.13-rc7 but wasn't merged into > > mainline until after 4.13. Comparing the two of them, 569dbb88e80d has > > the addition of commit fb1522e099f0 "KVM: update to new mmu_notifier > > semantic v2". So I would guess that what you landed on is a different > > bug than the one you were looking for. > > Ouch. Two bugs with such similiar behavior in a single kernel release? > > > Given that commit fb1522e099f0 was merged after -rc7 I assume it's an > > important fix, though the commit message doesn't spell that out. So I > > think that whenever bisect asks you to test a version that doesn't > > contain it, you should cherry-pick it first to avoid the other bug. (I > > think you will then need to use 'git bisect good|bad HEAD^' after > > testing, rather than implicitly flagging the current head commit.) > > Would > git show fb1522e099f0 | patch -p1 > build/test > git reset --hard > git bisect good|bad > be the same thing? I would feel much more comfortable with that. Yes that should be equivalent. Ben. -- Ben Hutchings Any sufficiently advanced bug is indistinguishable from a feature.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+debian-bugs@zugschlus.de> |
|---|---|
| Date | 2018-01-08 10:00 +0100 |
| Message-ID | <v5BrH-3wY-1@gated-at.bofh.it> |
| In reply to | #59761 |
On Mon, Dec 25, 2017 at 10:02:48PM +0000, Ben Hutchings wrote:
> Given that commit fb1522e099f0 was merged after -rc7 I assume it's an
> important fix, though the commit message doesn't spell that out. So I
> think that whenever bisect asks you to test a version that doesn't
> contain it, you should cherry-pick it first to avoid the other bug.
After two more weeks, I can now confirm that cherry-picking fb1522e099f0
onto earlier 4.13-rc kernels makes things _WORSE_.
I believe that
- plain 4.13-rc4 works fine and allows stable usage of KVM
virtualization
- 4.13-rc4 with cherry-picked fb1522e099f0 is bad, causing random
segfaults and file-system corruption in VMs under disk and CPU load
- 4.13-rc5 is bad either way
I will start bisecting between 4.13-rc4 and 4.13-rc5, hoping that this
will yield better results. Since I have to wait between three to five
days to flag a kernel as "good" without too much doubt, and bisect
4.13-rc4..4.13-rc5 will take "roughly 7 steps".
I am open to additional suggestions.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+debian-bugs@zugschlus.de> |
|---|---|
| Date | 2018-02-11 14:50 +0100 |
| Message-ID | <vi0aZ-2PZ-7@gated-at.bofh.it> |
| In reply to | #59895 |
Hi, after in total nine weeks of bisecting, broken filesystems, service outages (thankfully on unportant systems), 4.15 seems to have fixed the issue. After going to 4.15, the crashes never happened again. They have, however, happened with each and every 4.14 release I tried, which I stopped doing with 4.14.15 on Jan 28. This means, for me, that the issue is fixed and that I have just wasted nine weeks of time. For Debian, this means that there is a crippling, data-eating issue in the current long-term releae kernel. I do sincerely hope that I never have to lay my eye on any 4.14 kernel again and hope that no major distribution will release with this version. Greetings Marc On Mon, Jan 08, 2018 at 09:53:14AM +0100, Marc Haber wrote: > On Mon, Dec 25, 2017 at 10:02:48PM +0000, Ben Hutchings wrote: > > Given that commit fb1522e099f0 was merged after -rc7 I assume it's an > > important fix, though the commit message doesn't spell that out. So I > > think that whenever bisect asks you to test a version that doesn't > > contain it, you should cherry-pick it first to avoid the other bug. > > After two more weeks, I can now confirm that cherry-picking fb1522e099f0 > onto earlier 4.13-rc kernels makes things _WORSE_. > > I believe that > - plain 4.13-rc4 works fine and allows stable usage of KVM > virtualization > - 4.13-rc4 with cherry-picked fb1522e099f0 is bad, causing random > segfaults and file-system corruption in VMs under disk and CPU load > - 4.13-rc5 is bad either way > > I will start bisecting between 4.13-rc4 and 4.13-rc5, hoping that this > will yield better results. Since I have to wait between three to five > days to flag a kernel as "good" without too much doubt, and bisect > 4.13-rc4..4.13-rc5 will take "roughly 7 steps". > > I am open to additional suggestions. > > Greetings > Marc > > > -- > ----------------------------------------------------------------------------- > Marc Haber | "I don't trust Computers. They | Mailadresse im Header > Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 > Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 > -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
[toc] | [prev] | [next] | [standalone]
| From | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| Date | 2018-02-18 10:20 +0100 |
| Message-ID | <vktix-319-5@gated-at.bofh.it> |
| In reply to | #60187 |
Source: linux Source-Version: 4.15~rc8-1~exp1 Hi Marc, On Sun, Feb 11, 2018 at 02:44:44PM +0100, Marc Haber wrote: > Hi, > > after in total nine weeks of bisecting, broken filesystems, service > outages (thankfully on unportant systems), 4.15 seems to have fixed the > issue. After going to 4.15, the crashes never happened again. > > They have, however, happened with each and every 4.14 release I tried, > which I stopped doing with 4.14.15 on Jan 28. > > This means, for me, that the issue is fixed and that I have just wasted > nine weeks of time. > > For Debian, this means that there is a crippling, data-eating issue in > the current long-term releae kernel. I do sincerely hope that I never > have to lay my eye on any 4.14 kernel again and hope that no major > distribution will release with this version. I'm sorry this was a frustrated triage, I can immagine. Looking today through the kernel archive, I noticed an answer from Paolo Bonzini, <62aa6b81-5456-07dc-cf64-e46747d3a70d@redhat.com>, claiming this is fixed by https://git.kernel.org/linus/2a266f23550be997d783f27e704b9b40c4010292 which is in 4.15-rc8, and thus confirming that you did not had the issue anymore in 4.15. Closing this bug with that version, but do you have a chance to confirm that? Regards, Salvatore
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+debian-bugs@zugschlus.de> |
|---|---|
| Date | 2018-02-18 11:40 +0100 |
| Message-ID | <vkuxY-3NF-5@gated-at.bofh.it> |
| In reply to | #60238 |
On Sun, Feb 18, 2018 at 10:15:43AM +0100, Salvatore Bonaccorso wrote: > Looking today through the kernel archive, I noticed an answer from > Paolo Bonzini, <62aa6b81-5456-07dc-cf64-e46747d3a70d@redhat.com>, > claiming this is fixed by > > https://git.kernel.org/linus/2a266f23550be997d783f27e704b9b40c4010292 > which is in 4.15-rc8, and thus confirming that you did not had the > issue anymore in 4.15. ... unfortunately with a totally unexplaining commit message though. > Closing this bug with that version, but do you have a chance to > confirm that? What exactly do you want me to test: - that the bug doesn't happen any more in Debian 4.15 kernels? - that ths bug still happens in Debian's 4.14 kernel and vanishes with the patch applied? - Something else? Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
[toc] | [prev] | [next] | [standalone]
| From | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| Date | 2018-02-19 06:40 +0100 |
| Message-ID | <vkMlb-74N-1@gated-at.bofh.it> |
| In reply to | #60241 |
Hi Marc, On Sun, Feb 18, 2018 at 11:34:21AM +0100, Marc Haber wrote: > On Sun, Feb 18, 2018 at 10:15:43AM +0100, Salvatore Bonaccorso wrote: > > Looking today through the kernel archive, I noticed an answer from > > Paolo Bonzini, <62aa6b81-5456-07dc-cf64-e46747d3a70d@redhat.com>, > > claiming this is fixed by > > > > https://git.kernel.org/linus/2a266f23550be997d783f27e704b9b40c4010292 > > which is in 4.15-rc8, and thus confirming that you did not had the > > issue anymore in 4.15. > > ... unfortunately with a totally unexplaining commit message though. > > > Closing this bug with that version, but do you have a chance to > > confirm that? > > What exactly do you want me to test: > > - that the bug doesn't happen any more in Debian 4.15 kernels? > - that ths bug still happens in Debian's 4.14 kernel and vanishes with > the patch applied? > - Something else? In an optimal case we get a confirmation that 2a266f23550be997d783f27e704b9b40c4010292 is the fixing commit for your issues. But given we have uploaded 4.15.4-1 to unstable, if you can confirm that this one defintively fix your issue that would be great (bonus if you can confirm your last non-working 4.14+commit fixes the issue as well). Regards, Salvatore
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+debian-bugs@zugschlus.de> |
|---|---|
| Date | 2018-02-21 16:10 +0100 |
| Message-ID | <vlEbT-8n5-3@gated-at.bofh.it> |
| In reply to | #60245 |
On Mon, Feb 19, 2018 at 06:31:16AM +0100, Salvatore Bonaccorso wrote: > On Sun, Feb 18, 2018 at 11:34:21AM +0100, Marc Haber wrote: > > On Sun, Feb 18, 2018 at 10:15:43AM +0100, Salvatore Bonaccorso wrote: > > > Looking today through the kernel archive, I noticed an answer from > > > Paolo Bonzini, <62aa6b81-5456-07dc-cf64-e46747d3a70d@redhat.com>, > > > claiming this is fixed by > > > > > > https://git.kernel.org/linus/2a266f23550be997d783f27e704b9b40c4010292 > > > which is in 4.15-rc8, and thus confirming that you did not had the > > > issue anymore in 4.15. > > > > ... unfortunately with a totally unexplaining commit message though. > > > > > Closing this bug with that version, but do you have a chance to > > > confirm that? > > > > What exactly do you want me to test: > > > > - that the bug doesn't happen any more in Debian 4.15 kernels? > > - that ths bug still happens in Debian's 4.14 kernel and vanishes with > > the patch applied? > > - Something else? > > In an optimal case we get a confirmation that > 2a266f23550be997d783f27e704b9b40c4010292 is the fixing commit for your > issues. But given we have uploaded 4.15.4-1 to unstable, if you can > confirm that this one defintively fix your issue that would be great > (bonus if you can confirm your last non-working 4.14+commit fixes the > issue as well). If I used git correctly, then 4.14.20 already has 2a266f23550be997d783f27e704b9b40c4010292, so I tried 4.14.19. 4.14.19 on the one virt host that had the most violent failures failed in the first hour of operation, but with a slightly different error behavior that I was used to. I am therefore not sure whether we are not talking about multiple issues, one of them having been fixed somewhere in between 4.14.13 and 4.14.19. I then applied 2a266f23550be997d783f27e704b9b40c4010292 to 4.14.19, resulting in 4.4.19+, and this one has been running flawlessly for two days (and 0 minutes, incidentally) now. I will stay on 4.14.19+ until 4.15.5 comes out (and will update then). If you don't hear from me again in this bug report, then you can safely assume that 4.14.19+ lived on the test machine until its planned decommissioning during the 4.15.5 rollout. Hope this helps. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+debian-bugs@zugschlus.de> |
|---|---|
| Date | 2018-02-23 09:20 +0100 |
| Message-ID | <vmgKd-1qv-3@gated-at.bofh.it> |
| In reply to | #60258 |
On Wed, Feb 21, 2018 at 03:57:31PM +0100, Marc Haber wrote: > I then applied 2a266f23550be997d783f27e704b9b40c4010292 to 4.14.19, > resulting in 4.4.19+, and this one has been running flawlessly for two > days (and 0 minutes, incidentally) now. I will stay on 4.14.19+ until > 4.15.5 comes out (and will update then). If you don't hear from me again > in this bug report, then you can safely assume that 4.14.19+ lived on > the test machine until its planned decommissioning during the 4.15.5 > rollout. I regret to say that one of the VMs running on the host running 4.14.19+ has just suffered a "BUG: soft lockup - CPU#1 stuck for 58s!" which is an atypical behavior for the issue I had previously, but might have a common cause. 4.15.5 is currently building on my build host, and I'll move to that kernel asap. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.kernel
csiph-web