* Major KVM issues with kernel 4.5 on the host
@ 2016-03-17 16:54 Marc Haber
2016-03-17 18:11 ` Borislav Petkov
0 siblings, 1 reply; 49+ messages in thread
From: Marc Haber @ 2016-03-17 16:54 UTC (permalink / raw)
To: linux-kernel
Hi,
I have a (semi-productive[1]) system ("host") running Debian unstable.
On this system, a few VMs (Debian unstable, Debian testing) ("vm1",
"vm2", "vm3") are running. I roll my own kernels and take vanilla
upstream sources. No distribution patches.
Since host was updated to Kernel 4.5, the VMs have started acting up.
All of them. The range of strangeness begins with "relocation error,
system halted" on system startup, corrupted data files on disk,
filesystems remounted read-only, libraries rejected with "invalid ELF
format", binaries segfaulting all of a sudden. Downgrading host to
kernel 4.4.5 magically fixed all those issues.
Going back to 4.5 lets the issues reappear. Here, for example, ext4 fs
errors, logged in one of the VMs:
Mar 17 17:39:57 spinturn kernel: EXT4-fs error (device dm-0): ext4_lookup:1602: inode #415065: comm aide: deleted inode referenced: 546538
Mar 17 17:39:57 spinturn kernel: EXT4-fs error (device dm-0): ext4_lookup:1602: inode #415065: comm aide: deleted inode referenced: 546530
Mar 17 17:39:57 spinturn kernel: EXT4-fs error (device dm-0): ext4_iget:4269: inode #546543: comm aide: bad extra_isize (44800 != 256)
Mar 17 17:39:58 spinturn kernel: EXT4-fs error (device dm-0): ext4_iget:4466: inode #546568: comm aide: bogus i_mode (144)
Mar 17 17:39:58 spinturn kernel: EXT4-fs error (device dm-0): ext4_lookup:1602: inode #546548: comm aide: deleted inode referenced: 546564
Mar 17 17:39:58 spinturn kernel: EXT4-fs error (device dm-0): ext4_lookup:1602: inode #546548: comm aide: deleted inode referenced: 546562
Mar 17 17:39:58 spinturn kernel: EXT4-fs error (device dm-0): ext4_iget:4269: inode #546563: comm aide: bad extra_isize (6464 != 256)
Mar 17 17:39:58 spinturn kernel: EXT4-fs error (device dm-0): ext4_iget:4466: inode #546561: comm aide: bogus i_mode (0)
Mar 17 17:39:58 spinturn kernel: EXT4-fs error (device dm-0): ext4_iget:4269: inode #546529: comm aide: bad extra_isize (1152 != 256)
Mar 17 17:39:58 spinturn kernel: EXT4-fs error (device dm-0): ext4_xattr_block_get:297: inode #546359: comm aide: bad block 677784
I'm going to try reproducing the issue on a less "important" machine
so that bisecting is less painful, but maybe you guys have an idea
what's going wrong here.
jftr, kernel 4.5 in guest and in standalone systems seems to be
unproblematic.
Greetings
Marc
[1] my main workstation, running enough services for the local network
that disturbances in its operation cause reasonable discomfort, but not the
Enterprise kind of "productive"
--
-----------------------------------------------------------------------------
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
^ permalink raw reply [flat|nested] 49+ messages in thread* Re: Major KVM issues with kernel 4.5 on the host 2016-03-17 16:54 Major KVM issues with kernel 4.5 on the host Marc Haber @ 2016-03-17 18:11 ` Borislav Petkov 2016-03-18 10:01 ` Paolo Bonzini 2016-03-18 18:49 ` Marc Haber 0 siblings, 2 replies; 49+ messages in thread From: Borislav Petkov @ 2016-03-17 18:11 UTC (permalink / raw) To: Marc Haber; +Cc: linux-kernel, kvm ML + kvm ML. Do you have any funky messages in host's dmesg ? Can you upload a full dmesg from both a good and a bad host kernel? On Thu, Mar 17, 2016 at 05:54:35PM +0100, Marc Haber wrote: > Hi, > > I have a (semi-productive[1]) system ("host") running Debian unstable. > On this system, a few VMs (Debian unstable, Debian testing) ("vm1", > "vm2", "vm3") are running. I roll my own kernels and take vanilla > upstream sources. No distribution patches. > > Since host was updated to Kernel 4.5, the VMs have started acting up. > All of them. The range of strangeness begins with "relocation error, > system halted" on system startup, corrupted data files on disk, > filesystems remounted read-only, libraries rejected with "invalid ELF > format", binaries segfaulting all of a sudden. Downgrading host to > kernel 4.4.5 magically fixed all those issues. > > Going back to 4.5 lets the issues reappear. Here, for example, ext4 fs > errors, logged in one of the VMs: > > Mar 17 17:39:57 spinturn kernel: EXT4-fs error (device dm-0): ext4_lookup:1602: inode #415065: comm aide: deleted inode referenced: 546538 > Mar 17 17:39:57 spinturn kernel: EXT4-fs error (device dm-0): ext4_lookup:1602: inode #415065: comm aide: deleted inode referenced: 546530 > Mar 17 17:39:57 spinturn kernel: EXT4-fs error (device dm-0): ext4_iget:4269: inode #546543: comm aide: bad extra_isize (44800 != 256) > Mar 17 17:39:58 spinturn kernel: EXT4-fs error (device dm-0): ext4_iget:4466: inode #546568: comm aide: bogus i_mode (144) > Mar 17 17:39:58 spinturn kernel: EXT4-fs error (device dm-0): ext4_lookup:1602: inode #546548: comm aide: deleted inode referenced: 546564 > Mar 17 17:39:58 spinturn kernel: EXT4-fs error (device dm-0): ext4_lookup:1602: inode #546548: comm aide: deleted inode referenced: 546562 > Mar 17 17:39:58 spinturn kernel: EXT4-fs error (device dm-0): ext4_iget:4269: inode #546563: comm aide: bad extra_isize (6464 != 256) > Mar 17 17:39:58 spinturn kernel: EXT4-fs error (device dm-0): ext4_iget:4466: inode #546561: comm aide: bogus i_mode (0) > Mar 17 17:39:58 spinturn kernel: EXT4-fs error (device dm-0): ext4_iget:4269: inode #546529: comm aide: bad extra_isize (1152 != 256) > Mar 17 17:39:58 spinturn kernel: EXT4-fs error (device dm-0): ext4_xattr_block_get:297: inode #546359: comm aide: bad block 677784 > > I'm going to try reproducing the issue on a less "important" machine > so that bisecting is less painful, but maybe you guys have an idea > what's going wrong here. > > jftr, kernel 4.5 in guest and in standalone systems seems to be > unproblematic. > > Greetings > Marc > > > [1] my main workstation, running enough services for the local network > that disturbances in its operation cause reasonable discomfort, but not the > Enterprise kind of "productive" > > -- > ----------------------------------------------------------------------------- > 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 > -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-03-17 18:11 ` Borislav Petkov @ 2016-03-18 10:01 ` Paolo Bonzini 2016-04-13 18:37 ` Marc Haber 2016-03-18 18:49 ` Marc Haber 1 sibling, 1 reply; 49+ messages in thread From: Paolo Bonzini @ 2016-03-18 10:01 UTC (permalink / raw) To: Borislav Petkov, Marc Haber; +Cc: linux-kernel, kvm ML On 17/03/2016 19:11, Borislav Petkov wrote: > I'm going to try reproducing the issue on a less "important" machine > so that bisecting is less painful, but maybe you guys have an idea > what's going wrong here. No idea, sorry. :( Bisecting would be great. I'll also try reproducing and bisecting next week, in the meanwhile just having the host dmesg would help a lot. Paolo ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-03-18 10:01 ` Paolo Bonzini @ 2016-04-13 18:37 ` Marc Haber 2016-04-13 20:36 ` Paolo Bonzini 0 siblings, 1 reply; 49+ messages in thread From: Marc Haber @ 2016-04-13 18:37 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Borislav Petkov, linux-kernel, kvm ML [-- Attachment #1: Type: text/plain, Size: 864 bytes --] On Fri, Mar 18, 2016 at 11:01:46AM +0100, Paolo Bonzini wrote: > On 17/03/2016 19:11, Borislav Petkov wrote: > > I'm going to try reproducing the issue on a less "important" machine > > so that bisecting is less painful, but maybe you guys have an idea > > what's going wrong here. > > No idea, sorry. :( Bisecting would be great. Working on that now. > I'll also try reproducing and bisecting next week, in the meanwhile > just having the host dmesg would help a lot. Attached. I hope the message will get through to the list. 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 [-- Attachment #2: dmesg.fan.4.5.1 --] [-- Type: text/plain, Size: 76258 bytes --] [ 0.000000] Linux version 4.5.1-zgws1 (mh@fan) (gcc version 5.3.1 20160409 (Debian 5.3.1-14) ) #2 SMP Wed Apr 13 06:32:03 UTC 2016 [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.5.1-zgws1 root=/dev/mapper/root ro radeon.modeset=1 splash quiet scsi_mod.scan=sync [ 0.000000] tseg: 0000000000 [ 0.000000] x86/fpu: Legacy x87 FPU detected. [ 0.000000] x86/fpu: Using 'lazy' FPU context switches. [ 0.000000] e820: BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009abff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009ac00-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000e2000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000cff7ffff] usable [ 0.000000] BIOS-e820: [mem 0x00000000cff80000-0x00000000cff97fff] ACPI data [ 0.000000] BIOS-e820: [mem 0x00000000cff98000-0x00000000cffbffff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000cffc0000-0x00000000cfffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000ffa00000-0x00000000ffffffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000062fffffff] usable [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] SMBIOS 2.5 present. [ 0.000000] DMI: System manufacturer System Product Name/M5A88-V EVO, BIOS 1603 10/12/2012 [ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved [ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable [ 0.000000] AGP: No AGP bridge found [ 0.000000] e820: last_pfn = 0x630000 max_arch_pfn = 0x400000000 [ 0.000000] MTRR default type: uncachable [ 0.000000] MTRR fixed ranges enabled: [ 0.000000] 00000-9FFFF write-back [ 0.000000] A0000-EFFFF uncachable [ 0.000000] F0000-FFFFF write-protect [ 0.000000] MTRR variable ranges enabled: [ 0.000000] 0 base 000000000000 mask FFFF80000000 write-back [ 0.000000] 1 base 000080000000 mask FFFFC0000000 write-back [ 0.000000] 2 base 0000C0000000 mask FFFFF0000000 write-back [ 0.000000] 3 disabled [ 0.000000] 4 disabled [ 0.000000] 5 disabled [ 0.000000] 6 disabled [ 0.000000] 7 disabled [ 0.000000] TOM2: 0000000630000000 aka 25344M [ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT [ 0.000000] e820: update [mem 0xd0000000-0xffffffff] usable ==> reserved [ 0.000000] e820: last_pfn = 0xcff80 max_arch_pfn = 0x400000000 [ 0.000000] found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at [ffff8800000ff780] [ 0.000000] Base memory trampoline at [ffff880000094000] 94000 size 24576 [ 0.000000] Using GB pages for direct mapping [ 0.000000] BRK [0x01a83000, 0x01a83fff] PGTABLE [ 0.000000] BRK [0x01a84000, 0x01a84fff] PGTABLE [ 0.000000] BRK [0x01a85000, 0x01a85fff] PGTABLE [ 0.000000] BRK [0x01a86000, 0x01a86fff] PGTABLE [ 0.000000] RAMDISK: [mem 0x357bc000-0x36bd5fff] [ 0.000000] ACPI: Early table checksum verification disabled [ 0.000000] ACPI: RSDP 0x00000000000FBC30 000024 (v02 ACPIAM) [ 0.000000] ACPI: XSDT 0x00000000CFF80100 000054 (v01 101212 XSDT1626 20121012 MSFT 00000097) [ 0.000000] ACPI: FACP 0x00000000CFF80290 0000F4 (v03 101212 FACP1626 20121012 MSFT 00000097) [ 0.000000] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 64/32 (20160108/tbfadt-623) [ 0.000000] ACPI: DSDT 0x00000000CFF80460 00F14D (v01 A1867 A1867001 00000001 INTL 20060113) [ 0.000000] ACPI: FACS 0x00000000CFF98000 000040 [ 0.000000] ACPI: FACS 0x00000000CFF98000 000040 [ 0.000000] ACPI: APIC 0x00000000CFF80390 00008C (v01 101212 APIC1626 20121012 MSFT 00000097) [ 0.000000] ACPI: MCFG 0x00000000CFF80420 00003C (v01 101212 OEMMCFG 20121012 MSFT 00000097) [ 0.000000] ACPI: OEMB 0x00000000CFF98040 000072 (v01 101212 OEMB1626 20121012 MSFT 00000097) [ 0.000000] ACPI: HPET 0x00000000CFF8F8B0 000038 (v01 101212 OEMHPET 20121012 MSFT 00000097) [ 0.000000] ACPI: SSDT 0x00000000CFF8F8F0 000E10 (v01 A M I POWERNOW 00000001 AMD 00000001) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] Scanning NUMA topology in Northbridge 24 [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000062fffffff] [ 0.000000] NODE_DATA(0) allocated [mem 0x62fffa000-0x62fffdfff] [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff] [ 0.000000] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] [ 0.000000] Normal [mem 0x0000000100000000-0x000000062fffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000001000-0x0000000000099fff] [ 0.000000] node 0: [mem 0x0000000000100000-0x00000000cff7ffff] [ 0.000000] node 0: [mem 0x0000000100000000-0x000000062fffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000062fffffff] [ 0.000000] On node 0 totalpages: 6291225 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 21 pages reserved [ 0.000000] DMA zone: 3993 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 13246 pages used for memmap [ 0.000000] DMA32 zone: 847744 pages, LIFO batch:31 [ 0.000000] Normal zone: 84992 pages used for memmap [ 0.000000] Normal zone: 5439488 pages, LIFO batch:31 [ 0.000000] ACPI: PM-Timer IO Port: 0x808 [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] ACPI: HPET id: 0x8300 base: 0xfed00000 [ 0.000000] smpboot: Allowing 8 CPUs, 2 hotplug CPUs [ 0.000000] PM: Registered nosave memory: [mem 0x00000000-0x00000fff] [ 0.000000] PM: Registered nosave memory: [mem 0x0009a000-0x0009afff] [ 0.000000] PM: Registered nosave memory: [mem 0x0009b000-0x0009ffff] [ 0.000000] PM: Registered nosave memory: [mem 0x000a0000-0x000e1fff] [ 0.000000] PM: Registered nosave memory: [mem 0x000e2000-0x000fffff] [ 0.000000] PM: Registered nosave memory: [mem 0xcff80000-0xcff97fff] [ 0.000000] PM: Registered nosave memory: [mem 0xcff98000-0xcffbffff] [ 0.000000] PM: Registered nosave memory: [mem 0xcffc0000-0xcfffffff] [ 0.000000] PM: Registered nosave memory: [mem 0xd0000000-0xff9fffff] [ 0.000000] PM: Registered nosave memory: [mem 0xffa00000-0xffffffff] [ 0.000000] e820: [mem 0xd0000000-0xff9fffff] available for PCI devices [ 0.000000] Booting paravirtualized kernel on bare hardware [ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns [ 0.000000] setup_percpu: NR_CPUS:16 nr_cpumask_bits:16 nr_cpu_ids:8 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 32 pages/cpu @ffff88062fc00000 s92568 r8192 d30312 u262144 [ 0.000000] pcpu-alloc: s92568 r8192 d30312 u262144 alloc=1*2097152 [ 0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 6192902 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-4.5.1-zgws1 root=/dev/mapper/root ro radeon.modeset=1 splash quiet scsi_mod.scan=sync [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] AGP: Checking aperture... [ 0.000000] AGP: No AGP bridge found [ 0.000000] AGP: Node 0: aperture [bus addr 0x00000000-0x01ffffff] (32MB) [ 0.000000] AGP: Your BIOS doesn't leave an aperture memory hole [ 0.000000] AGP: Please enable the IOMMU option in the BIOS setup [ 0.000000] AGP: This costs you 64MB of RAM [ 0.000000] AGP: Mapping aperture over RAM [mem 0xc4000000-0xc7ffffff] (65536KB) [ 0.000000] PM: Registered nosave memory: [mem 0xc4000000-0xc7ffffff] [ 0.000000] Memory: 5341540K/25164900K available (4231K kernel code, 817K rwdata, 1856K rodata, 976K init, 752K bss, 557560K reserved, 0K cma-reserved) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] Build-time adjustment of leaf fanout to 64. [ 0.000000] RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=8. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=8 [ 0.000000] NR_IRQS:4352 nr_irqs:488 16 [ 0.000000] spurious 8259A interrupt: IRQ7. [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [tty0] enabled [ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484873504 ns [ 0.000000] hpet clockevent registered [ 0.000000] tsc: Fast TSC calibration using PIT [ 0.000000] tsc: Detected 3214.264 MHz processor [ 0.000003] Calibrating delay loop (skipped), value calculated using timer frequency.. 6428.52 BogoMIPS (lpj=12857056) [ 0.000006] pid_max: default: 32768 minimum: 301 [ 0.000022] ACPI: Core revision 20160108 [ 0.008499] ACPI: 2 ACPI AML tables successfully acquired and loaded [ 0.008546] Security Framework initialized [ 0.010349] Dentry cache hash table entries: 4194304 (order: 13, 33554432 bytes) [ 0.018917] Inode-cache hash table entries: 2097152 (order: 12, 16777216 bytes) [ 0.022960] Mount-cache hash table entries: 65536 (order: 7, 524288 bytes) [ 0.022991] Mountpoint-cache hash table entries: 65536 (order: 7, 524288 bytes) [ 0.023499] CPU: Physical Processor ID: 0 [ 0.023500] CPU: Processor Core ID: 0 [ 0.023502] mce: CPU supports 6 MCE banks [ 0.023509] LVT offset 0 assigned for vector 0xf9 [ 0.023513] process: using AMD E400 aware idle routine [ 0.023515] Last level iTLB entries: 4KB 512, 2MB 16, 4MB 8 [ 0.023516] Last level dTLB entries: 4KB 512, 2MB 128, 4MB 64, 1GB 0 [ 0.023727] Freeing SMP alternatives memory: 12K (ffffffff819c2000 - ffffffff819c5000) [ 0.128135] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [ 0.272891] smpboot: CPU0: AMD Phenom(tm) II X6 1090T Processor (family: 0x10, model: 0xa, stepping: 0x0) [ 0.272914] Performance Events: AMD PMU driver. [ 0.272917] ... version: 0 [ 0.272918] ... bit width: 48 [ 0.272919] ... generic registers: 4 [ 0.272920] ... value mask: 0000ffffffffffff [ 0.272921] ... max period: 00007fffffffffff [ 0.272922] ... fixed-purpose events: 0 [ 0.272923] ... event mask: 000000000000000f [ 0.273176] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. [ 0.273264] x86: Booting SMP configuration: [ 0.273265] .... node #0, CPUs: #1 [ 0.275910] process: System has AMD C1E enabled [ 0.275920] process: Switch to broadcast mode on CPU1 [ 0.275935] #2 [ 0.278551] process: Switch to broadcast mode on CPU2 [ 0.278570] #3 [ 0.281216] process: Switch to broadcast mode on CPU3 [ 0.281235] #4 [ 0.283852] process: Switch to broadcast mode on CPU4 [ 0.283877] #5 [ 0.286452] x86: Booted up 1 node, 6 CPUs [ 0.286454] smpboot: Total of 6 processors activated (38571.16 BogoMIPS) [ 0.293106] process: Switch to broadcast mode on CPU5 [ 0.293195] process: Switch to broadcast mode on CPU0 [ 0.411747] node 0 initialised, 4816450 pages in 116ms [ 0.411999] devtmpfs: initialized [ 0.418170] PM: Registering ACPI NVS region [mem 0xcff98000-0xcffbffff] (163840 bytes) [ 0.418271] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns [ 0.418327] prandom: seed boundary self test passed [ 0.418790] prandom: 100 self tests passed [ 0.418793] pinctrl core: initialized pinctrl subsystem [ 0.419058] NET: Registered protocol family 16 [ 0.436005] cpuidle: using governor ladder [ 0.448006] cpuidle: using governor menu [ 0.448018] node 0 link 0: io port [1000, ffffff] [ 0.448021] TOM: 00000000d0000000 aka 3328M [ 0.448022] Fam 10h mmconf [mem 0xe0000000-0xefffffff] [ 0.448024] node 0 link 0: mmio [d0000000, dfffffff] [ 0.448026] node 0 link 0: mmio [e0000000, efffffff] ==> none [ 0.448028] node 0 link 0: mmio [f0000000, febfffff] [ 0.448029] node 0 link 0: mmio [fec00000, fffeffff] [ 0.448031] node 0 link 0: mmio [ffff0000, ffffffff] [ 0.448032] TOM2: 0000000630000000 aka 25344M [ 0.448034] bus: [bus 00-1f] on node 0 link 0 [ 0.448035] bus: 00 [io 0x0000-0xffff] [ 0.448036] bus: 00 [mem 0xd0000000-0xdfffffff] [ 0.448037] bus: 00 [mem 0xf0000000-0xffffffff] [ 0.448038] bus: 00 [mem 0x630000000-0xfcffffffff] [ 0.448100] ACPI: bus type PCI registered [ 0.448102] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 0.448192] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) [ 0.448194] PCI: not using MMCONFIG [ 0.448195] PCI: Using configuration type 1 for base access [ 0.448196] PCI: Using configuration type 1 for extended access [ 0.448747] mtrr: your CPUs had inconsistent variable MTRR settings [ 0.448748] mtrr: probably your BIOS does not setup all CPUs. [ 0.448749] mtrr: corrected configuration. [ 0.460147] HugeTLB registered 1 GB page size, pre-allocated 0 pages [ 0.460150] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 0.460598] ACPI: Added _OSI(Module Device) [ 0.460600] ACPI: Added _OSI(Processor Device) [ 0.460601] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.460602] ACPI: Added _OSI(Processor Aggregator Device) [ 0.461594] ACPI: Executed 3 blocks of module-level executable AML code [ 0.760401] ACPI : EC: EC started [ 0.760450] ACPI: Interpreter enabled [ 0.760468] ACPI: (supports S0 S3 S4 S5) [ 0.760470] ACPI: Using IOAPIC for interrupt routing [ 0.760497] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000) [ 0.761626] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources [ 0.761640] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 0.766274] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.766279] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] [ 0.766474] acpi PNP0A03:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability] [ 0.766698] PCI host bridge to bus 0000:00 [ 0.766701] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] [ 0.766702] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] [ 0.766704] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] [ 0.766706] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff window] [ 0.766707] pci_bus 0000:00: root bus resource [mem 0xd0000000-0xdfffffff window] [ 0.766709] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfebfffff window] [ 0.766710] pci_bus 0000:00: root bus resource [bus 00-ff] [ 0.766718] pci 0000:00:00.0: [1022:9601] type 00 class 0x060000 [ 0.766813] pci 0000:00:02.0: [1022:9603] type 01 class 0x060400 [ 0.766843] pci 0000:00:02.0: PME# supported from D0 D3hot D3cold [ 0.766881] pci 0000:00:02.0: System wakeup disabled by ACPI [ 0.766925] pci 0000:00:0a.0: [1022:9609] type 01 class 0x060400 [ 0.766953] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold [ 0.766989] pci 0000:00:0a.0: System wakeup disabled by ACPI [ 0.767035] pci 0000:00:11.0: [1002:4391] type 00 class 0x010601 [ 0.767049] pci 0000:00:11.0: reg 0x10: [io 0xb000-0xb007] [ 0.767057] pci 0000:00:11.0: reg 0x14: [io 0xa000-0xa003] [ 0.767065] pci 0000:00:11.0: reg 0x18: [io 0x9000-0x9007] [ 0.767073] pci 0000:00:11.0: reg 0x1c: [io 0x8000-0x8003] [ 0.767081] pci 0000:00:11.0: reg 0x20: [io 0x7000-0x700f] [ 0.767089] pci 0000:00:11.0: reg 0x24: [mem 0xfe8ffc00-0xfe8fffff] [ 0.767186] pci 0000:00:12.0: [1002:4397] type 00 class 0x0c0310 [ 0.767197] pci 0000:00:12.0: reg 0x10: [mem 0xfe8fe000-0xfe8fefff] [ 0.767281] pci 0000:00:12.0: System wakeup disabled by ACPI [ 0.767322] pci 0000:00:12.2: [1002:4396] type 00 class 0x0c0320 [ 0.767336] pci 0000:00:12.2: reg 0x10: [mem 0xfe8ff800-0xfe8ff8ff] [ 0.767404] pci 0000:00:12.2: supports D1 D2 [ 0.767405] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot [ 0.767442] pci 0000:00:12.2: System wakeup disabled by ACPI [ 0.767484] pci 0000:00:13.0: [1002:4397] type 00 class 0x0c0310 [ 0.767495] pci 0000:00:13.0: reg 0x10: [mem 0xfe8fd000-0xfe8fdfff] [ 0.767576] pci 0000:00:13.0: System wakeup disabled by ACPI [ 0.767617] pci 0000:00:13.2: [1002:4396] type 00 class 0x0c0320 [ 0.767631] pci 0000:00:13.2: reg 0x10: [mem 0xfe8ff400-0xfe8ff4ff] [ 0.767698] pci 0000:00:13.2: supports D1 D2 [ 0.767700] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot [ 0.767736] pci 0000:00:13.2: System wakeup disabled by ACPI [ 0.767778] pci 0000:00:14.0: [1002:4385] type 00 class 0x0c0500 [ 0.767899] pci 0000:00:14.2: [1002:4383] type 00 class 0x040300 [ 0.767916] pci 0000:00:14.2: reg 0x10: [mem 0xfe8f4000-0xfe8f7fff 64bit] [ 0.767989] pci 0000:00:14.2: PME# supported from D0 D3hot D3cold [ 0.768029] pci 0000:00:14.2: System wakeup disabled by ACPI [ 0.768070] pci 0000:00:14.3: [1002:439d] type 00 class 0x060100 [ 0.768198] pci 0000:00:14.4: [1002:4384] type 01 class 0x060401 [ 0.768265] pci 0000:00:14.4: System wakeup disabled by ACPI [ 0.768305] pci 0000:00:14.5: [1002:4399] type 00 class 0x0c0310 [ 0.768321] pci 0000:00:14.5: reg 0x10: [mem 0xfe8fc000-0xfe8fcfff] [ 0.768402] pci 0000:00:14.5: System wakeup disabled by ACPI [ 0.768444] pci 0000:00:15.0: [1002:43a0] type 01 class 0x060400 [ 0.768501] pci 0000:00:15.0: supports D1 D2 [ 0.768540] pci 0000:00:15.0: System wakeup disabled by ACPI [ 0.768581] pci 0000:00:15.1: [1002:43a1] type 01 class 0x060400 [ 0.768643] pci 0000:00:15.1: supports D1 D2 [ 0.768682] pci 0000:00:15.1: System wakeup disabled by ACPI [ 0.768726] pci 0000:00:16.0: [1002:4397] type 00 class 0x0c0310 [ 0.768737] pci 0000:00:16.0: reg 0x10: [mem 0xfe8f3000-0xfe8f3fff] [ 0.768819] pci 0000:00:16.0: System wakeup disabled by ACPI [ 0.768859] pci 0000:00:16.2: [1002:4396] type 00 class 0x0c0320 [ 0.768873] pci 0000:00:16.2: reg 0x10: [mem 0xfe8ff000-0xfe8ff0ff] [ 0.768941] pci 0000:00:16.2: supports D1 D2 [ 0.768942] pci 0000:00:16.2: PME# supported from D0 D1 D2 D3hot [ 0.768979] pci 0000:00:16.2: System wakeup disabled by ACPI [ 0.769018] pci 0000:00:18.0: [1022:1200] type 00 class 0x060000 [ 0.769080] pci 0000:00:18.1: [1022:1201] type 00 class 0x060000 [ 0.769142] pci 0000:00:18.2: [1022:1202] type 00 class 0x060000 [ 0.769203] pci 0000:00:18.3: [1022:1203] type 00 class 0x060000 [ 0.769266] pci 0000:00:18.4: [1022:1204] type 00 class 0x060000 [ 0.769367] pci 0000:01:00.0: [1002:68f9] type 00 class 0x030000 [ 0.769379] pci 0000:01:00.0: reg 0x10: [mem 0xd0000000-0xdfffffff 64bit pref] [ 0.769387] pci 0000:01:00.0: reg 0x18: [mem 0xfe9e0000-0xfe9fffff 64bit] [ 0.769393] pci 0000:01:00.0: reg 0x20: [io 0xc000-0xc0ff] [ 0.769403] pci 0000:01:00.0: reg 0x30: [mem 0xfe9c0000-0xfe9dffff pref] [ 0.769433] pci 0000:01:00.0: supports D1 D2 [ 0.769478] pci 0000:01:00.1: [1002:aa68] type 00 class 0x040300 [ 0.769490] pci 0000:01:00.1: reg 0x10: [mem 0xfe9bc000-0xfe9bffff 64bit] [ 0.769541] pci 0000:01:00.1: supports D1 D2 [ 0.776012] pci 0000:00:02.0: PCI bridge to [bus 01] [ 0.776016] pci 0000:00:02.0: bridge window [io 0xc000-0xcfff] [ 0.776019] pci 0000:00:02.0: bridge window [mem 0xfe900000-0xfe9fffff] [ 0.776022] pci 0000:00:02.0: bridge window [mem 0xd0000000-0xdfffffff 64bit pref] [ 0.776078] pci 0000:02:00.0: [1b21:1042] type 00 class 0x0c0330 [ 0.776097] pci 0000:02:00.0: reg 0x10: [mem 0xfeaf8000-0xfeafffff 64bit] [ 0.776189] pci 0000:02:00.0: PME# supported from D3hot D3cold [ 0.784015] pci 0000:00:0a.0: PCI bridge to [bus 02] [ 0.784020] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafffff] [ 0.784075] pci 0000:03:05.0: [1000:0006] type 00 class 0x010000 [ 0.784090] pci 0000:03:05.0: reg 0x10: [io 0xd000-0xd0ff] [ 0.784101] pci 0000:03:05.0: reg 0x14: [mem 0xfebfbc00-0xfebfbcff] [ 0.784207] pci 0000:03:06.0: [1131:7146] type 00 class 0x048000 [ 0.784222] pci 0000:03:06.0: reg 0x10: [mem 0xfebfb800-0xfebfb9ff] [ 0.784335] pci 0000:03:07.0: [13f6:0111] type 00 class 0x040100 [ 0.784354] pci 0000:03:07.0: reg 0x10: [io 0xd800-0xd8ff] [ 0.784451] pci 0000:03:07.0: supports D1 D2 [ 0.784515] pci 0000:00:14.4: PCI bridge to [bus 03] (subtractive decode) [ 0.784518] pci 0000:00:14.4: bridge window [io 0xd000-0xdfff] [ 0.784521] pci 0000:00:14.4: bridge window [mem 0xfeb00000-0xfebfffff] [ 0.784525] pci 0000:00:14.4: bridge window [io 0x0000-0x0cf7 window] (subtractive decode) [ 0.784526] pci 0000:00:14.4: bridge window [io 0x0d00-0xffff window] (subtractive decode) [ 0.784528] pci 0000:00:14.4: bridge window [mem 0x000a0000-0x000bffff window] (subtractive decode) [ 0.784529] pci 0000:00:14.4: bridge window [mem 0x000d0000-0x000dffff window] (subtractive decode) [ 0.784531] pci 0000:00:14.4: bridge window [mem 0xd0000000-0xdfffffff window] (subtractive decode) [ 0.784532] pci 0000:00:14.4: bridge window [mem 0xf0000000-0xfebfffff window] (subtractive decode) [ 0.784576] pci 0000:00:15.0: PCI bridge to [bus 04] [ 0.784653] pci 0000:05:00.0: [10ec:8168] type 00 class 0x020000 [ 0.784672] pci 0000:05:00.0: reg 0x10: [io 0xe800-0xe8ff] [ 0.784699] pci 0000:05:00.0: reg 0x18: [mem 0xfdfff000-0xfdffffff 64bit pref] [ 0.784717] pci 0000:05:00.0: reg 0x20: [mem 0xfdff8000-0xfdffbfff 64bit pref] [ 0.784806] pci 0000:05:00.0: supports D1 D2 [ 0.784808] pci 0000:05:00.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.784849] pci 0000:05:00.0: System wakeup disabled by ACPI [ 0.792017] pci 0000:00:15.1: PCI bridge to [bus 05] [ 0.792023] pci 0000:00:15.1: bridge window [io 0xe000-0xefff] [ 0.792030] pci 0000:00:15.1: bridge window [mem 0xfdf00000-0xfdffffff 64bit pref] [ 0.792587] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 6 7 9 10 11 14 15) [ 0.792642] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *9 10 11 14 15) [ 0.792700] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 *10 11 14 15) [ 0.792756] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 9 10 *11 14 15) [ 0.792802] ACPI: PCI Interrupt Link [LNKE] (IRQs *3 4 5 6 7 9 10 11 14 15) [ 0.792838] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 *7 9 10 11 14 15) [ 0.792874] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 *6 7 9 10 11 14 15) [ 0.792910] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 14 15) *0 [ 0.792974] ACPI: Enabled 1 GPEs in block 00 to 1F [ 0.793001] ACPI : EC: GPE = 0xa, I/O: command/status = 0x66, data = 0x62 [ 0.793115] vgaarb: setting as boot device: PCI:0000:01:00.0 [ 0.793116] vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none [ 0.793118] vgaarb: loaded [ 0.793119] vgaarb: bridge control possible 0000:01:00.0 [ 0.793172] pps_core: LinuxPPS API ver. 1 registered [ 0.793173] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 0.793177] PTP clock support registered [ 0.793203] PCI: Using ACPI for IRQ routing [ 0.800504] PCI: pci_cache_line_size set to 64 bytes [ 0.800558] e820: reserve RAM buffer [mem 0x0009ac00-0x0009ffff] [ 0.800560] e820: reserve RAM buffer [mem 0xcff80000-0xcfffffff] [ 0.800698] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 [ 0.800700] hpet0: 3 comparators, 32-bit 14.318180 MHz counter [ 0.802789] clocksource: Switched to clocksource hpet [ 0.806740] pnp: PnP ACPI init [ 0.806886] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.806961] pnp 00:01: Plug and Play ACPI device, IDs PNP0b00 (active) [ 0.807044] pnp 00:02: Plug and Play ACPI device, IDs PNP0303 PNP030b (active) [ 0.807384] pnp 00:03: [dma 0 disabled] [ 0.807449] pnp 00:03: Plug and Play ACPI device, IDs PNP0501 (active) [ 0.807539] system 00:04: [mem 0xfec00000-0xfec00fff] could not be reserved [ 0.807541] system 00:04: [mem 0xfee00000-0xfee00fff] has been reserved [ 0.807543] system 00:04: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.807711] system 00:05: [io 0x04d0-0x04d1] has been reserved [ 0.807713] system 00:05: [io 0x040b] has been reserved [ 0.807714] system 00:05: [io 0x04d6] has been reserved [ 0.807716] system 00:05: [io 0x0c00-0x0c01] has been reserved [ 0.807718] system 00:05: [io 0x0c14] has been reserved [ 0.807719] system 00:05: [io 0x0c50-0x0c51] has been reserved [ 0.807721] system 00:05: [io 0x0c52] has been reserved [ 0.807723] system 00:05: [io 0x0c6c] has been reserved [ 0.807724] system 00:05: [io 0x0c6f] has been reserved [ 0.807726] system 00:05: [io 0x0cd0-0x0cd1] has been reserved [ 0.807727] system 00:05: [io 0x0cd2-0x0cd3] has been reserved [ 0.807729] system 00:05: [io 0x0cd4-0x0cd5] has been reserved [ 0.807731] system 00:05: [io 0x0cd6-0x0cd7] has been reserved [ 0.807732] system 00:05: [io 0x0cd8-0x0cdf] has been reserved [ 0.807734] system 00:05: [io 0x0b00-0x0b3f] has been reserved [ 0.807736] system 00:05: [io 0x0800-0x089f] could not be reserved [ 0.807737] system 00:05: [io 0x0b00-0x0b1f] has been reserved [ 0.807739] system 00:05: [io 0x0b20-0x0b3f] has been reserved [ 0.807741] system 00:05: [io 0x0900-0x090f] has been reserved [ 0.807743] system 00:05: [io 0x0910-0x091f] has been reserved [ 0.807744] system 00:05: [io 0xfe00-0xfefe] has been reserved [ 0.807746] system 00:05: [mem 0xffb80000-0xffbfffff] has been reserved [ 0.807748] system 00:05: [mem 0xfec10000-0xfec1001f] has been reserved [ 0.807750] system 00:05: [mem 0xfed80000-0xfed80fff] has been reserved [ 0.807752] system 00:05: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.807902] system 00:06: [io 0x0230-0x023f] has been reserved [ 0.807904] system 00:06: [io 0x0290-0x029f] has been reserved [ 0.807905] system 00:06: [io 0x0300-0x030f] has been reserved [ 0.807907] system 00:06: [io 0x0a30-0x0a3f] has been reserved [ 0.807909] system 00:06: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.807961] system 00:07: [mem 0xe0000000-0xefffffff] has been reserved [ 0.807963] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.808069] system 00:08: [mem 0x00000000-0x0009ffff] could not be reserved [ 0.808071] system 00:08: [mem 0x000c0000-0x000cffff] could not be reserved [ 0.808073] system 00:08: [mem 0x000e0000-0x000fffff] could not be reserved [ 0.808074] system 00:08: [mem 0x00100000-0xcfffffff] could not be reserved [ 0.808076] system 00:08: [mem 0xfec00000-0xffffffff] could not be reserved [ 0.808078] system 00:08: Plug and Play ACPI device, IDs PNP0c01 (active) [ 0.808154] pnp: PnP ACPI: found 9 devices [ 0.815258] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns [ 0.815286] pci 0000:00:02.0: PCI bridge to [bus 01] [ 0.815288] pci 0000:00:02.0: bridge window [io 0xc000-0xcfff] [ 0.815291] pci 0000:00:02.0: bridge window [mem 0xfe900000-0xfe9fffff] [ 0.815293] pci 0000:00:02.0: bridge window [mem 0xd0000000-0xdfffffff 64bit pref] [ 0.815295] pci 0000:00:0a.0: PCI bridge to [bus 02] [ 0.815298] pci 0000:00:0a.0: bridge window [mem 0xfea00000-0xfeafffff] [ 0.815301] pci 0000:00:14.4: PCI bridge to [bus 03] [ 0.815304] pci 0000:00:14.4: bridge window [io 0xd000-0xdfff] [ 0.815308] pci 0000:00:14.4: bridge window [mem 0xfeb00000-0xfebfffff] [ 0.815315] pci 0000:00:15.0: PCI bridge to [bus 04] [ 0.815323] pci 0000:00:15.1: PCI bridge to [bus 05] [ 0.815325] pci 0000:00:15.1: bridge window [io 0xe000-0xefff] [ 0.815330] pci 0000:00:15.1: bridge window [mem 0xfdf00000-0xfdffffff 64bit pref] [ 0.815335] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window] [ 0.815337] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window] [ 0.815338] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window] [ 0.815340] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff window] [ 0.815341] pci_bus 0000:00: resource 8 [mem 0xd0000000-0xdfffffff window] [ 0.815343] pci_bus 0000:00: resource 9 [mem 0xf0000000-0xfebfffff window] [ 0.815344] pci_bus 0000:01: resource 0 [io 0xc000-0xcfff] [ 0.815345] pci_bus 0000:01: resource 1 [mem 0xfe900000-0xfe9fffff] [ 0.815347] pci_bus 0000:01: resource 2 [mem 0xd0000000-0xdfffffff 64bit pref] [ 0.815348] pci_bus 0000:02: resource 1 [mem 0xfea00000-0xfeafffff] [ 0.815350] pci_bus 0000:03: resource 0 [io 0xd000-0xdfff] [ 0.815351] pci_bus 0000:03: resource 1 [mem 0xfeb00000-0xfebfffff] [ 0.815353] pci_bus 0000:03: resource 4 [io 0x0000-0x0cf7 window] [ 0.815354] pci_bus 0000:03: resource 5 [io 0x0d00-0xffff window] [ 0.815355] pci_bus 0000:03: resource 6 [mem 0x000a0000-0x000bffff window] [ 0.815357] pci_bus 0000:03: resource 7 [mem 0x000d0000-0x000dffff window] [ 0.815358] pci_bus 0000:03: resource 8 [mem 0xd0000000-0xdfffffff window] [ 0.815360] pci_bus 0000:03: resource 9 [mem 0xf0000000-0xfebfffff window] [ 0.815361] pci_bus 0000:05: resource 0 [io 0xe000-0xefff] [ 0.815362] pci_bus 0000:05: resource 2 [mem 0xfdf00000-0xfdffffff 64bit pref] [ 0.815487] NET: Registered protocol family 2 [ 0.815782] TCP established hash table entries: 262144 (order: 9, 2097152 bytes) [ 0.816318] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) [ 0.816552] TCP: Hash tables configured (established 262144 bind 65536) [ 0.816617] UDP hash table entries: 16384 (order: 7, 524288 bytes) [ 0.816775] UDP-Lite hash table entries: 16384 (order: 7, 524288 bytes) [ 0.817061] NET: Registered protocol family 1 [ 1.939111] pci 0000:01:00.0: Video device with shadowed ROM [ 1.939226] PCI: CLS 64 bytes, default 64 [ 1.939274] Unpacking initramfs... [ 2.203589] Freeing initrd memory: 20584K (ffff8800357bc000 - ffff880036bd6000) [ 2.203866] PCI-DMA: Disabling AGP. [ 2.203997] PCI-DMA: aperture base @ c4000000 size 65536 KB [ 2.203998] PCI-DMA: using GART IOMMU. [ 2.204000] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture [ 2.207742] LVT offset 1 assigned for vector 0x400 [ 2.207753] IBS: LVT offset 1 assigned [ 2.207809] perf: AMD IBS detected (0x0000001f) [ 2.208271] futex hash table entries: 2048 (order: 5, 131072 bytes) [ 2.208564] Initialise system trusted keyring [ 2.209591] Key type asymmetric registered [ 2.209595] Asymmetric key parser 'x509' registered [ 2.209635] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248) [ 2.209688] io scheduler noop registered [ 2.209691] io scheduler deadline registered [ 2.209708] io scheduler cfq registered (default) [ 2.210266] pcieport 0000:00:02.0: Signaling PME through PCIe PME interrupt [ 2.210268] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt [ 2.210269] pci 0000:01:00.1: Signaling PME through PCIe PME interrupt [ 2.210271] pcie_pme 0000:00:02.0:pcie01: service driver pcie_pme loaded [ 2.210285] pcieport 0000:00:0a.0: Signaling PME through PCIe PME interrupt [ 2.210286] pci 0000:02:00.0: Signaling PME through PCIe PME interrupt [ 2.210288] pcie_pme 0000:00:0a.0:pcie01: service driver pcie_pme loaded [ 2.210308] pcieport 0000:00:15.0: Signaling PME through PCIe PME interrupt [ 2.210311] pcie_pme 0000:00:15.0:pcie01: service driver pcie_pme loaded [ 2.210331] pcieport 0000:00:15.1: Signaling PME through PCIe PME interrupt [ 2.210332] pci 0000:05:00.0: Signaling PME through PCIe PME interrupt [ 2.210335] pcie_pme 0000:00:15.1:pcie01: service driver pcie_pme loaded [ 2.210341] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 2.210348] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [ 2.210397] GHES: HEST is not enabled! [ 2.210403] xenfs: not registering filesystem on non-xen platform [ 2.210488] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 2.230962] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A [ 2.232185] lp: driver loaded but no devices found [ 2.232963] ppdev: user-space parallel port driver [ 2.232968] Linux agpgart interface v0.103 [ 2.232994] AMD IOMMUv2 driver by Joerg Roedel <jroedel@suse.de> [ 2.232995] AMD IOMMUv2 functionality not available on this system [ 2.233994] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 [ 2.233996] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp [ 2.234128] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.234223] mousedev: PS/2 mouse device common for all mice [ 2.234264] rtc_cmos 00:01: RTC can wake from S4 [ 2.234390] rtc_cmos 00:01: rtc core: registered rtc_cmos as rtc0 [ 2.234411] rtc_cmos 00:01: alarms up to one month, y3k, 114 bytes nvram, hpet irqs [ 2.234477] alg: No test for skein256 (skein) [ 2.234549] alg: No test for skein512 (skein) [ 2.234595] alg: No test for skein1024 (skein) [ 2.234678] drop_monitor: Initializing network drop monitor service [ 2.234827] NET: Registered protocol family 10 [ 2.235060] NET: Registered protocol family 17 [ 2.235402] microcode: CPU0: patch_level=0x010000bf [ 2.235412] microcode: CPU1: patch_level=0x010000bf [ 2.235427] microcode: CPU2: patch_level=0x010000bf [ 2.235437] microcode: CPU3: patch_level=0x010000bf [ 2.235447] microcode: CPU4: patch_level=0x010000bf [ 2.235453] microcode: CPU5: patch_level=0x010000bf [ 2.235492] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba [ 2.235661] registered taskstats version 1 [ 2.235669] Loading compiled-in X.509 certificates [ 2.236095] rtc_cmos 00:01: setting system clock to 2016-04-13 17:49:12 UTC (1460569752) [ 2.236156] PM: Hibernation image not present or could not be loaded. [ 2.237146] Freeing unused kernel memory: 976K (ffffffff818ce000 - ffffffff819c2000) [ 2.237148] Write protecting the kernel read-only data: 8192k [ 2.237862] Freeing unused kernel memory: 1904K (ffff880001424000 - ffff880001600000) [ 2.238527] Freeing unused kernel memory: 192K (ffff8800017d0000 - ffff880001800000) [ 2.256232] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0 [ 2.313560] random: systemd-udevd urandom read with 6 bits of entropy available [ 2.338754] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1 [ 2.338759] ACPI: Power Button [PWRB] [ 2.338829] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 [ 2.338831] ACPI: Power Button [PWRF] [ 2.344691] SCSI subsystem initialized [ 2.344893] ACPI: bus type USB registered [ 2.344935] usbcore: registered new interface driver usbfs [ 2.344948] usbcore: registered new interface driver hub [ 2.344995] usbcore: registered new device driver usb [ 2.345029] [drm] Initialized drm 1.1.0 20060810 [ 2.345380] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 2.345729] ehci-pci: EHCI PCI platform driver [ 2.345864] QUIRK: Enable AMD PLL fix [ 2.345882] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 2.345892] ehci-pci 0000:00:12.2: EHCI Host Controller [ 2.345903] ehci-pci 0000:00:12.2: new USB bus registered, assigned bus number 1 [ 2.345909] ehci-pci 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround [ 2.345918] ehci-pci 0000:00:12.2: debug port 1 [ 2.345952] ehci-pci 0000:00:12.2: irq 17, io mem 0xfe8ff800 [ 2.347432] libata version 3.00 loaded. [ 2.348014] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [ 2.348637] r8169 0000:05:00.0 eth0: RTL8168evl/8111evl at 0xffffc9000356c000, 54:04:a6:82:21:00, XID 0c900800 IRQ 28 [ 2.348639] r8169 0000:05:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko] [ 2.352516] [drm] radeon kernel modesetting enabled. [ 2.353589] CRAT table not found [ 2.353592] Finished initializing topology ret=0 [ 2.353659] kfd kfd: Initialized module [ 2.354183] [drm] initializing kernel modesetting (CEDAR 0x1002:0x68F9 0x174B:0x2127). [ 2.354192] [drm] register mmio base: 0xFE9E0000 [ 2.354194] [drm] register mmio size: 131072 [ 2.354950] ehci-pci 0000:00:12.2: USB 2.0 started, EHCI 1.00 [ 2.354989] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 2.354991] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.354993] usb usb1: Product: EHCI Host Controller [ 2.354994] usb usb1: Manufacturer: Linux 4.5.1-zgws1 ehci_hcd [ 2.354995] usb usb1: SerialNumber: 0000:00:12.2 [ 2.355159] hub 1-0:1.0: USB hub found [ 2.355168] hub 1-0:1.0: 5 ports detected [ 2.355336] xhci_hcd 0000:02:00.0: xHCI Host Controller [ 2.355347] xhci_hcd 0000:02:00.0: new USB bus registered, assigned bus number 2 [ 2.358601] ATOM BIOS: CEDAR [ 2.358699] radeon 0000:01:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used) [ 2.358701] radeon 0000:01:00.0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF [ 2.358702] [drm] Detected VRAM RAM=1024M, BAR=256M [ 2.358703] [drm] RAM width 64bits DDR [ 2.358764] [TTM] Zone kernel: Available graphics memory: 12348480 kiB [ 2.358765] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [ 2.358766] [TTM] Initializing pool allocator [ 2.358771] [TTM] Initializing DMA pool allocator [ 2.358789] [drm] radeon: 1024M of VRAM memory ready [ 2.358791] [drm] radeon: 1024M of GTT memory ready. [ 2.358801] [drm] Loading CEDAR Microcode [ 2.358881] [drm] Internal thermal controller with fan control [ 2.364998] xhci_hcd 0000:02:00.0: hcc params 0x0200f180 hci version 0x96 quirks 0x00080000 [ 2.365254] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [ 2.365256] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.365258] usb usb2: Product: xHCI Host Controller [ 2.365259] usb usb2: Manufacturer: Linux 4.5.1-zgws1 xhci-hcd [ 2.365260] usb usb2: SerialNumber: 0000:02:00.0 [ 2.365416] hub 2-0:1.0: USB hub found [ 2.365426] hub 2-0:1.0: 2 ports detected [ 2.365543] xhci_hcd 0000:02:00.0: xHCI Host Controller [ 2.365547] xhci_hcd 0000:02:00.0: new USB bus registered, assigned bus number 3 [ 2.365560] ehci-pci 0000:00:13.2: EHCI Host Controller [ 2.365569] usb usb3: We don't know the algorithms for LPM for this host, disabling LPM. [ 2.365588] usb usb3: New USB device found, idVendor=1d6b, idProduct=0003 [ 2.365590] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.365591] usb usb3: Product: xHCI Host Controller [ 2.365592] usb usb3: Manufacturer: Linux 4.5.1-zgws1 xhci-hcd [ 2.365594] usb usb3: SerialNumber: 0000:02:00.0 [ 2.365713] hub 3-0:1.0: USB hub found [ 2.365721] hub 3-0:1.0: 2 ports detected [ 2.365827] ehci-pci 0000:00:13.2: new USB bus registered, assigned bus number 4 [ 2.365832] ehci-pci 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround [ 2.365846] ehci-pci 0000:00:13.2: debug port 1 [ 2.365891] ehci-pci 0000:00:13.2: irq 17, io mem 0xfe8ff400 [ 2.374907] ehci-pci 0000:00:13.2: USB 2.0 started, EHCI 1.00 [ 2.374940] usb usb4: New USB device found, idVendor=1d6b, idProduct=0002 [ 2.374942] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.374944] usb usb4: Product: EHCI Host Controller [ 2.374945] usb usb4: Manufacturer: Linux 4.5.1-zgws1 ehci_hcd [ 2.374946] usb usb4: SerialNumber: 0000:00:13.2 [ 2.375077] hub 4-0:1.0: USB hub found [ 2.375083] hub 4-0:1.0: 5 ports detected [ 2.375341] ehci-pci 0000:00:16.2: EHCI Host Controller [ 2.375346] ehci-pci 0000:00:16.2: new USB bus registered, assigned bus number 5 [ 2.375350] ehci-pci 0000:00:16.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround [ 2.375361] ehci-pci 0000:00:16.2: debug port 1 [ 2.375389] ehci-pci 0000:00:16.2: irq 17, io mem 0xfe8ff000 [ 2.386140] [drm] radeon: dpm initialized [ 2.386216] [drm] GART: num cpu pages 262144, num gpu pages 262144 [ 2.386898] ehci-pci 0000:00:16.2: USB 2.0 started, EHCI 1.00 [ 2.386932] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002 [ 2.386934] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.386936] usb usb5: Product: EHCI Host Controller [ 2.386937] usb usb5: Manufacturer: Linux 4.5.1-zgws1 ehci_hcd [ 2.386939] usb usb5: SerialNumber: 0000:00:16.2 [ 2.387077] hub 5-0:1.0: USB hub found [ 2.387083] hub 5-0:1.0: 4 ports detected [ 2.387250] ahci 0000:00:11.0: version 3.0 [ 2.387423] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 2.387490] ahci 0000:00:11.0: AHCI 0001.0200 32 slots 6 ports 6 Gbps 0x3f impl SATA mode [ 2.387493] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part [ 2.387521] ohci-pci: OHCI PCI platform driver [ 2.388386] scsi host0: ahci [ 2.388530] scsi host1: ahci [ 2.388668] scsi host2: ahci [ 2.388835] scsi host3: ahci [ 2.388968] scsi host4: ahci [ 2.389101] scsi host5: ahci [ 2.389164] ata1: SATA max UDMA/133 abar m1024@0xfe8ffc00 port 0xfe8ffd00 irq 19 [ 2.389167] ata2: SATA max UDMA/133 abar m1024@0xfe8ffc00 port 0xfe8ffd80 irq 19 [ 2.389169] ata3: SATA max UDMA/133 abar m1024@0xfe8ffc00 port 0xfe8ffe00 irq 19 [ 2.389172] ata4: SATA max UDMA/133 abar m1024@0xfe8ffc00 port 0xfe8ffe80 irq 19 [ 2.389176] ata5: SATA max UDMA/133 abar m1024@0xfe8ffc00 port 0xfe8fff00 irq 19 [ 2.389178] ata6: SATA max UDMA/133 abar m1024@0xfe8ffc00 port 0xfe8fff80 irq 19 [ 2.389290] ohci-pci 0000:00:12.0: OHCI PCI host controller [ 2.389297] ohci-pci 0000:00:12.0: new USB bus registered, assigned bus number 6 [ 2.389329] ohci-pci 0000:00:12.0: irq 18, io mem 0xfe8fe000 [ 2.403847] [drm] PCIE GART of 1024M enabled (table at 0x000000000025E000). [ 2.403929] radeon 0000:01:00.0: WB enabled [ 2.403931] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff880613092c00 [ 2.403933] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff880613092c0c [ 2.404698] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x000000000005c418 and cpu addr 0xffffc9000381c418 [ 2.404700] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 2.404701] [drm] Driver supports precise vblank timestamp query. [ 2.404702] radeon 0000:01:00.0: radeon: MSI limited to 32-bit [ 2.404725] radeon 0000:01:00.0: radeon: using MSI. [ 2.404751] [drm] radeon: irq initialized. [ 2.420864] [drm] ring test on 0 succeeded in 1 usecs [ 2.420869] [drm] ring test on 3 succeeded in 2 usecs [ 2.446941] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001 [ 2.446943] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.446945] usb usb6: Product: OHCI PCI host controller [ 2.446947] usb usb6: Manufacturer: Linux 4.5.1-zgws1 ohci_hcd [ 2.446948] usb usb6: SerialNumber: 0000:00:12.0 [ 2.447081] hub 6-0:1.0: USB hub found [ 2.447089] hub 6-0:1.0: 5 ports detected [ 2.447308] ohci-pci 0000:00:13.0: OHCI PCI host controller [ 2.447313] ohci-pci 0000:00:13.0: new USB bus registered, assigned bus number 7 [ 2.447334] ohci-pci 0000:00:13.0: irq 18, io mem 0xfe8fd000 [ 2.506934] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001 [ 2.506937] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.506938] usb usb7: Product: OHCI PCI host controller [ 2.506940] usb usb7: Manufacturer: Linux 4.5.1-zgws1 ohci_hcd [ 2.506941] usb usb7: SerialNumber: 0000:00:13.0 [ 2.507067] hub 7-0:1.0: USB hub found [ 2.507075] hub 7-0:1.0: 5 ports detected [ 2.507285] ohci-pci 0000:00:14.5: OHCI PCI host controller [ 2.507289] ohci-pci 0000:00:14.5: new USB bus registered, assigned bus number 8 [ 2.507309] ohci-pci 0000:00:14.5: irq 18, io mem 0xfe8fc000 [ 2.508633] sym0: <860> rev 0x2 at pci 0000:03:05.0 irq 20 [ 2.510783] sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking [ 2.510785] sym0: open drain IRQ line driver [ 2.510786] sym0: using LOAD/STORE-based firmware. [ 2.517070] sym0: SCSI BUS has been reset. [ 2.517086] scsi host6: sym-2.2.3 [ 2.566939] usb usb8: New USB device found, idVendor=1d6b, idProduct=0001 [ 2.566942] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.566944] usb usb8: Product: OHCI PCI host controller [ 2.566945] usb usb8: Manufacturer: Linux 4.5.1-zgws1 ohci_hcd [ 2.566946] usb usb8: SerialNumber: 0000:00:14.5 [ 2.567077] hub 8-0:1.0: USB hub found [ 2.567085] hub 8-0:1.0: 2 ports detected [ 2.567252] ohci-pci 0000:00:16.0: OHCI PCI host controller [ 2.567257] ohci-pci 0000:00:16.0: new USB bus registered, assigned bus number 9 [ 2.567276] ohci-pci 0000:00:16.0: irq 18, io mem 0xfe8f3000 [ 2.606579] [drm] ring test on 5 succeeded in 1 usecs [ 2.606585] [drm] UVD initialized successfully. [ 2.606704] [drm] ib test on ring 0 succeeded in 0 usecs [ 2.606731] [drm] ib test on ring 3 succeeded in 0 usecs [ 2.626945] usb usb9: New USB device found, idVendor=1d6b, idProduct=0001 [ 2.626948] usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.626949] usb usb9: Product: OHCI PCI host controller [ 2.626950] usb usb9: Manufacturer: Linux 4.5.1-zgws1 ohci_hcd [ 2.626952] usb usb9: SerialNumber: 0000:00:16.0 [ 2.627084] hub 9-0:1.0: USB hub found [ 2.627092] hub 9-0:1.0: 4 ports detected [ 2.690917] usb 4-1: new high-speed USB device number 2 using ehci-pci [ 2.697724] ata1: SATA link down (SStatus 0 SControl 300) [ 2.697775] ata2: SATA link down (SStatus 0 SControl 300) [ 2.701530] ata4: SATA link down (SStatus 0 SControl 300) [ 2.823243] usb 4-1: New USB device found, idVendor=0409, idProduct=005a [ 2.823246] usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 2.823603] hub 4-1:1.0: USB hub found [ 2.823745] hub 4-1:1.0: 4 ports detected [ 2.854954] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 2.854979] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 2.855003] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 2.855858] ata6.00: ATA-8: ST4000DM000-1F2168, CC51, max UDMA/133 [ 2.855860] ata6.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA [ 2.856794] ata6.00: configured for UDMA/133 [ 2.856852] ata5.00: supports DRM functions and may not be fully accessible [ 2.856919] ata5.00: READ LOG DMA EXT failed, trying unqueued [ 2.856956] ata5.00: failed to get NCQ Send/Recv Log Emask 0x1 [ 2.856958] ata5.00: ATA-9: Samsung SSD 840 EVO 1TB, EXT0CB6Q, max UDMA/133 [ 2.856959] ata5.00: 1953525168 sectors, multi 1: LBA48 NCQ (depth 31/32), AA [ 2.857130] ata5.00: supports DRM functions and may not be fully accessible [ 2.857197] ata5.00: failed to get NCQ Send/Recv Log Emask 0x1 [ 2.857199] ata5.00: configured for UDMA/133 [ 2.857470] ata3.00: ATAPI: ATAPI iHAS124 B, AL0Q, max UDMA/100 [ 2.858288] ata3.00: configured for UDMA/100 [ 2.861965] scsi 2:0:0:0: CD-ROM ATAPI iHAS124 B AL0Q PQ: 0 ANSI: 5 [ 2.867883] scsi 4:0:0:0: Direct-Access ATA Samsung SSD 840 CB6Q PQ: 0 ANSI: 5 [ 2.899275] scsi 5:0:0:0: Direct-Access ATA ST4000DM000-1F21 CC51 PQ: 0 ANSI: 5 [ 2.925272] sd 4:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) [ 2.925277] sd 5:0:0:0: [sdb] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB) [ 2.925280] sd 5:0:0:0: [sdb] 4096-byte physical blocks [ 2.925395] sd 5:0:0:0: [sdb] Write Protect is off [ 2.925399] sd 5:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 2.925424] sd 4:0:0:0: [sda] Write Protect is off [ 2.925428] sd 4:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 2.925456] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.925472] sd 4:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.934953] usb 4-4: new high-speed USB device number 3 using ehci-pci [ 2.939838] sr 2:0:0:0: [sr0] scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray [ 2.939841] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 2.940014] sr 2:0:0:0: Attached scsi CD-ROM sr0 [ 3.070984] usb 4-4: New USB device found, idVendor=05e3, idProduct=0716 [ 3.070987] usb 4-4: New USB device strings: Mfr=0, Product=1, SerialNumber=2 [ 3.070988] usb 4-4: Product: USB Storage [ 3.070989] usb 4-4: SerialNumber: 000000009744 [ 3.072826] usb-storage 4-4:1.0: USB Mass Storage device detected [ 3.073001] scsi host7: usb-storage 4-4:1.0 [ 3.073082] usbcore: registered new interface driver usb-storage [ 3.100032] sdb: sdb1 sdb2 sdb3 [ 3.100516] sd 5:0:0:0: [sdb] Attached SCSI disk [ 3.154940] usb 4-1.2: new high-speed USB device number 4 using ehci-pci [ 3.206945] tsc: Refined TSC clocksource calibration: 3214.363 MHz [ 3.206949] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2e554a52bb8, max_idle_ns: 440795344034 ns [ 3.248497] usb 4-1.2: New USB device found, idVendor=05e3, idProduct=0608 [ 3.248500] usb 4-1.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 3.248501] usb 4-1.2: Product: USB2.0 Hub [ 3.248868] hub 4-1.2:1.0: USB hub found [ 3.249220] hub 4-1.2:1.0: 4 ports detected [ 3.274994] [drm] ib test on ring 5 succeeded [ 3.275582] [drm] Radeon Display Connectors [ 3.275584] [drm] Connector 0: [ 3.275585] [drm] DVI-I-1 [ 3.275586] [drm] HPD2 [ 3.275587] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [ 3.275588] [drm] Encoders: [ 3.275589] [drm] DFP1: INTERNAL_UNIPHY1 [ 3.275590] [drm] CRT2: INTERNAL_KLDSCP_DAC2 [ 3.275591] [drm] Connector 1: [ 3.275592] [drm] DVI-I-2 [ 3.275592] [drm] HPD4 [ 3.275594] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [ 3.275594] [drm] Encoders: [ 3.275595] [drm] DFP2: INTERNAL_UNIPHY [ 3.275596] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 3.352219] [drm] fb mappable at 0xD045F000 [ 3.352220] [drm] vram apper at 0xD0000000 [ 3.352221] [drm] size 7680000 [ 3.352222] [drm] fb depth is 24 [ 3.352223] [drm] pitch is 6400 [ 3.352295] fbcon: radeondrmfb (fb0) is primary device [ 3.384305] usb 4-1.3: new full-speed USB device number 5 using ehci-pci [ 3.423975] Console: switching to colour frame buffer device 200x75 [ 3.428928] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device [ 3.442997] [drm] Initialized radeon 2.43.0 20080528 for 0000:01:00.0 on minor 0 [ 3.510559] usb 4-1.3: New USB device found, idVendor=046d, idProduct=c52b [ 3.510561] usb 4-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 3.510562] usb 4-1.3: Product: USB Receiver [ 3.510564] usb 4-1.3: Manufacturer: Logitech [ 3.512504] hidraw: raw HID events driver (C) Jiri Kosina [ 3.517869] usbcore: registered new interface driver usbhid [ 3.517871] usbhid: USB HID core driver [ 3.518501] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1.3/4-1.3:1.0/0003:046D:C52B.0001/input/input3 [ 3.571036] hid-generic 0003:046D:C52B.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:00:13.2-1.3/input0 [ 3.571317] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1.3/4-1.3:1.1/0003:046D:C52B.0002/input/input4 [ 3.578962] usb 4-1.2.1: new high-speed USB device number 6 using ehci-pci [ 3.627103] hid-generic 0003:046D:C52B.0002: input,hiddev0,hidraw1: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:13.2-1.3/input1 [ 3.628660] hid-generic 0003:046D:C52B.0003: hiddev0,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:13.2-1.3/input2 [ 3.673292] usb 4-1.2.1: New USB device found, idVendor=0000, idProduct=0000 [ 3.673294] usb 4-1.2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 3.673296] usb 4-1.2.1: Product: USB [ 3.673297] usb 4-1.2.1: Manufacturer: SMI Corporation [ 3.673298] usb 4-1.2.1: SerialNumber: AA6271010J3000004068 [ 3.673566] usb-storage 4-1.2.1:1.0: USB Mass Storage device detected [ 3.673732] scsi host8: usb-storage 4-1.2.1:1.0 [ 3.742959] usb 4-1.2.2: new high-speed USB device number 7 using ehci-pci [ 3.839815] usb 4-1.2.2: New USB device found, idVendor=05e3, idProduct=0723 [ 3.839817] usb 4-1.2.2: New USB device strings: Mfr=3, Product=4, SerialNumber=2 [ 3.839819] usb 4-1.2.2: Product: USB Storage [ 3.839820] usb 4-1.2.2: Manufacturer: Generic [ 3.839821] usb 4-1.2.2: SerialNumber: 000000009454 [ 3.840445] usb-storage 4-1.2.2:1.0: USB Mass Storage device detected [ 3.840611] scsi host9: usb-storage 4-1.2.2:1.0 [ 3.880603] sda: sda1 sda2 sda3 [ 3.881197] sd 4:0:0:0: [sda] Attached SCSI disk [ 4.072267] scsi 7:0:0:0: Direct-Access Generic STORAGE DEVICE 9744 PQ: 0 ANSI: 0 [ 4.073764] scsi 7:0:0:1: Direct-Access Generic STORAGE DEVICE 9744 PQ: 0 ANSI: 0 [ 4.080672] sd 7:0:0:0: [sdc] Attached SCSI removable disk [ 4.082515] sd 7:0:0:1: [sdd] Attached SCSI removable disk [ 4.207068] clocksource: Switched to clocksource tsc [ 4.671955] scsi 8:0:0:0: Direct-Access ST 4GB 0000 PQ: 0 ANSI: 0 CCS [ 4.672683] sd 8:0:0:0: [sde] 7831552 512-byte logical blocks: (4.01 GB/3.73 GiB) [ 4.673445] sd 8:0:0:0: [sde] Write Protect is off [ 4.673448] sd 8:0:0:0: [sde] Mode Sense: 43 00 00 00 [ 4.674195] sd 8:0:0:0: [sde] No Caching mode page found [ 4.674223] sd 8:0:0:0: [sde] Assuming drive cache: write through [ 4.677950] sde: sde1 [ 4.680480] sd 8:0:0:0: [sde] Attached SCSI removable disk [ 4.840809] scsi 9:0:0:0: Direct-Access Generic STORAGE DEVICE 9454 PQ: 0 ANSI: 0 [ 4.842331] sd 9:0:0:0: [sdf] Attached SCSI removable disk [ 7.573035] microcode: CPU0: new patch_level=0x010000dc [ 7.573054] microcode: CPU1: new patch_level=0x010000dc [ 7.573059] microcode: CPU2: new patch_level=0x010000dc [ 7.573084] microcode: CPU3: new patch_level=0x010000dc [ 7.573099] microcode: CPU4: new patch_level=0x010000dc [ 7.573113] microcode: CPU5: new patch_level=0x010000dc [ 8.379162] device-mapper: uevent: version 1.0.3 [ 8.379241] device-mapper: ioctl: 4.34.0-ioctl (2015-10-28) initialised: dm-devel@redhat.com [ 8.496427] random: nonblocking pool is initialized [ 13.872845] NET: Registered protocol family 38 [ 14.001631] EXT4-fs (dm-17): couldn't mount as ext3 due to feature incompatibilities [ 14.018280] EXT4-fs (dm-17): mounted filesystem with ordered data mode. Opts: (null) [ 16.395318] raid6: sse2x1 gen() 4661 MB/s [ 16.463287] raid6: sse2x1 xor() 4670 MB/s [ 16.531310] raid6: sse2x2 gen() 7458 MB/s [ 16.599282] raid6: sse2x2 xor() 7962 MB/s [ 16.667322] raid6: sse2x4 gen() 8376 MB/s [ 16.735321] raid6: sse2x4 xor() 3954 MB/s [ 16.735323] raid6: using algorithm sse2x4 gen() 8376 MB/s [ 16.735324] raid6: .... xor() 3954 MB/s, rmw enabled [ 16.735325] raid6: using intx1 recovery algorithm [ 16.735542] xor: measuring software checksum speed [ 16.775298] prefetch64-sse: 13798.000 MB/sec [ 16.815319] generic_sse: 13291.000 MB/sec [ 16.815324] xor: using function: prefetch64-sse (13798.000 MB/sec) [ 16.860649] Btrfs loaded [ 17.029325] BTRFS: device fsid 83529235-e16d-4ce6-ac1e-1f893b0fa421 devid 1 transid 7 /dev/mapper/fan_r-scratch [ 17.089934] EXT4-fs (dm-17): mounted filesystem with ordered data mode. Opts: (null) [ 17.443170] systemd[1]: systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN) [ 17.443377] systemd[1]: Detected architecture x86-64. [ 17.443601] systemd[1]: Set hostname to <fan>. [ 17.655400] systemd[1]: Listening on Journal Socket. [ 17.655576] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. [ 17.655607] systemd[1]: Listening on udev Control Socket. [ 17.655633] systemd[1]: Listening on Device-mapper event daemon FIFOs. [ 17.655657] systemd[1]: Listening on LVM2 poll daemon socket. [ 17.655689] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe. [ 17.655697] systemd[1]: Reached target Remote File Systems (Pre). [ 17.655727] systemd[1]: Started Forward Password Requests to Wall Directory Watch. [ 17.655845] systemd[1]: Created slice User and Session Slice. [ 17.655897] systemd[1]: Listening on Network Service Netlink Socket. [ 17.655914] systemd[1]: Listening on fsck to fsckd communication Socket. [ 17.655932] systemd[1]: Listening on LVM2 metadata daemon socket. [ 17.655949] systemd[1]: Listening on udev Kernel Socket. [ 17.655970] systemd[1]: Listening on Journal Socket (/dev/log). [ 17.659485] systemd[1]: Listening on Syslog Socket. [ 17.659503] systemd[1]: Reached target Remote File Systems. [ 17.659618] systemd[1]: Created slice System Slice. [ 17.683435] systemd[1]: Mounting Huge Pages File System... [ 17.683975] systemd[1]: Starting LSB: Create aliases for SCSI devices under /dev/scsi... [ 17.684607] systemd[1]: Starting Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling... [ 17.702358] systemd[1]: Starting Create list of required static device nodes for the current kernel... [ 17.737587] systemd[1]: Starting Load Kernel Modules... [ 17.737742] systemd[1]: Created slice system-serial\x2dgetty.slice. [ 17.738343] systemd[1]: Mounting Debug File System... [ 17.738895] systemd[1]: Starting crypto devices that need a key script... [ 17.739475] systemd[1]: Starting Set the console keyboard layout... [ 17.739644] systemd[1]: Created slice system-systemd\x2dfsck.slice. [ 17.739662] systemd[1]: Reached target Slices. [ 17.740250] systemd[1]: Mounting POSIX Message Queue File System... [ 17.740418] systemd[1]: Created slice system-systemd\x2dcryptsetup.slice. [ 17.741983] systemd[1]: Started Create list of required static device nodes for the current kernel. [ 17.756760] systemd[1]: Starting Create Static Device Nodes in /dev... [ 17.776867] systemd[1]: Started Load Kernel Modules. [ 17.803545] systemd[1]: Starting Apply Kernel Variables... [ 17.804443] systemd[1]: Mounted Debug File System. [ 17.804506] systemd[1]: Mounted Huge Pages File System. [ 17.804547] systemd[1]: Mounted POSIX Message Queue File System. [ 17.835775] systemd[1]: Started LSB: Create aliases for SCSI devices under /dev/scsi. [ 17.836019] systemd[1]: Started Apply Kernel Variables. [ 17.836718] systemd[1]: Starting Remount Root and Kernel File Systems... [ 17.843020] systemd[1]: Started LVM2 metadata daemon. [ 17.846318] EXT4-fs (dm-17): re-mounted. Opts: (null) [ 17.846927] systemd[1]: Started Remount Root and Kernel File Systems. [ 17.847545] systemd[1]: Starting Load/Save Random Seed... [ 17.848029] systemd[1]: Starting LSB: Create aliases for SCSI devices under /dev/scsi... [ 17.853091] systemd[1]: Starting udev Coldplug all Devices... [ 17.853593] systemd[1]: Started LSB: Create aliases for SCSI devices under /dev/scsi. [ 17.862568] systemd[1]: Started Load/Save Random Seed. [ 17.867576] systemd[1]: Started Create Static Device Nodes in /dev. [ 17.871230] systemd[1]: Starting udev Kernel Device Manager... [ 17.919394] systemd[1]: Started udev Kernel Device Manager. [ 17.920459] systemd[1]: Started udev Coldplug all Devices. [ 17.973232] ACPI: processor limited to max C-state 1 [ 18.009535] ATK0110 ATK0110:00: EC enabled [ 18.061767] ACPI Warning: SystemIO range 0x0000000000000B00-0x0000000000000B07 conflicts with OpRegion 0x0000000000000B00-0x0000000000000B0F (\SOR1) (20160108/utaddress-255) [ 18.061774] ACPI Warning: SystemIO range 0x0000000000000B00-0x0000000000000B07 conflicts with OpRegion 0x0000000000000B00-0x0000000000000B2F (\_SB.PCI0.SBRG.ASOC.SMRG) (20160108/utaddress-255) [ 18.061778] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 18.067032] acpi-cpufreq: overriding BIOS provided _PSD data [ 18.067824] sr 2:0:0:0: Attached scsi generic sg0 type 5 [ 18.067866] sd 4:0:0:0: Attached scsi generic sg1 type 0 [ 18.067897] sd 5:0:0:0: Attached scsi generic sg2 type 0 [ 18.067961] sd 7:0:0:0: Attached scsi generic sg3 type 0 [ 18.068003] sd 7:0:0:1: Attached scsi generic sg4 type 0 [ 18.068042] sd 8:0:0:0: Attached scsi generic sg5 type 0 [ 18.068078] sd 9:0:0:0: Attached scsi generic sg6 type 0 [ 18.077043] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 18.113810] systemd[1]: Found device /dev/ttyS0. [ 18.126676] input: PC Speaker as /devices/platform/pcspkr/input/input5 [ 18.140181] EDAC MC: Ver: 3.0.0 [ 18.149300] MCE: In-kernel MCE decoding enabled. [ 18.155005] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client [ 18.160916] AMD64 EDAC driver v3.4.0 [ 18.160940] EDAC amd64: DRAM ECC enabled. [ 18.160947] EDAC amd64: F10h detected (node 0). [ 18.160960] EDAC MC: DCT0 chip selects: [ 18.160962] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 18.160963] EDAC amd64: MC: 2: 4096MB 3: 4096MB [ 18.160964] EDAC amd64: MC: 4: 0MB 5: 0MB [ 18.160965] EDAC amd64: MC: 6: 0MB 7: 0MB [ 18.160966] EDAC MC: DCT1 chip selects: [ 18.160967] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 18.160969] EDAC amd64: MC: 2: 4096MB 3: 4096MB [ 18.160970] EDAC amd64: MC: 4: 0MB 5: 0MB [ 18.160971] EDAC amd64: MC: 6: 0MB 7: 0MB [ 18.160972] EDAC amd64: using x4 syndromes. [ 18.160973] EDAC amd64: MCT channel count: 2 [ 18.161162] EDAC MC0: Giving out device to module amd64_edac controller F10h: DEV 0000:00:18.2 (INTERRUPT) [ 18.161192] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.2 (POLLED) [ 18.163272] kvm: Nested Virtualization enabled [ 18.163278] kvm: Nested Paging enabled [ 18.164760] input: HDA ATI HDMI HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:02.0/0000:01:00.1/sound/card1/input6 [ 18.171184] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC892: line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line [ 18.171187] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 18.171190] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) [ 18.171191] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 [ 18.171193] snd_hda_codec_realtek hdaudioC0D0: dig-out=0x11/0x1e [ 18.171194] snd_hda_codec_realtek hdaudioC0D0: inputs: [ 18.171196] snd_hda_codec_realtek hdaudioC0D0: Front Mic=0x19 [ 18.171198] snd_hda_codec_realtek hdaudioC0D0: Rear Mic=0x18 [ 18.171199] snd_hda_codec_realtek hdaudioC0D0: Line=0x1a [ 18.188918] input: HDA ATI SB Front Mic as /devices/pci0000:00/0000:00:14.2/sound/card0/input7 [ 18.189126] input: HDA ATI SB Rear Mic as /devices/pci0000:00/0000:00:14.2/sound/card0/input8 [ 18.189225] input: HDA ATI SB Line as /devices/pci0000:00/0000:00:14.2/sound/card0/input9 [ 18.189344] input: HDA ATI SB Line Out Front as /devices/pci0000:00/0000:00:14.2/sound/card0/input10 [ 18.189420] input: HDA ATI SB Line Out Surround as /devices/pci0000:00/0000:00:14.2/sound/card0/input11 [ 18.189502] input: HDA ATI SB Line Out CLFE as /devices/pci0000:00/0000:00:14.2/sound/card0/input12 [ 18.189587] input: HDA ATI SB Line Out Side as /devices/pci0000:00/0000:00:14.2/sound/card0/input13 [ 18.189681] input: HDA ATI SB Front Headphone as /devices/pci0000:00/0000:00:14.2/sound/card0/input14 [ 18.199487] systemd[1]: Started Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling. [ 18.222203] systemd[1]: dev-disk-by\x2dpartlabel-EFI\x5cx20System.device: Dev dev-disk-by\x2dpartlabel-EFI\x5cx20System.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:11.0/ata6/host5/target5:0:0/5:0:0:0/block/sdb/sdb1 and /sys/devices/pci0000:00/0000:00:11.0/ata5/host4/target4:0:0/4:0:0:0/block/sda/sda1 [ 18.244438] systemd[1]: Found device /dev/disk/by-id/dm-name-fan-c_root. [ 18.271622] systemd[1]: Starting Cryptography Setup for root... [ 18.274440] systemd[1]: dev-disk-by\x2dpartlabel-BIOS\x5cx20boot\x5cx20partition.device: Dev dev-disk-by\x2dpartlabel-BIOS\x5cx20boot\x5cx20partition.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:11.0/ata6/host5/target5:0:0/5:0:0:0/block/sdb/sdb2 and /sys/devices/pci0000:00/0000:00:11.0/ata5/host4/target4:0:0/4:0:0:0/block/sda/sda2 [ 18.285458] systemd[1]: Started Cryptography Setup for root. [ 18.307196] systemd[1]: Reached target Sound Card. [ 19.021709] systemd[1]: Started Set the console keyboard layout. [ 19.047706] systemd[1]: Starting Show Plymouth Boot Screen... [ 19.047777] systemd[1]: Reached target Local File Systems (Pre). [ 19.047985] systemd[1]: tmp.mount: Directory /tmp to mount over is not empty, mounting anyway. [ 19.049669] systemd[1]: Mounting /tmp... [ 19.055793] systemd[1]: Mounted /tmp. [ 19.061741] systemd[1]: Reached target Local File Systems. [ 19.062448] systemd[1]: Starting LSB: ebtables ruleset management... [ 19.063277] systemd[1]: Starting Set console font and keymap... [ 19.064027] systemd[1]: Starting Tell Plymouth To Write Out Runtime Data... [ 19.076171] systemd[1]: Started Entropy daemon using the HAVEGE algorithm. [ 19.077032] systemd[1]: Starting Journal Service... [ 19.077971] systemd[1]: Started Set console font and keymap. [ 19.096972] systemd[1]: Created slice system-getty.slice. [ 19.113024] systemd[1]: Started Tell Plymouth To Write Out Runtime Data. [ 19.113562] systemd[1]: Started Show Plymouth Boot Screen. [ 19.113826] systemd[1]: Started Forward Password Requests to Plymouth Directory Watch. [ 19.114571] systemd[1]: Started LSB: ebtables ruleset management. [ 19.154931] systemd[1]: Started Journal Service. [ 19.192438] systemd-journald[908]: Received request to flush runtime journal from PID 1 [ 20.539705] Adding 26212348k swap on /dev/mapper/swap0. Priority:-1 extents:1 across:26212348k SS [ 21.824978] EXT4-fs (dm-19): mounted filesystem with ordered data mode. Opts: (null) [ 24.118708] BTRFS: device label fanbtr_r devid 1 transid 58271 /dev/dm-20 [ 35.986382] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this. [ 35.995294] IPv6: ADDRCONF(NETDEV_UP): br0: link is not ready [ 36.118145] r8169 0000:05:00.0 eth0: link down [ 36.118157] r8169 0000:05:00.0 eth0: link down [ 36.118282] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 36.157086] traps: atop[1931] trap divide error ip:4073c2 sp:7ffe87e6ca30 error:0 in atop[400000+26000] [ 36.572027] ip_tables: (C) 2000-2006 Netfilter Core Team [ 36.596597] nf_conntrack version 0.5.0 (65536 buckets, 262144 max) [ 37.721197] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 37.760463] Ebtables v2.0 registered [ 38.450305] r8169 0000:05:00.0 eth0: link up [ 38.450321] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 426.723240] device dummy0 entered promiscuous mode [ 426.723503] br0: port 1(dummy0) entered forwarding state [ 426.723555] br0: port 1(dummy0) entered forwarding state [ 426.723673] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready [ 441.743662] br0: port 1(dummy0) entered forwarding state [ 467.001241] tun: Universal TUN/TAP device driver, 1.6 [ 467.001246] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> [ 467.056963] device vnet0 entered promiscuous mode [ 467.072818] br0: port 2(vnet0) entered forwarding state [ 467.072870] br0: port 2(vnet0) entered forwarding state [ 470.139397] kvm: zapping shadow pages for mmio generation wraparound [ 470.140322] kvm: zapping shadow pages for mmio generation wraparound [ 475.887632] kvm [3824]: vcpu0, guest rIP: 0xffffffff81047122 unhandled rdmsr: 0x3a [ 475.887640] kvm [3824]: vcpu0, guest rIP: 0xffffffff81047122 unhandled rdmsr: 0xd90 [ 482.129007] br0: port 2(vnet0) entered forwarding state [ 878.782383] br0: port 2(vnet0) entered disabled state [ 878.782662] device vnet0 left promiscuous mode [ 878.782679] br0: port 2(vnet0) entered disabled state [ 891.092992] EXT4-fs (dm-22): mounted filesystem with ordered data mode. Opts: (null) [ 903.183041] EXT4-fs (dm-21): mounted filesystem with ordered data mode. Opts: (null) [ 1901.650787] SGI XFS with ACLs, security attributes, realtime, no debug enabled [ 1901.696398] ntfs: driver 2.1.32 [Flags: R/W MODULE]. [ 1901.725153] fuse init (API version 7.24) [ 1901.850748] EXT4-fs (sda1): VFS: Can't find ext4 filesystem [ 1901.854969] EXT4-fs (sda1): VFS: Can't find ext4 filesystem [ 1901.863947] EXT2-fs (sda1): error: can't find an ext2 filesystem on dev sda1. [ 1901.869046] XFS (sda1): Invalid superblock magic number [ 1901.871069] FAT-fs (sda1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 1901.871197] FAT-fs (sda1): bogus number of reserved sectors [ 1901.871200] FAT-fs (sda1): Can't find a valid FAT filesystem [ 1901.872747] FAT-fs (sda1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 1901.872874] FAT-fs (sda1): bogus number of reserved sectors [ 1901.872877] FAT-fs (sda1): Can't find a valid FAT filesystem [ 1901.921289] EXT4-fs (sda2): VFS: Can't find ext4 filesystem [ 1901.923726] EXT4-fs (sda2): VFS: Can't find ext4 filesystem [ 1901.927518] EXT2-fs (sda2): error: can't find an ext2 filesystem on dev sda2. [ 1901.930486] XFS (sda2): Invalid superblock magic number [ 1901.933162] FAT-fs (sda2): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 1901.933275] FAT-fs (sda2): bogus number of reserved sectors [ 1901.933281] FAT-fs (sda2): Can't find a valid FAT filesystem [ 1901.935517] FAT-fs (sda2): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 1901.935609] FAT-fs (sda2): bogus number of reserved sectors [ 1901.935613] FAT-fs (sda2): Can't find a valid FAT filesystem [ 1902.059713] EXT4-fs (sdb1): VFS: Can't find ext4 filesystem [ 1902.062842] EXT4-fs (sdb1): VFS: Can't find ext4 filesystem [ 1902.067076] EXT2-fs (sdb1): error: can't find an ext2 filesystem on dev sdb1. [ 1902.070001] XFS (sdb1): Invalid superblock magic number [ 1902.072658] FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 1902.072856] FAT-fs (sdb1): bogus number of reserved sectors [ 1902.072860] FAT-fs (sdb1): Can't find a valid FAT filesystem [ 1902.074567] FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 1902.074721] FAT-fs (sdb1): bogus number of reserved sectors [ 1902.074725] FAT-fs (sdb1): Can't find a valid FAT filesystem [ 1902.113249] EXT4-fs (sdb2): bad geometry: block count 976492246 exceeds size of device (256 blocks) [ 1903.066503] EXT4-fs (dm-16): VFS: Can't find ext4 filesystem [ 1903.069379] EXT4-fs (dm-16): VFS: Can't find ext4 filesystem [ 1903.077810] EXT2-fs (dm-16): error: can't find an ext2 filesystem on dev dm-16. [ 1903.080875] XFS (dm-16): Invalid superblock magic number [ 1903.082683] FAT-fs (dm-16): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 1903.082860] FAT-fs (dm-16): bogus number of reserved sectors [ 1903.082863] FAT-fs (dm-16): Can't find a valid FAT filesystem [ 1903.084050] FAT-fs (dm-16): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 1903.084261] FAT-fs (dm-16): bogus number of reserved sectors [ 1903.084266] FAT-fs (dm-16): Can't find a valid FAT filesystem [ 1927.125502] EXT4-fs (dm-19): mounted filesystem with ordered data mode. Opts: (null) [ 1927.224238] EXT4-fs (sde1): mounted filesystem with ordered data mode. Opts: (null) [ 1993.738680] EXT4-fs (sda1): VFS: Can't find ext4 filesystem [ 1993.742927] EXT4-fs (sda1): VFS: Can't find ext4 filesystem [ 1993.751610] EXT2-fs (sda1): error: can't find an ext2 filesystem on dev sda1. [ 1993.756747] XFS (sda1): Invalid superblock magic number [ 1993.759692] FAT-fs (sda1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 1993.759846] FAT-fs (sda1): bogus number of reserved sectors [ 1993.759851] FAT-fs (sda1): Can't find a valid FAT filesystem [ 1993.763688] FAT-fs (sda1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 1993.763877] FAT-fs (sda1): bogus number of reserved sectors [ 1993.763885] FAT-fs (sda1): Can't find a valid FAT filesystem [ 1993.840763] EXT4-fs (sda2): VFS: Can't find ext4 filesystem [ 1993.843181] EXT4-fs (sda2): VFS: Can't find ext4 filesystem [ 1993.851330] EXT2-fs (sda2): error: can't find an ext2 filesystem on dev sda2. [ 1993.863472] XFS (sda2): Invalid superblock magic number [ 1993.869396] FAT-fs (sda2): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 1993.869540] FAT-fs (sda2): bogus number of reserved sectors [ 1993.869548] FAT-fs (sda2): Can't find a valid FAT filesystem [ 1993.872471] FAT-fs (sda2): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 1993.872559] FAT-fs (sda2): bogus number of reserved sectors [ 1993.872562] FAT-fs (sda2): Can't find a valid FAT filesystem [ 1993.960102] EXT4-fs (sdb1): VFS: Can't find ext4 filesystem [ 1993.962499] EXT4-fs (sdb1): VFS: Can't find ext4 filesystem [ 1993.966707] EXT2-fs (sdb1): error: can't find an ext2 filesystem on dev sdb1. [ 1993.969430] XFS (sdb1): Invalid superblock magic number [ 1993.971076] FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 1993.971227] FAT-fs (sdb1): bogus number of reserved sectors [ 1993.971234] FAT-fs (sdb1): Can't find a valid FAT filesystem [ 1993.975310] FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 1993.975489] FAT-fs (sdb1): bogus number of reserved sectors [ 1993.975497] FAT-fs (sdb1): Can't find a valid FAT filesystem [ 1994.018593] EXT4-fs (sdb2): bad geometry: block count 976492246 exceeds size of device (256 blocks) [ 1994.546923] EXT4-fs (dm-16): VFS: Can't find ext4 filesystem [ 1994.551046] EXT4-fs (dm-16): VFS: Can't find ext4 filesystem [ 1994.557962] EXT2-fs (dm-16): error: can't find an ext2 filesystem on dev dm-16. [ 1994.561371] XFS (dm-16): Invalid superblock magic number [ 1994.565877] FAT-fs (dm-16): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 1994.566149] FAT-fs (dm-16): bogus number of reserved sectors [ 1994.566158] FAT-fs (dm-16): Can't find a valid FAT filesystem [ 1994.568813] FAT-fs (dm-16): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [ 1994.568994] FAT-fs (dm-16): bogus number of reserved sectors [ 1994.568998] FAT-fs (dm-16): Can't find a valid FAT filesystem [ 2017.276871] EXT4-fs (dm-19): mounted filesystem with ordered data mode. Opts: (null) ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-13 18:37 ` Marc Haber @ 2016-04-13 20:36 ` Paolo Bonzini 2016-04-13 20:52 ` Marc Haber 2016-04-13 22:29 ` Marc Haber 0 siblings, 2 replies; 49+ messages in thread From: Paolo Bonzini @ 2016-04-13 20:36 UTC (permalink / raw) To: Marc Haber; +Cc: Borislav Petkov, linux-kernel, kvm ML On 13/04/2016 20:37, Marc Haber wrote: > On Fri, Mar 18, 2016 at 11:01:46AM +0100, Paolo Bonzini wrote: >> On 17/03/2016 19:11, Borislav Petkov wrote: >>> I'm going to try reproducing the issue on a less "important" machine >>> so that bisecting is less painful, but maybe you guys have an idea >>> what's going wrong here. >> >> No idea, sorry. :( Bisecting would be great. > > Working on that now. > >> I'll also try reproducing and bisecting next week, in the meanwhile >> just having the host dmesg would help a lot. > > Attached. I hope the message will get through to the list. Didn't help, but a fresh look at the list of 4.5 patches helped. What the hell was I thinking, I missed write_rdtscp_aux who obviously uses MSR_TSC_AUX. diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index 31346a3f20a5..1481dea15844 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -39,6 +39,7 @@ #include <asm/kvm_para.h> #include <asm/virtext.h> +#include <asm/vgtod.h> #include "trace.h" #define __ex(x) __kvm_handle_fault_on_reboot(x) @@ -1240,9 +1241,6 @@ static void svm_vcpu_load(struct kvm_vcpu *vcpu, int cpu) wrmsrl(MSR_AMD64_TSC_RATIO, tsc_ratio); } } - /* This assumes that the kernel never uses MSR_TSC_AUX */ - if (static_cpu_has(X86_FEATURE_RDTSCP)) - wrmsrl(MSR_TSC_AUX, svm->tsc_aux); } static void svm_vcpu_put(struct kvm_vcpu *vcpu) @@ -3847,6 +3845,8 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu) svm->vmcb->save.cr2 = vcpu->arch.cr2; clgi(); + if (static_cpu_has(X86_FEATURE_RDTSCP)) + wrmsrl(MSR_TSC_AUX, svm->tsc_aux); local_irq_enable(); @@ -3923,6 +3923,8 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu) #endif ); + if (static_cpu_has(X86_FEATURE_RDTSCP)) + wrmsrl(MSR_TSC_AUX, __getcpu()); #ifdef CONFIG_X86_64 wrmsrl(MSR_GS_BASE, svm->host.gs_base); #else Paolo ^ permalink raw reply related [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-13 20:36 ` Paolo Bonzini @ 2016-04-13 20:52 ` Marc Haber 2016-04-13 22:29 ` Marc Haber 1 sibling, 0 replies; 49+ messages in thread From: Marc Haber @ 2016-04-13 20:52 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Borislav Petkov, linux-kernel, kvm ML On Wed, Apr 13, 2016 at 10:36:34PM +0200, Paolo Bonzini wrote: > Didn't help, but a fresh look at the list of 4.5 patches helped. > What the hell was I thinking, I missed write_rdtscp_aux who > obviously uses MSR_TSC_AUX. So you want me to apply that to 4.5 od 4.5.1 and try 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-13 20:36 ` Paolo Bonzini 2016-04-13 20:52 ` Marc Haber @ 2016-04-13 22:29 ` Marc Haber 2016-04-14 1:16 ` Paolo Bonzini 1 sibling, 1 reply; 49+ messages in thread From: Marc Haber @ 2016-04-13 22:29 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Borislav Petkov, linux-kernel, kvm ML On Wed, Apr 13, 2016 at 10:36:34PM +0200, Paolo Bonzini wrote: > Didn't help, but a fresh look at the list of 4.5 patches helped. > What the hell was I thinking, I missed write_rdtscp_aux who > obviously uses MSR_TSC_AUX. I applied this patch to 4.5, which didn't go cleanly, I had to do it manually, and there is no change in behavior. Sometimes, the Vm just crashes, but most times the filesystem is remounted ro. [ 84.658968] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #7669: comm aide: deleted inode referenced: 27903 [ 84.664877] Aborting journal on device dm-0-8. [ 84.667992] EXT4-fs (dm-0): Remounting filesystem read-only [ 84.670972] EXT4-fs error (device dm-0): ext4_journal_check_start:56: Detected aborted journal [ 84.763331] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #7669: comm aide: deleted inode referenced: 27898 [ 84.825412] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #7669: comm aide: deleted inode referenced: 27895 [ 84.907959] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #7669: comm aide: deleted inode referenced: 27893 [ 84.915187] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #7669: comm aide: deleted inode referenced: 27900 [ 84.961062] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #7669: comm aide: deleted inode referenced: 27889 [ 84.983700] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #7669: comm aide: deleted inode referenced: 27891 [ 98.315538] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #23567: comm aide: deleted inode referenced: 27897 [ 98.323606] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #23567: comm aide: deleted inode referenced: 27904 [ 99.889927] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #4650: comm aide: deleted inode referenced: 27892 [ 99.893823] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #4650: comm aide: deleted inode referenced: 27901 [ 99.901140] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #4650: comm aide: deleted inode referenced: 27890 [ 99.904898] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #4650: comm aide: deleted inode referenced: 27896 [ 99.909758] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #4650: comm aide: deleted inode referenced: 27899 [ 99.914394] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #4650: comm aide: deleted inode referenced: 27894 [ 207.132045] serial8250: too much work for irq4 [ 207.220043] serial8250: too much work for irq4 [ 207.312028] serial8250: too much work for irq4 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-13 22:29 ` Marc Haber @ 2016-04-14 1:16 ` Paolo Bonzini 2016-04-14 5:22 ` Marc Haber ` (2 more replies) 0 siblings, 3 replies; 49+ messages in thread From: Paolo Bonzini @ 2016-04-14 1:16 UTC (permalink / raw) To: Marc Haber; +Cc: Borislav Petkov, linux-kernel, kvm ML On 14/04/2016 00:29, Marc Haber wrote: > On Wed, Apr 13, 2016 at 10:36:34PM +0200, Paolo Bonzini wrote: >> Didn't help, but a fresh look at the list of 4.5 patches helped. >> What the hell was I thinking, I missed write_rdtscp_aux who >> obviously uses MSR_TSC_AUX. > > I applied this patch to 4.5, which didn't go cleanly, I had to do it > manually, and there is no change in behavior. Sometimes, the Vm just > crashes, but most times the filesystem is remounted ro. Ok, then I guess bisection is needed. Please first try commit 45bdbcfdf241. If it fails, then the bug come together with KVM's merge window changes for 4.5-rc1. Please apply the patch I sent here when bisection is past 46896c73c1a4dde527c3a3cc43379deeb41985a1 (which means that probably that should be the commit you try second; the bisection then becomes much easier). Thanks, Paolo > [ 84.658968] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #7669: comm aide: deleted inode referenced: 27903 > [ 84.664877] Aborting journal on device dm-0-8. > [ 84.667992] EXT4-fs (dm-0): Remounting filesystem read-only > [ 84.670972] EXT4-fs error (device dm-0): ext4_journal_check_start:56: Detected aborted journal > [ 84.763331] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #7669: comm aide: deleted inode referenced: 27898 > [ 84.825412] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #7669: comm aide: deleted inode referenced: 27895 > [ 84.907959] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #7669: comm aide: deleted inode referenced: 27893 > [ 84.915187] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #7669: comm aide: deleted inode referenced: 27900 > [ 84.961062] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #7669: comm aide: deleted inode referenced: 27889 > [ 84.983700] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #7669: comm aide: deleted inode referenced: 27891 > [ 98.315538] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #23567: comm aide: deleted inode referenced: 27897 > [ 98.323606] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #23567: comm aide: deleted inode referenced: 27904 > [ 99.889927] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #4650: comm aide: deleted inode referenced: 27892 > [ 99.893823] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #4650: comm aide: deleted inode referenced: 27901 > [ 99.901140] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #4650: comm aide: deleted inode referenced: 27890 > [ 99.904898] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #4650: comm aide: deleted inode referenced: 27896 > [ 99.909758] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #4650: comm aide: deleted inode referenced: 27899 > [ 99.914394] EXT4-fs error (device dm-0): ext4_lookup:1602: inode #4650: comm aide: deleted inode referenced: 27894 > [ 207.132045] serial8250: too much work for irq4 > [ 207.220043] serial8250: too much work for irq4 > [ 207.312028] serial8250: too much work for irq4 > > > Greetings > Marc > ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-14 1:16 ` Paolo Bonzini @ 2016-04-14 5:22 ` Marc Haber 2016-04-21 8:39 ` Marc Haber 2016-04-14 6:07 ` Marc Haber 2016-04-14 16:47 ` Marc Haber 2 siblings, 1 reply; 49+ messages in thread From: Marc Haber @ 2016-04-14 5:22 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Borislav Petkov, linux-kernel, kvm ML On Thu, Apr 14, 2016 at 03:16:29AM +0200, Paolo Bonzini wrote: > On 14/04/2016 00:29, Marc Haber wrote: > > On Wed, Apr 13, 2016 at 10:36:34PM +0200, Paolo Bonzini wrote: > >> Didn't help, but a fresh look at the list of 4.5 patches helped. > >> What the hell was I thinking, I missed write_rdtscp_aux who > >> obviously uses MSR_TSC_AUX. > > > > I applied this patch to 4.5, which didn't go cleanly, I had to do it > > manually, and there is no change in behavior. Sometimes, the Vm just > > crashes, but most times the filesystem is remounted ro. > > Ok, then I guess bisection is needed. Please first try commit > 45bdbcfdf241. If it fails, then the bug come together with KVM's merge > window changes for 4.5-rc1. Please apply the patch I sent here when > bisection is past 46896c73c1a4dde527c3a3cc43379deeb41985a1 (which means > that probably that should be the commit you try second; the bisection > then becomes much easier). I have never bisected this deeply. Can you please give more advice, with which two commits to start? And how do I find out whether I am "past" a commit? I am als not a git expert, a few command lines would be appreciated. Things have not become any easier this night; 4.5-rc7 ran for more than three hours before it failed :-( 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-14 5:22 ` Marc Haber @ 2016-04-21 8:39 ` Marc Haber 2016-04-21 12:37 ` Borislav Petkov 0 siblings, 1 reply; 49+ messages in thread From: Marc Haber @ 2016-04-21 8:39 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Borislav Petkov, linux-kernel, kvm ML On Thu, Apr 14, 2016 at 07:22:20AM +0200, Marc Haber wrote: > On Thu, Apr 14, 2016 at 03:16:29AM +0200, Paolo Bonzini wrote: > > On 14/04/2016 00:29, Marc Haber wrote: > > > On Wed, Apr 13, 2016 at 10:36:34PM +0200, Paolo Bonzini wrote: > > >> Didn't help, but a fresh look at the list of 4.5 patches helped. > > >> What the hell was I thinking, I missed write_rdtscp_aux who > > >> obviously uses MSR_TSC_AUX. > > > > > > I applied this patch to 4.5, which didn't go cleanly, I had to do it > > > manually, and there is no change in behavior. Sometimes, the Vm just > > > crashes, but most times the filesystem is remounted ro. > > > > Ok, then I guess bisection is needed. Please first try commit > > 45bdbcfdf241. If it fails, then the bug come together with KVM's merge > > window changes for 4.5-rc1. Please apply the patch I sent here when > > bisection is past 46896c73c1a4dde527c3a3cc43379deeb41985a1 (which means > > that probably that should be the commit you try second; the bisection > > then becomes much easier). > > I have never bisected this deeply. Can you please give more advice, > with which two commits to start? And how do I find out whether I am > "past" a commit? I am als not a git expert, a few command lines would > be appreciated. I have tried bisecting, and finally bisect says that the bad commit is 0e749e54244eec87b2a3cd0a4314e60bc6781115 dax: increase granularity of dax_clear_blocks() operations However, a kernel built after $ git checkout 0e749e54244eec87b2a3cd0a4314e60bc6781115 seems to be fine, at least my VM is running for 15 hours now. I guess I need to start over again with git bisect good 0e749e54244eec87b2a3cd0a4314e60bc6781115 and git bisect bad v4.5. Currently, I cannot explain how this has happened, I must have flagged an actually good kernel as bad from my understanding of git bisect. Can you give advice how to continue here? 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-21 8:39 ` Marc Haber @ 2016-04-21 12:37 ` Borislav Petkov 2016-04-21 14:50 ` Marc Haber 0 siblings, 1 reply; 49+ messages in thread From: Borislav Petkov @ 2016-04-21 12:37 UTC (permalink / raw) To: Marc Haber; +Cc: Paolo Bonzini, linux-kernel, kvm ML On Thu, Apr 21, 2016 at 10:39:48AM +0200, Marc Haber wrote: > Currently, I cannot explain how this has happened, I must have flagged > an actually good kernel as bad from my understanding of git bisect. > > Can you give advice how to continue here? Yap, sounds like you marked a bisection step incorrectly, which lead into the wrong direction. How reliable is your reproducer? Also, do the bisection as Paolo suggested: * try 45bdbcfdf241. * then do $ git bisect start v4.5-rc1 v4.4 which marks -rc1 as bad and 4.4 as good. While you're doing that bisect, do what Paolo said by applying the diff here https://lkml.kernel.org/r/570EADD2.8030300@redhat.com when the bisection point you're at at each step contains 46896c73c1a4 ("KVM: svm: add support for RDTSCP") You should apply the above hunk by doing $ patch -p1 --dry-run -i /tmp/hunk If it applies fine, you then apply it $ patch -p1 -i /tmp/hunk All clear? If not, do not hesitate to ask. Thanks -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-21 12:37 ` Borislav Petkov @ 2016-04-21 14:50 ` Marc Haber 2016-04-21 16:51 ` Borislav Petkov 0 siblings, 1 reply; 49+ messages in thread From: Marc Haber @ 2016-04-21 14:50 UTC (permalink / raw) To: Borislav Petkov; +Cc: Paolo Bonzini, linux-kernel, kvm ML On Thu, Apr 21, 2016 at 02:37:11PM +0200, Borislav Petkov wrote: > On Thu, Apr 21, 2016 at 10:39:48AM +0200, Marc Haber wrote: > > Currently, I cannot explain how this has happened, I must have flagged > > an actually good kernel as bad from my understanding of git bisect. > > > > Can you give advice how to continue here? > > Yap, sounds like you marked a bisection step incorrectly, which lead > into the wrong direction. How reliable is your reproducer? Usually, the crash or filesystem corruption happens in the first 15 to 30 minutes. I have had one instance running three hours before corrupting, I have therefore upped the run time to nine hours before saying "this kernel is good". What bothers me is that since I ended up with a "suspect" commit that actually results in a "good" kernel (running for 22 hours now), I must have said "bad" to an actually "good" kernel, which means that I had an unrelated crash or corruption. Is that reasoning correct? > Also, do the bisection as Paolo suggested: > > * try 45bdbcfdf241. That one qualified as "good" six days ago. I'll retry, maybe I just didn't wait long enough. "Trying" means make oldconfig, make deb-pkg in my case right? Does it matter what I answer to the numerous config questions that keep coming up during the oldconfig step? > * then do > > $ git bisect start v4.5-rc1 v4.4 > > which marks -rc1 as bad and 4.4 as good. Would it help to explicitly mark 0e749e54244eec87b2a3cd0a4314e60bc6781115 as good so that the knowledge gained during the last week is not completely lost? > While you're doing that bisect, do what Paolo said by applying the diff > here > > https://lkml.kernel.org/r/570EADD2.8030300@redhat.com > > when the bisection point you're at at each step contains > > 46896c73c1a4 ("KVM: svm: add support for RDTSCP") > > You should apply the above hunk by doing > > $ patch -p1 --dry-run -i /tmp/hunk > > If it applies fine, you then apply it > > $ patch -p1 -i /tmp/hunk > > All clear? So I need to git log | grep 46896c73c1a4 and apply the patch again each time the commit is found? 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-21 14:50 ` Marc Haber @ 2016-04-21 16:51 ` Borislav Petkov 2016-04-21 20:04 ` Marc Haber 0 siblings, 1 reply; 49+ messages in thread From: Borislav Petkov @ 2016-04-21 16:51 UTC (permalink / raw) To: Marc Haber; +Cc: Paolo Bonzini, linux-kernel, kvm ML On Thu, Apr 21, 2016 at 04:50:05PM +0200, Marc Haber wrote: > What bothers me is that since I ended up with a "suspect" commit that > actually results in a "good" kernel (running for 22 hours now), I must > have said "bad" to an actually "good" kernel, which means that I had > an unrelated crash or corruption. Is that reasoning correct? Hmm, did that "unrelated crash or corruption" have the same symptoms as the original one? > That one qualified as "good" six days ago. I'll retry, maybe I just > didn't wait long enough. So if the trigger time is varying so much, I'd try to double that to make sure I'm fairly certain about each commit I'm testing. Also, this is a single box we're talking about, right? And you're sure it hasn't had any corruption issues so far? I see you have amd64_edac loading, so it must have ECC DIMMs. Have you had any reports in the past of ECC errors in dmesg? Or other MCEs, lockups, etc? Can you grep your logs for stuff like "hardware error", "mce", "edac" etc? Do a case-insensitive search. > "Trying" means make oldconfig, make deb-pkg in my case right? Does it > matter what I answer to the numerous config questions that keep coming > up during the oldconfig step? What I do is: $ git bisect <good|bad> to mark the current commit after having tested it. Then I do $ yes "" | make oldconfig to set the new config options. Then $ make -j7 $ make modules_install install and reboot into the new kernel. Kernel name will possibly change each time so I write down on paper which kernel I'm testing. You can verify when booting it by doing: $ dmesg | head [ 0.000000] Linux version 4.6.0-rc2+ (boris@pd) (gcc version 5.3.1 20160101 (Debian 5.3.1-5) ) #1 SMP PREEMPT Wed Apr 6 20:22:51 CEST 2016 ... that date at the end of the line and number "#1" should be current. Number is also in .version and gets issued when you finish building: Kernel: arch/x86/boot/bzImage is ready (#1) > Would it help to explicitly mark > 0e749e54244eec87b2a3cd0a4314e60bc6781115 as good so that the knowledge > gained during the last week is not completely lost? I'd do the whole thing again, just to be sure. I know, bisection is very time-consuming :-\ And it is particularly annoying if it is done on the box I'm normally using daily. > So I need to git log | grep 46896c73c1a4 and apply the patch again > each time the commit is found? I think you can let git do that for ya: $ git branch --contains 46896c73c1a4 * (HEAD detached at 46896c73c1a4) that lists that the current checked out HEAD contains that commit. If you do $ git checkout 46896c73c1a4~1 then that "(HEAD detached..." line is not in the list of branches containing it. HTH. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-21 16:51 ` Borislav Petkov @ 2016-04-21 20:04 ` Marc Haber 2016-04-23 16:04 ` Borislav Petkov 0 siblings, 1 reply; 49+ messages in thread From: Marc Haber @ 2016-04-21 20:04 UTC (permalink / raw) To: Borislav Petkov; +Cc: Paolo Bonzini, linux-kernel, kvm ML On Thu, Apr 21, 2016 at 06:51:06PM +0200, Borislav Petkov wrote: > On Thu, Apr 21, 2016 at 04:50:05PM +0200, Marc Haber wrote: > > What bothers me is that since I ended up with a "suspect" commit that > > actually results in a "good" kernel (running for 22 hours now), I must > > have said "bad" to an actually "good" kernel, which means that I had > > an unrelated crash or corruption. Is that reasoning correct? > > Hmm, did that "unrelated crash or corruption" have the same symptoms as > the original one? Yes, but there are two symptoms. The VM either suffers file system issues (garbage read from files, or an aborted ext4 journal and following ro remount) or it stops dead in its tracks. > > That one qualified as "good" six days ago. I'll retry, maybe I just > > didn't wait long enough. > > So if the trigger time is varying so much, I'd try to double that to > make sure I'm fairly certain about each commit I'm testing. The longest trigger time I have seen was three hours, I tripled that to nine hours, that probably was not enough. > Also, this is a single box we're talking about, right? And you're sure > it hasn't had any corruption issues so far? It is a single box, and it runs perfectly with kernel 4.4. > I see you have amd64_edac loading, so it must have ECC DIMMs. Have you > had any reports in the past of ECC errors in dmesg? Or other MCEs, > lockups, etc? Can you grep your logs for stuff like "hardware error", > "mce", "edac" etc? Do a case-insensitive search. The box reports about one correctable error per week, so I probably have a faulty DIMM, but since the issue only surfaces in VMs while the host system is in perfect working order... And yes, I am pondering to simply replace the box with an Intel CPU. I see "mce: CPU supports 6 MCE banks" once for each reboot, and about 30 "Machine check events logged" since January. How do I see which events were logged? > > "Trying" means make oldconfig, make deb-pkg in my case right? Does it > > matter what I answer to the numerous config questions that keep coming > > up during the oldconfig step? > > What I do is: > > $ git bisect <good|bad> > > to mark the current commit after having tested it. Then I do > > $ yes "" | make oldconfig > > to set the new config options. So you basically select the default for new options. > Then > > $ make -j7 > $ make modules_install install > > and reboot into the new kernel. Kernel name will possibly change each > time so I write down on paper which kernel I'm testing. I go the way of Debian packages since it is easier to handle the crypto file systems when the machine is booting up. And yes, I think about doing a test reinstall on unencrypted disk to find out whether encryption plays a role, but I currently need the machine to urgently to take it out of serice for half a month, and, again, the host system is in perfect working order, it is just VMs that barf. > You can verify when booting it by doing: > > $ dmesg | head > [ 0.000000] Linux version 4.6.0-rc2+ (boris@pd) (gcc version 5.3.1 20160101 (Debian 5.3.1-5) ) #1 SMP PREEMPT Wed Apr 6 20:22:51 CEST 2016 > ... > > that date at the end of the line and number "#1" should be current. I check the date of the package I am installing and the date stamp of the kernels being installed to /boot. I'm reasonably sure I have that under control. > > Would it help to explicitly mark > > 0e749e54244eec87b2a3cd0a4314e60bc6781115 as good so that the knowledge > > gained during the last week is not completely lost? > > I'd do the whole thing again, just to be sure. > > I know, bisection is very time-consuming :-\ And it is particularly > annoying if it is done on the box I'm normally using daily. ... and if testing a "good" kernel means a day. > > So I need to git log | grep 46896c73c1a4 and apply the patch again > > each time the commit is found? > > I think you can let git do that for ya: > > $ git branch --contains 46896c73c1a4 > * (HEAD detached at 46896c73c1a4) > > that lists that the current checked out HEAD contains that commit. If you do > > $ git checkout 46896c73c1a4~1 > > then that "(HEAD detached..." line is not in the list of branches > containing it. And whenever 46896c73c1a4 is present, I need to apply Paolo's patch, right? 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-21 20:04 ` Marc Haber @ 2016-04-23 16:04 ` Borislav Petkov 2016-04-23 18:43 ` Marc Haber 0 siblings, 1 reply; 49+ messages in thread From: Borislav Petkov @ 2016-04-23 16:04 UTC (permalink / raw) To: Marc Haber; +Cc: Paolo Bonzini, linux-kernel, kvm ML On Thu, Apr 21, 2016 at 10:04:33PM +0200, Marc Haber wrote: > Yes, but there are two symptoms. The VM either suffers file system > issues (garbage read from files, or an aborted ext4 journal and > following ro remount) or it stops dead in its tracks. Stops dead? What does that mean exactly? Box is wedged solid and it doesn't react to any key presses? Because if so, this could really be a DRAM going bad and a correctable error turning into an uncorrectable. How old is the DRAM in that box? Judging by your CPU, it should be a couple of years... > The longest trigger time I have seen was three hours, I tripled that > to nine hours, that probably was not enough. So enlarge even more I guess. > The box reports about one correctable error per week, so I probably > have a faulty DIMM, but since the issue only surfaces in VMs while the > host system is in perfect working order... So it could be that correctable error turns into an uncorrectable one at some point. But then you should be getting an exception... > And yes, I am pondering to simply replace the box with an Intel CPU. Your CPU is fine, from what I've seen so far. > I see "mce: CPU supports 6 MCE banks" once for each reboot, and about > 30 "Machine check events logged" since January. How do I see which > events were logged? Hmm, you have [ 18.149300] MCE: In-kernel MCE decoding enabled. that's CONFIG_EDAC_DECODE_MCE, so you should have some "Hardware Error" lines in dmesg, I'd guess, decoding the errors. > So you basically select the default for new options. Yap. > I go the way of Debian packages since it is easier to handle the > crypto file systems when the machine is booting up. As long as you're testing the correct bisection kernels... > And yes, I think about doing a test reinstall on unencrypted disk to > find out whether encryption plays a role, but I currently need the > machine to urgently to take it out of serice for half a month, and, > again, the host system is in perfect working order, it is just VMs > that barf. Yeah, I can't reproduce it here and I have a very similar box to yours which is otherwise idle, more or less. Another fact which points to potentially DIMM going bad... > I check the date of the package I am installing and the date stamp of > the kernels being installed to /boot. I'm reasonably sure I have that > under control. Good. > ... and if testing a "good" kernel means a day. Yeah, it is annoying. In a perfect world, we all should have two identical boxes so that we use one as a workstation and the second for testing when the first one, the workstation barfs. I should bring that up with my manager next time... :-) > And whenever 46896c73c1a4 is present, I need to apply Paolo's patch, > right? Yap. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-23 16:04 ` Borislav Petkov @ 2016-04-23 18:43 ` Marc Haber 2016-04-23 18:52 ` Dr. David Alan Gilbert 2016-04-23 23:57 ` Major KVM issues with kernel 4.5 on the host Borislav Petkov 0 siblings, 2 replies; 49+ messages in thread From: Marc Haber @ 2016-04-23 18:43 UTC (permalink / raw) To: Borislav Petkov; +Cc: Paolo Bonzini, linux-kernel, kvm ML On Sat, Apr 23, 2016 at 06:04:29PM +0200, Borislav Petkov wrote: > On Thu, Apr 21, 2016 at 10:04:33PM +0200, Marc Haber wrote: > > Yes, but there are two symptoms. The VM either suffers file system > > issues (garbage read from files, or an aborted ext4 journal and > > following ro remount) or it stops dead in its tracks. > > Stops dead? What does that mean exactly? Box is wedged solid and it > doesn't react to any key presses? No ping, no reaction on serial console, no reaction on virtual console, no syslog entries. > Because if so, this could really be a DRAM going bad and a correctable > error turning into an uncorrectable. How old is the DRAM in that box? > Judging by your CPU, it should be a couple of years... Uncorrectable errors would still be identified by the ECC hardware, and the box wouldn't be perfectly fine with an "old" kernel. > > The box reports about one correctable error per week, so I probably > > have a faulty DIMM, but since the issue only surfaces in VMs while the > > host system is in perfect working order... > > So it could be that correctable error turns into an uncorrectable one at > some point. But then you should be getting an exception... Yes, that would be in the logs. > > And yes, I am pondering to simply replace the box with an Intel CPU. > > Your CPU is fine, from what I've seen so far. But we still postulate that the issue does only show on older AMD CPUs. Otherwise, I wouldn't be the only one making this experience. > > I go the way of Debian packages since it is easier to handle the > > crypto file systems when the machine is booting up. > > As long as you're testing the correct bisection kernels... I am reasonably sure about that, yes. > > And yes, I think about doing a test reinstall on unencrypted disk to > > find out whether encryption plays a role, but I currently need the > > machine to urgently to take it out of serice for half a month, and, > > again, the host system is in perfect working order, it is just VMs > > that barf. > > Yeah, I can't reproduce it here and I have a very similar box to yours > which is otherwise idle, more or less. > > Another fact which points to potentially DIMM going bad... Do you want me to memtest for 24 hours? 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-23 18:43 ` Marc Haber @ 2016-04-23 18:52 ` Dr. David Alan Gilbert 2016-05-12 20:20 ` transparent huge pages breaks KVM on AMD Marc Haber 2016-04-23 23:57 ` Major KVM issues with kernel 4.5 on the host Borislav Petkov 1 sibling, 1 reply; 49+ messages in thread From: Dr. David Alan Gilbert @ 2016-04-23 18:52 UTC (permalink / raw) To: Marc Haber; +Cc: Borislav Petkov, Paolo Bonzini, linux-kernel, kvm ML * Marc Haber (mh+linux-kernel@zugschlus.de) wrote: > On Sat, Apr 23, 2016 at 06:04:29PM +0200, Borislav Petkov wrote: > > On Thu, Apr 21, 2016 at 10:04:33PM +0200, Marc Haber wrote: > > > Yes, but there are two symptoms. The VM either suffers file system > > > issues (garbage read from files, or an aborted ext4 journal and > > > following ro remount) or it stops dead in its tracks. > > > > Stops dead? What does that mean exactly? Box is wedged solid and it > > doesn't react to any key presses? > > No ping, no reaction on serial console, no reaction on virtual > console, no syslog entries. > > > Because if so, this could really be a DRAM going bad and a correctable > > error turning into an uncorrectable. How old is the DRAM in that box? > > Judging by your CPU, it should be a couple of years... > > Uncorrectable errors would still be identified by the ECC hardware, > and the box wouldn't be perfectly fine with an "old" kernel. Hmm, your problem does sound like bad hardware, but.... If you've got a nice reliable crash, can you try turning transparent huge pages off on the host; echo never > /sys/kernel/mm/transparent_hugepage/enabled Dave > > > The box reports about one correctable error per week, so I probably > > > have a faulty DIMM, but since the issue only surfaces in VMs while the > > > host system is in perfect working order... > > > > So it could be that correctable error turns into an uncorrectable one at > > some point. But then you should be getting an exception... > > Yes, that would be in the logs. > > > > And yes, I am pondering to simply replace the box with an Intel CPU. > > > > Your CPU is fine, from what I've seen so far. > > But we still postulate that the issue does only show on older AMD > CPUs. Otherwise, I wouldn't be the only one making this experience. > > > > I go the way of Debian packages since it is easier to handle the > > > crypto file systems when the machine is booting up. > > > > As long as you're testing the correct bisection kernels... > > I am reasonably sure about that, yes. > > > > And yes, I think about doing a test reinstall on unencrypted disk to > > > find out whether encryption plays a role, but I currently need the > > > machine to urgently to take it out of serice for half a month, and, > > > again, the host system is in perfect working order, it is just VMs > > > that barf. > > > > Yeah, I can't reproduce it here and I have a very similar box to yours > > which is otherwise idle, more or less. > > > > Another fact which points to potentially DIMM going bad... > > Do you want me to memtest for 24 hours? > > 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 -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ dave @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* transparent huge pages breaks KVM on AMD. 2016-04-23 18:52 ` Dr. David Alan Gilbert @ 2016-05-12 20:20 ` Marc Haber 2016-05-12 20:24 ` Kirill A. Shutemov 2016-05-13 8:35 ` Dr. David Alan Gilbert 0 siblings, 2 replies; 49+ messages in thread From: Marc Haber @ 2016-05-12 20:20 UTC (permalink / raw) To: Dr. David Alan Gilbert Cc: Borislav Petkov, Paolo Bonzini, linux-kernel, kvm ML Hi David, On Sat, Apr 23, 2016 at 07:52:46PM +0100, Dr. David Alan Gilbert wrote: > Hmm, your problem does sound like bad hardware, but.... > If you've got a nice reliable crash, can you try turning transparent huge pages > off on the host; > echo never > /sys/kernel/mm/transparent_hugepage/enabled I must have missed this hint in the middle of the "your hardware is bad" avalance that came over me. I spent two weeks bisecting "good" kernels since during the repeated reconfigurations, transparent huge pages got turned off in kernel configuration. After running each kernel for 24 hours, I eventually ended up with a working 4.5 kernel. The configuration diff was short, showing transparent huge pages, and - finally - upon re-reading the thread I found your hint. I have now the result that 4.5, 4.5.1 and 4.5.4 corrupt KVM guest memory reliably in the first hour of running under disk load, causing the VM to either drop dead in the water, or to read randomness from disk. Rebooting fixes the VM. This happens as soon as transparent huge pages are turned on in the host. Turning off transparent huge pages by echo never > /sys/kernel/mm/transparent_hugepage/enabled fixes the issue even without rebooting the host. Start up the VM again and it works just fine. Is this an issue in (a) transparent huge pages, (b) KVM or (c) qemu? Where should this issue be forwarded? Or do we just accept it and turn transparent huge pages off? 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: transparent huge pages breaks KVM on AMD. 2016-05-12 20:20 ` transparent huge pages breaks KVM on AMD Marc Haber @ 2016-05-12 20:24 ` Kirill A. Shutemov 2016-05-12 20:34 ` Marc Haber 2016-05-13 8:35 ` Dr. David Alan Gilbert 1 sibling, 1 reply; 49+ messages in thread From: Kirill A. Shutemov @ 2016-05-12 20:24 UTC (permalink / raw) To: Marc Haber Cc: Dr. David Alan Gilbert, Borislav Petkov, Paolo Bonzini, linux-kernel, kvm ML On Thu, May 12, 2016 at 10:20:09PM +0200, Marc Haber wrote: > Hi David, > > On Sat, Apr 23, 2016 at 07:52:46PM +0100, Dr. David Alan Gilbert wrote: > > Hmm, your problem does sound like bad hardware, but.... > > If you've got a nice reliable crash, can you try turning transparent huge pages > > off on the host; > > echo never > /sys/kernel/mm/transparent_hugepage/enabled > > I must have missed this hint in the middle of the "your hardware is > bad" avalance that came over me. > > I spent two weeks bisecting "good" kernels since during the repeated > reconfigurations, transparent huge pages got turned off in kernel > configuration. After running each kernel for 24 hours, I eventually > ended up with a working 4.5 kernel. The configuration diff was short, > showing transparent huge pages, and - finally - upon re-reading the > thread I found your hint. > > I have now the result that 4.5, 4.5.1 and 4.5.4 corrupt KVM guest > memory reliably in the first hour of running under disk load, causing > the VM to either drop dead in the water, or to read randomness from > disk. Rebooting fixes the VM. This happens as soon as transparent huge > pages are turned on in the host. > > Turning off transparent huge pages by echo never > > /sys/kernel/mm/transparent_hugepage/enabled fixes the issue even > without rebooting the host. Start up the VM again and it works just > fine. > > Is this an issue in (a) transparent huge pages, (b) KVM or (c) qemu? > Where should this issue be forwarded? Or do we just accept it and turn > transparent huge pages off? Could you test this: http://lkml.kernel.org/r/1463070742-18401-1-git-send-email-aarcange@redhat.com ? -- Kirill A. Shutemov ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: transparent huge pages breaks KVM on AMD. 2016-05-12 20:24 ` Kirill A. Shutemov @ 2016-05-12 20:34 ` Marc Haber 2016-05-12 20:42 ` Kirill A. Shutemov 0 siblings, 1 reply; 49+ messages in thread From: Marc Haber @ 2016-05-12 20:34 UTC (permalink / raw) To: Kirill A. Shutemov Cc: Dr. David Alan Gilbert, Borislav Petkov, Paolo Bonzini, linux-kernel, kvm ML On Thu, May 12, 2016 at 11:24:02PM +0300, Kirill A. Shutemov wrote: > http://lkml.kernel.org/r/1463070742-18401-1-git-send-email-aarcange@redhat.com Is this in v4.6-rc7? If so, can I just test v4.6-rc7? If not so, would it be a valid approach to first check plain v4.6-rc7 and then patched v4.6-rc7? 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: transparent huge pages breaks KVM on AMD. 2016-05-12 20:34 ` Marc Haber @ 2016-05-12 20:42 ` Kirill A. Shutemov 2016-05-13 5:23 ` Marc Haber 0 siblings, 1 reply; 49+ messages in thread From: Kirill A. Shutemov @ 2016-05-12 20:42 UTC (permalink / raw) To: Marc Haber Cc: Dr. David Alan Gilbert, Borislav Petkov, Paolo Bonzini, linux-kernel, kvm ML, Andrea Arcangeli, Andrew Morton On Thu, May 12, 2016 at 10:34:57PM +0200, Marc Haber wrote: > On Thu, May 12, 2016 at 11:24:02PM +0300, Kirill A. Shutemov wrote: > > http://lkml.kernel.org/r/1463070742-18401-1-git-send-email-aarcange@redhat.com > > Is this in v4.6-rc7? No. > If so, can I just test v4.6-rc7? > > If not so, would it be a valid approach to first check plain v4.6-rc7 > and then patched v4.6-rc7? It haven't hit -mm tree yet. But I guess it should apply cleanly to v4.5. Or at least without major conflicts. Andrew, it looks like third bug report for the bug. It would be nice to propogate it quicker, if possible. -- Kirill A. Shutemov ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: transparent huge pages breaks KVM on AMD. 2016-05-12 20:42 ` Kirill A. Shutemov @ 2016-05-13 5:23 ` Marc Haber 2016-05-13 8:07 ` Borislav Petkov 0 siblings, 1 reply; 49+ messages in thread From: Marc Haber @ 2016-05-13 5:23 UTC (permalink / raw) To: Kirill A. Shutemov Cc: Dr. David Alan Gilbert, Borislav Petkov, Paolo Bonzini, linux-kernel, kvm ML, Andrea Arcangeli, Andrew Morton On Thu, May 12, 2016 at 11:42:16PM +0300, Kirill A. Shutemov wrote: > But I guess it should apply cleanly to v4.5. Or at least without major > conflicts. [11/511]mh@fan:~/linux/debug/linux$ curl 'http://marc.info/?l=linux-rdma&m=146307074800836&w=2' | patch -p1 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 12529 0 12529 0 0 9844 0 --:--:-- 0:00:01 --:--:-- 9849 patching file include/linux/mm.h Hunk #1 succeeded at 456 with fuzz 1 (offset -44 lines). patching file include/linux/swap.h Hunk #2 FAILED at 513. 1 out of 2 hunks FAILED -- saving rejects to file include/linux/swap.h.rej patching file mm/huge_memory.c Hunk #1 FAILED at 1298. Hunk #2 FAILED at 2079. Hunk #3 succeeded at 3340 (offset 117 lines). 2 out of 3 hunks FAILED -- saving rejects to file mm/huge_memory.c.rej patching file mm/memory.c Hunk #1 FAILED at 2373. Hunk #2 succeeded at 2331 with fuzz 2 (offset -56 lines). Hunk #3 FAILED at 2622. 2 out of 3 hunks FAILED -- saving rejects to file mm/memory.c.rej patching file mm/swapfile.c Hunk #1 FAILED at 922. 1 out of 1 hunk FAILED -- saving rejects to file mm/swapfile.c.rej [12/512]mh@fan:~/linux/debug/linux$ It doesn't, and it doesn't apply to 4.6-rc3 as well: [17/517]mh@fan:~/linux/debug/linux$ git checkout v4.6-rc3 Checking out files: 100% (9945/9945), done. Previous HEAD position was b562e44... Linux 4.5 HEAD is now at bf16200... Linux 4.6-rc3 [18/518]mh@fan:~/linux/debug/linux$ curl 'http://marc.info/?l=linux-rdma&m=146307074800836&w=2' | patch -p1 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 12529 0 12529 0 0 9692 0 --:--:-- 0:00:01 --:--:-- 9697 patching file include/linux/mm.h patching file include/linux/swap.h Hunk #2 FAILED at 513. 1 out of 2 hunks FAILED -- saving rejects to file include/linux/swap.h.rej patching file mm/huge_memory.c Hunk #1 FAILED at 1298. Hunk #2 FAILED at 2079. Hunk #3 succeeded at 3225 (offset 2 lines). 2 out of 3 hunks FAILED -- saving rejects to file mm/huge_memory.c.rej patching file mm/memory.c Hunk #1 FAILED at 2373. Hunk #2 succeeded at 2354 (offset -33 lines). Hunk #3 FAILED at 2622. 2 out of 3 hunks FAILED -- saving rejects to file mm/memory.c.rej patching file mm/swapfile.c Hunk #1 FAILED at 922. 1 out of 1 hunk FAILED -- saving rejects to file mm/swapfile.c.rej [19/519]mh@fan:~/linux/debug/linux$ How do I apply this? 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: transparent huge pages breaks KVM on AMD. 2016-05-13 5:23 ` Marc Haber @ 2016-05-13 8:07 ` Borislav Petkov 2016-05-13 8:09 ` Borislav Petkov ` (2 more replies) 0 siblings, 3 replies; 49+ messages in thread From: Borislav Petkov @ 2016-05-13 8:07 UTC (permalink / raw) To: Marc Haber Cc: Kirill A. Shutemov, Dr. David Alan Gilbert, Paolo Bonzini, linux-kernel, kvm ML, Andrea Arcangeli, Andrew Morton [-- Attachment #1: Type: text/plain, Size: 782 bytes --] On Fri, May 13, 2016 at 07:23:34AM +0200, Marc Haber wrote: > How do I apply this? I'm attaching it. $ patch -p1 --dry-run -i /tmp/01-mm-thp-calculate_the_mapcount_correctly_for_thp_pages_during_wp_faults.patch checking file include/linux/mm.h checking file include/linux/swap.h checking file mm/huge_memory.c checking file mm/memory.c checking file mm/swapfile.c $ patch -p1 -i /tmp/01-mm-thp-calculate_the_mapcount_correctly_for_thp_pages_during_wp_faults.patch patching file include/linux/mm.h patching file include/linux/swap.h patching file mm/huge_memory.c patching file mm/memory.c patching file mm/swapfile.c The --dry-run is to check whether it applies first. That's on 4.6-rc7+ here. HTH. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. [-- Attachment #2: 01-mm-thp-calculate_the_mapcount_correctly_for_thp_pages_during_wp_faults.patch --] [-- Type: text/x-diff, Size: 11895 bytes --] >From linux-kernel-owner@vger.kernel.org Tue May 10 21:21:32 2016 From: Andrea Arcangeli <aarcange@redhat.com> To: Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Alex Williamson <alex.williamson@redhat.com>, "Kirill A. Shutemov" <kirill@shutemov.name> Subject: [PATCH 1/1] mm: thp: calculate the mapcount correctly for THP pages during WP faults Date: Tue, 10 May 2016 21:21:22 +0200 Message-Id: <1462908082-12657-1-git-send-email-aarcange@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 Status: RO This will provide fully accuracy to the mapcount calculation in the write protect faults, so page pinning will not get broken by false positive copy-on-writes. total_mapcount() isn't the right calculation needed in reuse_swap_page(), so this introduces a page_trans_huge_mapcount() that is effectively the full accurate return value for page_mapcount() if dealing with Transparent Hugepages, however we only use the page_trans_huge_mapcount() during COW faults where it strictly needed, due to its higher runtime cost. This also provide at practical zero cost the total_mapcount information which is needed to know if we can still relocate the page anon_vma to the local vma. If page_trans_huge_mapcount() returns 1 we can reuse the page no matter if it's a pte or a pmd_trans_huge triggering the fault, but we can only relocate the page anon_vma to the local vma->anon_vma if we're sure it's only this "vma" mapping the whole THP physical range. Kirill A. Shutemov discovered the problem with moving the page anon_vma to the local vma->anon_vma in a previous version of this patch and another problem in the way page_move_anon_rmap() was called. Andrew Morton discovered that CONFIG_SWAP=n wouldn't build in a previous version, because reuse_swap_page must be a macro to call page_trans_huge_mapcount from swap.h, so this uses a macro again instead of an inline function. With this change at least it's a less dangerous usage than it was before, because "page" is used only once now, while with the previous code reuse_swap_page(page++) would have called page_mapcount on page+1 and it would have increased page twice instead of just once. Reviewed-by: "Kirill A. Shutemov" <kirill@shutemov.name> Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Hildenbrand <dahi@linux.vnet.ibm.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Geliang Tang <geliangtang@163.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Hugh Dickins <hughd@google.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jan Kara <jack@suse.cz> Cc: Jerome Marchand <jmarchan@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Matthew Wilcox <willy@linux.intel.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Miklos Szeredi <mszeredi@suse.cz> Cc: Minchan Kim <minchan@kernel.org> Cc: Vladimir Davydov <vdavydov@virtuozzo.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Xie XiuQi <xiexiuqi@huawei.com> Cc: linux-mm <linux-mm@kvack.org> Cc: lkml <linux-kernel@vger.kernel.org> Link: http://lkml.kernel.org/r/1462908082-12657-1-git-send-email-aarcange@redhat.com --- include/linux/mm.h | 9 +++++++ include/linux/swap.h | 6 ++--- mm/huge_memory.c | 67 +++++++++++++++++++++++++++++++++++++++++++++------- mm/memory.c | 22 ++++++++++------- mm/swapfile.c | 13 +++++----- 5 files changed, 91 insertions(+), 26 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 864d722..8f468e0 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -500,11 +500,20 @@ static inline int page_mapcount(struct page *page) #ifdef CONFIG_TRANSPARENT_HUGEPAGE int total_mapcount(struct page *page); +int page_trans_huge_mapcount(struct page *page, int *total_mapcount); #else static inline int total_mapcount(struct page *page) { return page_mapcount(page); } +static inline int page_trans_huge_mapcount(struct page *page, + int *total_mapcount) +{ + int mapcount = page_mapcount(page); + if (total_mapcount) + *total_mapcount = mapcount; + return mapcount; +} #endif static inline struct page *virt_to_head_page(const void *x) diff --git a/include/linux/swap.h b/include/linux/swap.h index 0a4cd47..ad22035 100644 --- a/include/linux/swap.h +++ b/include/linux/swap.h @@ -418,7 +418,7 @@ extern sector_t swapdev_block(int, pgoff_t); extern int page_swapcount(struct page *); extern int swp_swapcount(swp_entry_t entry); extern struct swap_info_struct *page_swap_info(struct page *); -extern int reuse_swap_page(struct page *); +extern bool reuse_swap_page(struct page *, int *); extern int try_to_free_swap(struct page *); struct backing_dev_info; @@ -513,8 +513,8 @@ static inline int swp_swapcount(swp_entry_t entry) return 0; } -#define reuse_swap_page(page) \ - (!PageTransCompound(page) && page_mapcount(page) == 1) +#define reuse_swap_page(page, total_mapcount) \ + (page_trans_huge_mapcount(page, total_mapcount) == 1) static inline int try_to_free_swap(struct page *page) { diff --git a/mm/huge_memory.c b/mm/huge_memory.c index f7daa7d..cbd2142 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1298,15 +1298,9 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, VM_BUG_ON_PAGE(!PageCompound(page) || !PageHead(page), page); /* * We can only reuse the page if nobody else maps the huge page or it's - * part. We can do it by checking page_mapcount() on each sub-page, but - * it's expensive. - * The cheaper way is to check page_count() to be equal 1: every - * mapcount takes page reference reference, so this way we can - * guarantee, that the PMD is the only mapping. - * This can give false negative if somebody pinned the page, but that's - * fine. + * part. */ - if (page_mapcount(page) == 1 && page_count(page) == 1) { + if (page_trans_huge_mapcount(page, NULL) == 1) { pmd_t entry; entry = pmd_mkyoung(orig_pmd); entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); @@ -2079,7 +2073,8 @@ static int __collapse_huge_page_isolate(struct vm_area_struct *vma, if (pte_write(pteval)) { writable = true; } else { - if (PageSwapCache(page) && !reuse_swap_page(page)) { + if (PageSwapCache(page) && + !reuse_swap_page(page, NULL)) { unlock_page(page); result = SCAN_SWAP_CACHE_PAGE; goto out; @@ -3223,6 +3218,60 @@ int total_mapcount(struct page *page) } /* + * This calculates accurately how many mappings a transparent hugepage + * has (unlike page_mapcount() which isn't fully accurate). This full + * accuracy is primarily needed to know if copy-on-write faults can + * reuse the page and change the mapping to read-write instead of + * copying them. At the same time this returns the total_mapcount too. + * + * The function returns the highest mapcount any one of the subpages + * has. If the return value is one, even if different processes are + * mapping different subpages of the transparent hugepage, they can + * all reuse it, because each process is reusing a different subpage. + * + * The total_mapcount is instead counting all virtual mappings of the + * subpages. If the total_mapcount is equal to "one", it tells the + * caller all mappings belong to the same "mm" and in turn the + * anon_vma of the transparent hugepage can become the vma->anon_vma + * local one as no other process may be mapping any of the subpages. + * + * It would be more accurate to replace page_mapcount() with + * page_trans_huge_mapcount(), however we only use + * page_trans_huge_mapcount() in the copy-on-write faults where we + * need full accuracy to avoid breaking page pinning, because + * page_trans_huge_mapcount() is slower than page_mapcount(). + */ +int page_trans_huge_mapcount(struct page *page, int *total_mapcount) +{ + int i, ret, _total_mapcount, mapcount; + + /* hugetlbfs shouldn't call it */ + VM_BUG_ON_PAGE(PageHuge(page), page); + + if (likely(!PageTransCompound(page))) + return atomic_read(&page->_mapcount) + 1; + + page = compound_head(page); + + _total_mapcount = ret = 0; + for (i = 0; i < HPAGE_PMD_NR; i++) { + mapcount = atomic_read(&page[i]._mapcount) + 1; + ret = max(ret, mapcount); + _total_mapcount += mapcount; + } + if (PageDoubleMap(page)) { + ret -= 1; + _total_mapcount -= HPAGE_PMD_NR; + } + mapcount = compound_mapcount(page); + ret += mapcount; + _total_mapcount += mapcount; + if (total_mapcount) + *total_mapcount = _total_mapcount; + return ret; +} + +/* * This function splits huge page into normal pages. @page can point to any * subpage of huge page to split. Split doesn't change the position of @page. * diff --git a/mm/memory.c b/mm/memory.c index 52c218e..07493e3 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -2373,6 +2373,7 @@ static int do_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, * not dirty accountable. */ if (PageAnon(old_page) && !PageKsm(old_page)) { + int total_mapcount; if (!trylock_page(old_page)) { get_page(old_page); pte_unmap_unlock(page_table, ptl); @@ -2387,13 +2388,18 @@ static int do_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, } put_page(old_page); } - if (reuse_swap_page(old_page)) { - /* - * The page is all ours. Move it to our anon_vma so - * the rmap code will not search our parent or siblings. - * Protected against the rmap code by the page lock. - */ - page_move_anon_rmap(old_page, vma, address); + if (reuse_swap_page(old_page, &total_mapcount)) { + if (total_mapcount == 1) { + /* + * The page is all ours. Move it to + * our anon_vma so the rmap code will + * not search our parent or siblings. + * Protected against the rmap code by + * the page lock. + */ + page_move_anon_rmap(compound_head(old_page), + vma, address); + } unlock_page(old_page); return wp_page_reuse(mm, vma, address, page_table, ptl, orig_pte, old_page, 0, 0); @@ -2617,7 +2623,7 @@ static int do_swap_page(struct mm_struct *mm, struct vm_area_struct *vma, inc_mm_counter_fast(mm, MM_ANONPAGES); dec_mm_counter_fast(mm, MM_SWAPENTS); pte = mk_pte(page, vma->vm_page_prot); - if ((flags & FAULT_FLAG_WRITE) && reuse_swap_page(page)) { + if ((flags & FAULT_FLAG_WRITE) && reuse_swap_page(page, NULL)) { pte = maybe_mkwrite(pte_mkdirty(pte), vma); flags &= ~FAULT_FLAG_WRITE; ret |= VM_FAULT_WRITE; diff --git a/mm/swapfile.c b/mm/swapfile.c index 83874ec..031713ab 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -922,18 +922,19 @@ out: * to it. And as a side-effect, free up its swap: because the old content * on disk will never be read, and seeking back there to write new content * later would only waste time away from clustering. + * + * NOTE: total_mapcount should not be relied upon by the caller if + * reuse_swap_page() returns false, but it may be always overwritten + * (see the other implementation for CONFIG_SWAP=n). */ -int reuse_swap_page(struct page *page) +bool reuse_swap_page(struct page *page, int *total_mapcount) { int count; VM_BUG_ON_PAGE(!PageLocked(page), page); if (unlikely(PageKsm(page))) - return 0; - /* The page is part of THP and cannot be reused */ - if (PageTransCompound(page)) - return 0; - count = page_mapcount(page); + return false; + count = page_trans_huge_mapcount(page, total_mapcount); if (count <= 1 && PageSwapCache(page)) { count += page_swapcount(page); if (count == 1 && !PageWriteback(page)) { ^ permalink raw reply related [flat|nested] 49+ messages in thread
* Re: transparent huge pages breaks KVM on AMD. 2016-05-13 8:07 ` Borislav Petkov @ 2016-05-13 8:09 ` Borislav Petkov 2016-05-13 13:21 ` Marc Haber 2016-05-14 6:19 ` Marc Haber 2016-05-13 9:08 ` Marc Haber 2016-05-13 14:59 ` Marc Haber 2 siblings, 2 replies; 49+ messages in thread From: Borislav Petkov @ 2016-05-13 8:09 UTC (permalink / raw) To: Marc Haber Cc: Kirill A. Shutemov, Dr. David Alan Gilbert, Paolo Bonzini, linux-kernel, kvm ML, Andrea Arcangeli, Andrew Morton [-- Attachment #1: Type: text/plain, Size: 129 bytes --] Try this one better - it fixes an unitialized var. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. [-- Attachment #2: 01-mm-thp-calculate_the_mapcount_correctly_for_thp_pages_during_wp_faults.patch --] [-- Type: text/x-diff, Size: 12406 bytes --] >From linux-kernel-owner@vger.kernel.org Thu May 12 18:32:37 2016 From: Andrea Arcangeli <aarcange@redhat.com> To: Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org Cc: Alex Williamson <alex.williamson@redhat.com>, "Kirill A. Shutemov" <kirill@shutemov.name>, "Luick, Dean" <dean.luick@intel.com>, "Marciniszyn, Mike" <mike.marciniszyn@intel.com> Subject: [PATCH 1/1] mm: thp: calculate the mapcount correctly for THP pages during WP faults Date: Thu, 12 May 2016 18:32:22 +0200 Message-Id: <1463070742-18401-1-git-send-email-aarcange@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 Status: RO This will provide fully accuracy to the mapcount calculation in the write protect faults, so page pinning will not get broken by false positive copy-on-writes. total_mapcount() isn't the right calculation needed in reuse_swap_page(), so this introduces a page_trans_huge_mapcount() that is effectively the full accurate return value for page_mapcount() if dealing with Transparent Hugepages, however we only use the page_trans_huge_mapcount() during COW faults where it strictly needed, due to its higher runtime cost. This also provide at practical zero cost the total_mapcount information which is needed to know if we can still relocate the page anon_vma to the local vma. If page_trans_huge_mapcount() returns 1 we can reuse the page no matter if it's a pte or a pmd_trans_huge triggering the fault, but we can only relocate the page anon_vma to the local vma->anon_vma if we're sure it's only this "vma" mapping the whole THP physical range. Kirill A. Shutemov discovered the problem with moving the page anon_vma to the local vma->anon_vma in a previous version of this patch and another problem in the way page_move_anon_rmap() was called. Andrew Morton discovered that CONFIG_SWAP=n wouldn't build in a previous version, because reuse_swap_page must be a macro to call page_trans_huge_mapcount from swap.h, so this uses a macro again instead of an inline function. With this change at least it's a less dangerous usage than it was before, because "page" is used only once now, while with the previous code reuse_swap_page(page++) would have called page_mapcount on page+1 and it would have increased page twice instead of just once. Dean Luick noticed an uninitialized variable that could result in a rmap inefficiency for the non-THP case in a previous version. Reviewed-by: "Kirill A. Shutemov" <kirill@shutemov.name> Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: "Luick Cc: "Marciniszyn Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Hildenbrand <dahi@linux.vnet.ibm.com> Cc: Dean" <dean.luick@intel.com> Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Ebru Akagunduz <ebru.akagunduz@gmail.com> Cc: Geliang Tang <geliangtang@163.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Hugh Dickins <hughd@google.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jan Kara <jack@suse.cz> Cc: Jerome Marchand <jmarchan@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Matthew Wilcox <willy@linux.intel.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike" <mike.marciniszyn@intel.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Vladimir Davydov <vdavydov@virtuozzo.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Xie XiuQi <xiexiuqi@huawei.com> Cc: linux-mm <linux-mm@kvack.org> Cc: linux-rdma@vger.kernel.org Cc: lkml <linux-kernel@vger.kernel.org> Link: http://lkml.kernel.org/r/1463070742-18401-1-git-send-email-aarcange@redhat.com --- include/linux/mm.h | 9 +++++++ include/linux/swap.h | 6 ++--- mm/huge_memory.c | 71 +++++++++++++++++++++++++++++++++++++++++++++------- mm/memory.c | 22 ++++++++++------ mm/swapfile.c | 13 +++++----- 5 files changed, 95 insertions(+), 26 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 864d722..8f468e0 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -500,11 +500,20 @@ static inline int page_mapcount(struct page *page) #ifdef CONFIG_TRANSPARENT_HUGEPAGE int total_mapcount(struct page *page); +int page_trans_huge_mapcount(struct page *page, int *total_mapcount); #else static inline int total_mapcount(struct page *page) { return page_mapcount(page); } +static inline int page_trans_huge_mapcount(struct page *page, + int *total_mapcount) +{ + int mapcount = page_mapcount(page); + if (total_mapcount) + *total_mapcount = mapcount; + return mapcount; +} #endif static inline struct page *virt_to_head_page(const void *x) diff --git a/include/linux/swap.h b/include/linux/swap.h index 0a4cd47..ad22035 100644 --- a/include/linux/swap.h +++ b/include/linux/swap.h @@ -418,7 +418,7 @@ extern sector_t swapdev_block(int, pgoff_t); extern int page_swapcount(struct page *); extern int swp_swapcount(swp_entry_t entry); extern struct swap_info_struct *page_swap_info(struct page *); -extern int reuse_swap_page(struct page *); +extern bool reuse_swap_page(struct page *, int *); extern int try_to_free_swap(struct page *); struct backing_dev_info; @@ -513,8 +513,8 @@ static inline int swp_swapcount(swp_entry_t entry) return 0; } -#define reuse_swap_page(page) \ - (!PageTransCompound(page) && page_mapcount(page) == 1) +#define reuse_swap_page(page, total_mapcount) \ + (page_trans_huge_mapcount(page, total_mapcount) == 1) static inline int try_to_free_swap(struct page *page) { diff --git a/mm/huge_memory.c b/mm/huge_memory.c index f7daa7d..b49ee12 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1298,15 +1298,9 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, VM_BUG_ON_PAGE(!PageCompound(page) || !PageHead(page), page); /* * We can only reuse the page if nobody else maps the huge page or it's - * part. We can do it by checking page_mapcount() on each sub-page, but - * it's expensive. - * The cheaper way is to check page_count() to be equal 1: every - * mapcount takes page reference reference, so this way we can - * guarantee, that the PMD is the only mapping. - * This can give false negative if somebody pinned the page, but that's - * fine. + * part. */ - if (page_mapcount(page) == 1 && page_count(page) == 1) { + if (page_trans_huge_mapcount(page, NULL) == 1) { pmd_t entry; entry = pmd_mkyoung(orig_pmd); entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); @@ -2079,7 +2073,8 @@ static int __collapse_huge_page_isolate(struct vm_area_struct *vma, if (pte_write(pteval)) { writable = true; } else { - if (PageSwapCache(page) && !reuse_swap_page(page)) { + if (PageSwapCache(page) && + !reuse_swap_page(page, NULL)) { unlock_page(page); result = SCAN_SWAP_CACHE_PAGE; goto out; @@ -3223,6 +3218,64 @@ int total_mapcount(struct page *page) } /* + * This calculates accurately how many mappings a transparent hugepage + * has (unlike page_mapcount() which isn't fully accurate). This full + * accuracy is primarily needed to know if copy-on-write faults can + * reuse the page and change the mapping to read-write instead of + * copying them. At the same time this returns the total_mapcount too. + * + * The function returns the highest mapcount any one of the subpages + * has. If the return value is one, even if different processes are + * mapping different subpages of the transparent hugepage, they can + * all reuse it, because each process is reusing a different subpage. + * + * The total_mapcount is instead counting all virtual mappings of the + * subpages. If the total_mapcount is equal to "one", it tells the + * caller all mappings belong to the same "mm" and in turn the + * anon_vma of the transparent hugepage can become the vma->anon_vma + * local one as no other process may be mapping any of the subpages. + * + * It would be more accurate to replace page_mapcount() with + * page_trans_huge_mapcount(), however we only use + * page_trans_huge_mapcount() in the copy-on-write faults where we + * need full accuracy to avoid breaking page pinning, because + * page_trans_huge_mapcount() is slower than page_mapcount(). + */ +int page_trans_huge_mapcount(struct page *page, int *total_mapcount) +{ + int i, ret, _total_mapcount, mapcount; + + /* hugetlbfs shouldn't call it */ + VM_BUG_ON_PAGE(PageHuge(page), page); + + if (likely(!PageTransCompound(page))) { + mapcount = atomic_read(&page->_mapcount) + 1; + if (total_mapcount) + *total_mapcount = mapcount; + return mapcount; + } + + page = compound_head(page); + + _total_mapcount = ret = 0; + for (i = 0; i < HPAGE_PMD_NR; i++) { + mapcount = atomic_read(&page[i]._mapcount) + 1; + ret = max(ret, mapcount); + _total_mapcount += mapcount; + } + if (PageDoubleMap(page)) { + ret -= 1; + _total_mapcount -= HPAGE_PMD_NR; + } + mapcount = compound_mapcount(page); + ret += mapcount; + _total_mapcount += mapcount; + if (total_mapcount) + *total_mapcount = _total_mapcount; + return ret; +} + +/* * This function splits huge page into normal pages. @page can point to any * subpage of huge page to split. Split doesn't change the position of @page. * diff --git a/mm/memory.c b/mm/memory.c index 52c218e..07493e3 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -2373,6 +2373,7 @@ static int do_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, * not dirty accountable. */ if (PageAnon(old_page) && !PageKsm(old_page)) { + int total_mapcount; if (!trylock_page(old_page)) { get_page(old_page); pte_unmap_unlock(page_table, ptl); @@ -2387,13 +2388,18 @@ static int do_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, } put_page(old_page); } - if (reuse_swap_page(old_page)) { - /* - * The page is all ours. Move it to our anon_vma so - * the rmap code will not search our parent or siblings. - * Protected against the rmap code by the page lock. - */ - page_move_anon_rmap(old_page, vma, address); + if (reuse_swap_page(old_page, &total_mapcount)) { + if (total_mapcount == 1) { + /* + * The page is all ours. Move it to + * our anon_vma so the rmap code will + * not search our parent or siblings. + * Protected against the rmap code by + * the page lock. + */ + page_move_anon_rmap(compound_head(old_page), + vma, address); + } unlock_page(old_page); return wp_page_reuse(mm, vma, address, page_table, ptl, orig_pte, old_page, 0, 0); @@ -2617,7 +2623,7 @@ static int do_swap_page(struct mm_struct *mm, struct vm_area_struct *vma, inc_mm_counter_fast(mm, MM_ANONPAGES); dec_mm_counter_fast(mm, MM_SWAPENTS); pte = mk_pte(page, vma->vm_page_prot); - if ((flags & FAULT_FLAG_WRITE) && reuse_swap_page(page)) { + if ((flags & FAULT_FLAG_WRITE) && reuse_swap_page(page, NULL)) { pte = maybe_mkwrite(pte_mkdirty(pte), vma); flags &= ~FAULT_FLAG_WRITE; ret |= VM_FAULT_WRITE; diff --git a/mm/swapfile.c b/mm/swapfile.c index 83874ec..031713ab 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -922,18 +922,19 @@ out: * to it. And as a side-effect, free up its swap: because the old content * on disk will never be read, and seeking back there to write new content * later would only waste time away from clustering. + * + * NOTE: total_mapcount should not be relied upon by the caller if + * reuse_swap_page() returns false, but it may be always overwritten + * (see the other implementation for CONFIG_SWAP=n). */ -int reuse_swap_page(struct page *page) +bool reuse_swap_page(struct page *page, int *total_mapcount) { int count; VM_BUG_ON_PAGE(!PageLocked(page), page); if (unlikely(PageKsm(page))) - return 0; - /* The page is part of THP and cannot be reused */ - if (PageTransCompound(page)) - return 0; - count = page_mapcount(page); + return false; + count = page_trans_huge_mapcount(page, total_mapcount); if (count <= 1 && PageSwapCache(page)) { count += page_swapcount(page); if (count == 1 && !PageWriteback(page)) { ^ permalink raw reply related [flat|nested] 49+ messages in thread
* Re: transparent huge pages breaks KVM on AMD. 2016-05-13 8:09 ` Borislav Petkov @ 2016-05-13 13:21 ` Marc Haber 2016-05-13 16:08 ` Borislav Petkov 2016-05-14 6:19 ` Marc Haber 1 sibling, 1 reply; 49+ messages in thread From: Marc Haber @ 2016-05-13 13:21 UTC (permalink / raw) To: Borislav Petkov Cc: Kirill A. Shutemov, Dr. David Alan Gilbert, Paolo Bonzini, linux-kernel, kvm ML, Andrea Arcangeli, Andrew Morton On Fri, May 13, 2016 at 10:09:52AM +0200, Borislav Petkov wrote: > Try this one better - it fixes an unitialized var. Instead, or in addiiton? 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: transparent huge pages breaks KVM on AMD. 2016-05-13 13:21 ` Marc Haber @ 2016-05-13 16:08 ` Borislav Petkov 0 siblings, 0 replies; 49+ messages in thread From: Borislav Petkov @ 2016-05-13 16:08 UTC (permalink / raw) To: Marc Haber Cc: Kirill A. Shutemov, Dr. David Alan Gilbert, Paolo Bonzini, linux-kernel, kvm ML, Andrea Arcangeli, Andrew Morton On Fri, May 13, 2016 at 03:21:56PM +0200, Marc Haber wrote: > Instead, or in addiiton? Instead. You'll notice that it doesn't apply if you try "in addition". -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: transparent huge pages breaks KVM on AMD. 2016-05-13 8:09 ` Borislav Petkov 2016-05-13 13:21 ` Marc Haber @ 2016-05-14 6:19 ` Marc Haber 1 sibling, 0 replies; 49+ messages in thread From: Marc Haber @ 2016-05-14 6:19 UTC (permalink / raw) To: Borislav Petkov Cc: Kirill A. Shutemov, Dr. David Alan Gilbert, Paolo Bonzini, linux-kernel, kvm ML, Andrea Arcangeli, Andrew Morton On Fri, May 13, 2016 at 10:09:52AM +0200, Borislav Petkov wrote: > Try this one better - it fixes an unitialized var. Nosireebob, VMs crash even with this patch in the host as soon as the host has THP enabled. 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: transparent huge pages breaks KVM on AMD. 2016-05-13 8:07 ` Borislav Petkov 2016-05-13 8:09 ` Borislav Petkov @ 2016-05-13 9:08 ` Marc Haber 2016-05-13 9:19 ` Borislav Petkov 2016-05-13 14:59 ` Marc Haber 2 siblings, 1 reply; 49+ messages in thread From: Marc Haber @ 2016-05-13 9:08 UTC (permalink / raw) To: Borislav Petkov Cc: Kirill A. Shutemov, Dr. David Alan Gilbert, Paolo Bonzini, linux-kernel, kvm ML, Andrea Arcangeli, Andrew Morton On Fri, May 13, 2016 at 10:07:45AM +0200, Borislav Petkov wrote: > On Fri, May 13, 2016 at 07:23:34AM +0200, Marc Haber wrote: > > How do I apply this? > > I'm attaching it. Ok, stupid me, I thought that one could simply curl the web page. Too bad that list archives keep mangling patches :-( It applies now to 4.5 as well. 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: transparent huge pages breaks KVM on AMD. 2016-05-13 9:08 ` Marc Haber @ 2016-05-13 9:19 ` Borislav Petkov 0 siblings, 0 replies; 49+ messages in thread From: Borislav Petkov @ 2016-05-13 9:19 UTC (permalink / raw) To: Marc Haber Cc: Kirill A. Shutemov, Dr. David Alan Gilbert, Paolo Bonzini, linux-kernel, kvm ML, Andrea Arcangeli, Andrew Morton On Fri, May 13, 2016 at 11:08:46AM +0200, Marc Haber wrote: > It applies now to 4.5 as well. Yeah, I tried getting the raw message from marc.info but then it said: patch unexpectedly ends in middle of line Hunk #1 succeeded at 922 with fuzz 1. The attached versions I sent you are from my lkml mbox - the only reason I keep it :-) -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: transparent huge pages breaks KVM on AMD. 2016-05-13 8:07 ` Borislav Petkov 2016-05-13 8:09 ` Borislav Petkov 2016-05-13 9:08 ` Marc Haber @ 2016-05-13 14:59 ` Marc Haber 2 siblings, 0 replies; 49+ messages in thread From: Marc Haber @ 2016-05-13 14:59 UTC (permalink / raw) To: Borislav Petkov Cc: Kirill A. Shutemov, Dr. David Alan Gilbert, Paolo Bonzini, linux-kernel, kvm ML, Andrea Arcangeli, Andrew Morton On Fri, May 13, 2016 at 10:07:45AM +0200, Borislav Petkov wrote: > On Fri, May 13, 2016 at 07:23:34AM +0200, Marc Haber wrote: > > How do I apply this? > > I'm attaching it. Had the VM crashing twice with this patch applied, THP==madvise on the host and THP==never in the VM. Now trying the other patch, assuming that it's intended to be used _instead_ of this one. 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: transparent huge pages breaks KVM on AMD. 2016-05-12 20:20 ` transparent huge pages breaks KVM on AMD Marc Haber 2016-05-12 20:24 ` Kirill A. Shutemov @ 2016-05-13 8:35 ` Dr. David Alan Gilbert 2016-05-13 14:03 ` Marc Haber 1 sibling, 1 reply; 49+ messages in thread From: Dr. David Alan Gilbert @ 2016-05-13 8:35 UTC (permalink / raw) To: Marc Haber; +Cc: Borislav Petkov, Paolo Bonzini, linux-kernel, kvm ML * Marc Haber (mh+linux-kernel@zugschlus.de) wrote: > Hi David, > > On Sat, Apr 23, 2016 at 07:52:46PM +0100, Dr. David Alan Gilbert wrote: > > Hmm, your problem does sound like bad hardware, but.... > > If you've got a nice reliable crash, can you try turning transparent huge pages > > off on the host; > > echo never > /sys/kernel/mm/transparent_hugepage/enabled > > I must have missed this hint in the middle of the "your hardware is > bad" avalance that came over me. > > I spent two weeks bisecting "good" kernels since during the repeated > reconfigurations, transparent huge pages got turned off in kernel > configuration. After running each kernel for 24 hours, I eventually > ended up with a working 4.5 kernel. The configuration diff was short, > showing transparent huge pages, and - finally - upon re-reading the > thread I found your hint. OK, good. When I sent that mail I'd hit a THP bug but in a corner of migration and at the time we didn't know why and there was no reason to think it would cause any other symptoms, but since it was also between 4.4 and 4.5 it did seem worth mentioning as a long shot, but it was no more than a long shot. > I have now the result that 4.5, 4.5.1 and 4.5.4 corrupt KVM guest > memory reliably in the first hour of running under disk load, causing > the VM to either drop dead in the water, or to read randomness from > disk. Rebooting fixes the VM. This happens as soon as transparent huge > pages are turned on in the host. > > Turning off transparent huge pages by echo never > > /sys/kernel/mm/transparent_hugepage/enabled fixes the issue even > without rebooting the host. Start up the VM again and it works just > fine. > > Is this an issue in (a) transparent huge pages, (b) KVM or (c) qemu? > Where should this issue be forwarded? Or do we just accept it and turn > transparent huge pages off? Try Andrea's fix for (a). Dave > > 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 -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ dave @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: transparent huge pages breaks KVM on AMD. 2016-05-13 8:35 ` Dr. David Alan Gilbert @ 2016-05-13 14:03 ` Marc Haber 0 siblings, 0 replies; 49+ messages in thread From: Marc Haber @ 2016-05-13 14:03 UTC (permalink / raw) To: Dr. David Alan Gilbert Cc: Borislav Petkov, Paolo Bonzini, linux-kernel, kvm ML On Fri, May 13, 2016 at 09:35:45AM +0100, Dr. David Alan Gilbert wrote: > also between 4.4 and 4.5 it did seem worth mentioning as a long shot, > but it was no more than a long shot. It was however helpful. I'd have bisected kernel configuration instead of using the runtime control first, and seeing your long shot two weeks earlier, it'd have saved myself those two weeks of tedious bisecting. > Try Andrea's fix for (a). In the works. 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-23 18:43 ` Marc Haber 2016-04-23 18:52 ` Dr. David Alan Gilbert @ 2016-04-23 23:57 ` Borislav Petkov 1 sibling, 0 replies; 49+ messages in thread From: Borislav Petkov @ 2016-04-23 23:57 UTC (permalink / raw) To: Marc Haber; +Cc: Paolo Bonzini, linux-kernel, kvm ML On Sat, Apr 23, 2016 at 08:43:41PM +0200, Marc Haber wrote: > Uncorrectable errors would still be identified by the ECC hardware, Not if the hardware decides to syncflood so that we don't even get to run the #MC handler... > and the box wouldn't be perfectly fine with an "old" kernel. Maybe the "old" kernel is not causing all the required ingredients to come together for the uncorrectable error to happen. But yeah, I agree, the fact that 4.4 is fine kinda doesn't fit with the uncorrectable error theory. > Yes, that would be in the logs. Presumably. And see above. > But we still postulate that the issue does only show on older AMD > CPUs. Otherwise, I wouldn't be the only one making this experience. It actually shows only on this one system. At least I'm not aware of any other report of the same issue. My system with a F10h, rev E is just fine. > Do you want me to memtest for 24 hours? Yeah, that memtest crap never triggers any ECCs. But if you're bored, why not... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-14 1:16 ` Paolo Bonzini 2016-04-14 5:22 ` Marc Haber @ 2016-04-14 6:07 ` Marc Haber 2016-04-14 16:47 ` Marc Haber 2 siblings, 0 replies; 49+ messages in thread From: Marc Haber @ 2016-04-14 6:07 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Borislav Petkov, linux-kernel, kvm ML On Thu, Apr 14, 2016 at 03:16:29AM +0200, Paolo Bonzini wrote: > Ok, then I guess bisection is needed. Please first try commit > 45bdbcfdf241. That kernel labels itself as "4.4.0-rc5+", is that correct? 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-14 1:16 ` Paolo Bonzini 2016-04-14 5:22 ` Marc Haber 2016-04-14 6:07 ` Marc Haber @ 2016-04-14 16:47 ` Marc Haber 2016-04-14 17:30 ` Paolo Bonzini 2 siblings, 1 reply; 49+ messages in thread From: Marc Haber @ 2016-04-14 16:47 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Borislav Petkov, linux-kernel, kvm ML On Thu, Apr 14, 2016 at 03:16:29AM +0200, Paolo Bonzini wrote: > Ok, then I guess bisection is needed. Please first try commit > 45bdbcfdf241. I did git checkout 45bdbcfdf241 and built the resulting kernel 4.4.0-rc5. This one has now been running for ten hours, which is threefold the longest time that a faulty kernel has held before a VM experienced corruption. So I guess, that one is fine. Since 4.5.0-rc1 is bad, I guess I do: git checkout 45bdbcfdf241 git bisect start git bisect good git bisect bad v4.5.0-rc1 right? 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-14 16:47 ` Marc Haber @ 2016-04-14 17:30 ` Paolo Bonzini 2016-04-14 17:47 ` Marc Haber 0 siblings, 1 reply; 49+ messages in thread From: Paolo Bonzini @ 2016-04-14 17:30 UTC (permalink / raw) To: Marc Haber; +Cc: Borislav Petkov, linux-kernel, kvm ML On 14/04/2016 18:47, Marc Haber wrote: >> > Ok, then I guess bisection is needed. Please first try commit >> > 45bdbcfdf241. > I did git checkout 45bdbcfdf241 and built the resulting kernel > 4.4.0-rc5. This one has now been running for ten hours, which is > threefold the longest time that a faulty kernel has held before a VM > experienced corruption. So I guess, that one is fine. Interesting, this means it's not a KVM bug. You can ignore my patch from yesterday (though we'll get it in anyway). > Since 4.5.0-rc1 is bad, I guess I do: > > git checkout 45bdbcfdf241 > git bisect start > git bisect good > git bisect bad v4.5.0-rc1 This is correct but you also want to do git bisect good 4.4.0 git bisect good 4.4.0-rc5 so that bisection basically works through the commits in the merge window. Thanks, Paolo ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-14 17:30 ` Paolo Bonzini @ 2016-04-14 17:47 ` Marc Haber 0 siblings, 0 replies; 49+ messages in thread From: Marc Haber @ 2016-04-14 17:47 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Borislav Petkov, linux-kernel, kvm ML On Thu, Apr 14, 2016 at 07:30:43PM +0200, Paolo Bonzini wrote: > On 14/04/2016 18:47, Marc Haber wrote: > >> > Ok, then I guess bisection is needed. Please first try commit > >> > 45bdbcfdf241. > > I did git checkout 45bdbcfdf241 and built the resulting kernel > > 4.4.0-rc5. This one has now been running for ten hours, which is > > threefold the longest time that a faulty kernel has held before a VM > > experienced corruption. So I guess, that one is fine. > > Interesting, this means it's not a KVM bug. You can ignore my patch > from yesterday (though we'll get it in anyway). > > > Since 4.5.0-rc1 is bad, I guess I do: > > > > git checkout 45bdbcfdf241 > > git bisect start > > git bisect good > > git bisect bad v4.5.0-rc1 > > This is correct but you also want to do > > git bisect good 4.4.0 > git bisect good 4.4.0-rc5 > > so that bisection basically works through the commits in the merge window. So I start over from this: [47/544]mh@fan:~/linux/debug/linux$ git checkout 45bdbcfdf241 HEAD is now at 45bdbcf... kvm: x86: Fix vmwrite to SECONDARY_VM_EXEC_CONTROL [48/545]mh@fan:~/linux/debug/linux$ git bisect start [49/546]mh@fan:~/linux/debug/linux$ git bisect good [50/547]mh@fan:~/linux/debug/linux$ git bisect bad v4.5-rc1 Bisecting: 5761 revisions left to test after this (roughly 13 steps) [cbd88cd4c07f9361914ab7fd7e21c9227986fe68] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux [51/548]mh@fan:~/linux/debug/linux$ git bisect good v4.4 Bisecting: 5468 revisions left to test after this (roughly 12 steps) [f9a03ae123c92c1f45cd2ca88d0f6edd787be78c] Merge tag 'for-f2fs-4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs [52/549]mh@fan:~/linux/debug/linux$ git bisect good v4.4-rc5 Bisecting: 5468 revisions left to test after this (roughly 12 steps) [f9a03ae123c92c1f45cd2ca88d0f6edd787be78c] Merge tag 'for-f2fs-4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs [53/550]mh@fan:~/linux/debug/linux$ This is going to take a few days as detecting a "bad" version may take a few hours. 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-03-17 18:11 ` Borislav Petkov 2016-03-18 10:01 ` Paolo Bonzini @ 2016-03-18 18:49 ` Marc Haber 2016-03-18 22:04 ` Borislav Petkov 1 sibling, 1 reply; 49+ messages in thread From: Marc Haber @ 2016-03-18 18:49 UTC (permalink / raw) To: Borislav Petkov; +Cc: linux-kernel, kvm ML Hi Borislav, On Thu, Mar 17, 2016 at 07:11:28PM +0100, Borislav Petkov wrote: > Do you have any funky messages in host's dmesg ? Not that I see. > Can you upload a full dmesg from both a good and a bad host kernel? http://q.bofh.de/~mh/stuff/20160317-fan-syslog-kvm-4.4.5 http://q.bofh.de/~mh/stuff/20160317-fan-syslog-kvm-4.5 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-03-18 18:49 ` Marc Haber @ 2016-03-18 22:04 ` Borislav Petkov 2016-03-19 0:08 ` Marc Haber 0 siblings, 1 reply; 49+ messages in thread From: Borislav Petkov @ 2016-03-18 22:04 UTC (permalink / raw) To: Marc Haber; +Cc: linux-kernel, kvm ML On Fri, Mar 18, 2016 at 07:49:29PM +0100, Marc Haber wrote: > http://q.bofh.de/~mh/stuff/20160317-fan-syslog-kvm-4.4.5 This one I got. > http://q.bofh.de/~mh/stuff/20160317-fan-syslog-kvm-4.5 This one doesn't want: HTTP request sent, awaiting response... 403 Forbidden 2016-03-18 22:57:46 ERROR 403: Forbidden. So I have a similar system to yours, I'll try to reproduce on it with 4.5. Anything special you're doing to cause the host kernel to barf which I should do here? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-03-18 22:04 ` Borislav Petkov @ 2016-03-19 0:08 ` Marc Haber 2016-03-20 13:31 ` Borislav Petkov 2016-03-21 9:08 ` Paolo Bonzini 0 siblings, 2 replies; 49+ messages in thread From: Marc Haber @ 2016-03-19 0:08 UTC (permalink / raw) To: Borislav Petkov; +Cc: linux-kernel, kvm ML Hi Borislav, On Fri, Mar 18, 2016 at 11:04:29PM +0100, Borislav Petkov wrote: > On Fri, Mar 18, 2016 at 07:49:29PM +0100, Marc Haber wrote: > > http://q.bofh.de/~mh/stuff/20160317-fan-syslog-kvm-4.4.5 > > This one I got. > > > http://q.bofh.de/~mh/stuff/20160317-fan-syslog-kvm-4.5 > > This one doesn't want: > > HTTP request sent, awaiting response... 403 Forbidden > 2016-03-18 22:57:46 ERROR 403: Forbidden. Idiot me. File permissions fixed. > Anything special you're doing to cause the host kernel to barf which I > should do here? Booting Debian Linux, apt-get update, apt-get upgrade, and run aide (which builds checksums for the entire filesystem, a rather disk-bound activity). 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-03-19 0:08 ` Marc Haber @ 2016-03-20 13:31 ` Borislav Petkov 2016-03-20 17:14 ` Andrey Korolyov 2016-04-13 18:20 ` Marc Haber 2016-03-21 9:08 ` Paolo Bonzini 1 sibling, 2 replies; 49+ messages in thread From: Borislav Petkov @ 2016-03-20 13:31 UTC (permalink / raw) To: Marc Haber; +Cc: linux-kernel, kvm ML On Sat, Mar 19, 2016 at 01:08:37AM +0100, Marc Haber wrote: > Booting Debian Linux, apt-get update, apt-get upgrade, and run aide > (which builds checksums for the entire filesystem, a rather disk-bound > activity). So I did that and aide ran a whole init and check all the way through and all fine. I don't see anything out of the ordinary in your dmesg outputs either. The next things we should look like is: * diff .configs - there might be something there * try to reproduce on debian testing or even stable. I have had similar issues with debian unstable in the past. * something else which I'm not thinking of it right now. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-03-20 13:31 ` Borislav Petkov @ 2016-03-20 17:14 ` Andrey Korolyov 2016-03-20 18:25 ` Borislav Petkov 2016-04-13 18:20 ` Marc Haber 1 sibling, 1 reply; 49+ messages in thread From: Andrey Korolyov @ 2016-03-20 17:14 UTC (permalink / raw) To: Borislav Petkov; +Cc: Marc Haber, Linux Kernel Mailing List, kvm ML On Sun, Mar 20, 2016 at 4:31 PM, Borislav Petkov <bp@alien8.de> wrote: > On Sat, Mar 19, 2016 at 01:08:37AM +0100, Marc Haber wrote: >> Booting Debian Linux, apt-get update, apt-get upgrade, and run aide >> (which builds checksums for the entire filesystem, a rather disk-bound >> activity). > > So I did that and aide ran a whole init and check all the way through > and all fine. I don't see anything out of the ordinary in your dmesg > outputs either. > > The next things we should look like is: > > * diff .configs - there might be something there > > * try to reproduce on debian testing or even stable. I have had similar > issues with debian unstable in the past. > > * something else which I'm not thinking of it right now. > > -- > Regards/Gruss, > Boris. > Kinda naive question - do you run same ucode version as Marc on his device? ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-03-20 17:14 ` Andrey Korolyov @ 2016-03-20 18:25 ` Borislav Petkov 2016-03-20 18:42 ` Andrey Korolyov 0 siblings, 1 reply; 49+ messages in thread From: Borislav Petkov @ 2016-03-20 18:25 UTC (permalink / raw) To: Andrey Korolyov; +Cc: Marc Haber, Linux Kernel Mailing List, kvm ML On Sun, Mar 20, 2016 at 08:14:58PM +0300, Andrey Korolyov wrote: > Kinda naive question - do you run same ucode version as Marc on his device? Yeah, we both have 0x010000dc. In case you're referring to the recent faulty AMD microcode patch - it doesn't apply here. The boxes in question are family 0x10 and the microcode patch is for family 0x15. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-03-20 18:25 ` Borislav Petkov @ 2016-03-20 18:42 ` Andrey Korolyov 2016-03-20 18:58 ` Borislav Petkov 0 siblings, 1 reply; 49+ messages in thread From: Andrey Korolyov @ 2016-03-20 18:42 UTC (permalink / raw) To: Borislav Petkov; +Cc: Marc Haber, Linux Kernel Mailing List, kvm ML On Sun, Mar 20, 2016 at 9:25 PM, Borislav Petkov <bp@alien8.de> wrote: > On Sun, Mar 20, 2016 at 08:14:58PM +0300, Andrey Korolyov wrote: >> Kinda naive question - do you run same ucode version as Marc on his device? > > Yeah, we both have 0x010000dc. > > In case you're referring to the recent faulty AMD microcode patch - > it doesn't apply here. The boxes in question are family 0x10 and the > microcode patch is for family 0x15. > Yes, I suggested that the issue could fall over a different family as well to expose explicit corruption of a guest pages (as opposed to a generic corruption in a known case). Since there is no direct evidence of what exactly (data or pgt) is getting corrupted, would disabling npt for a testing purposes be helpful? ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-03-20 18:42 ` Andrey Korolyov @ 2016-03-20 18:58 ` Borislav Petkov 2016-04-13 18:22 ` Marc Haber 0 siblings, 1 reply; 49+ messages in thread From: Borislav Petkov @ 2016-03-20 18:58 UTC (permalink / raw) To: Andrey Korolyov; +Cc: Marc Haber, Linux Kernel Mailing List, kvm ML On Sun, Mar 20, 2016 at 09:42:15PM +0300, Andrey Korolyov wrote: > Yes, I suggested that the issue could fall over a different family as > well to expose explicit corruption of a guest pages (as opposed to a > generic corruption in a known case). Probably, but I don't think it is microcode patch related. > Since there is no direct evidence of what exactly (data or pgt) is > getting corrupted, would disabling npt for a testing purposes be > helpful? So I'm not sure what even happens here yet. I haven't seen anything out of the ordinary in Marc's dmesg and I wasn't able to reproduce either. So would it be good to try with "npt=0"? Sure, why not. Marc, you could give that a try to see if it changes anything... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-03-20 18:58 ` Borislav Petkov @ 2016-04-13 18:22 ` Marc Haber 2016-04-13 20:37 ` Paolo Bonzini 0 siblings, 1 reply; 49+ messages in thread From: Marc Haber @ 2016-04-13 18:22 UTC (permalink / raw) To: Borislav Petkov; +Cc: Andrey Korolyov, Linux Kernel Mailing List, kvm ML On Sun, Mar 20, 2016 at 07:58:13PM +0100, Borislav Petkov wrote: > So I'm not sure what even happens here yet. I haven't seen anything out > of the ordinary in Marc's dmesg and I wasn't able to reproduce either. > So would it be good to try with "npt=0"? Sure, why not. npt=0 goes on the kernel command line of the host or of the guest? Or is it a KVM option? 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-04-13 18:22 ` Marc Haber @ 2016-04-13 20:37 ` Paolo Bonzini 0 siblings, 0 replies; 49+ messages in thread From: Paolo Bonzini @ 2016-04-13 20:37 UTC (permalink / raw) To: Marc Haber, Borislav Petkov Cc: Andrey Korolyov, Linux Kernel Mailing List, kvm ML On 13/04/2016 20:22, Marc Haber wrote: >> So I'm not sure what even happens here yet. I haven't seen anything out >> > of the ordinary in Marc's dmesg and I wasn't able to reproduce either. >> > So would it be good to try with "npt=0"? Sure, why not. > npt=0 goes on the kernel command line of the host or of the guest? Or > is it a KVM option? It is an option to the kvm-amd module, but I think I found it. Paolo ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-03-20 13:31 ` Borislav Petkov 2016-03-20 17:14 ` Andrey Korolyov @ 2016-04-13 18:20 ` Marc Haber 1 sibling, 0 replies; 49+ messages in thread From: Marc Haber @ 2016-04-13 18:20 UTC (permalink / raw) To: Borislav Petkov; +Cc: linux-kernel, kvm ML On Sun, Mar 20, 2016 at 02:31:58PM +0100, Borislav Petkov wrote: > On Sat, Mar 19, 2016 at 01:08:37AM +0100, Marc Haber wrote: > > Booting Debian Linux, apt-get update, apt-get upgrade, and run aide > > (which builds checksums for the entire filesystem, a rather disk-bound > > activity). > > So I did that and aide ran a whole init and check all the way through > and all fine. I don't see anything out of the ordinary in your dmesg > outputs either. > > The next things we should look like is: > > * diff .configs - there might be something there# Here we go: [2/501]mh@fan:~$ diff -u0 /boot/config-4.4.6-zgws1 /boot/config-4.5.1-zgws1 --- /boot/config-4.4.6-zgws1 2016-03-28 15:50:36.000000000 +0200 +++ /boot/config-4.5.1-zgws1 2016-04-13 08:32:44.000000000 +0200 @@ -3 +3 @@ -# Linux/x86_64 4.4.6 Kernel Configuration +# Linux/x86_64 4.5.1 Kernel Configuration @@ -14 +13,0 @@ -CONFIG_HAVE_LATENCYTOP_SUPPORT=y @@ -15,0 +15,4 @@ +CONFIG_ARCH_MMAP_RND_BITS_MIN=28 +CONFIG_ARCH_MMAP_RND_BITS_MAX=32 +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8 +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 @@ -147,7 +149,0 @@ -# CONFIG_CGROUP_DEBUG is not set -CONFIG_CGROUP_FREEZER=y -CONFIG_CGROUP_PIDS=y -CONFIG_CGROUP_DEVICE=y -CONFIG_CPUSETS=y -CONFIG_PROC_PID_CPUSET=y -CONFIG_CGROUP_CPUACCT=y @@ -158,3 +154,3 @@ -# CONFIG_MEMCG_KMEM is not set -# CONFIG_CGROUP_HUGETLB is not set -CONFIG_CGROUP_PERF=y +CONFIG_BLK_CGROUP=y +# CONFIG_DEBUG_BLK_CGROUP is not set +CONFIG_CGROUP_WRITEBACK=y @@ -165,3 +161,9 @@ -CONFIG_BLK_CGROUP=y -# CONFIG_DEBUG_BLK_CGROUP is not set -CONFIG_CGROUP_WRITEBACK=y +CONFIG_CGROUP_PIDS=y +CONFIG_CGROUP_FREEZER=y +# CONFIG_CGROUP_HUGETLB is not set +CONFIG_CPUSETS=y +CONFIG_PROC_PID_CPUSET=y +CONFIG_CGROUP_DEVICE=y +CONFIG_CGROUP_CPUACCT=y +CONFIG_CGROUP_PERF=y +# CONFIG_CGROUP_DEBUG is not set @@ -254 +255,0 @@ -CONFIG_HAVE_DMA_ATTRS=y @@ -288,0 +290,4 @@ +CONFIG_HAVE_ARCH_MMAP_RND_BITS=y +CONFIG_ARCH_MMAP_RND_BITS=28 +CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS=y +CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8 @@ -377,0 +383 @@ +CONFIG_X86_FAST_FEATURE_TESTS=y @@ -383 +389 @@ -CONFIG_IOSF_MBI=m +CONFIG_IOSF_MBI=y @@ -390,0 +397 @@ +# CONFIG_QUEUED_LOCK_STAT is not set @@ -769,0 +777 @@ +# CONFIG_VMD is not set @@ -772,0 +781 @@ +CONFIG_NET_EGRESS=y @@ -824,0 +834 @@ +# CONFIG_INET_DIAG_DESTROY is not set @@ -945,0 +956,3 @@ +CONFIG_NF_DUP_NETDEV=m +CONFIG_NFT_DUP_NETDEV=m +CONFIG_NFT_FWD_NETDEV=m @@ -1252,0 +1266 @@ +# CONFIG_6LOWPAN_DEBUGFS is not set @@ -1344,0 +1359 @@ +CONFIG_SOCK_CGROUP_DATA=y @@ -1411 +1425,0 @@ -CONFIG_WEXT_SPY=y @@ -1423,5 +1437 @@ -CONFIG_LIB80211=m -CONFIG_LIB80211_CRYPT_WEP=m -CONFIG_LIB80211_CRYPT_CCMP=m -CONFIG_LIB80211_CRYPT_TKIP=m -# CONFIG_LIB80211_DEBUG is not set +# CONFIG_LIB80211 is not set @@ -1469 +1479,2 @@ -# CONFIG_NFC_ST_NCI is not set +# CONFIG_NFC_ST_NCI_I2C is not set +# CONFIG_NFC_ST_NCI_SPI is not set @@ -1616,2 +1627,2 @@ -CONFIG_PARPORT_PC=m -CONFIG_PARPORT_SERIAL=m +CONFIG_PARPORT_PC=y +CONFIG_PARPORT_SERIAL=y @@ -1619 +1630 @@ -CONFIG_PARPORT_PC_SUPERIO=y +# CONFIG_PARPORT_PC_SUPERIO is not set @@ -1968,0 +1980 @@ +# CONFIG_DM_DEBUG_BLOCK_STACK_TRACING is not set @@ -1971 +1982,0 @@ -# CONFIG_DM_DEBUG_BLOCK_STACK_TRACING is not set @@ -2131,0 +2143 @@ +# CONFIG_NET_VENDOR_NETRONOME is not set @@ -2263,43 +2275,6 @@ -# CONFIG_PCMCIA_RAYCS is not set -# CONFIG_LIBERTAS_THINFIRM is not set -# CONFIG_AIRO is not set -# CONFIG_ATMEL is not set -# CONFIG_AT76C50X_USB is not set -# CONFIG_AIRO_CS is not set -# CONFIG_PCMCIA_WL3501 is not set -# CONFIG_PRISM54 is not set -# CONFIG_USB_ZD1201 is not set -# CONFIG_USB_NET_RNDIS_WLAN is not set -# CONFIG_ADM8211 is not set -# CONFIG_RTL8180 is not set -# CONFIG_RTL8187 is not set -# CONFIG_MAC80211_HWSIM is not set -# CONFIG_MWL8K is not set -# CONFIG_ATH_CARDS is not set -CONFIG_B43=m -CONFIG_B43_BCMA=y -CONFIG_B43_SSB=y -CONFIG_B43_BUSES_BCMA_AND_SSB=y -# CONFIG_B43_BUSES_BCMA is not set -# CONFIG_B43_BUSES_SSB is not set -CONFIG_B43_PCI_AUTOSELECT=y -CONFIG_B43_PCICORE_AUTOSELECT=y -CONFIG_B43_SDIO=y -CONFIG_B43_BCMA_PIO=y -CONFIG_B43_PIO=y -CONFIG_B43_PHY_G=y -CONFIG_B43_PHY_N=y -CONFIG_B43_PHY_LP=y -CONFIG_B43_PHY_HT=y -CONFIG_B43_LEDS=y -CONFIG_B43_HWRNG=y -# CONFIG_B43_DEBUG is not set -# CONFIG_B43LEGACY is not set -# CONFIG_BRCMSMAC is not set -# CONFIG_BRCMFMAC is not set -CONFIG_HOSTAP=m -CONFIG_HOSTAP_FIRMWARE=y -# CONFIG_HOSTAP_FIRMWARE_NVRAM is not set -CONFIG_HOSTAP_PLX=m -CONFIG_HOSTAP_PCI=m -CONFIG_HOSTAP_CS=m +# CONFIG_WLAN_VENDOR_ADMTEK is not set +# CONFIG_WLAN_VENDOR_ATH is not set +# CONFIG_WLAN_VENDOR_ATMEL is not set +# CONFIG_WLAN_VENDOR_BROADCOM is not set +# CONFIG_WLAN_VENDOR_CISCO is not set +CONFIG_WLAN_VENDOR_INTEL=y @@ -2307,0 +2283,2 @@ +# CONFIG_IWL4965 is not set +# CONFIG_IWL3945 is not set @@ -2321,14 +2298,13 @@ -# CONFIG_IWL4965 is not set -# CONFIG_IWL3945 is not set -# CONFIG_LIBERTAS is not set -# CONFIG_HERMES is not set -# CONFIG_P54_COMMON is not set -# CONFIG_RT2X00 is not set -# CONFIG_WL_MEDIATEK is not set -# CONFIG_RTL_CARDS is not set -# CONFIG_RTL8XXXU is not set -# CONFIG_WL_TI is not set -# CONFIG_ZD1211RW is not set -# CONFIG_MWIFIEX is not set -# CONFIG_CW1200 is not set -# CONFIG_RSI_91X is not set +# CONFIG_WLAN_VENDOR_INTERSIL is not set +# CONFIG_WLAN_VENDOR_MARVELL is not set +# CONFIG_WLAN_VENDOR_MEDIATEK is not set +# CONFIG_WLAN_VENDOR_RALINK is not set +# CONFIG_WLAN_VENDOR_REALTEK is not set +# CONFIG_WLAN_VENDOR_RSI is not set +# CONFIG_WLAN_VENDOR_ST is not set +# CONFIG_WLAN_VENDOR_TI is not set +# CONFIG_WLAN_VENDOR_ZYDAS is not set +# CONFIG_PCMCIA_RAYCS is not set +# CONFIG_PCMCIA_WL3501 is not set +# CONFIG_MAC80211_HWSIM is not set +# CONFIG_USB_NET_RNDIS_WLAN is not set @@ -2466,0 +2443 @@ +# CONFIG_TOUCHSCREEN_EGALAX_SERIAL is not set @@ -2612 +2589 @@ -CONFIG_PRINTER=m +CONFIG_PRINTER=y @@ -2614 +2591 @@ -CONFIG_PPDEV=m +CONFIG_PPDEV=y @@ -2766,0 +2744 @@ +# CONFIG_SPI_LOOPBACK_TEST is not set @@ -2826,0 +2805 @@ +# CONFIG_GPIO_104_IDI_48 is not set @@ -2993 +2971,0 @@ -# CONFIG_SENSORS_HTU21 is not set @@ -3090,0 +3069 @@ +CONFIG_WATCHDOG_SYSFS=y @@ -3096,0 +3076 @@ +# CONFIG_ZIIRAVE_WATCHDOG is not set @@ -3151 +3130,0 @@ -CONFIG_SSB_BLOCKIO=y @@ -3154 +3133 @@ -CONFIG_SSB_B43_PCI_BRIDGE=y +# CONFIG_SSB_B43_PCI_BRIDGE is not set @@ -3159 +3137,0 @@ -# CONFIG_SSB_HOST_SOC is not set @@ -3171 +3148,0 @@ -CONFIG_BCMA_BLOCKIO=y @@ -3256,0 +3234,2 @@ +# CONFIG_REGULATOR_PV88060 is not set +# CONFIG_REGULATOR_PV88090 is not set @@ -3565,0 +3545 @@ +# CONFIG_VIDEO_CS3308 is not set @@ -3875 +3854,0 @@ -# CONFIG_DRM_RADEON_UMS is not set @@ -3878,0 +3858 @@ +CONFIG_DRM_AMD_POWERPLAY=y @@ -3917,0 +3898 @@ +CONFIG_FB_NOTIFY=y @@ -4621,0 +4603 @@ +# CONFIG_RTC_DRV_RX8010 is not set @@ -4842 +4823,0 @@ -# CONFIG_IIO_SIMPLE_DUMMY is not set @@ -4870 +4851,2 @@ -# CONFIG_WILC1000_DRIVER is not set +# CONFIG_WILC1000_SDIO is not set +# CONFIG_WILC1000_SPI is not set @@ -4896,0 +4879 @@ +# CONFIG_ASUS_WIRELESS is not set @@ -4901,0 +4885 @@ +CONFIG_INTEL_HID_EVENT=m @@ -4912,0 +4897 @@ +CONFIG_INTEL_PUNIT_IPC=m @@ -4921,0 +4907,2 @@ +# CONFIG_COMMON_CLK_CS2000_CP is not set +# CONFIG_COMMON_CLK_NXP is not set @@ -4978,0 +4966 @@ +# CONFIG_IIO_CONFIGFS is not set @@ -4980,0 +4969 @@ +# CONFIG_IIO_SW_TRIGGER is not set @@ -4989,0 +4979,2 @@ +# CONFIG_MMA7455_I2C is not set +# CONFIG_MMA7455_SPI is not set @@ -4993,0 +4985 @@ +# CONFIG_MXC6255 is not set @@ -5010,0 +5003 @@ +# CONFIG_INA2XX_ADC is not set @@ -5028,0 +5022 @@ +# CONFIG_IAQCORE is not set @@ -5061,0 +5056,5 @@ +# IIO dummy driver +# +# CONFIG_IIO_SIMPLE_DUMMY is not set + +# @@ -5087,0 +5087,5 @@ +# Health sensors +# +# CONFIG_MAX30100 is not set + +# @@ -5188,0 +5193,2 @@ +CONFIG_ARM_GIC_MAX_NR=1 +# CONFIG_TS4800_IRQ is not set @@ -5297,0 +5304 @@ +# CONFIG_MANDATORY_FILE_LOCKING is not set @@ -5574,0 +5582 @@ +# CONFIG_WQ_WATCHDOG is not set @@ -5616,0 +5625 @@ +# CONFIG_DEBUG_WQ_FORCE_RR_CPU is not set @@ -5692,0 +5702,3 @@ +CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y +# CONFIG_UBSAN is not set +CONFIG_ARCH_HAS_DEVMEM_IS_ALLOWED=y @@ -5693,0 +5706 @@ +CONFIG_IO_STRICT_DEVMEM=y @@ -5749,0 +5763 @@ +# CONFIG_INTEGRITY_TRUSTED_KEYRING is not set @@ -5930,0 +5945,2 @@ +CONFIG_CRYPTO_DEV_QAT_C3XXX=m +CONFIG_CRYPTO_DEV_QAT_C62X=m @@ -5931,0 +5948,2 @@ +CONFIG_CRYPTO_DEV_QAT_C3XXXVF=m +CONFIG_CRYPTO_DEV_QAT_C62XVF=m @@ -6040,0 +6059 @@ +# CONFIG_IRQ_POLL is not set > * try to reproduce on debian testing or even stable. I have had similar > issues with debian unstable in the past. Gut feeling is that this is not the case. Why would it only appear on VM hosts then? Debian unstable and testing are pretty close together these days, and the issue is around for a month now in current unstable. Btw, I am a DD, I know my way around debian and my gut feeling is pretty well calibrated here. I can try stable in the VM, but I'd rather not take the host out of business. Would that help? My CPU is also rather old: processor : 5 vendor_id : AuthenticAMD cpu family : 16 model : 10 model name : AMD Phenom(tm) II X6 1090T Processor stepping : 0 microcode : 0x10000dc cpu MHz : 1600.000 cache size : 512 KB physical id : 0 siblings : 6 core id : 5 cpu cores : 6 apicid : 5 initial apicid : 5 fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr cpb hw_pstate vmmcall npt lbrv svm_lock nrip_save pausefilter bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs bogomips : 6428.52 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate cpb afaik, this CPU is not affected by the current microcode issues, isn't it? I do have the amd64-microcode package installed, which is supposed to do everything automatically, and my initramfs doesn't have a microcode "partition" prepended, gunzip | cpio -i gives the plain initramfs contents directly. 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Major KVM issues with kernel 4.5 on the host 2016-03-19 0:08 ` Marc Haber 2016-03-20 13:31 ` Borislav Petkov @ 2016-03-21 9:08 ` Paolo Bonzini 1 sibling, 0 replies; 49+ messages in thread From: Paolo Bonzini @ 2016-03-21 9:08 UTC (permalink / raw) To: Marc Haber, Borislav Petkov; +Cc: linux-kernel, kvm ML On 19/03/2016 01:08, Marc Haber wrote: >> > >>> > > http://q.bofh.de/~mh/stuff/20160317-fan-syslog-kvm-4.5 >> > >> > This one doesn't want: >> > >> > HTTP request sent, awaiting response... 403 Forbidden >> > 2016-03-18 22:57:46 ERROR 403: Forbidden. > Idiot me. File permissions fixed. > >> > Anything special you're doing to cause the host kernel to barf which I >> > should do here? > Booting Debian Linux, apt-get update, apt-get upgrade, and run aide > (which builds checksums for the entire filesystem, a rather disk-bound > activity). Ok, so this is AMD. I'll take a look. Paolo ^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~2016-05-14 6:19 UTC | newest] Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-03-17 16:54 Major KVM issues with kernel 4.5 on the host Marc Haber 2016-03-17 18:11 ` Borislav Petkov 2016-03-18 10:01 ` Paolo Bonzini 2016-04-13 18:37 ` Marc Haber 2016-04-13 20:36 ` Paolo Bonzini 2016-04-13 20:52 ` Marc Haber 2016-04-13 22:29 ` Marc Haber 2016-04-14 1:16 ` Paolo Bonzini 2016-04-14 5:22 ` Marc Haber 2016-04-21 8:39 ` Marc Haber 2016-04-21 12:37 ` Borislav Petkov 2016-04-21 14:50 ` Marc Haber 2016-04-21 16:51 ` Borislav Petkov 2016-04-21 20:04 ` Marc Haber 2016-04-23 16:04 ` Borislav Petkov 2016-04-23 18:43 ` Marc Haber 2016-04-23 18:52 ` Dr. David Alan Gilbert 2016-05-12 20:20 ` transparent huge pages breaks KVM on AMD Marc Haber 2016-05-12 20:24 ` Kirill A. Shutemov 2016-05-12 20:34 ` Marc Haber 2016-05-12 20:42 ` Kirill A. Shutemov 2016-05-13 5:23 ` Marc Haber 2016-05-13 8:07 ` Borislav Petkov 2016-05-13 8:09 ` Borislav Petkov 2016-05-13 13:21 ` Marc Haber 2016-05-13 16:08 ` Borislav Petkov 2016-05-14 6:19 ` Marc Haber 2016-05-13 9:08 ` Marc Haber 2016-05-13 9:19 ` Borislav Petkov 2016-05-13 14:59 ` Marc Haber 2016-05-13 8:35 ` Dr. David Alan Gilbert 2016-05-13 14:03 ` Marc Haber 2016-04-23 23:57 ` Major KVM issues with kernel 4.5 on the host Borislav Petkov 2016-04-14 6:07 ` Marc Haber 2016-04-14 16:47 ` Marc Haber 2016-04-14 17:30 ` Paolo Bonzini 2016-04-14 17:47 ` Marc Haber 2016-03-18 18:49 ` Marc Haber 2016-03-18 22:04 ` Borislav Petkov 2016-03-19 0:08 ` Marc Haber 2016-03-20 13:31 ` Borislav Petkov 2016-03-20 17:14 ` Andrey Korolyov 2016-03-20 18:25 ` Borislav Petkov 2016-03-20 18:42 ` Andrey Korolyov 2016-03-20 18:58 ` Borislav Petkov 2016-04-13 18:22 ` Marc Haber 2016-04-13 20:37 ` Paolo Bonzini 2016-04-13 18:20 ` Marc Haber 2016-03-21 9:08 ` Paolo Bonzini
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).