* [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
@ 2014-03-10 10:04 Julian Wollrath
2014-03-10 10:27 ` Paul Bolle
2014-03-10 10:39 ` Thomas Gleixner
0 siblings, 2 replies; 41+ messages in thread
From: Julian Wollrath @ 2014-03-10 10:04 UTC (permalink / raw)
To: x86; +Cc: linux-kernel
Hi,
on a Thinkpad x121e (AMD E-450 APU) with version 3.13.5 and earlier of
the kernel I get:
[...]
[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.001000] tsc: Detected 1646.619 MHz processor
[ 0.000004] Calibrating delay loop (skipped), value calculated using
timer frequency.. 3293.23 BogoMIPS (lpj=1646619)
[...]
but starting with v3.14-rc1 the fast TSC calibration fails:
[...]
[ 0.000000] tsc: Fast TSC calibration failed
[ 0.000000] tsc: PIT calibration matches HPET. 1 loops
[ 0.000000] tsc: Detected 1646.490 MHz processor
[...]
If you need more information, please do not hesitate to ask.
With best regards,
Julian Wollrath
Full dmesg output:
[ 0.000000] Linux version 3.14.0-rc5 (wolle@ilfaris) (gcc version
4.8.2 (Debian 4.8.2-16) ) #1 SMP Mon Mar 3 16:13:57 CET 2014
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.14.0-rc5
root=/dev/mapper/encrypted-root ro quiet [ 0.000000] e820:
BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem
0x0000000000000000-0x000000000009d7ff] usable [ 0.000000] BIOS-e820:
[mem 0x000000000009d800-0x000000000009ffff] reserved [ 0.000000]
BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000c6ceafff]
usable [ 0.000000] BIOS-e820: [mem
0x00000000c6ceb000-0x00000000c70fafff] reserved [ 0.000000]
BIOS-e820: [mem 0x00000000c70fb000-0x00000000c717afff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x00000000c717b000-0x00000000c71dafff]
ACPI data [ 0.000000] BIOS-e820: [mem
0x00000000c71db000-0x00000000c7bfffff] usable [ 0.000000] BIOS-e820:
[mem 0x00000000c7c00000-0x00000000c7ffffff] reserved [ 0.000000]
BIOS-e820: [mem 0x00000000fec00000-0x00000000fecfffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed80000-0x00000000fed80fff]
reserved [ 0.000000] BIOS-e820: [mem
0x00000000ffe00000-0x00000000ffffffff] reserved [ 0.000000]
BIOS-e820: [mem 0x0000000100000000-0x000000011effffff] usable
[ 0.000000] NX (Execute Disable) protection: active [ 0.000000]
SMBIOS 2.6 present. [ 0.000000] DMI: LENOVO 30515YG/30515YG, BIOS
8RET52WW (1.15 ) 11/15/2011 [ 0.000000] e820: update [mem
0x00000000-0x00000fff] usable ==> reserved [ 0.000000] e820: remove
[mem 0x000a0000-0x000fffff] usable [ 0.000000] No AGP bridge found
[ 0.000000] e820: last_pfn = 0x11f000 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-BFFFF uncachable [ 0.000000] C0000-FFFFF
write-protect [ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 base 000000000 mask F80000000 write-back
[ 0.000000] 1 base 080000000 mask FC0000000 write-back
[ 0.000000] 2 base 0C0000000 mask FF8000000 write-back
[ 0.000000] 3 base 0FFF90000 mask FFFFF0000 uncachable
[ 0.000000] 4 base 0FED80000 mask FFFFFF000 uncachable
[ 0.000000] 5 disabled [ 0.000000] 6 disabled
[ 0.000000] 7 base 0FFE00000 mask FFFE00000 write-protect
[ 0.000000] TOM2: 000000011f000000 aka 4592M [ 0.000000] x86 PAT
enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000]
e820: last_pfn = 0xc7c00 max_arch_pfn = 0x400000000 [ 0.000000] Base
memory trampoline at [ffff880000097000] 97000 size 24576 [ 0.000000]
Using GB pages for direct mapping [ 0.000000] init_memory_mapping:
[mem 0x00000000-0x000fffff] [ 0.000000] [mem 0x00000000-0x000fffff]
page 4k [ 0.000000] BRK [0x01a2d000, 0x01a2dfff] PGTABLE
[ 0.000000] BRK [0x01a2e000, 0x01a2efff] PGTABLE
[ 0.000000] BRK [0x01a2f000, 0x01a2ffff] PGTABLE
[ 0.000000] init_memory_mapping: [mem 0x11ee00000-0x11effffff]
[ 0.000000] [mem 0x11ee00000-0x11effffff] page 2M
[ 0.000000] BRK [0x01a30000, 0x01a30fff] PGTABLE
[ 0.000000] init_memory_mapping: [mem 0x11c000000-0x11edfffff]
[ 0.000000] [mem 0x11c000000-0x11edfffff] page 2M
[ 0.000000] init_memory_mapping: [mem 0x100000000-0x11bffffff]
[ 0.000000] [mem 0x100000000-0x11bffffff] page 2M
[ 0.000000] init_memory_mapping: [mem 0x00100000-0xc6ceafff]
[ 0.000000] [mem 0x00100000-0x001fffff] page 4k
[ 0.000000] [mem 0x00200000-0x3fffffff] page 2M
[ 0.000000] [mem 0x40000000-0xbfffffff] page 1G
[ 0.000000] [mem 0xc0000000-0xc6bfffff] page 2M
[ 0.000000] [mem 0xc6c00000-0xc6ceafff] page 4k
[ 0.000000] init_memory_mapping: [mem 0xc71db000-0xc7bfffff]
[ 0.000000] [mem 0xc71db000-0xc71fffff] page 4k
[ 0.000000] [mem 0xc7200000-0xc7bfffff] page 2M
[ 0.000000] BRK [0x01a31000, 0x01a31fff] PGTABLE
[ 0.000000] RAMDISK: [mem 0x376c2000-0x37b58fff]
[ 0.000000] ACPI: RSDP 00000000000f00e0 000024 (v04 LENOVO)
[ 0.000000] ACPI: XSDT 00000000c71da120 000074 (v01 LENOVO TP-8R
00000003 PTEC 00000002) [ 0.000000] ACPI: FACP 00000000c71c5000
0000F4 (v04 LENOVO TP-8R 00001150 PTL 00000002) [ 0.000000]
ACPI: DSDT 00000000c71c7000 0112E1 (v01 LENOVO TP-8R 00001000 PTEC
00001150) [ 0.000000] ACPI: FACS 00000000c7166000 000040
[ 0.000000] ACPI: SLIC 00000000c71d9000 000176 (v01 LENOVO TP-8R
00001150 PTEC 00000001) [ 0.000000] ACPI: HPET 00000000c71c4000
000038 (v01 LENOVO TP-8R 00001150 PTL 00000002) [ 0.000000]
ACPI: APIC 00000000c71c3000 00005E (v02 LENOVO TP-8R 00001150 PTL
00000002) [ 0.000000] ACPI: MCFG 00000000c71c2000 00003C (v01 LENOVO
TP-8R 00001150 PTL 00000002) [ 0.000000] ACPI: UEFI
00000000c71c1000 00003E (v01 LENOVO TP-8R 00001150 PTL 00000002)
[ 0.000000] ACPI: UEFI 00000000c71c0000 000042 (v01 PTL COMBUF
00000001 PTL 00000001) [ 0.000000] ACPI: SSDT 00000000c71bf000
0003DE (v01 AMD POWERNOW 00000001 AMD 00000001) [ 0.000000]
ACPI: SSDT 00000000c71bd000 00168E (v02 AMD ALIB 00000001 MSFT
04000000) [ 0.000000] ACPI: UEFI 00000000c71bc000 00013E (v01 LENOVO
TP-8R 00001150 PTL 00000002) [ 0.000000] ACPI: Local APIC
address 0xfee00000 [ 0.000000] [ffffea0000000000-ffffea0003ffffff]
PMD -> [ffff88011ac00000-ffff88011dffffff] on node 0 [ 0.000000]
Zone ranges: [ 0.000000] DMA [mem 0x00001000-0x00ffffff]
[ 0.000000] DMA32 [mem 0x01000000-0xffffffff] [ 0.000000]
Normal [mem 0x100000000-0x11effffff] [ 0.000000] Movable zone
start for each node [ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x00001000-0x0009cfff] [ 0.000000]
node 0: [mem 0x00100000-0xc6ceafff] [ 0.000000] node 0: [mem
0xc71db000-0xc7bfffff] [ 0.000000] node 0: [mem
0x100000000-0x11effffff] [ 0.000000] On node 0 totalpages: 943788
[ 0.000000] DMA zone: 56 pages used for memmap [ 0.000000]
DMA zone: 21 pages reserved [ 0.000000] DMA zone: 3996 pages, LIFO
batch:0 [ 0.000000] DMA32 zone: 11113 pages used for memmap
[ 0.000000] DMA32 zone: 812816 pages, LIFO batch:31
[ 0.000000] Normal zone: 1736 pages used for memmap
[ 0.000000] Normal zone: 126976 pages, LIFO batch:31
[ 0.000000] ACPI: PM-Timer IO Port: 0x808 [ 0.000000] ACPI: Local
APIC address 0xfee00000 [ 0.000000] ACPI: LAPIC (acpi_id[0x00]
lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x01]
lapic_id[0x01] enabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00]
high edge lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high
edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x02]
address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 2,
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:
IRQ0 used by override. [ 0.000000] ACPI: IRQ2 used by override.
[ 0.000000] ACPI: IRQ9 used by override.
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] ACPI: HPET id: 0x43538210 base: 0xfed00000
[ 0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs
[ 0.000000] nr_irqs_gsi: 40
[ 0.000000] PM: Registered nosave memory: [mem 0x0009d000-0x0009dfff]
[ 0.000000] PM: Registered nosave memory: [mem 0x0009e000-0x0009ffff]
[ 0.000000] PM: Registered nosave memory: [mem 0x000a0000-0x000dffff]
[ 0.000000] PM: Registered nosave memory: [mem 0x000e0000-0x000fffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xc6ceb000-0xc70fafff]
[ 0.000000] PM: Registered nosave memory: [mem 0xc70fb000-0xc717afff]
[ 0.000000] PM: Registered nosave memory: [mem 0xc717b000-0xc71dafff]
[ 0.000000] PM: Registered nosave memory: [mem 0xc7c00000-0xc7ffffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xc8000000-0xfebfffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xfec00000-0xfecfffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xfed00000-0xfed7ffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xfed80000-0xfed80fff]
[ 0.000000] PM: Registered nosave memory: [mem 0xfed81000-0xffdfffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xffe00000-0xffffffff]
[ 0.000000] e820: [mem 0xc8000000-0xfebfffff] available for PCI
devices [ 0.000000] setup_percpu: NR_CPUS:2 nr_cpumask_bits:2
nr_cpu_ids:2 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 27 pages/cpu
@ffff88011ec00000 s80064 r8192 d22336 u1048576 [ 0.000000]
pcpu-alloc: s80064 r8192 d22336 u1048576 alloc=1*2097152 [ 0.000000]
pcpu-alloc: [0] 0 1 [ 0.000000] Built 1 zonelists in Zone order,
mobility grouping on. Total pages: 930862 [ 0.000000] Kernel
command line: BOOT_IMAGE=/vmlinuz-3.14.0-rc5
root=/dev/mapper/encrypted-root ro quiet [ 0.000000] PID hash table
entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Dentry cache hash
table entries: 524288 (order: 10, 4194304 bytes) [ 0.000000]
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
[ 0.000000] Checking aperture... [ 0.000000] No AGP bridge found
[ 0.000000] Memory: 3634188K/3775152K available (4378K kernel code,
586K rwdata, 1428K rodata, 836K init, 776K bss, 140964K reserved)
[ 0.000000] Hierarchical RCU implementation. [ 0.000000]
RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000]
NR_IRQS:4352 nr_irqs:512 16 [ 0.000000] ACPI: Core revision 20131218
[ 0.000000] ACPI: All ACPI Tables successfully acquired
[ 0.000000] spurious 8259A interrupt: IRQ7. [ 0.000000] Console:
colour VGA+ 80x25 [ 0.000000] console [tty0] enabled
[ 0.000000] hpet clockevent registered
[ 0.000000] tsc: Fast TSC calibration failed
[ 0.000000] tsc: PIT calibration matches HPET. 1 loops
[ 0.000000] tsc: Detected 1646.490 MHz processor
[ 0.000044] Calibrating delay loop (skipped), value calculated using
timer frequency.. 3292.98 BogoMIPS (lpj=1646490) [ 0.000049]
pid_max: default: 32768 minimum: 301 [ 0.000113] Mount-cache hash
table entries: 256 [ 0.000420] tseg: 00c7c00000
[ 0.000424] CPU: Physical Processor ID: 0
[ 0.000426] CPU: Processor Core ID: 0
[ 0.000429] mce: CPU supports 6 MCE banks
[ 0.000444] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 4
[ 0.000444] Last level dTLB entries: 4KB 512, 2MB 8, 4MB 4, 1GB 0
[ 0.000444] tlb_flushall_shift: 6
[ 0.000610] Freeing SMP alternatives memory: 16K (ffffffff81965000 -
ffffffff81969000) [ 0.001115] ..TIMER: vector=0x30 apic1=0 pin1=2
apic2=-1 pin2=-1 [ 0.011123] smpboot: CPU0: AMD E-450 APU with
Radeon(tm) HD Graphics (fam: 14, model: 02, stepping: 00)
[ 0.112402] Performance Events: AMD PMU driver. [ 0.112410] ...
version: 0 [ 0.112412] ... bit width: 48
[ 0.112414] ... generic registers: 4
[ 0.112416] ... value mask: 0000ffffffffffff
[ 0.112419] ... max period: 00007fffffffffff
[ 0.112421] ... fixed-purpose events: 0
[ 0.112423] ... event mask: 000000000000000f
[ 0.112936] x86: Booting SMP configuration:
[ 0.112942] .... node #0, CPUs: #1
[ 0.126168] x86: Booted up 1 node, 2 CPUs
[ 0.126172] smpboot: Total of 2 processors activated (6585.96
BogoMIPS) [ 0.126852] devtmpfs: initialized
[ 0.127236] PM: Registering ACPI NVS region [mem
0xc70fb000-0xc717afff] (524288 bytes) [ 0.127623] NET: Registered
protocol family 16 [ 0.127764] cpuidle: using governor ladder
[ 0.127768] cpuidle: using governor menu
[ 0.127943] ACPI: bus type PCI registered
[ 0.128062] PCI: MMCONFIG for domain 0000 [bus 00-1f] at [mem
0xf8000000-0xf9ffffff] (base 0xf8000000) [ 0.128067] PCI: not using
MMCONFIG [ 0.128070] PCI: Using configuration type 1 for base access
[ 0.128072] PCI: Using configuration type 1 for extended access
[ 0.129325] bio: create slab <bio-0> at 0
[ 0.129525] ACPI: Added _OSI(Module Device)
[ 0.129529] ACPI: Added _OSI(Processor Device)
[ 0.129532] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.129534] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.143453] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
[ 0.150390] ACPI: Interpreter enabled
[ 0.150408] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep
State [\_S1_] (20131218/hwxface-580) [ 0.150417] ACPI Exception:
AE_NOT_FOUND, While evaluating Sleep State [\_S2_]
(20131218/hwxface-580) [ 0.150441] ACPI: (supports S0 S3 S4 S5)
[ 0.150445] ACPI: Using IOAPIC for interrupt routing [ 0.150712]
PCI: MMCONFIG for domain 0000 [bus 00-1f] at [mem
0xf8000000-0xf9ffffff] (base 0xf8000000) [ 0.151180] PCI: MMCONFIG
at [mem 0xf8000000-0xf9ffffff] reserved in ACPI motherboard resources
[ 0.153412] PCI: Using host bridge windows from ACPI; if necessary,
use "pci=nocrs" and report a bug [ 0.154324] [Firmware Bug]: ACPI:
No _BQC method, cannot determine initial brightness [ 0.154349]
[Firmware Bug]: ACPI: No _BQC method, cannot determine initial
brightness [ 0.165487] [Firmware Bug]: ACPI: No _BQC method, cannot
determine initial brightness [ 0.165529] [Firmware Bug]: ACPI: No
_BQC method, cannot determine initial brightness [ 0.169424] ACPI:
PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.169440] acpi
PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments
MSI] [ 0.170026] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug
PME AER PCIeCapability] [ 0.171823] acpi PNP0A08:00: ignoring host
bridge window [mem 0x000ce000-0x000cffff] (conflicts with Video ROM
[mem 0x000c0000-0x000ce5ff]) [ 0.171834] acpi PNP0A08:00: [Firmware
Info]: MMCONFIG for domain 0000 [bus 00-1f] only partially covers this
bridge [ 0.171891] PCI host bridge to bus 0000:00 [ 0.171897]
pci_bus 0000:00: root bus resource [bus 00-ff] [ 0.171902] pci_bus
0000:00: root bus resource [mem 0x000a0000-0x000bffff] [ 0.171906]
pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000c1fff]
[ 0.171910] pci_bus 0000:00: root bus resource [mem
0x000c2000-0x000c3fff] [ 0.171914] pci_bus 0000:00: root bus
resource [mem 0x000c4000-0x000c5fff] [ 0.171917] pci_bus 0000:00:
root bus resource [mem 0x000c6000-0x000c7fff] [ 0.171921] pci_bus
0000:00: root bus resource [mem 0x000c8000-0x000c9fff] [ 0.171925]
pci_bus 0000:00: root bus resource [mem 0x000ca000-0x000cbfff]
[ 0.171929] pci_bus 0000:00: root bus resource [mem
0x000cc000-0x000cdfff] [ 0.171932] pci_bus 0000:00: root bus
resource [mem 0x000d0000-0x000d1fff] [ 0.171937] pci_bus 0000:00:
root bus resource [mem 0x000d2000-0x000d3fff] [ 0.171940] pci_bus
0000:00: root bus resource [mem 0x000d4000-0x000d5fff] [ 0.171944]
pci_bus 0000:00: root bus resource [mem 0x000d6000-0x000d7fff]
[ 0.171947] pci_bus 0000:00: root bus resource [mem
0x000d8000-0x000d9fff] [ 0.171951] pci_bus 0000:00: root bus
resource [mem 0x000da000-0x000dbfff] [ 0.171955] pci_bus 0000:00:
root bus resource [mem 0x000dc000-0x000ddfff] [ 0.171958] pci_bus
0000:00: root bus resource [mem 0x000de000-0x000dffff] [ 0.171962]
pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000e1fff]
[ 0.171965] pci_bus 0000:00: root bus resource [mem
0x000e2000-0x000e3fff] [ 0.171969] pci_bus 0000:00: root bus
resource [mem 0x000e4000-0x000e5fff] [ 0.171972] pci_bus 0000:00:
root bus resource [mem 0x000e6000-0x000e7fff] [ 0.171976] pci_bus
0000:00: root bus resource [mem 0x000e8000-0x000e9fff] [ 0.171980]
pci_bus 0000:00: root bus resource [mem 0x000ea000-0x000ebfff]
[ 0.171983] pci_bus 0000:00: root bus resource [mem
0x000ec000-0x000edfff] [ 0.171987] pci_bus 0000:00: root bus
resource [mem 0x000ee000-0x000effff] [ 0.171990] pci_bus 0000:00:
root bus resource [mem 0xe0000000-0xf7ffffff] [ 0.171994] pci_bus
0000:00: root bus resource [mem 0xf8000000-0xffffffff] [ 0.171998]
pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7] [ 0.172001]
pci_bus 0000:00: root bus resource [io 0x0d00-0xffff] [ 0.172017]
pci 0000:00:00.0: [1022:1510] type 00 class 0x060000 [ 0.172182] pci
0000:00:01.0: [1002:9806] type 00 class 0x030000 [ 0.172198] pci
0000:00:01.0: reg 0x10: [mem 0xe0000000-0xefffffff pref] [ 0.172209]
pci 0000:00:01.0: reg 0x14: [io 0x3000-0x30ff] [ 0.172220] pci
0000:00:01.0: reg 0x18: [mem 0xf0300000-0xf033ffff] [ 0.172286] pci
0000:00:01.0: supports D1 D2 [ 0.172409] pci 0000:00:01.1:
[1002:1314] type 00 class 0x040300 [ 0.172423] pci 0000:00:01.1: reg
0x10: [mem 0xf0344000-0xf0347fff] [ 0.172498] pci 0000:00:01.1:
supports D1 D2 [ 0.172668] pci 0000:00:04.0: [1022:1512] type 01
class 0x060400 [ 0.172749] pci 0000:00:04.0: PME# supported from D0
D3hot D3cold [ 0.172826] pci 0000:00:04.0: System wakeup disabled by
ACPI [ 0.172902] pci 0000:00:06.0: [1022:1514] type 01 class
0x060400 [ 0.172981] pci 0000:00:06.0: PME# supported from D0 D3hot
D3cold [ 0.173056] pci 0000:00:06.0: System wakeup disabled by ACPI
[ 0.173133] pci 0000:00:07.0: [1022:1515] type 01 class 0x060400
[ 0.173217] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
[ 0.173291] pci 0000:00:07.0: System wakeup disabled by ACPI
[ 0.173426] pci 0000:00:11.0: [1002:4391] type 00 class 0x010601
[ 0.173454] pci 0000:00:11.0: reg 0x10: [io 0x3118-0x311f]
[ 0.173468] pci 0000:00:11.0: reg 0x14: [io 0x3124-0x3127]
[ 0.173482] pci 0000:00:11.0: reg 0x18: [io 0x3110-0x3117]
[ 0.173497] pci 0000:00:11.0: reg 0x1c: [io 0x3120-0x3123]
[ 0.173511] pci 0000:00:11.0: reg 0x20: [io 0x3100-0x310f]
[ 0.173526] pci 0000:00:11.0: reg 0x24: [mem 0xf034a000-0xf034a3ff]
[ 0.173748] pci 0000:00:12.0: [1002:4397] type 00 class 0x0c0310
[ 0.173768] pci 0000:00:12.0: reg 0x10: [mem 0xf0349000-0xf0349fff]
[ 0.173926] pci 0000:00:12.0: System wakeup disabled by ACPI
[ 0.174002] pci 0000:00:12.2: [1002:4396] type 00 class 0x0c0320
[ 0.174029] pci 0000:00:12.2: reg 0x10: [mem 0xf034a500-0xf034a5ff]
[ 0.174140] pci 0000:00:12.2: supports D1 D2 [ 0.174143] pci
0000:00:12.2: PME# supported from D0 D1 D2 D3hot [ 0.174238] pci
0000:00:12.2: System wakeup disabled by ACPI [ 0.174361] pci
0000:00:13.0: [1002:4397] type 00 class 0x0c0310 [ 0.174381] pci
0000:00:13.0: reg 0x10: [mem 0xf0348000-0xf0348fff] [ 0.174534] pci
0000:00:13.0: System wakeup disabled by ACPI [ 0.174658] pci
0000:00:13.2: [1002:4396] type 00 class 0x0c0320 [ 0.174685] pci
0000:00:13.2: reg 0x10: [mem 0xf034a400-0xf034a4ff] [ 0.174795] pci
0000:00:13.2: supports D1 D2 [ 0.174799] pci 0000:00:13.2: PME#
supported from D0 D1 D2 D3hot [ 0.174968] pci 0000:00:14.0:
[1002:4385] type 00 class 0x0c0500 [ 0.175164] pci 0000:00:14.2:
[1002:4383] type 00 class 0x040300 [ 0.175196] pci 0000:00:14.2: reg
0x10: [mem 0xf0340000-0xf0343fff 64bit] [ 0.175285] pci
0000:00:14.2: PME# supported from D0 D3hot D3cold [ 0.175355] pci
0000:00:14.2: System wakeup disabled by ACPI [ 0.175470] pci
0000:00:14.3: [1002:439d] type 00 class 0x060100 [ 0.175714] pci
0000:00:14.4: [1002:4384] type 01 class 0x060401 [ 0.175821] pci
0000:00:14.4: System wakeup disabled by ACPI [ 0.175895] pci
0000:00:18.0: [1022:1700] type 00 class 0x060000 [ 0.176039] pci
0000:00:18.1: [1022:1701] type 00 class 0x060000 [ 0.176177] pci
0000:00:18.2: [1022:1702] type 00 class 0x060000 [ 0.176313] pci
0000:00:18.3: [1022:1703] type 00 class 0x060000 [ 0.176464] pci
0000:00:18.4: [1022:1704] type 00 class 0x060000 [ 0.176599] pci
0000:00:18.5: [1022:1718] type 00 class 0x060000 [ 0.176734] pci
0000:00:18.6: [1022:1716] type 00 class 0x060000 [ 0.176866] pci
0000:00:18.7: [1022:1719] type 00 class 0x060000 [ 0.177169] pci
0000:01:00.0: [8086:4239] type 00 class 0x028000 [ 0.177262] pci
0000:01:00.0: reg 0x10: [mem 0xf0200000-0xf0201fff 64bit]
[ 0.177507] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[ 0.180291] pci 0000:00:04.0: PCI bridge to [bus 01] [ 0.180310]
pci 0000:00:04.0: bridge window [mem 0xf0200000-0xf02fffff]
[ 0.180416] pci 0000:02:00.0: [1969:1083] type 00 class 0x020000
[ 0.180443] pci 0000:02:00.0: reg 0x10: [mem 0xf0100000-0xf013ffff
64bit] [ 0.180459] pci 0000:02:00.0: reg 0x18: [io 0x2000-0x207f]
[ 0.180574] pci 0000:02:00.0: PME# supported from D0 D1 D2 D3hot
D3cold [ 0.183220] pci 0000:00:06.0: PCI bridge to [bus 02]
[ 0.183246] pci 0000:00:06.0: bridge window [io 0x2000-0x2fff]
[ 0.183259] pci 0000:00:06.0: bridge window [mem
0xf0100000-0xf01fffff] [ 0.183430] pci 0000:03:00.0: [10ec:5209]
type 00 class 0xff0000 [ 0.183456] pci 0000:03:00.0: reg 0x10: [mem
0xf0000000-0xf0000fff] [ 0.183528] pci 0000:03:00.0: reg 0x30: [mem
0xffff0000-0xffffffff pref] [ 0.183605] pci 0000:03:00.0: supports
D1 D2 [ 0.183609] pci 0000:03:00.0: PME# supported from D1 D2 D3hot
[ 0.186193] pci 0000:00:07.0: PCI bridge to [bus 03] [ 0.186210]
pci 0000:00:07.0: bridge window [mem 0xf0000000-0xf00fffff]
[ 0.186442] pci 0000:00:14.4: PCI bridge to [bus 04] (subtractive
decode) [ 0.186456] pci 0000:00:14.4: bridge window [mem
0x000a0000-0x000bffff] (subtractive decode) [ 0.186460] pci
0000:00:14.4: bridge window [mem 0x000c0000-0x000c1fff] (subtractive
decode) [ 0.186465] pci 0000:00:14.4: bridge window [mem
0x000c2000-0x000c3fff] (subtractive decode) [ 0.186468] pci
0000:00:14.4: bridge window [mem 0x000c4000-0x000c5fff] (subtractive
decode) [ 0.186472] pci 0000:00:14.4: bridge window [mem
0x000c6000-0x000c7fff] (subtractive decode) [ 0.186476] pci
0000:00:14.4: bridge window [mem 0x000c8000-0x000c9fff] (subtractive
decode) [ 0.186480] pci 0000:00:14.4: bridge window [mem
0x000ca000-0x000cbfff] (subtractive decode) [ 0.186483] pci
0000:00:14.4: bridge window [mem 0x000cc000-0x000cdfff] (subtractive
decode) [ 0.186487] pci 0000:00:14.4: bridge window [mem
0x000d0000-0x000d1fff] (subtractive decode) [ 0.186491] pci
0000:00:14.4: bridge window [mem 0x000d2000-0x000d3fff] (subtractive
decode) [ 0.186494] pci 0000:00:14.4: bridge window [mem
0x000d4000-0x000d5fff] (subtractive decode) [ 0.186498] pci
0000:00:14.4: bridge window [mem 0x000d6000-0x000d7fff] (subtractive
decode) [ 0.186502] pci 0000:00:14.4: bridge window [mem
0x000d8000-0x000d9fff] (subtractive decode) [ 0.186506] pci
0000:00:14.4: bridge window [mem 0x000da000-0x000dbfff] (subtractive
decode) [ 0.186509] pci 0000:00:14.4: bridge window [mem
0x000dc000-0x000ddfff] (subtractive decode) [ 0.186513] pci
0000:00:14.4: bridge window [mem 0x000de000-0x000dffff] (subtractive
decode) [ 0.186517] pci 0000:00:14.4: bridge window [mem
0x000e0000-0x000e1fff] (subtractive decode) [ 0.186520] pci
0000:00:14.4: bridge window [mem 0x000e2000-0x000e3fff] (subtractive
decode) [ 0.186524] pci 0000:00:14.4: bridge window [mem
0x000e4000-0x000e5fff] (subtractive decode) [ 0.186528] pci
0000:00:14.4: bridge window [mem 0x000e6000-0x000e7fff] (subtractive
decode) [ 0.186531] pci 0000:00:14.4: bridge window [mem
0x000e8000-0x000e9fff] (subtractive decode) [ 0.186535] pci
0000:00:14.4: bridge window [mem 0x000ea000-0x000ebfff] (subtractive
decode) [ 0.186539] pci 0000:00:14.4: bridge window [mem
0x000ec000-0x000edfff] (subtractive decode) [ 0.186542] pci
0000:00:14.4: bridge window [mem 0x000ee000-0x000effff] (subtractive
decode) [ 0.186546] pci 0000:00:14.4: bridge window [mem
0xe0000000-0xf7ffffff] (subtractive decode) [ 0.186550] pci
0000:00:14.4: bridge window [mem 0xf8000000-0xffffffff] (subtractive
decode) [ 0.186554] pci 0000:00:14.4: bridge window [io
0x0000-0x0cf7] (subtractive decode) [ 0.186557] pci 0000:00:14.4:
bridge window [io 0x0d00-0xffff] (subtractive decode) [ 0.186674]
pci_bus 0000:00: on NUMA node 0 [ 0.187344] ACPI: PCI Interrupt Link
[LNKA] (IRQs 10 11) *0 [ 0.187511] ACPI: PCI Interrupt Link [LNKB]
(IRQs 10 11) *0 [ 0.187635] ACPI: PCI Interrupt Link [LNKC] (IRQs 10
11) *0 [ 0.187757] ACPI: PCI Interrupt Link [LNKD] (IRQs 10 11) *0
[ 0.187859] ACPI: PCI Interrupt Link [LNKE] (IRQs 10 11) *0
[ 0.187939] ACPI: PCI Interrupt Link [LNKF] (IRQs 10 11) *0
[ 0.188019] ACPI: PCI Interrupt Link [LNKG] (IRQs 10 11) *0
[ 0.188100] ACPI: PCI Interrupt Link [LNKH] (IRQs 10 11) *0
[ 0.188741] ACPI: Enabled 2 GPEs in block 00 to 1F [ 0.188869]
ACPI : EC: GPE = 0x3, I/O: command/status = 0x66, data = 0x62
[ 0.189205] vgaarb: device added:
PCI:0000:00:01.0,decodes=io+mem,owns=io+mem,locks=none [ 0.189222]
vgaarb: loaded [ 0.189224] vgaarb: bridge control possible
0000:00:01.0 [ 0.189311] PCI: Using ACPI for IRQ routing
[ 0.190536] PCI: pci_cache_line_size set to 64 bytes [ 0.190820]
e820: reserve RAM buffer [mem 0x0009d800-0x0009ffff] [ 0.190825]
e820: reserve RAM buffer [mem 0xc6ceb000-0xc7ffffff] [ 0.190828]
e820: reserve RAM buffer [mem 0xc7c00000-0xc7ffffff] [ 0.190831]
e820: reserve RAM buffer [mem 0x11f000000-0x11fffffff] [ 0.191109]
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 [ 0.191117] hpet0: 3
comparators, 32-bit 14.318180 MHz counter [ 0.193264] Switched to
clocksource hpet [ 0.199767] pnp: PnP ACPI init [ 0.199801] ACPI:
bus type PNP registered [ 0.200067] system 00:00: [io
0x0f50-0x0f51] has been reserved [ 0.200073] system 00:00: [mem
0xfec00000-0xfec00fff] could not be reserved [ 0.200078] system
00:00: [mem 0xfee00000-0xfee00fff] has been reserved [ 0.200083]
system 00:00: [mem 0xf8000000-0xf9ffffff] has been reserved
[ 0.200090] system 00:00: Plug and Play ACPI device, IDs PNP0c02
(active) [ 0.200800] pnp 00:01: [dma 4] [ 0.200854] pnp 00:01:
Plug and Play ACPI device, IDs PNP0200 (active) [ 0.200926] pnp
00:02: Plug and Play ACPI device, IDs PNP0c04 (active) [ 0.200991]
pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
[ 0.201046] pnp 00:04: Plug and Play ACPI device, IDs PNP0800
(active) [ 0.201107] pnp 00:05: Plug and Play ACPI device, IDs
PNP0303 (active) [ 0.201185] pnp 00:06: Plug and Play ACPI device,
IDs LEN0026 PNP0f13 (active) [ 0.201362] system 00:07: [io
0x04d0-0x04d1] has been reserved [ 0.201367] system 00:07: [io
0x0530-0x0537] has been reserved [ 0.201372] system 00:07: [io
0x0800-0x0827] could not be reserved [ 0.201376] system 00:07: [io
0x0830] has been reserved [ 0.201380] system 00:07: [io
0x0840-0x0847] has been reserved [ 0.201384] system 00:07: [io
0x0b00-0x0b1f] has been reserved [ 0.201388] system 00:07: [io
0x0b20-0x0b3f] has been reserved [ 0.201392] system 00:07: [io
0x0c00-0x0c01] has been reserved [ 0.201396] system 00:07: [io
0x0c14] has been reserved [ 0.201400] system 00:07: [io
0x0c50-0x0c52] has been reserved [ 0.201404] system 00:07: [io
0x0cd0-0x0cd1] has been reserved [ 0.201408] system 00:07: [io
0x0cd2-0x0cd3] has been reserved [ 0.201412] system 00:07: [io
0x0cd4-0x0cd5] has been reserved [ 0.201415] system 00:07: [io
0x0cd6-0x0cd7] has been reserved [ 0.201419] system 00:07: [io
0x0cd8-0x0cdf] has been reserved [ 0.201423] system 00:07: [io
0x0cf9] could not be reserved [ 0.201427] system 00:07: [io
0x8100-0x81ff window] has been reserved [ 0.201431] system 00:07:
[io 0x8200-0x82ff window] has been reserved [ 0.201437] system
00:07: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.201621]
pnp 00:08: [Firmware Bug]: [mem 0x00000000-0xffffffffffffffff disabled]
covers only part of AMD MMCONFIG area [mem 0xf8000000-0xf9ffffff];
adding more reservations [ 0.201670] system 00:08: [mem
0x000e0000-0x000fffff] could not be reserved [ 0.201674] system
00:08: [mem 0xffe00000-0xffffffff] has been reserved [ 0.201679]
system 00:08: [mem 0xfec10000-0xfec1001f] has been reserved
[ 0.201683] system 00:08: [mem 0xfed00000-0xfed003ff] has been
reserved [ 0.201687] system 00:08: [mem 0xfed61000-0xfed613ff] has
been reserved [ 0.201691] system 00:08: [mem 0xfed80000-0xfed80fff]
has been reserved [ 0.201696] system 00:08: Plug and Play ACPI
device, IDs PNP0c01 (active) [ 0.202116] pnp: PnP ACPI: found 9
devices [ 0.202123] ACPI: bus type PNP unregistered [ 0.212310]
pci 0000:03:00.0: no compatible bridge window for [mem
0xffff0000-0xffffffff pref] [ 0.212353] pci 0000:00:07.0: bridge
window [io 0x1000-0x0fff] to [bus 03] add_size 1000 [ 0.212360] pci
0000:00:07.0: bridge window [mem 0x00100000-0x001fffff pref] to [bus
03] add_size 200000 [ 0.212426] pci 0000:00:07.0: res[15]=[mem
0x00100000-0x001fffff pref] get_res_add_size add_size 200000
[ 0.212431] pci 0000:00:07.0: res[13]=[io 0x1000-0x0fff]
get_res_add_size add_size 1000 [ 0.212454] pci 0000:00:07.0: BAR 15:
assigned [mem 0xf0400000-0xf06fffff pref] [ 0.212463] pci
0000:00:07.0: BAR 13: assigned [io 0x1000-0x1fff] [ 0.212469] pci
0000:00:04.0: PCI bridge to [bus 01] [ 0.212477] pci 0000:00:04.0:
bridge window [mem 0xf0200000-0xf02fffff] [ 0.212486] pci
0000:00:06.0: PCI bridge to [bus 02] [ 0.212491] pci 0000:00:06.0:
bridge window [io 0x2000-0x2fff] [ 0.212498] pci 0000:00:06.0:
bridge window [mem 0xf0100000-0xf01fffff] [ 0.212510] pci
0000:03:00.0: BAR 6: assigned [mem 0xf0400000-0xf040ffff pref]
[ 0.212514] pci 0000:00:07.0: PCI bridge to [bus 03] [ 0.212519]
pci 0000:00:07.0: bridge window [io 0x1000-0x1fff] [ 0.212525]
pci 0000:00:07.0: bridge window [mem 0xf0000000-0xf00fffff]
[ 0.212531] pci 0000:00:07.0: bridge window [mem
0xf0400000-0xf06fffff pref] [ 0.212538] pci 0000:00:14.4: PCI bridge
to [bus 04] [ 0.212603] pci_bus 0000:00: resource 4 [mem
0x000a0000-0x000bffff] [ 0.212608] pci_bus 0000:00: resource 5 [mem
0x000c0000-0x000c1fff] [ 0.212611] pci_bus 0000:00: resource 6 [mem
0x000c2000-0x000c3fff] [ 0.212615] pci_bus 0000:00: resource 7 [mem
0x000c4000-0x000c5fff] [ 0.212619] pci_bus 0000:00: resource 8 [mem
0x000c6000-0x000c7fff] [ 0.212622] pci_bus 0000:00: resource 9 [mem
0x000c8000-0x000c9fff] [ 0.212626] pci_bus 0000:00: resource 10 [mem
0x000ca000-0x000cbfff] [ 0.212629] pci_bus 0000:00: resource 11 [mem
0x000cc000-0x000cdfff] [ 0.212633] pci_bus 0000:00: resource 12 [mem
0x000d0000-0x000d1fff] [ 0.212636] pci_bus 0000:00: resource 13 [mem
0x000d2000-0x000d3fff] [ 0.212640] pci_bus 0000:00: resource 14 [mem
0x000d4000-0x000d5fff] [ 0.212643] pci_bus 0000:00: resource 15 [mem
0x000d6000-0x000d7fff] [ 0.212647] pci_bus 0000:00: resource 16 [mem
0x000d8000-0x000d9fff] [ 0.212650] pci_bus 0000:00: resource 17 [mem
0x000da000-0x000dbfff] [ 0.212654] pci_bus 0000:00: resource 18 [mem
0x000dc000-0x000ddfff] [ 0.212657] pci_bus 0000:00: resource 19 [mem
0x000de000-0x000dffff] [ 0.212661] pci_bus 0000:00: resource 20 [mem
0x000e0000-0x000e1fff] [ 0.212664] pci_bus 0000:00: resource 21 [mem
0x000e2000-0x000e3fff] [ 0.212668] pci_bus 0000:00: resource 22 [mem
0x000e4000-0x000e5fff] [ 0.212672] pci_bus 0000:00: resource 23 [mem
0x000e6000-0x000e7fff] [ 0.212675] pci_bus 0000:00: resource 24 [mem
0x000e8000-0x000e9fff] [ 0.212679] pci_bus 0000:00: resource 25 [mem
0x000ea000-0x000ebfff] [ 0.212682] pci_bus 0000:00: resource 26 [mem
0x000ec000-0x000edfff] [ 0.212686] pci_bus 0000:00: resource 27 [mem
0x000ee000-0x000effff] [ 0.212689] pci_bus 0000:00: resource 28 [mem
0xe0000000-0xf7ffffff] [ 0.212693] pci_bus 0000:00: resource 29 [mem
0xf8000000-0xffffffff] [ 0.212697] pci_bus 0000:00: resource 30 [io
0x0000-0x0cf7] [ 0.212700] pci_bus 0000:00: resource 31 [io
0x0d00-0xffff] [ 0.212704] pci_bus 0000:01: resource 1 [mem
0xf0200000-0xf02fffff] [ 0.212708] pci_bus 0000:02: resource 0 [io
0x2000-0x2fff] [ 0.212712] pci_bus 0000:02: resource 1 [mem
0xf0100000-0xf01fffff] [ 0.212716] pci_bus 0000:03: resource 0 [io
0x1000-0x1fff] [ 0.212719] pci_bus 0000:03: resource 1 [mem
0xf0000000-0xf00fffff] [ 0.212723] pci_bus 0000:03: resource 2 [mem
0xf0400000-0xf06fffff pref] [ 0.212728] pci_bus 0000:04: resource 4
[mem 0x000a0000-0x000bffff] [ 0.212731] pci_bus 0000:04: resource 5
[mem 0x000c0000-0x000c1fff] [ 0.212735] pci_bus 0000:04: resource 6
[mem 0x000c2000-0x000c3fff] [ 0.212739] pci_bus 0000:04: resource 7
[mem 0x000c4000-0x000c5fff] [ 0.212742] pci_bus 0000:04: resource 8
[mem 0x000c6000-0x000c7fff] [ 0.212746] pci_bus 0000:04: resource 9
[mem 0x000c8000-0x000c9fff] [ 0.212749] pci_bus 0000:04: resource 10
[mem 0x000ca000-0x000cbfff] [ 0.212753] pci_bus 0000:04: resource 11
[mem 0x000cc000-0x000cdfff] [ 0.212756] pci_bus 0000:04: resource 12
[mem 0x000d0000-0x000d1fff] [ 0.212760] pci_bus 0000:04: resource 13
[mem 0x000d2000-0x000d3fff] [ 0.212763] pci_bus 0000:04: resource 14
[mem 0x000d4000-0x000d5fff] [ 0.212767] pci_bus 0000:04: resource 15
[mem 0x000d6000-0x000d7fff] [ 0.212770] pci_bus 0000:04: resource 16
[mem 0x000d8000-0x000d9fff] [ 0.212774] pci_bus 0000:04: resource 17
[mem 0x000da000-0x000dbfff] [ 0.212777] pci_bus 0000:04: resource 18
[mem 0x000dc000-0x000ddfff] [ 0.212780] pci_bus 0000:04: resource 19
[mem 0x000de000-0x000dffff] [ 0.212784] pci_bus 0000:04: resource 20
[mem 0x000e0000-0x000e1fff] [ 0.212787] pci_bus 0000:04: resource 21
[mem 0x000e2000-0x000e3fff] [ 0.212791] pci_bus 0000:04: resource 22
[mem 0x000e4000-0x000e5fff] [ 0.212794] pci_bus 0000:04: resource 23
[mem 0x000e6000-0x000e7fff] [ 0.212798] pci_bus 0000:04: resource 24
[mem 0x000e8000-0x000e9fff] [ 0.212802] pci_bus 0000:04: resource 25
[mem 0x000ea000-0x000ebfff] [ 0.212806] pci_bus 0000:04: resource 26
[mem 0x000ec000-0x000edfff] [ 0.212809] pci_bus 0000:04: resource 27
[mem 0x000ee000-0x000effff] [ 0.212813] pci_bus 0000:04: resource 28
[mem 0xe0000000-0xf7ffffff] [ 0.212816] pci_bus 0000:04: resource 29
[mem 0xf8000000-0xffffffff] [ 0.212820] pci_bus 0000:04: resource 30
[io 0x0000-0x0cf7] [ 0.212823] pci_bus 0000:04: resource 31 [io
0x0d00-0xffff] [ 0.212923] NET: Registered protocol family 2
[ 0.213325] TCP established hash table entries: 32768 (order: 6,
262144 bytes) [ 0.213497] TCP bind hash table entries: 32768 (order:
7, 524288 bytes) [ 0.213758] TCP: Hash tables configured
(established 32768 bind 32768) [ 0.213860] TCP: reno registered
[ 0.213873] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[ 0.213915] UDP-Lite hash table entries: 2048 (order: 4, 65536
bytes) [ 0.214171] NET: Registered protocol family 1 [ 0.214206]
pci 0000:00:01.0: Boot video device [ 0.340349] PCI: CLS 32 bytes,
default 64 [ 0.340449] Unpacking initramfs... [ 0.504434] Freeing
initrd memory: 4700K (ffff8800376c2000 - ffff880037b59000)
[ 0.504446] PCI-DMA: Using software bounce buffering for IO
(SWIOTLB) [ 0.504451] software IO TLB [mem 0xc2ceb000-0xc6ceb000]
(64MB) mapped at [ffff8800c2ceb000-ffff8800c6ceafff] [ 0.504727] LVT
offset 0 assigned for vector 0x400 [ 0.504843] perf: AMD IBS
detected (0x000000ff) [ 0.505631] futex hash table entries: 512
(order: 3, 32768 bytes) [ 0.505770] audit: initializing netlink
subsys (disabled) [ 0.505805] audit: type=2000
audit(1393860031.403:1): initialized [ 0.506408] HugeTLB registered
2 MB page size, pre-allocated 0 pages [ 0.506888] SGI XFS with ACLs,
security attributes, large block/inode numbers, no debug enabled
[ 0.507223] msgmni has been set to 7107 [ 0.508149] alg: No test
for stdrng (krng) [ 0.508211] Block layer SCSI generic (bsg) driver
version 0.4 loaded (major 253) [ 0.508219] io scheduler noop
registered [ 0.508237] io scheduler cfq registered (default)
[ 0.508698] pcieport 0000:00:04.0: irq 40 for MSI/MSI-X
[ 0.509020] pcieport 0000:00:06.0: irq 41 for MSI/MSI-X
[ 0.509278] pcieport 0000:00:07.0: irq 42 for MSI/MSI-X
[ 0.509448] pcieport 0000:00:04.0: Signaling PME through PCIe PME
interrupt [ 0.509453] pci 0000:01:00.0: Signaling PME through PCIe
PME interrupt [ 0.509459] pcie_pme 0000:00:04.0:pcie01: service
driver pcie_pme loaded [ 0.509485] pcieport 0000:00:06.0: Signaling
PME through PCIe PME interrupt [ 0.509489] pci 0000:02:00.0:
Signaling PME through PCIe PME interrupt [ 0.509495] pcie_pme
0000:00:06.0:pcie01: service driver pcie_pme loaded [ 0.509525]
pcieport 0000:00:07.0: Signaling PME through PCIe PME interrupt
[ 0.509529] pci 0000:03:00.0: Signaling PME through PCIe PME
interrupt [ 0.509535] pcie_pme 0000:00:07.0:pcie01: service driver
pcie_pme loaded [ 0.509545] pci_hotplug: PCI Hot Plug PCI Core
version: 0.5 [ 0.509641] GHES: HEST is not enabled! [ 0.509785]
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 0.510790]
i8042: PNP: PS/2 Controller [PNP0303:KBC0,PNP0f13:MSE0] at 0x60,0x64
irq 1,12 [ 0.514775] i8042: Detected active multiplexing controller,
rev 1.1 [ 0.516372] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 0.516383] serio: i8042 AUX0 port at 0x60,0x64 irq 12
[ 0.516403] serio: i8042 AUX1 port at 0x60,0x64 irq 12
[ 0.516407] serio: i8042 AUX2 port at 0x60,0x64 irq 12
[ 0.516411] serio: i8042 AUX3 port at 0x60,0x64 irq 12
[ 0.516728] mousedev: PS/2 mouse device common for all mice
[ 0.516863] rtc_cmos 00:03: RTC can wake from S4 [ 0.517121]
rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 [ 0.517215]
rtc_cmos 00:03: alarms up to one month, 114 bytes nvram, hpet irqs
[ 0.517368] drop_monitor: Initializing network drop monitor service
[ 0.517461] TCP: cubic registered [ 0.517563] NET: Registered
protocol family 10 [ 0.517963] NET: Registered protocol family 17
[ 0.518503] registered taskstats version 1 [ 0.519235] rtc_cmos
00:03: setting system clock to 2014-03-03 15:20:32 UTC (1393860032)
[ 0.521165] Freeing unused kernel memory: 836K (ffffffff81894000 -
ffffffff81965000) [ 0.521173] Write protecting the kernel read-only
data: 8192k [ 0.530171] Freeing unused kernel memory: 1756K
(ffff880001449000 - ffff880001600000) [ 0.533393] Freeing unused
kernel memory: 620K (ffff880001765000 - ffff880001800000)
[ 0.565470] input: AT Translated Set 2 keyboard
as /devices/platform/i8042/serio0/input/input0 [ 0.702521]
systemd-udevd[59]: starting version 204 [ 0.761883] atl1c
0000:02:00.0: version 1.0.1.1-NAPI [ 0.772791] rtsx_pci
0000:03:00.0: irq 43 for MSI/MSI-X [ 0.772817] rtsx_pci
0000:03:00.0: rtsx_pci_acquire_irq: pcr->msi_en = 1, pci->irq = 43
[ 0.786099] ACPI: bus type USB registered [ 0.786163] usbcore:
registered new interface driver usbfs [ 0.786196] usbcore:
registered new interface driver hub [ 0.787422] thermal LNXTHERM:00:
registered as thermal_zone0 [ 0.787431] ACPI: Thermal Zone [THZ0]
(74 C) [ 0.788180] SCSI subsystem initialized [ 0.789031]
usbcore: registered new device driver usb [ 0.789818] ehci_hcd: USB
2.0 'Enhanced' Host Controller (EHCI) Driver [ 0.790272] ehci-pci:
EHCI PCI platform driver [ 0.790396] ohci_hcd: USB 1.1 'Open' Host
Controller (OHCI) Driver [ 0.790709] ohci-pci: OHCI PCI platform
driver [ 0.790715] QUIRK: Enable AMD PLL fix [ 0.790808] ehci-pci
0000:00:12.2: EHCI Host Controller [ 0.790822] ehci-pci
0000:00:12.2: new USB bus registered, assigned bus number 1
[ 0.790834] ehci-pci 0000:00:12.2: applying AMD
SB700/SB800/Hudson-2/3 EHCI dummy qh workaround [ 0.790896] ehci-pci
0000:00:12.2: debug port 1 [ 0.790959] ehci-pci 0000:00:12.2: irq
17, io mem 0xf034a500 [ 0.792755] libata version 3.00 loaded.
[ 0.796468] ehci-pci 0000:00:12.2: USB 2.0 started, EHCI 1.00
[ 0.796682] usb usb1: New USB device found, idVendor=1d6b,
idProduct=0002 [ 0.796687] usb usb1: New USB device strings: Mfr=3,
Product=2, SerialNumber=1 [ 0.796691] usb usb1: Product: EHCI Host
Controller [ 0.796695] usb usb1: Manufacturer: Linux 3.14.0-rc5
ehci_hcd [ 0.796698] usb usb1: SerialNumber: 0000:00:12.2
[ 0.796963] hub 1-0:1.0: USB hub found [ 0.796980] hub 1-0:1.0: 5
ports detected [ 0.797752] ehci-pci 0000:00:13.2: EHCI Host
Controller [ 0.797767] ehci-pci 0000:00:13.2: new USB bus
registered, assigned bus number 2 [ 0.797776] ehci-pci 0000:00:13.2:
applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
[ 0.797792] ehci-pci 0000:00:13.2: debug port 1 [ 0.797838]
ehci-pci 0000:00:13.2: irq 17, io mem 0xf034a400 [ 0.803373]
ehci-pci 0000:00:13.2: USB 2.0 started, EHCI 1.00 [ 0.803479] usb
usb2: New USB device found, idVendor=1d6b, idProduct=0002
[ 0.803484] usb usb2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1 [ 0.803488] usb usb2: Product: EHCI Host Controller
[ 0.803492] usb usb2: Manufacturer: Linux 3.14.0-rc5 ehci_hcd
[ 0.803495] usb usb2: SerialNumber: 0000:00:13.2 [ 0.804288] hub
2-0:1.0: USB hub found [ 0.804310] hub 2-0:1.0: 5 ports detected
[ 0.805000] ohci-pci 0000:00:12.0: OHCI PCI host controller
[ 0.805026] ohci-pci 0000:00:12.0: new USB bus registered, assigned
bus number 3 [ 0.805142] ohci-pci 0000:00:12.0: irq 18, io mem
0xf0349000 [ 0.859727] usb usb3: New USB device found,
idVendor=1d6b, idProduct=0001 [ 0.859736] usb usb3: New USB device
strings: Mfr=3, Product=2, SerialNumber=1 [ 0.859741] usb usb3:
Product: OHCI PCI host controller [ 0.859744] usb usb3:
Manufacturer: Linux 3.14.0-rc5 ohci_hcd [ 0.859748] usb usb3:
SerialNumber: 0000:00:12.0 [ 0.860070] hub 3-0:1.0: USB hub found
[ 0.860142] hub 3-0:1.0: 5 ports detected [ 0.860546] ahci
0000:00:11.0: version 3.0 [ 0.860907] ahci 0000:00:11.0: AHCI
0001.0200 32 slots 1 ports 3 Gbps 0x1 impl SATA mode [ 0.860914]
ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum
part [ 0.868041] scsi0 : ahci [ 0.868202] ata1: SATA max UDMA/133
abar m1024@0xf034a000 port 0xf034a100 irq 19 [ 0.868648] ohci-pci
0000:00:13.0: OHCI PCI host controller [ 0.868670] ohci-pci
0000:00:13.0: new USB bus registered, assigned bus number 4
[ 0.868777] ohci-pci 0000:00:13.0: irq 18, io mem 0xf0348000
[ 0.878088] microcode: CPU0: patch_level=0x05000101 [ 0.884259]
microcode: CPU0: new patch_level=0x05000119 [ 0.895149] microcode:
CPU1: patch_level=0x05000101 [ 0.901259] microcode: CPU1: new
patch_level=0x05000119 [ 0.902455] microcode: Microcode Update
Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba [ 0.923607]
usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.923616] usb usb4: New USB device strings: Mfr=3, Product=2,
SerialNumber=1 [ 0.923620] usb usb4: Product: OHCI PCI host
controller [ 0.923624] usb usb4: Manufacturer: Linux 3.14.0-rc5
ohci_hcd [ 0.923628] usb usb4: SerialNumber: 0000:00:13.0
[ 0.923990] hub 4-0:1.0: USB hub found [ 0.924011] hub 4-0:1.0: 5
ports detected [ 1.106739] usb 2-5: new high-speed USB device number
2 using ehci-pci [ 1.234596] usb 2-5: New USB device found,
idVendor=5986, idProduct=01a6 [ 1.234611] usb 2-5: New USB device
strings: Mfr=1, Product=2, SerialNumber=3 [ 1.234619] usb 2-5:
Product: Integrated Camera [ 1.234626] usb 2-5: Manufacturer: Image
Processor [ 1.234631] usb 2-5: SerialNumber: Integrated Camera
[ 1.328689] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1.355647] ata1.00: ATA-8: ST320LT007-9ZV142, 0004LVM1, max
UDMA/133 [ 1.355657] ata1.00: 625142448 sectors, multi 16: LBA48 NCQ
(depth 31/32) [ 1.359554] ata1.00: configured for UDMA/133
[ 1.360154] scsi 0:0:0:0: Direct-Access ATA
ST320LT007-9ZV14 0004 PQ: 0 ANSI: 5 [ 1.371367] sd 0:0:0:0: [sda]
625142448 512-byte logical blocks: (320 GB/298 GiB) [ 1.371377] sd
0:0:0:0: [sda] 4096-byte physical blocks [ 1.371747] sd 0:0:0:0:
[sda] Write Protect is off [ 1.371753] sd 0:0:0:0: [sda] Mode Sense:
00 3a 00 00 [ 1.371795] sd 0:0:0:0: [sda] Write cache: enabled, read
cache: enabled, doesn't support DPO or FUA [ 1.385552] sda: sda1
sda2 [ 1.387028] sd 0:0:0:0: [sda] Attached SCSI disk [ 1.390557]
sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 1.505693] tsc:
Refined TSC clocksource calibration: 1646.492 MHz [ 1.725719]
device-mapper: uevent: version 1.0.3 [ 1.725828] device-mapper:
ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-devel@redhat.com
[ 1.734716] random: lvm urandom read with 60 bits of entropy
available [ 2.506210] Switched to clocksource tsc [ 3.257829]
random: nonblocking pool is initialized [ 6.442224] sha256_ssse3:
Using SSSE3 optimized SHA-256 implementation [ 6.444710] bio: create
slab <bio-1> at 1 [ 6.666335] bio: create slab <bio-1> at 1
[ 7.086264] PM: Starting manual resume from disk [ 7.092253] XFS
(dm-1): Mounting Filesystem [ 7.298350] XFS (dm-1): Ending clean
mount [ 10.245772] systemd-udevd[427]: starting version 204
[ 11.845425] snd_hda_intel 0000:00:01.1: irq 44 for MSI/MSI-X
[ 11.932703] ACPI: acpi_idle registered with cpuidle [ 11.979458]
input: HD-Audio Generic HDMI/DP,pcm=3
as /devices/pci0000:00/0000:00:01.1/sound/card0/input5 [ 11.993048]
hda_codec: CX20590: BIOS auto-probing. [ 11.994715] input: HDA
Digital PCBeep as /devices/pci0000:00/0000:00:14.2/input/input6
[ 12.054192] ACPI Warning: SystemIO range
0x0000000000000b00-0x0000000000000b07 conflicts with OpRegion
0x0000000000000b00-0x0000000000000b0f (\_SB_.PCI0.SMB_.SMB0)
(20131218/utaddress-258) [ 12.054208] ACPI: If an ACPI driver is
available for this device, you should use it instead of the native
driver [ 12.110101] ACPI: Video Device [VGA] (multi-head: yes rom:
no post: no) [ 12.110131] [Firmware Bug]: ACPI: No _BQC method,
cannot determine initial brightness [ 12.110228] [Firmware Bug]:
ACPI: No _BQC method, cannot determine initial brightness
[ 12.113207] acpi device:02: registered as cooling_device2
[ 12.113316] input: Video Bus
as /devices/LNXSYSTM:00/device:00/PNP0A08:00/device:01/LNXVIDEO:00/input/input7
[ 12.113436] ACPI: Video Device [VGA1] (multi-head: yes rom: no
post: no) [ 12.133242] acpi device:38: registered as cooling_device3
[ 12.133376] input: Video Bus
as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input8
[ 12.170303] Linux video capture interface: v2.00 [ 12.197243]
cfg80211: Calling CRDA to update world regulatory domain [ 12.219165]
Intel(R) Wireless WiFi driver for Linux, in-tree: [ 12.219172]
Copyright(c) 2003- 2014 Intel Corporation [ 12.219661] iwlwifi
0000:01:00.0: irq 45 for MSI/MSI-X [ 12.269003] ACPI: AC Adapter
[ACAD] (on-line) [ 12.304159] ACPI: Battery Slot [BAT1] (battery
present) [ 12.304295] input: Power Button
as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input9
[ 12.304306] ACPI: Power Button [PWRB] [ 12.304386] input: Sleep
Button as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input10
[ 12.304391] ACPI: Sleep Button [SLPB] [ 12.304514] input: Lid
Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input11
[ 12.304857] ACPI: Lid Switch [LID] [ 12.304994] input: Power
Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input12 [ 12.305001]
ACPI: Power Button [PWRF] [ 12.325266] acpi-cpufreq: overriding BIOS
provided _PSD data [ 12.344764] Linux agpgart interface v0.103
[ 12.374346] [drm] Initialized drm 1.1.0 20060810 [ 12.446977]
Non-volatile memory driver v1.3 [ 12.453842] wmi: Mapper loaded
[ 12.489927] input: PC Speaker
as /devices/platform/pcspkr/input/input13 [ 12.512101] uvcvideo:
Found UVC 1.00 device Integrated Camera (5986:01a6) [ 12.513891]
input: Integrated Camera
as /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/input/input14
[ 12.514037] usbcore: registered new interface driver uvcvideo
[ 12.514041] USB Video Class driver (1.1.1) [ 12.622854]
thinkpad_acpi: ThinkPad ACPI Extras v0.25 [ 12.622862] thinkpad_acpi:
http://ibm-acpi.sf.net/ [ 12.622866] thinkpad_acpi: ThinkPad BIOS
8RET52WW (1.15 ), EC unknown [ 12.622869] thinkpad_acpi: Lenovo
ThinkPad X121e, model 30515YG [ 12.623358] thinkpad_acpi: Unsupported
brightness interface, please contact
ibm-acpi-devel@lists.sourceforge.net [ 12.624220] thinkpad_acpi:
radio switch found; radios are enabled [ 12.624271] thinkpad_acpi:
possible tablet mode switch found; ThinkPad in laptop mode
[ 12.624310] thinkpad_acpi: This ThinkPad has standard ACPI backlight
brightness control, supported by the ACPI video driver [ 12.624313]
thinkpad_acpi: Disabling thinkpad-acpi brightness events by default...
[ 12.647985] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio
is blocked [ 12.649643] thinkpad_acpi: Console audio control enabled,
mode: monitor (read only) [ 12.654396] input: ThinkPad Extra Buttons
as /devices/platform/thinkpad_acpi/input/input15 [ 12.664347] input:
HDA ATI SB Headphone
as /devices/pci0000:00/0000:00:14.2/sound/card1/input17 [ 12.664615]
input: HDA ATI SB Mic
as /devices/pci0000:00/0000:00:14.2/sound/card1/input16 [ 12.994110]
iwlwifi 0000:01:00.0: loaded firmware version 9.221.4.1 build 25532
op_mode iwldvm [ 13.318102] [drm] radeon kernel modesetting enabled.
[ 13.319255] [drm] initializing kernel modesetting (PALM
0x1002:0x9806 0x17AA:0x21EC). [ 13.319311] [drm] register mmio base:
0xF0300000 [ 13.319313] [drm] register mmio size: 262144
[ 13.319414] ATOM BIOS: Lenovo [ 13.319489] radeon 0000:00:01.0:
VRAM: 384M 0x0000000000000000 - 0x0000000017FFFFFF (384M used)
[ 13.319494] radeon 0000:00:01.0: GTT: 1024M 0x0000000018000000 -
0x0000000057FFFFFF [ 13.319497] [drm] Detected VRAM RAM=384M,
BAR=256M [ 13.319500] [drm] RAM width 32bits DDR [ 13.319593] [TTM]
Zone kernel: Available graphics memory: 1821058 kiB [ 13.319596]
[TTM] Initializing pool allocator [ 13.319606] [TTM] Initializing DMA
pool allocator [ 13.319648] [drm] radeon: 384M of VRAM memory ready
[ 13.319651] [drm] radeon: 1024M of GTT memory ready. [ 13.319673]
[drm] Loading PALM Microcode [ 13.350105] iwlwifi 0000:01:00.0:
CONFIG_IWLWIFI_DEBUG disabled [ 13.350120] iwlwifi 0000:01:00.0:
CONFIG_IWLWIFI_DEBUGFS disabled [ 13.350128] iwlwifi 0000:01:00.0:
CONFIG_IWLWIFI_DEVICE_TRACING disabled [ 13.350137] iwlwifi
0000:01:00.0: Detected Intel(R) Centrino(R) Advanced-N 6200 AGN,
REV=0x74 [ 13.350365] iwlwifi 0000:01:00.0: L1 Disabled; Enabling L0S
[ 13.432938] usb 3-4: new full-speed USB device number 2 using
ohci-pci [ 13.589577] usb 3-4: New USB device found, idVendor=0a5c,
idProduct=217f [ 13.589592] usb 3-4: New USB device strings: Mfr=1,
Product=2, SerialNumber=3 [ 13.589600] usb 3-4: Product: Broadcom
Bluetooth Device [ 13.589607] usb 3-4: Manufacturer: Broadcom Corp
[ 13.589613] usb 3-4: SerialNumber: E4D53DC801B2 [ 13.609251]
ieee80211 phy0: Selected rate control algorithm
'iwl-agn-rs' [ 13.720002] psmouse serio4: synaptics: Touchpad model:
1, fw: 8.0, id: 0x1e2b1, caps: 0xd001a3/0x940300/0x123c00, board id:
1917, fw id: 864720 [ 13.720031] psmouse serio4: synaptics: serio:
Synaptics pass-through port at isa0060/serio4/input0 [ 13.763378]
input: SynPS/2 Synaptics TouchPad
as /devices/platform/i8042/serio4/input/input21 [ 13.907564] [drm]
Internal thermal controller without fan control [ 13.907769] [drm]
Found smc ucode version: 0x00010601 [ 13.908034] [drm] radeon: dpm
initialized [ 13.926141] [drm] GART: num cpu pages 262144, num gpu
pages 262144 [ 13.947069] [drm] PCIE GART of 1024M enabled (table at
0x0000000000273000). [ 13.947701] radeon 0000:00:01.0: WB enabled
[ 13.947715] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr
0x0000000018000c00 and cpu addr 0xffff8800376f0c00 [ 13.947724]
radeon 0000:00:01.0: fence driver on ring 3 use gpu addr
0x0000000018000c0c and cpu addr 0xffff8800376f0c0c [ 13.949267]
radeon 0000:00:01.0: fence driver on ring 5 use gpu addr
0x0000000000072118 and cpu addr 0xffffc900028b2118 [ 13.949346] [drm]
Supports vblank timestamp caching Rev 2 (21.10.2013). [ 13.949358]
[drm] Driver supports precise vblank timestamp query. [ 13.949409]
radeon 0000:00:01.0: irq 46 for MSI/MSI-X [ 13.949440] radeon
0000:00:01.0: radeon: using MSI. [ 13.949492] [drm] radeon: irq
initialized. [ 13.967614] [drm] ring test on 0 succeeded in 1 usecs
[ 13.967698] [drm] ring test on 3 succeeded in 1 usecs [ 14.024184]
[drm] ring test on 5 succeeded in 1 usecs [ 14.044314] [drm] UVD
initialized successfully. [ 14.045325] [drm] ib test on ring 0
succeeded in 0 usecs [ 14.045426] [drm] ib test on ring 3 succeeded
in 0 usecs [ 14.064586] Bluetooth: Core ver 2.18 [ 14.064672] NET:
Registered protocol family 31 [ 14.064676] Bluetooth: HCI device and
connection manager initialized [ 14.065105] Bluetooth: HCI socket
layer initialized [ 14.065113] Bluetooth: L2CAP socket layer
initialized [ 14.065142] Bluetooth: SCO socket layer initialized
[ 14.066485] [drm] ib test on ring 5 succeeded [ 14.138967] [drm]
radeon atom DIG backlight initialized [ 14.138989] [drm] Radeon
Display Connectors [ 14.138995] [drm] Connector 0: [ 14.139003]
[drm] LVDS-1 [ 14.139007] [drm] HPD1 [ 14.139015] [drm] DDC:
0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [ 14.139020]
[drm] Encoders: [ 14.139024] [drm] LCD1: INTERNAL_UNIPHY
[ 14.139028] [drm] Connector 1: [ 14.139033] [drm] HDMI-A-1
[ 14.139036] [drm] HPD2 [ 14.139043] [drm] DDC: 0x6440 0x6440
0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [ 14.139046] [drm]
Encoders: [ 14.139050] [drm] DFP1: INTERNAL_UNIPHY [ 14.139054]
[drm] Connector 2: [ 14.139058] [drm] VGA-1 [ 14.139064] [drm]
DDC: 0x64d8 0x64d8 0x64dc 0x64dc 0x64e0 0x64e0 0x64e4 0x64e4
[ 14.139068] [drm] Encoders: [ 14.139072] [drm] CRT1:
INTERNAL_KLDSCP_DAC1 [ 14.335848] usbcore: registered new interface
driver btusb [ 14.390389] cfg80211: World regulatory domain updated:
[ 14.390406] cfg80211: DFS Master region: unset [ 14.390411]
cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain,
max_eirp) [ 14.390419] cfg80211: (2402000 KHz - 2472000 KHz @ 40000
KHz), (N/A, 2000 mBm) [ 14.390426] cfg80211: (2457000 KHz - 2482000
KHz @ 40000 KHz), (N/A, 2000 mBm) [ 14.390431] cfg80211: (2474000
KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm) [ 14.390437]
cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2000 mBm)
[ 14.390442] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz),
(N/A, 2000 mBm) [ 14.390448] cfg80211: (57240000 KHz - 63720000 KHz
@ 2160000 KHz), (N/A, 0 mBm) [ 14.390799] cfg80211: Calling CRDA for
country: DE [ 14.419151] cfg80211: Regulatory domain changed to
country: DE [ 14.419163] cfg80211: DFS Master region: ETSI
[ 14.419169] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp) [ 14.419175] cfg80211: (2400000 KHz -
2483500 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 14.419179] cfg80211:
(5150000 KHz - 5350000 KHz @ 80000 KHz), (N/A, 2000 mBm) [ 14.419182]
cfg80211: (5470000 KHz - 5725000 KHz @ 80000 KHz), (N/A, 2698 mBm)
[ 14.419186] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz),
(N/A, 4000 mBm) [ 14.563465] [drm] fb mappable at 0xE0477000
[ 14.563474] [drm] vram apper at 0xE0000000 [ 14.563477] [drm] size
4325376 [ 14.563480] [drm] fb depth is 24 [ 14.563483] [drm]
pitch is 5632 [ 14.563767] fbcon: radeondrmfb (fb0) is primary device
[ 15.127958] Console: switching to colour frame buffer device 170x48
[ 15.134456] radeon 0000:00:01.0: fb0: radeondrmfb frame buffer
device [ 15.134460] radeon 0000:00:01.0: registered panic notifier
[ 15.135419] [drm] Initialized radeon 2.37.0 20080528 for
0000:00:01.0 on minor 0 [ 16.792941] Adding 4001788k swap
on /dev/mapper/encrypted-swap. Priority:-1 extents:1 across:4001788k
[ 16.878938] psmouse serio5: alps: Unknown ALPS touchpad: E7=10 00
64, EC=10 00 64 [ 18.256795] psmouse serio5: trackpoint: IBM
TrackPoint firmware: 0x0e, buttons: 3/3 [ 18.483078] input: TPPS/2
IBM TrackPoint as /devices/platform/i8042/serio4/serio5/input/input22
[ 19.372185] fuse init (API version 7.22) [ 19.572798] loop: module
loaded [ 20.150009] XFS (sda1): Mounting Filesystem [ 20.281452]
XFS (sda1): Ending clean mount
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-10 10:04 [RESEND] Fast TSC calibration fails with v3.14-rc1 and later Julian Wollrath
@ 2014-03-10 10:27 ` Paul Bolle
2014-03-10 14:06 ` Thomas Gleixner
2014-03-10 10:39 ` Thomas Gleixner
1 sibling, 1 reply; 41+ messages in thread
From: Paul Bolle @ 2014-03-10 10:27 UTC (permalink / raw)
To: Julian Wollrath; +Cc: x86, linux-kernel
On Mon, 2014-03-10 at 11:04 +0100, Julian Wollrath wrote:
> on a Thinkpad x121e (AMD E-450 APU) with version 3.13.5 and earlier of
> the kernel I get:
> [...]
> [ 0.000000] tsc: Fast TSC calibration using PIT
> [ 0.001000] tsc: Detected 1646.619 MHz processor
> [ 0.000004] Calibrating delay loop (skipped), value calculated using
> timer frequency.. 3293.23 BogoMIPS (lpj=1646619)
> [...]
>
>
> but starting with v3.14-rc1 the fast TSC calibration fails:
> [...]
> [ 0.000000] tsc: Fast TSC calibration failed
> [ 0.000000] tsc: PIT calibration matches HPET. 1 loops
> [ 0.000000] tsc: Detected 1646.490 MHz processor
> [...]
>
> If you need more information, please do not hesitate to ask.
I submitted a patch to downgrade the "Fast TSC calibration failed"
message to KERN_INFO level, see https://lkml.org/lkml/2012/9/26/131 .
That patch was basically ignored. I've carried it locally ever since.
So the error need not be v3.14-rc1 specific. But perhaps something
changed in v3.14-rc1 that makes it easier to trigger that error. I
haven't checked.
(I wrote some notes on this issue in
https://lkml.org/lkml/2012/9/24/221 , perhaps they might be of help.)
Paul Bolle
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-10 10:04 [RESEND] Fast TSC calibration fails with v3.14-rc1 and later Julian Wollrath
2014-03-10 10:27 ` Paul Bolle
@ 2014-03-10 10:39 ` Thomas Gleixner
2014-03-11 13:29 ` Julian Wollrath
1 sibling, 1 reply; 41+ messages in thread
From: Thomas Gleixner @ 2014-03-10 10:39 UTC (permalink / raw)
To: Julian Wollrath; +Cc: x86, linux-kernel
On Mon, 10 Mar 2014, Julian Wollrath wrote:
> on a Thinkpad x121e (AMD E-450 APU) with version 3.13.5 and earlier of
> the kernel I get:
> [...]
> [ 0.000000] tsc: Fast TSC calibration using PIT
> [ 0.001000] tsc: Detected 1646.619 MHz processor
> [ 0.000004] Calibrating delay loop (skipped), value calculated using
> timer frequency.. 3293.23 BogoMIPS (lpj=1646619)
> [...]
>
>
> but starting with v3.14-rc1 the fast TSC calibration fails:
> [...]
> [ 0.000000] tsc: Fast TSC calibration failed
> [ 0.000000] tsc: PIT calibration matches HPET. 1 loops
> [ 0.000000] tsc: Detected 1646.490 MHz processor
> [...]
The only change in the calibration code post 3.13 is that we added the
MSR based calibration for ATOM:
@@ -419,6 +651,13 @@ unsigned long native_calibrate_tsc(void)
unsigned long flags, latch, ms, fast_calibrate;
int hpet = is_hpet_enabled(), i, loopmin;
+ /* Calibrate TSC using MSR for Intel Atom SoCs */
+ local_irq_save(flags);
+ fast_calibrate = try_msr_calibrate_tsc();
+ local_irq_restore(flags);
+ if (fast_calibrate)
+ return fast_calibrate;
+
local_irq_save(flags);
fast_calibrate = quick_pit_calibrate();
local_irq_restore(flags);
And that definitely does not affect the quick calibration. No idea,
except bisecting.
Thanks,
tglx
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-10 10:27 ` Paul Bolle
@ 2014-03-10 14:06 ` Thomas Gleixner
2014-03-10 15:28 ` Paul Bolle
0 siblings, 1 reply; 41+ messages in thread
From: Thomas Gleixner @ 2014-03-10 14:06 UTC (permalink / raw)
To: Paul Bolle; +Cc: Julian Wollrath, x86, linux-kernel
On Mon, 10 Mar 2014, Paul Bolle wrote:
> On Mon, 2014-03-10 at 11:04 +0100, Julian Wollrath wrote:
> > on a Thinkpad x121e (AMD E-450 APU) with version 3.13.5 and earlier of
> > the kernel I get:
> > [...]
> > [ 0.000000] tsc: Fast TSC calibration using PIT
> > [ 0.001000] tsc: Detected 1646.619 MHz processor
> > [ 0.000004] Calibrating delay loop (skipped), value calculated using
> > timer frequency.. 3293.23 BogoMIPS (lpj=1646619)
> > [...]
> >
> >
> > but starting with v3.14-rc1 the fast TSC calibration fails:
> > [...]
> > [ 0.000000] tsc: Fast TSC calibration failed
> > [ 0.000000] tsc: PIT calibration matches HPET. 1 loops
> > [ 0.000000] tsc: Detected 1646.490 MHz processor
> > [...]
> >
> > If you need more information, please do not hesitate to ask.
>
> I submitted a patch to downgrade the "Fast TSC calibration failed"
> message to KERN_INFO level, see https://lkml.org/lkml/2012/9/26/131 .
> That patch was basically ignored. I've carried it locally ever since.
And how is this related to Julians observation, that fast calibration
works in 3.13, but stopped to work in 3.14-rc ?
Thanks,
tglx
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-10 14:06 ` Thomas Gleixner
@ 2014-03-10 15:28 ` Paul Bolle
2014-03-10 17:04 ` Thomas Gleixner
2014-03-11 13:27 ` Julian Wollrath
0 siblings, 2 replies; 41+ messages in thread
From: Paul Bolle @ 2014-03-10 15:28 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Julian Wollrath, x86, linux-kernel
On Mon, 2014-03-10 at 15:06 +0100, Thomas Gleixner wrote:
> And how is this related to Julians observation, that fast calibration
> works in 3.13, but stopped to work in 3.14-rc ?
In the rest of my message - which you didn't quote - I stated that "the
error need not be v3.14-rc1 specific. But perhaps something changed in
v3.14-rc1 that makes it easier to trigger that error. I haven't
checked". (I didn't add that, in my experience, this message is not seen
at every boot.) So I'm basically advising Julian to double check whether
this is really a change in behavior between v3.13 and v3.14-rc1. But
perhaps Julian already did.
And I'm also telling Julian that, as far as I can tell, there's no
reason to print this message at KERN_ERR level because what subsequently
will happen is that an alternative calibration strategy is tried. So a
failure of fast TSC calibration is apparently not so severe. See
https://lkml.org/lkml/2012/9/24/221 . Is that analysis incorrect?
Thanks,
Paul Bolle
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-10 15:28 ` Paul Bolle
@ 2014-03-10 17:04 ` Thomas Gleixner
2014-03-10 18:32 ` Paul Bolle
2014-03-11 13:27 ` Julian Wollrath
1 sibling, 1 reply; 41+ messages in thread
From: Thomas Gleixner @ 2014-03-10 17:04 UTC (permalink / raw)
To: Paul Bolle; +Cc: Julian Wollrath, x86, linux-kernel
On Mon, 10 Mar 2014, Paul Bolle wrote:
> On Mon, 2014-03-10 at 15:06 +0100, Thomas Gleixner wrote:
> > And how is this related to Julians observation, that fast calibration
> > works in 3.13, but stopped to work in 3.14-rc ?
>
> In the rest of my message - which you didn't quote - I stated that "the
> error need not be v3.14-rc1 specific. But perhaps something changed in
> v3.14-rc1 that makes it easier to trigger that error. I haven't
> checked". (I didn't add that, in my experience, this message is not seen
> at every boot.) So I'm basically advising Julian to double check whether
> this is really a change in behavior between v3.13 and v3.14-rc1. But
> perhaps Julian already did.
Oh, yes.
> > on a Thinkpad x121e (AMD E-450 APU) with version 3.13.5 and earlier of
> > the kernel I get:
> > [...]
> > but starting with v3.14-rc1 the fast TSC calibration fails:
> And I'm also telling Julian that, as far as I can tell, there's no
> reason to print this message at KERN_ERR level because what subsequently
> will happen is that an alternative calibration strategy is tried. So a
> failure of fast TSC calibration is apparently not so severe. See
And that does exactly make the regression he's observing go
away?
We want to know why stuff which worked and actually should still work
suddenly fails. Sure, the machine boots and nothing explodes, but it's
still a regression.
> https://lkml.org/lkml/2012/9/24/221 . Is that analysis incorrect?
Kinda. But there is no reason for the fast calibration to fail except
BIOS induced SMI nonsense.
Thanks,
tglx
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-10 17:04 ` Thomas Gleixner
@ 2014-03-10 18:32 ` Paul Bolle
2014-03-10 18:57 ` Thomas Gleixner
0 siblings, 1 reply; 41+ messages in thread
From: Paul Bolle @ 2014-03-10 18:32 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Jerome Oufella, Julian Wollrath, x86, linux-kernel
[Added Jerome, who submitted a patch similar to mine.]
On Mon, 2014-03-10 at 18:04 +0100, Thomas Gleixner wrote:
> On Mon, 10 Mar 2014, Paul Bolle wrote:
> > https://lkml.org/lkml/2012/9/24/221 . Is that analysis incorrect?
>
> Kinda. But there is no reason for the fast calibration to fail except
> BIOS induced SMI nonsense.
What made me submit my patch, in 2012, is that this error is printed
very early, before boot animation kicks in. Ie, it looks rather scary.
And when I dug through the code I noticed that this condition seems
actually to be handled already: the kernel just tries an alternative
calibration method.
So I think this should be printed at (say) KERN_INFO level (so it will
be suppressed during boot). More so if the solution would be "upgrade
the BIOS". Upgrading the BIOS on a ThinkPad, for instance, can require
fiddling with quite a bit of low level programs. And how do we know an
upgraded BIOS actually helps?
Or is there a way to handle the "SMI nonsense" (whatever that may be)?
Paul Bolle
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-10 18:32 ` Paul Bolle
@ 2014-03-10 18:57 ` Thomas Gleixner
2014-03-10 19:19 ` Paul Bolle
0 siblings, 1 reply; 41+ messages in thread
From: Thomas Gleixner @ 2014-03-10 18:57 UTC (permalink / raw)
To: Paul Bolle; +Cc: Jerome Oufella, Julian Wollrath, x86, linux-kernel
On Mon, 10 Mar 2014, Paul Bolle wrote:
>
> Or is there a way to handle the "SMI nonsense" (whatever that may be)?
No, there is none. That's "value add" from the BIOS/board manufacturer
which utilizes the System Management Interrupt and steals CPU time
from the OS.
Thanks,
tglx
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-10 18:57 ` Thomas Gleixner
@ 2014-03-10 19:19 ` Paul Bolle
2014-03-10 20:50 ` Thomas Gleixner
0 siblings, 1 reply; 41+ messages in thread
From: Paul Bolle @ 2014-03-10 19:19 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Jerome Oufella, Julian Wollrath, x86, linux-kernel
Thomas Gleixner schreef op ma 10-03-2014 om 19:57 [+0100]:
> On Mon, 10 Mar 2014, Paul Bolle wrote:
> >
> > Or is there a way to handle the "SMI nonsense" (whatever that may be)?
>
> No, there is none. That's "value add" from the BIOS/board manufacturer
> which utilizes the System Management Interrupt and steals CPU time
> from the OS.
So could you please consider downgrading this message?
Yes, this will make regressions less visible, although I'm unsure we're
actually seeing a regression here. But I think that this is better than
scaring people about a situation they can't easily do something about,
if at all. Especially since fast TSC calibration failures, apparently,
can be worked around.
Paul Bolle
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-10 19:19 ` Paul Bolle
@ 2014-03-10 20:50 ` Thomas Gleixner
2014-03-10 23:06 ` Paul Bolle
0 siblings, 1 reply; 41+ messages in thread
From: Thomas Gleixner @ 2014-03-10 20:50 UTC (permalink / raw)
To: Paul Bolle; +Cc: Jerome Oufella, Julian Wollrath, x86, linux-kernel
On Mon, 10 Mar 2014, Paul Bolle wrote:
> Thomas Gleixner schreef op ma 10-03-2014 om 19:57 [+0100]:
> > On Mon, 10 Mar 2014, Paul Bolle wrote:
> > >
> > > Or is there a way to handle the "SMI nonsense" (whatever that may be)?
> >
> > No, there is none. That's "value add" from the BIOS/board manufacturer
> > which utilizes the System Management Interrupt and steals CPU time
> > from the OS.
>
> So could you please consider downgrading this message?
>
> Yes, this will make regressions less visible, although I'm unsure we're
> actually seeing a regression here. But I think that this is better than
> scaring people about a situation they can't easily do something about,
> if at all. Especially since fast TSC calibration failures, apparently,
> can be worked around.
If something works fine from version X up to v3.13 and then suddenly
fails, then we can safely ignore it because there is a work around or
fallback? And just shrug and say: Oh, it's not a regression.
Dammit no. We want to know WHY!
I'm not going to downgrade that message for a simple reason.
A lot of people including me spent quite some precious time to work
around the brainwreckage of
- those who invented the concept of unreliable hardware (TSC) in the
first place
- the BIOS/board manufacturers who add crap to their BIOSes which
renders it even more unusable. Yes, even the slow calibration fails
due to that.
And now you whine because we tell loudly, that the hardware/BIOS is
crap?
You're barking up the wrong tree:
Go and tell your hardware supplier!
But sure, it's simpler to submit a patch which makes that issue less
visible just because you don't like the verbosity of those who made it
work for YOU in the first place.
Thanks,
tglx
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-10 20:50 ` Thomas Gleixner
@ 2014-03-10 23:06 ` Paul Bolle
2014-03-11 16:02 ` Thomas Gleixner
0 siblings, 1 reply; 41+ messages in thread
From: Paul Bolle @ 2014-03-10 23:06 UTC (permalink / raw)
To: Thomas Gleixner
Cc: H. Peter Anvin, Jerome Oufella, Julian Wollrath, x86,
linux-kernel
On Mon, 2014-03-10 at 21:50 +0100, Thomas Gleixner wrote:
> On Mon, 10 Mar 2014, Paul Bolle wrote:
> > So could you please consider downgrading this message?
> >
> > Yes, this will make regressions less visible, although I'm unsure we're
> > actually seeing a regression here. But I think that this is better than
> > scaring people about a situation they can't easily do something about,
> > if at all. Especially since fast TSC calibration failures, apparently,
> > can be worked around.
>
> If something works fine from version X up to v3.13 and then suddenly
> fails, then we can safely ignore it because there is a work around or
> fallback? And just shrug and say: Oh, it's not a regression.
That's not what I said, not at all. Saying that "I'm unsure we're
actually seeing a regression" is not shrugging it off.
> Dammit no. We want to know WHY!
Here I am one and half year after reporting seeing this error. I'm not
aware of anyone reporting it before me. Anyhow, I don't think things
were working fine up to v3.13. And in my report (I'm not going to link
to it again) I suggested to downgrade this message. My exact words were:
So, without even understanding why tsc calibration is needed, it does
look unnecessary to print "Fast TSC calibration failed" at error level.
If that's correct, I'd be happy to submit the trivial patch to downgrade
it to (say) informational level.
Which was fine with hpa (added in CC).
I actually submitted that patch, sent a reminder, and Jerome sent a
similar patch. Most of that was directly sent to you too. I don't think
we got any reaction whatsoever. And, still, suggesting this is not a
regression and reiterating that this could also be printed at something
else than error level somehow provoked your outburst.
I'd like to discuss a way forward. But could you please _try_ to
understand why I said what I said in this discussion?
Paul Bolle
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-10 15:28 ` Paul Bolle
2014-03-10 17:04 ` Thomas Gleixner
@ 2014-03-11 13:27 ` Julian Wollrath
1 sibling, 0 replies; 41+ messages in thread
From: Julian Wollrath @ 2014-03-11 13:27 UTC (permalink / raw)
To: Paul Bolle; +Cc: Thomas Gleixner, x86, linux-kernel
Am Mon, 10 Mar 2014 16:28:34 +0100
schrieb Paul Bolle <pebolle@tiscali.nl>:
> So I'm basically advising Julian to
> double check whether this is really a change in behavior between
> v3.13 and v3.14-rc1. But perhaps Julian already did.
Yes, I did and it happens reliably on every boot with v3.14-rc1.
Cheers,
Julian Wollrath
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-10 10:39 ` Thomas Gleixner
@ 2014-03-11 13:29 ` Julian Wollrath
2014-03-11 13:56 ` Thomas Gleixner
0 siblings, 1 reply; 41+ messages in thread
From: Julian Wollrath @ 2014-03-11 13:29 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: x86, linux-kernel
Am Mon, 10 Mar 2014 11:39:44 +0100 (CET)
schrieb Thomas Gleixner <tglx@linutronix.de>:
> And that definitely does not affect the quick calibration. No idea,
> except bisecting.
Ok, via bisecting I found commit
73f7d1ca32638028e3271f54616773727e2f9f26 (see below) to be the one that
introduced this regression.
Cheers,
Julian Wollrath
>From 73f7d1ca32638028e3271f54616773727e2f9f26 Mon Sep 17 00:00:00 2001
From: "Lee, Chun-Yi" <joeyli.kernel@gmail.com>
Date: Wed, 15 Jan 2014 15:25:48 +0800
Subject: [PATCH] ACPI / init: Run acpi_early_init() before timekeeping_init()
This is a variant patch from Rafael J. Wysocki's
ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()
According to Matt Fleming, if acpi_early_init() was executed before
efi_enter_virtual_mode(), the EFI initialization could benefit from
it, so Rafael's patch makes that happen.
And, we want accessing ACPI TAD device to set system clock, so move
acpi_early_init() before timekeeping_init(). This final position is
also before efi_enter_virtual_mode().
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
init/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/init/main.c b/init/main.c
index febc511e078a..b6d93c840154 100644
--- a/init/main.c
+++ b/init/main.c
@@ -565,6 +565,7 @@ asmlinkage void __init start_kernel(void)
init_timers();
hrtimers_init();
softirq_init();
+ acpi_early_init();
timekeeping_init();
time_init();
sched_clock_postinit();
@@ -641,7 +642,6 @@ asmlinkage void __init start_kernel(void)
check_bugs();
- acpi_early_init(); /* before LAPIC and SMP init */
sfi_init_late();
if (efi_enabled(EFI_RUNTIME_SERVICES)) {
--
1.9.0
^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-11 13:29 ` Julian Wollrath
@ 2014-03-11 13:56 ` Thomas Gleixner
2014-03-11 17:15 ` Julian Wollrath
0 siblings, 1 reply; 41+ messages in thread
From: Thomas Gleixner @ 2014-03-11 13:56 UTC (permalink / raw)
To: Julian Wollrath; +Cc: x86, LKML, Lee, Chun-Yi, Rafael J. Wysocki
On Tue, 11 Mar 2014, Julian Wollrath wrote:
> Am Mon, 10 Mar 2014 11:39:44 +0100 (CET)
> schrieb Thomas Gleixner <tglx@linutronix.de>:
> > And that definitely does not affect the quick calibration. No idea,
> > except bisecting.
> Ok, via bisecting I found commit
> 73f7d1ca32638028e3271f54616773727e2f9f26 (see below) to be the one that
> introduced this regression.
Interesting. I have no idea what's going on. But maybe can the ACPI
folks shed some light on it.
Thanks,
tglx
>
> Cheers,
> Julian Wollrath
>
> From 73f7d1ca32638028e3271f54616773727e2f9f26 Mon Sep 17 00:00:00 2001
> From: "Lee, Chun-Yi" <joeyli.kernel@gmail.com>
> Date: Wed, 15 Jan 2014 15:25:48 +0800
> Subject: [PATCH] ACPI / init: Run acpi_early_init() before timekeeping_init()
>
> This is a variant patch from Rafael J. Wysocki's
> ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()
>
> According to Matt Fleming, if acpi_early_init() was executed before
> efi_enter_virtual_mode(), the EFI initialization could benefit from
> it, so Rafael's patch makes that happen.
>
> And, we want accessing ACPI TAD device to set system clock, so move
> acpi_early_init() before timekeeping_init(). This final position is
> also before efi_enter_virtual_mode().
>
> Tested-by: Toshi Kani <toshi.kani@hp.com>
> Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> init/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/init/main.c b/init/main.c
> index febc511e078a..b6d93c840154 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -565,6 +565,7 @@ asmlinkage void __init start_kernel(void)
> init_timers();
> hrtimers_init();
> softirq_init();
> + acpi_early_init();
> timekeeping_init();
> time_init();
> sched_clock_postinit();
> @@ -641,7 +642,6 @@ asmlinkage void __init start_kernel(void)
>
> check_bugs();
>
> - acpi_early_init(); /* before LAPIC and SMP init */
> sfi_init_late();
>
> if (efi_enabled(EFI_RUNTIME_SERVICES)) {
> --
> 1.9.0
>
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-10 23:06 ` Paul Bolle
@ 2014-03-11 16:02 ` Thomas Gleixner
0 siblings, 0 replies; 41+ messages in thread
From: Thomas Gleixner @ 2014-03-11 16:02 UTC (permalink / raw)
To: Paul Bolle
Cc: H. Peter Anvin, Jerome Oufella, Julian Wollrath, x86,
linux-kernel
On Tue, 11 Mar 2014, Paul Bolle wrote:
> On Mon, 2014-03-10 at 21:50 +0100, Thomas Gleixner wrote:
> > Dammit no. We want to know WHY!
>
> Here I am one and half year after reporting seeing this error. I'm not
> aware of anyone reporting it before me. Anyhow, I don't think things
> were working fine up to v3.13. And in my report (I'm not going to link
You can think what you want.
According to Julian things were working fine for him and he actually
sat down and found out WHY things stopped working. That's what counts.
I really have a hard time to understand why you are wasting everyones
time with a completely pointless discussion about the printk level of
this particular thing. It's not spewing a backtrace. It's one line of
printk and there is no rule, that recoverable issues are not allowed
to be printed at KERN_ERR level.
Julian noticed a change of behaviour due to that after 3.13. That's
way more important than your personal dislike of a particular error
level.
Thanks,
tglx
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-11 13:56 ` Thomas Gleixner
@ 2014-03-11 17:15 ` Julian Wollrath
2014-03-12 4:00 ` joeyli
0 siblings, 1 reply; 41+ messages in thread
From: Julian Wollrath @ 2014-03-11 17:15 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: x86, LKML, Lee, Chun-Yi, Rafael J. Wysocki
Am Tue, 11 Mar 2014 14:56:41 +0100 (CET)
schrieb Thomas Gleixner <tglx@linutronix.de>:
> > Ok, via bisecting I found commit
> > 73f7d1ca32638028e3271f54616773727e2f9f26 (see below) to be the one
> > that introduced this regression.
>
> Interesting. I have no idea what's going on. But maybe can the ACPI
> folks shed some light on it.
I have absolutely no idea, if it is the right thing to do and why it
works, but the patch below fixes the problem. Thank you for your help.
Cheers,
Julian Wollrath
>From 7664f495039d93adfce073e58840a46549904f04 Mon Sep 17 00:00:00 2001
From: Julian Wollrath <jwollrath@web.de>
Date: Tue, 11 Mar 2014 18:05:43 +0100
Subject: [PATCH] Fix fast TSC calibration
Since commit 73f7d1ca32638028e3271f54616773727e2f9f26 the fast TSC calibration
failed on a Thinkpad X121e with an AMD E450 APU. Moving acpi_early_init() after
late_time_init() fixes this.
Signed-off-by: Julian Wollrath <jwollrath@web.de>
---
init/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/init/main.c b/init/main.c
index eb03090cdced..bf9d99148bd6 100644
--- a/init/main.c
+++ b/init/main.c
@@ -561,7 +561,6 @@ asmlinkage void __init start_kernel(void)
init_timers();
hrtimers_init();
softirq_init();
- acpi_early_init();
timekeeping_init();
time_init();
sched_clock_postinit();
@@ -609,6 +608,7 @@ asmlinkage void __init start_kernel(void)
numa_policy_init();
if (late_time_init)
late_time_init();
+ acpi_early_init();
sched_clock_init();
calibrate_delay();
pidmap_init();
--
1.9.0
^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-11 17:15 ` Julian Wollrath
@ 2014-03-12 4:00 ` joeyli
2014-03-12 10:20 ` Julian Wollrath
2014-03-12 11:20 ` Rafael J. Wysocki
0 siblings, 2 replies; 41+ messages in thread
From: joeyli @ 2014-03-12 4:00 UTC (permalink / raw)
To: Julian Wollrath; +Cc: Thomas Gleixner, x86, LKML, Lee, Rafael J. Wysocki
Hi Julian,
於 二，2014-03-11 於 18:15 +0100，Julian Wollrath 提到：
> Am Tue, 11 Mar 2014 14:56:41 +0100 (CET)
> schrieb Thomas Gleixner <tglx@linutronix.de>:
> > > Ok, via bisecting I found commit
> > > 73f7d1ca32638028e3271f54616773727e2f9f26 (see below) to be the one
> > > that introduced this regression.
> >
> > Interesting. I have no idea what's going on. But maybe can the ACPI
> > folks shed some light on it.
>
My patch moved acpi_early_init() to before timekeeping_init() is for
prepare the later using ACPI TAD to set system clock. I think that
because acpi_early_init() setup SCI interrupt and enable acpi subsystem,
it causes fast TSC calibration fail.
> I have absolutely no idea, if it is the right thing to do and why it
> works, but the patch below fixes the problem. Thank you for your help.
>
>
> Cheers,
> Julian Wollrath
>
> From 7664f495039d93adfce073e58840a46549904f04 Mon Sep 17 00:00:00 2001
> From: Julian Wollrath <jwollrath@web.de>
> Date: Tue, 11 Mar 2014 18:05:43 +0100
> Subject: [PATCH] Fix fast TSC calibration
>
> Since commit 73f7d1ca32638028e3271f54616773727e2f9f26 the fast TSC calibration
> failed on a Thinkpad X121e with an AMD E450 APU. Moving acpi_early_init() after
> late_time_init() fixes this.
>
> Signed-off-by: Julian Wollrath <jwollrath@web.de>
> ---
> init/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/init/main.c b/init/main.c
> index eb03090cdced..bf9d99148bd6 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -561,7 +561,6 @@ asmlinkage void __init start_kernel(void)
> init_timers();
> hrtimers_init();
> softirq_init();
> - acpi_early_init();
> timekeeping_init();
> time_init();
> sched_clock_postinit();
> @@ -609,6 +608,7 @@ asmlinkage void __init start_kernel(void)
> numa_policy_init();
> if (late_time_init)
> late_time_init();
> + acpi_early_init();
> sched_clock_init();
> calibrate_delay();
> pidmap_init();
The late_time_init() dependent on timekeeping_init(), if we don't want
move acpi_early_init() before timekeeping_init() then just direct put it
before efi_enter_virtual_mode() because we tested this changed.
This patch restricts the position to run acpi_early_init() before
timekeeping_init() when only "CMOS RTC Not Present" bit set in FADT.
Could you please help to test it on your machine?
Thanks a lot!
Joey Lee
>From 8ef4fff76dd2f50bef1e8eb9c96f3b0228a38401 Mon Sep 17 00:00:00 2001
From: Lee, Chun-Yi <jlee@suse.com>
Date: Wed, 12 Mar 2014 11:36:32 +0800
Subject: [PATCH] ACPI / init: Run acpi_early_init() before timekeeping_init() when CMOS RTC Not Present bit set
This is a variant patch from Rafael J. Wysocki's
ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()
According to Matt Fleming, if acpi_early_init() was executed before
efi_enter_virtual_mode(), the EFI initialization could benefit from
it, so Rafael's patch makes that happen.
And, later we want accessing ACPI TAD device to set system clock, so
move acpi_early_init() before timekeeping_init() when "CMOS RTC Not
Present" bit set. This position is also before efi_enter_virtual_mode().
Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
---
init/main.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/init/main.c b/init/main.c
index eb03090..e1b69d2 100644
--- a/init/main.c
+++ b/init/main.c
@@ -561,7 +561,9 @@ asmlinkage void __init start_kernel(void)
init_timers();
hrtimers_init();
softirq_init();
- acpi_early_init();
+ if (acpi_gbl_FADT.header.revision >= 5 &&
+ acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC)
+ acpi_early_init();
timekeeping_init();
time_init();
sched_clock_postinit();
@@ -613,6 +615,9 @@ asmlinkage void __init start_kernel(void)
calibrate_delay();
pidmap_init();
anon_vma_init();
+ if (!(acpi_gbl_FADT.header.revision >= 5 &&
+ acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC))
+ acpi_early_init();
#ifdef CONFIG_X86
if (efi_enabled(EFI_RUNTIME_SERVICES))
efi_enter_virtual_mode();
--
1.6.4.2
^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-12 4:00 ` joeyli
@ 2014-03-12 10:20 ` Julian Wollrath
2014-03-12 13:52 ` joeyli
2014-03-12 11:20 ` Rafael J. Wysocki
1 sibling, 1 reply; 41+ messages in thread
From: Julian Wollrath @ 2014-03-12 10:20 UTC (permalink / raw)
To: joeyli; +Cc: Thomas Gleixner, x86, LKML, Lee, Rafael J. Wysocki
> This patch restricts the position to run acpi_early_init() before
> timekeeping_init() when only "CMOS RTC Not Present" bit set in FADT.
>
> Could you please help to test it on your machine?
That patch fixes the problem, thank you.
Cheers,
Julian Wollrath
>
>
> Thanks a lot!
> Joey Lee
>
>
> >From 8ef4fff76dd2f50bef1e8eb9c96f3b0228a38401 Mon Sep 17 00:00:00
> >2001
> From: Lee, Chun-Yi <jlee@suse.com>
> Date: Wed, 12 Mar 2014 11:36:32 +0800
> Subject: [PATCH] ACPI / init: Run acpi_early_init() before
> timekeeping_init() when CMOS RTC Not Present bit set
>
> This is a variant patch from Rafael J. Wysocki's
> ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()
>
> According to Matt Fleming, if acpi_early_init() was executed before
> efi_enter_virtual_mode(), the EFI initialization could benefit from
> it, so Rafael's patch makes that happen.
>
> And, later we want accessing ACPI TAD device to set system clock, so
> move acpi_early_init() before timekeeping_init() when "CMOS RTC Not
> Present" bit set. This position is also before
> efi_enter_virtual_mode().
>
> Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
> ---
> init/main.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/init/main.c b/init/main.c
> index eb03090..e1b69d2 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -561,7 +561,9 @@ asmlinkage void __init start_kernel(void)
> init_timers();
> hrtimers_init();
> softirq_init();
> - acpi_early_init();
> + if (acpi_gbl_FADT.header.revision >= 5 &&
> + acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC)
> + acpi_early_init();
> timekeeping_init();
> time_init();
> sched_clock_postinit();
> @@ -613,6 +615,9 @@ asmlinkage void __init start_kernel(void)
> calibrate_delay();
> pidmap_init();
> anon_vma_init();
> + if (!(acpi_gbl_FADT.header.revision >= 5 &&
> + acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC))
> + acpi_early_init();
> #ifdef CONFIG_X86
> if (efi_enabled(EFI_RUNTIME_SERVICES))
> efi_enter_virtual_mode();
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-12 4:00 ` joeyli
2014-03-12 10:20 ` Julian Wollrath
@ 2014-03-12 11:20 ` Rafael J. Wysocki
2014-03-12 13:30 ` Rafael J. Wysocki
2014-03-12 14:00 ` joeyli
1 sibling, 2 replies; 41+ messages in thread
From: Rafael J. Wysocki @ 2014-03-12 11:20 UTC (permalink / raw)
To: joeyli; +Cc: Julian Wollrath, Thomas Gleixner, x86, LKML, Lee,
Rafael J. Wysocki
On Wednesday, March 12, 2014 12:00:07 PM joeyli wrote:
> Hi Julian,
>
> 於 二，2014-03-11 於 18:15 +0100，Julian Wollrath 提到：
> > Am Tue, 11 Mar 2014 14:56:41 +0100 (CET)
> > schrieb Thomas Gleixner <tglx@linutronix.de>:
> > > > Ok, via bisecting I found commit
> > > > 73f7d1ca32638028e3271f54616773727e2f9f26 (see below) to be the one
> > > > that introduced this regression.
> > >
> > > Interesting. I have no idea what's going on. But maybe can the ACPI
> > > folks shed some light on it.
> >
>
> My patch moved acpi_early_init() to before timekeeping_init() is for
> prepare the later using ACPI TAD to set system clock. I think that
> because acpi_early_init() setup SCI interrupt and enable acpi subsystem,
> it causes fast TSC calibration fail.
>
> > I have absolutely no idea, if it is the right thing to do and why it
> > works, but the patch below fixes the problem. Thank you for your help.
> >
> >
> > Cheers,
> > Julian Wollrath
> >
> > From 7664f495039d93adfce073e58840a46549904f04 Mon Sep 17 00:00:00 2001
> > From: Julian Wollrath <jwollrath@web.de>
> > Date: Tue, 11 Mar 2014 18:05:43 +0100
> > Subject: [PATCH] Fix fast TSC calibration
> >
> > Since commit 73f7d1ca32638028e3271f54616773727e2f9f26 the fast TSC calibration
> > failed on a Thinkpad X121e with an AMD E450 APU. Moving acpi_early_init() after
> > late_time_init() fixes this.
> >
> > Signed-off-by: Julian Wollrath <jwollrath@web.de>
> > ---
> > init/main.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/init/main.c b/init/main.c
> > index eb03090cdced..bf9d99148bd6 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -561,7 +561,6 @@ asmlinkage void __init start_kernel(void)
> > init_timers();
> > hrtimers_init();
> > softirq_init();
> > - acpi_early_init();
> > timekeeping_init();
> > time_init();
> > sched_clock_postinit();
> > @@ -609,6 +608,7 @@ asmlinkage void __init start_kernel(void)
> > numa_policy_init();
> > if (late_time_init)
> > late_time_init();
> > + acpi_early_init();
> > sched_clock_init();
> > calibrate_delay();
> > pidmap_init();
>
> The late_time_init() dependent on timekeeping_init(), if we don't want
> move acpi_early_init() before timekeeping_init() then just direct put it
> before efi_enter_virtual_mode() because we tested this changed.
>
> This patch restricts the position to run acpi_early_init() before
> timekeeping_init() when only "CMOS RTC Not Present" bit set in FADT.
>
> Could you please help to test it on your machine?
>
>
> Thanks a lot!
> Joey Lee
>
>
> >From 8ef4fff76dd2f50bef1e8eb9c96f3b0228a38401 Mon Sep 17 00:00:00 2001
> From: Lee, Chun-Yi <jlee@suse.com>
> Date: Wed, 12 Mar 2014 11:36:32 +0800
> Subject: [PATCH] ACPI / init: Run acpi_early_init() before timekeeping_init() when CMOS RTC Not Present bit set
>
> This is a variant patch from Rafael J. Wysocki's
> ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()
>
> According to Matt Fleming, if acpi_early_init() was executed before
> efi_enter_virtual_mode(), the EFI initialization could benefit from
> it, so Rafael's patch makes that happen.
>
> And, later we want accessing ACPI TAD device to set system clock, so
> move acpi_early_init() before timekeeping_init() when "CMOS RTC Not
> Present" bit set. This position is also before efi_enter_virtual_mode().
>
> Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
> ---
> init/main.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/init/main.c b/init/main.c
> index eb03090..e1b69d2 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -561,7 +561,9 @@ asmlinkage void __init start_kernel(void)
> init_timers();
> hrtimers_init();
> softirq_init();
> - acpi_early_init();
> + if (acpi_gbl_FADT.header.revision >= 5 &&
> + acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC)
> + acpi_early_init();
Sorry, this is not the right way to address that.
First of all, checking fields in acpi_gbl_FADT from anything in init/main.c
is wrong. If anything, please move that check to acpi_early_init(). And
make it check it if it's been called already.
> timekeeping_init();
> time_init();
> sched_clock_postinit();
> @@ -613,6 +615,9 @@ asmlinkage void __init start_kernel(void)
> calibrate_delay();
> pidmap_init();
> anon_vma_init();
> + if (!(acpi_gbl_FADT.header.revision >= 5 &&
> + acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC))
> + acpi_early_init();
And then you can call it here again.
> #ifdef CONFIG_X86
> if (efi_enabled(EFI_RUNTIME_SERVICES))
> efi_enter_virtual_mode();
>
But I wonder: Can we simply enable SCI later? In other words, can we
split acpi_early_init() so that the part before acpi_enable_subsystem()
is done before timekeeping_init() and the part including and after
is done right after anon_vma_init()? Would the TAD initialization work
then?
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-12 11:20 ` Rafael J. Wysocki
@ 2014-03-12 13:30 ` Rafael J. Wysocki
2014-03-12 13:55 ` Julian Wollrath
2014-03-12 15:41 ` joeyli
2014-03-12 14:00 ` joeyli
1 sibling, 2 replies; 41+ messages in thread
From: Rafael J. Wysocki @ 2014-03-12 13:30 UTC (permalink / raw)
To: joeyli, Julian Wollrath
Cc: Thomas Gleixner, x86, LKML, Rafael J. Wysocki, H. Peter Anvin
On Wednesday, March 12, 2014 12:20:02 PM Rafael J. Wysocki wrote:
> On Wednesday, March 12, 2014 12:00:07 PM joeyli wrote:
> > Hi Julian,
> >
> > 於 二，2014-03-11 於 18:15 +0100，Julian Wollrath 提到：
> > > Am Tue, 11 Mar 2014 14:56:41 +0100 (CET)
> > > schrieb Thomas Gleixner <tglx@linutronix.de>:
> > > > > Ok, via bisecting I found commit
> > > > > 73f7d1ca32638028e3271f54616773727e2f9f26 (see below) to be the one
> > > > > that introduced this regression.
> > > >
> > > > Interesting. I have no idea what's going on. But maybe can the ACPI
> > > > folks shed some light on it.
> > >
> >
> > My patch moved acpi_early_init() to before timekeeping_init() is for
> > prepare the later using ACPI TAD to set system clock. I think that
> > because acpi_early_init() setup SCI interrupt and enable acpi subsystem,
> > it causes fast TSC calibration fail.
> >
> > > I have absolutely no idea, if it is the right thing to do and why it
> > > works, but the patch below fixes the problem. Thank you for your help.
> > >
> > >
> > > Cheers,
> > > Julian Wollrath
> > >
> > > From 7664f495039d93adfce073e58840a46549904f04 Mon Sep 17 00:00:00 2001
> > > From: Julian Wollrath <jwollrath@web.de>
> > > Date: Tue, 11 Mar 2014 18:05:43 +0100
> > > Subject: [PATCH] Fix fast TSC calibration
> > >
> > > Since commit 73f7d1ca32638028e3271f54616773727e2f9f26 the fast TSC calibration
> > > failed on a Thinkpad X121e with an AMD E450 APU. Moving acpi_early_init() after
> > > late_time_init() fixes this.
> > >
> > > Signed-off-by: Julian Wollrath <jwollrath@web.de>
> > > ---
> > > init/main.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/init/main.c b/init/main.c
> > > index eb03090cdced..bf9d99148bd6 100644
> > > --- a/init/main.c
> > > +++ b/init/main.c
> > > @@ -561,7 +561,6 @@ asmlinkage void __init start_kernel(void)
> > > init_timers();
> > > hrtimers_init();
> > > softirq_init();
> > > - acpi_early_init();
> > > timekeeping_init();
> > > time_init();
> > > sched_clock_postinit();
> > > @@ -609,6 +608,7 @@ asmlinkage void __init start_kernel(void)
> > > numa_policy_init();
> > > if (late_time_init)
> > > late_time_init();
> > > + acpi_early_init();
> > > sched_clock_init();
> > > calibrate_delay();
> > > pidmap_init();
> >
> > The late_time_init() dependent on timekeeping_init(), if we don't want
> > move acpi_early_init() before timekeeping_init() then just direct put it
> > before efi_enter_virtual_mode() because we tested this changed.
> >
> > This patch restricts the position to run acpi_early_init() before
> > timekeeping_init() when only "CMOS RTC Not Present" bit set in FADT.
> >
> > Could you please help to test it on your machine?
> >
> >
> > Thanks a lot!
> > Joey Lee
> >
> >
> > >From 8ef4fff76dd2f50bef1e8eb9c96f3b0228a38401 Mon Sep 17 00:00:00 2001
> > From: Lee, Chun-Yi <jlee@suse.com>
> > Date: Wed, 12 Mar 2014 11:36:32 +0800
> > Subject: [PATCH] ACPI / init: Run acpi_early_init() before timekeeping_init() when CMOS RTC Not Present bit set
> >
> > This is a variant patch from Rafael J. Wysocki's
> > ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()
> >
> > According to Matt Fleming, if acpi_early_init() was executed before
> > efi_enter_virtual_mode(), the EFI initialization could benefit from
> > it, so Rafael's patch makes that happen.
> >
> > And, later we want accessing ACPI TAD device to set system clock, so
> > move acpi_early_init() before timekeeping_init() when "CMOS RTC Not
> > Present" bit set. This position is also before efi_enter_virtual_mode().
> >
> > Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
> > ---
> > init/main.c | 7 ++++++-
> > 1 files changed, 6 insertions(+), 1 deletions(-)
> >
> > diff --git a/init/main.c b/init/main.c
> > index eb03090..e1b69d2 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -561,7 +561,9 @@ asmlinkage void __init start_kernel(void)
> > init_timers();
> > hrtimers_init();
> > softirq_init();
> > - acpi_early_init();
> > + if (acpi_gbl_FADT.header.revision >= 5 &&
> > + acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC)
> > + acpi_early_init();
>
> Sorry, this is not the right way to address that.
>
> First of all, checking fields in acpi_gbl_FADT from anything in init/main.c
> is wrong. If anything, please move that check to acpi_early_init(). And
> make it check it if it's been called already.
>
> > timekeeping_init();
> > time_init();
> > sched_clock_postinit();
> > @@ -613,6 +615,9 @@ asmlinkage void __init start_kernel(void)
> > calibrate_delay();
> > pidmap_init();
> > anon_vma_init();
> > + if (!(acpi_gbl_FADT.header.revision >= 5 &&
> > + acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC))
> > + acpi_early_init();
>
> And then you can call it here again.
>
> > #ifdef CONFIG_X86
> > if (efi_enabled(EFI_RUNTIME_SERVICES))
> > efi_enter_virtual_mode();
> >
>
> But I wonder: Can we simply enable SCI later? In other words, can we
> split acpi_early_init() so that the part before acpi_enable_subsystem()
> is done before timekeeping_init() and the part including and after
> is done right after anon_vma_init()? Would the TAD initialization work
> then?
Below is a patch implementing that idea. Julian, can you please test this one too?
Rafael
---
drivers/acpi/bus.c | 20 +++++++++++++++-----
include/linux/acpi.h | 1 +
init/main.c | 1 +
3 files changed, 17 insertions(+), 5 deletions(-)
Index: linux-pm/drivers/acpi/bus.c
===================================================================
--- linux-pm.orig/drivers/acpi/bus.c
+++ linux-pm/drivers/acpi/bus.c
@@ -494,11 +494,21 @@ void __init acpi_early_init(void)
}
status = acpi_load_tables();
- if (ACPI_FAILURE(status)) {
- printk(KERN_ERR PREFIX
- "Unable to load the System Description Tables\n");
- goto error0;
- }
+ if (ACPI_SUCCESS(status))
+ return;
+
+ printk(KERN_ERR PREFIX "Unable to load the System Description Tables\n");
+
+ error0:
+ disable_acpi();
+}
+
+void __init acpi_subsystem_init(void)
+{
+ acpi_status status;
+
+ if (acpi_disabled)
+ return;
#ifdef CONFIG_X86
if (!acpi_ioapic) {
Index: linux-pm/include/linux/acpi.h
===================================================================
--- linux-pm.orig/include/linux/acpi.h
+++ linux-pm/include/linux/acpi.h
@@ -401,6 +401,7 @@ extern acpi_status acpi_pci_osc_control_
#define ACPI_OST_SC_INSERT_NOT_SUPPORTED 0x82
extern void acpi_early_init(void);
+extern void acpi_subsystem_init(void);
extern int acpi_nvs_register(__u64 start, __u64 size);
Index: linux-pm/init/main.c
===================================================================
--- linux-pm.orig/init/main.c
+++ linux-pm/init/main.c
@@ -613,6 +613,7 @@ asmlinkage void __init start_kernel(void
calibrate_delay();
pidmap_init();
anon_vma_init();
+ acpi_subsystem_init();
#ifdef CONFIG_X86
if (efi_enabled(EFI_RUNTIME_SERVICES))
efi_enter_virtual_mode();
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-12 10:20 ` Julian Wollrath
@ 2014-03-12 13:52 ` joeyli
0 siblings, 0 replies; 41+ messages in thread
From: joeyli @ 2014-03-12 13:52 UTC (permalink / raw)
To: Julian Wollrath; +Cc: Thomas Gleixner, x86, LKML, Lee, Rafael J. Wysocki
於 三，2014-03-12 於 11:20 +0100，Julian Wollrath 提到：
> > This patch restricts the position to run acpi_early_init() before
> > timekeeping_init() when only "CMOS RTC Not Present" bit set in FADT.
> >
> > Could you please help to test it on your machine?
> That patch fixes the problem, thank you.
>
> Cheers,
> Julian Wollrath
> >
Thanks for your test.
Regards
Joey Lee
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-12 13:30 ` Rafael J. Wysocki
@ 2014-03-12 13:55 ` Julian Wollrath
2014-03-12 15:41 ` joeyli
1 sibling, 0 replies; 41+ messages in thread
From: Julian Wollrath @ 2014-03-12 13:55 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: joeyli, Thomas Gleixner, x86, LKML, Rafael J. Wysocki,
H. Peter Anvin
> > But I wonder: Can we simply enable SCI later? In other words, can
> > we split acpi_early_init() so that the part before
> > acpi_enable_subsystem() is done before timekeeping_init() and the
> > part including and after is done right after anon_vma_init()?
> > Would the TAD initialization work then?
>
> Below is a patch implementing that idea. Julian, can you please test
> this one too?
That patch also fixes the problem, thank you.
Cheers,
Julian
>
> Rafael
>
> ---
> drivers/acpi/bus.c | 20 +++++++++++++++-----
> include/linux/acpi.h | 1 +
> init/main.c | 1 +
> 3 files changed, 17 insertions(+), 5 deletions(-)
>
> Index: linux-pm/drivers/acpi/bus.c
> ===================================================================
> --- linux-pm.orig/drivers/acpi/bus.c
> +++ linux-pm/drivers/acpi/bus.c
> @@ -494,11 +494,21 @@ void __init acpi_early_init(void)
> }
>
> status = acpi_load_tables();
> - if (ACPI_FAILURE(status)) {
> - printk(KERN_ERR PREFIX
> - "Unable to load the System Description
> Tables\n");
> - goto error0;
> - }
> + if (ACPI_SUCCESS(status))
> + return;
> +
> + printk(KERN_ERR PREFIX "Unable to load the System
> Description Tables\n"); +
> + error0:
> + disable_acpi();
> +}
> +
> +void __init acpi_subsystem_init(void)
> +{
> + acpi_status status;
> +
> + if (acpi_disabled)
> + return;
>
> #ifdef CONFIG_X86
> if (!acpi_ioapic) {
> Index: linux-pm/include/linux/acpi.h
> ===================================================================
> --- linux-pm.orig/include/linux/acpi.h
> +++ linux-pm/include/linux/acpi.h
> @@ -401,6 +401,7 @@ extern acpi_status acpi_pci_osc_control_
> #define ACPI_OST_SC_INSERT_NOT_SUPPORTED 0x82
>
> extern void acpi_early_init(void);
> +extern void acpi_subsystem_init(void);
>
> extern int acpi_nvs_register(__u64 start, __u64 size);
>
> Index: linux-pm/init/main.c
> ===================================================================
> --- linux-pm.orig/init/main.c
> +++ linux-pm/init/main.c
> @@ -613,6 +613,7 @@ asmlinkage void __init start_kernel(void
> calibrate_delay();
> pidmap_init();
> anon_vma_init();
> + acpi_subsystem_init();
> #ifdef CONFIG_X86
> if (efi_enabled(EFI_RUNTIME_SERVICES))
> efi_enter_virtual_mode();
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-12 11:20 ` Rafael J. Wysocki
2014-03-12 13:30 ` Rafael J. Wysocki
@ 2014-03-12 14:00 ` joeyli
1 sibling, 0 replies; 41+ messages in thread
From: joeyli @ 2014-03-12 14:00 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Julian Wollrath, Thomas Gleixner, x86, LKML, Lee,
Rafael J. Wysocki
於 三，2014-03-12 於 12:20 +0100，Rafael J. Wysocki 提到：
> On Wednesday, March 12, 2014 12:00:07 PM joeyli wrote:
> > Hi Julian,
[...]
> >
> >
> > >From 8ef4fff76dd2f50bef1e8eb9c96f3b0228a38401 Mon Sep 17 00:00:00 2001
> > From: Lee, Chun-Yi <jlee@suse.com>
> > Date: Wed, 12 Mar 2014 11:36:32 +0800
> > Subject: [PATCH] ACPI / init: Run acpi_early_init() before timekeeping_init() when CMOS RTC Not Present bit set
> >
> > This is a variant patch from Rafael J. Wysocki's
> > ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()
> >
> > According to Matt Fleming, if acpi_early_init() was executed before
> > efi_enter_virtual_mode(), the EFI initialization could benefit from
> > it, so Rafael's patch makes that happen.
> >
> > And, later we want accessing ACPI TAD device to set system clock, so
> > move acpi_early_init() before timekeeping_init() when "CMOS RTC Not
> > Present" bit set. This position is also before efi_enter_virtual_mode().
> >
> > Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
> > ---
> > init/main.c | 7 ++++++-
> > 1 files changed, 6 insertions(+), 1 deletions(-)
> >
> > diff --git a/init/main.c b/init/main.c
> > index eb03090..e1b69d2 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -561,7 +561,9 @@ asmlinkage void __init start_kernel(void)
> > init_timers();
> > hrtimers_init();
> > softirq_init();
> > - acpi_early_init();
> > + if (acpi_gbl_FADT.header.revision >= 5 &&
> > + acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC)
> > + acpi_early_init();
>
> Sorry, this is not the right way to address that.
>
> First of all, checking fields in acpi_gbl_FADT from anything in init/main.c
> is wrong. If anything, please move that check to acpi_early_init(). And
> make it check it if it's been called already.
>
I see, thanks for your suggestion.
> > timekeeping_init();
> > time_init();
> > sched_clock_postinit();
> > @@ -613,6 +615,9 @@ asmlinkage void __init start_kernel(void)
> > calibrate_delay();
> > pidmap_init();
> > anon_vma_init();
> > + if (!(acpi_gbl_FADT.header.revision >= 5 &&
> > + acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC))
> > + acpi_early_init();
>
> And then you can call it here again.
>
> > #ifdef CONFIG_X86
> > if (efi_enabled(EFI_RUNTIME_SERVICES))
> > efi_enter_virtual_mode();
> >
>
> But I wonder: Can we simply enable SCI later? In other words, can we
> split acpi_early_init() so that the part before acpi_enable_subsystem()
> is done before timekeeping_init() and the part including and after
> is done right after anon_vma_init()? Would the TAD initialization work
> then?
>
The machine that support ACPI TAD doesn't on my hand now, I need find a
time go to check it. Per DSDT, it trigger SMI in _GRT and _SRT to
get/set time. Looks no SCI involve.
Thanks a lot!
Joey Lee
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-12 13:30 ` Rafael J. Wysocki
2014-03-12 13:55 ` Julian Wollrath
@ 2014-03-12 15:41 ` joeyli
2014-03-12 16:20 ` Thomas Gleixner
1 sibling, 1 reply; 41+ messages in thread
From: joeyli @ 2014-03-12 15:41 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Julian Wollrath, Thomas Gleixner, x86, LKML, Rafael J. Wysocki,
H. Peter Anvin
Hi Rafael,
於 三，2014-03-12 於 14:30 +0100，Rafael J. Wysocki 提到：
> > But I wonder: Can we simply enable SCI later? In other words, can
> we
> > split acpi_early_init() so that the part before
> acpi_enable_subsystem()
> > is done before timekeeping_init() and the part including and after
> > is done right after anon_vma_init()? Would the TAD initialization
> work
> > then?
>
> Below is a patch implementing that idea. Julian, can you please test
> this one too?
>
> Rafael
>
> ---
> drivers/acpi/bus.c | 20 +++++++++++++++-----
> include/linux/acpi.h | 1 +
> init/main.c | 1 +
> 3 files changed, 17 insertions(+), 5 deletions(-)
>
> Index: linux-pm/drivers/acpi/bus.c
> ===================================================================
> --- linux-pm.orig/drivers/acpi/bus.c
> +++ linux-pm/drivers/acpi/bus.c
> @@ -494,11 +494,21 @@ void __init acpi_early_init(void)
> }
>
> status = acpi_load_tables();
> - if (ACPI_FAILURE(status)) {
> - printk(KERN_ERR PREFIX
> - "Unable to load the System Description Tables
> \n");
> - goto error0;
> - }
> + if (ACPI_SUCCESS(status))
> + return;
> +
> + printk(KERN_ERR PREFIX "Unable to load the System Description
> Tables\n");
> +
> + error0:
> + disable_acpi();
> +}
> +
> +void __init acpi_subsystem_init(void)
> +{
> + acpi_status status;
> +
> + if (acpi_disabled)
> + return;
>
After check the DSDT of target machine, I afraid the above patch is not
enough to use _GRT and _SRT because they need opregion support of
SystemMemory and SystemIO for trigger SMM to access RTC.
In my current semifinished patches, I add code to run the
acpi_ev_install_region_handlers() in acpi_enable_subsystem() when
acpi_early_init(), for install region handler to support opregion.
Before install region_handlers, it call acpi_enable() to enable acpi
mode and I think need setup SCI interrupt before run acpi_enable():
acpi_early_init(void)
acpi_pic_sci_set_trigger(acpi_gbl_FADT.sci_interrupt,
acpi_enable_subsystem(u32 flags)
acpi_enable(); /* Enable ACPI mode */
acpi_tb_initialize_facs();
acpi_ev_install_region_handlers(); /* Need it! */
For developing ACPI TAD support, I used SystemIO to access CMOS port in
DSDT of Intel DQ57 for simulate ACPI TAD. It also need SystemIO opregion
support as the real machine. I just run your patch on this machine but
it failed.
I think maybe still using ACPI_FADT_NO_CMOS_RTC to check does
acpi_early_init() need run before timekeeping_init().
If there have any future machine that applied ACPI TAD but "Fast TSC
calibration" fail, at least the alternate TSC calibration can work
around issue.
Thanks a lot!
Joey Lee
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-12 15:41 ` joeyli
@ 2014-03-12 16:20 ` Thomas Gleixner
2014-03-12 16:23 ` Thomas Gleixner
0 siblings, 1 reply; 41+ messages in thread
From: Thomas Gleixner @ 2014-03-12 16:20 UTC (permalink / raw)
To: joeyli
Cc: Rafael J. Wysocki, Julian Wollrath, x86, LKML, Rafael J. Wysocki,
H. Peter Anvin
On Wed, 12 Mar 2014, joeyli wrote:
> I think maybe still using ACPI_FADT_NO_CMOS_RTC to check does
> acpi_early_init() need run before timekeeping_init().
> If there have any future machine that applied ACPI TAD but "Fast TSC
> calibration" fail, at least the alternate TSC calibration can work
> around issue.
Well, it can work around, but it sucks as it's way slower than the
fast one. And we really don't want to pay that price for some half
baken ACPI nonsense.
Why exactly do you need that ACPI stuff before timekeeping_init()?
Thanks,
tglx
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-12 16:20 ` Thomas Gleixner
@ 2014-03-12 16:23 ` Thomas Gleixner
2014-03-12 16:39 ` Thomas Gleixner
0 siblings, 1 reply; 41+ messages in thread
From: Thomas Gleixner @ 2014-03-12 16:23 UTC (permalink / raw)
To: joeyli
Cc: Rafael J. Wysocki, Julian Wollrath, x86, LKML, Rafael J. Wysocki,
H. Peter Anvin
On Wed, 12 Mar 2014, Thomas Gleixner wrote:
> On Wed, 12 Mar 2014, joeyli wrote:
> > I think maybe still using ACPI_FADT_NO_CMOS_RTC to check does
> > acpi_early_init() need run before timekeeping_init().
> > If there have any future machine that applied ACPI TAD but "Fast TSC
> > calibration" fail, at least the alternate TSC calibration can work
> > around issue.
>
> Well, it can work around, but it sucks as it's way slower than the
> fast one. And we really don't want to pay that price for some half
> baken ACPI nonsense.
>
> Why exactly do you need that ACPI stuff before timekeeping_init()?
According to the changelog:
And, we want accessing ACPI TAD device to set system clock, so move
acpi_early_init() before timekeeping_init(). This final position is
also before efi_enter_virtual_mode().
Why do we need to access that TAD thing (whatever newfangled that is)
at this point?
Thanks,
tglx
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-12 16:23 ` Thomas Gleixner
@ 2014-03-12 16:39 ` Thomas Gleixner
2014-03-12 23:27 ` Rafael J. Wysocki
0 siblings, 1 reply; 41+ messages in thread
From: Thomas Gleixner @ 2014-03-12 16:39 UTC (permalink / raw)
To: joeyli
Cc: Rafael J. Wysocki, Julian Wollrath, x86, LKML, Rafael J. Wysocki,
H. Peter Anvin
On Wed, 12 Mar 2014, Thomas Gleixner wrote:
> On Wed, 12 Mar 2014, Thomas Gleixner wrote:
>
> > On Wed, 12 Mar 2014, joeyli wrote:
> > > I think maybe still using ACPI_FADT_NO_CMOS_RTC to check does
> > > acpi_early_init() need run before timekeeping_init().
> > > If there have any future machine that applied ACPI TAD but "Fast TSC
> > > calibration" fail, at least the alternate TSC calibration can work
> > > around issue.
> >
> > Well, it can work around, but it sucks as it's way slower than the
> > fast one. And we really don't want to pay that price for some half
> > baken ACPI nonsense.
> >
> > Why exactly do you need that ACPI stuff before timekeeping_init()?
>
> According to the changelog:
>
> And, we want accessing ACPI TAD device to set system clock, so move
> acpi_early_init() before timekeeping_init(). This final position is
> also before efi_enter_virtual_mode().
>
> Why do we need to access that TAD thing (whatever newfangled that is)
> at this point?
And we have no support for that nonsense in tree, so why do we need to
disturb functionality which does not need that at all?
We can revisit the issue when we actually have reached a conclusion
how to deal with that and when we are merging something which supports
TAD.
Up to then we really can live without that and put the call just
before efi_enter_virtual_mode().
Even if the TAD stuff should be used to set system time, you can do so
way after timekeeping_init() when the proper driver is
installed. That's how a lot of embedded systems do it today simply
because they can't access the rtc that early.
There is no point to inflict this ACPI nonsense in early boot. It's
bad enough that we have to deal with it at all.
Thanks,
tglx
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-12 16:39 ` Thomas Gleixner
@ 2014-03-12 23:27 ` Rafael J. Wysocki
2014-03-12 23:49 ` Thomas Gleixner
2014-03-13 0:54 ` Thomas Gleixner
0 siblings, 2 replies; 41+ messages in thread
From: Rafael J. Wysocki @ 2014-03-12 23:27 UTC (permalink / raw)
To: Thomas Gleixner
Cc: joeyli, Julian Wollrath, x86, LKML, Rafael J. Wysocki,
H. Peter Anvin
On Wednesday, March 12, 2014 05:39:15 PM Thomas Gleixner wrote:
> On Wed, 12 Mar 2014, Thomas Gleixner wrote:
> > On Wed, 12 Mar 2014, Thomas Gleixner wrote:
> >
> > > On Wed, 12 Mar 2014, joeyli wrote:
> > > > I think maybe still using ACPI_FADT_NO_CMOS_RTC to check does
> > > > acpi_early_init() need run before timekeeping_init().
> > > > If there have any future machine that applied ACPI TAD but "Fast TSC
> > > > calibration" fail, at least the alternate TSC calibration can work
> > > > around issue.
> > >
> > > Well, it can work around, but it sucks as it's way slower than the
> > > fast one. And we really don't want to pay that price for some half
> > > baken ACPI nonsense.
> > >
> > > Why exactly do you need that ACPI stuff before timekeeping_init()?
> >
> > According to the changelog:
> >
> > And, we want accessing ACPI TAD device to set system clock, so move
> > acpi_early_init() before timekeeping_init(). This final position is
> > also before efi_enter_virtual_mode().
> >
> > Why do we need to access that TAD thing (whatever newfangled that is)
> > at this point?
>
> And we have no support for that nonsense in tree, so why do we need to
> disturb functionality which does not need that at all?
>
> We can revisit the issue when we actually have reached a conclusion
> how to deal with that and when we are merging something which supports
> TAD.
>
> Up to then we really can live without that and put the call just
> before efi_enter_virtual_mode().
I agree, and we need to fix that for 3.14. Patch is appended.
Thanks,
Rafael
---
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Subject: ACPI / init: Invoke early ACPI initialization later
Commit 73f7d1ca3263 (ACPI / init: Run acpi_early_init() before
timekeeping_init()) optimistically moved the early ACPI initialization
before timekeeping_init(), but that didn't work, because it broke fast
TSC calibration for Julian Wollrath on Thinkpad x121e (and most likely
for others too). The reason is that acpi_early_init() enables the SCI
and that interferes with the fast TSC calibration mechanism.
Thus follow the original idea to execute acpi_early_init() before
efi_enter_virtual_mode() to help the EFI people for now and we can
revisit the other problem that commit 73f7d1ca3263 attempted to
address in the future (if really necessary).
Fixes: 73f7d1ca3263 (ACPI / init: Run acpi_early_init() before timekeeping_init())
Reported-by: Julian Wollrath <jwollrath@web.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
init/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-pm/init/main.c
===================================================================
--- linux-pm.orig/init/main.c
+++ linux-pm/init/main.c
@@ -561,7 +561,6 @@ asmlinkage void __init start_kernel(void
init_timers();
hrtimers_init();
softirq_init();
- acpi_early_init();
timekeeping_init();
time_init();
sched_clock_postinit();
@@ -613,6 +612,7 @@ asmlinkage void __init start_kernel(void
calibrate_delay();
pidmap_init();
anon_vma_init();
+ acpi_early_init();
#ifdef CONFIG_X86
if (efi_enabled(EFI_RUNTIME_SERVICES))
efi_enter_virtual_mode();
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-12 23:27 ` Rafael J. Wysocki
@ 2014-03-12 23:49 ` Thomas Gleixner
2014-03-13 0:13 ` Rafael J. Wysocki
2014-03-13 2:56 ` joeyli
2014-03-13 0:54 ` Thomas Gleixner
1 sibling, 2 replies; 41+ messages in thread
From: Thomas Gleixner @ 2014-03-12 23:49 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: joeyli, Julian Wollrath, x86, LKML, Rafael J. Wysocki,
H. Peter Anvin
On Thu, 13 Mar 2014, Rafael J. Wysocki wrote:
> I agree, and we need to fix that for 3.14. Patch is appended.
You beat me by a few minutes. Was about to send out the same, just
with a more spicy changelog :)
> ---
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Subject: ACPI / init: Invoke early ACPI initialization later
>
> Commit 73f7d1ca3263 (ACPI / init: Run acpi_early_init() before
> timekeeping_init()) optimistically moved the early ACPI initialization
> before timekeeping_init(), but that didn't work, because it broke fast
> TSC calibration for Julian Wollrath on Thinkpad x121e (and most likely
> for others too). The reason is that acpi_early_init() enables the SCI
> and that interferes with the fast TSC calibration mechanism.
>
> Thus follow the original idea to execute acpi_early_init() before
> efi_enter_virtual_mode() to help the EFI people for now and we can
> revisit the other problem that commit 73f7d1ca3263 attempted to
> address in the future (if really necessary).
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-12 23:49 ` Thomas Gleixner
@ 2014-03-13 0:13 ` Rafael J. Wysocki
2014-03-13 2:56 ` joeyli
1 sibling, 0 replies; 41+ messages in thread
From: Rafael J. Wysocki @ 2014-03-13 0:13 UTC (permalink / raw)
To: Thomas Gleixner
Cc: joeyli, Julian Wollrath, x86, LKML, Rafael J. Wysocki,
H. Peter Anvin
On Thursday, March 13, 2014 12:49:07 AM Thomas Gleixner wrote:
> On Thu, 13 Mar 2014, Rafael J. Wysocki wrote:
> > I agree, and we need to fix that for 3.14. Patch is appended.
>
> You beat me by a few minutes. Was about to send out the same, just
> with a more spicy changelog :)
>
> > ---
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Subject: ACPI / init: Invoke early ACPI initialization later
> >
> > Commit 73f7d1ca3263 (ACPI / init: Run acpi_early_init() before
> > timekeeping_init()) optimistically moved the early ACPI initialization
> > before timekeeping_init(), but that didn't work, because it broke fast
> > TSC calibration for Julian Wollrath on Thinkpad x121e (and most likely
> > for others too). The reason is that acpi_early_init() enables the SCI
> > and that interferes with the fast TSC calibration mechanism.
> >
> > Thus follow the original idea to execute acpi_early_init() before
> > efi_enter_virtual_mode() to help the EFI people for now and we can
> > revisit the other problem that commit 73f7d1ca3263 attempted to
> > address in the future (if really necessary).
>
> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Thanks!
I have a plan to push this to Linus for -rc7.
Rafael
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-12 23:27 ` Rafael J. Wysocki
2014-03-12 23:49 ` Thomas Gleixner
@ 2014-03-13 0:54 ` Thomas Gleixner
2014-03-13 1:01 ` Thomas Gleixner
` (2 more replies)
1 sibling, 3 replies; 41+ messages in thread
From: Thomas Gleixner @ 2014-03-13 0:54 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: joeyli, Julian Wollrath, x86, LKML, Rafael J. Wysocki,
H. Peter Anvin, John Stultz, Ted Ts'o, Linus Torvalds
On Thu, 13 Mar 2014, Rafael J. Wysocki wrote:
> Thus follow the original idea to execute acpi_early_init() before
> efi_enter_virtual_mode() to help the EFI people for now and we can
> revisit the other problem that commit 73f7d1ca3263 attempted to
> address in the future (if really necessary).
It's not necessary at all. In fact we really want to get rid of the
arch specific cmos stuff which is an historical leftover.
I talked to John Stultz earlier today and he agrees that there are
only a few trivial things to add to the RTC subsystem to make this
work.
>From the timekeeping POV there is absolutely no need to set the wall
clock time early. The kernel boot phase does not care about wall time
at all. We should have it done before we hit userspace, but not even
that is a hard requirement.
That TAD/EFI time mess is not going to happen before that is solved.
Thanks,
tglx
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-13 0:54 ` Thomas Gleixner
@ 2014-03-13 1:01 ` Thomas Gleixner
2014-03-13 2:38 ` joeyli
2014-03-13 3:41 ` H. Peter Anvin
2 siblings, 0 replies; 41+ messages in thread
From: Thomas Gleixner @ 2014-03-13 1:01 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: joeyli, Julian Wollrath, x86, LKML, Rafael J. Wysocki,
H. Peter Anvin, John Stultz, Ted Ts'o, Linus Torvalds
On Thu, 13 Mar 2014, Thomas Gleixner wrote:
> On Thu, 13 Mar 2014, Rafael J. Wysocki wrote:
> > Thus follow the original idea to execute acpi_early_init() before
> > efi_enter_virtual_mode() to help the EFI people for now and we can
> > revisit the other problem that commit 73f7d1ca3263 attempted to
> > address in the future (if really necessary).
>
> It's not necessary at all. In fact we really want to get rid of the
> arch specific cmos stuff which is an historical leftover.
>
> I talked to John Stultz earlier today and he agrees that there are
> only a few trivial things to add to the RTC subsystem to make this
> work.
>
> From the timekeeping POV there is absolutely no need to set the wall
> clock time early. The kernel boot phase does not care about wall time
> at all. We should have it done before we hit userspace, but not even
> that is a hard requirement.
>
> That TAD/EFI time mess is not going to happen before that is solved.
Though there was one odd request versus randomness to take the RTC
into account very early on boot. I really can't make any sense of it.
How helpful is entropy which is added by something which can be
reevaluated by looking at the boot time? The randomness factor of the
standard 1 sec resolution is not that amazing either.
Why don't we make use of the inherent randomness of todays cpus which
will help ALL architectures and systems independent of early RTC
availablity? Something along these lines will add a way better initial
entropy than any RTC can provide:
u64 random_init(void)
{
u64 i = 0, tmp = SEED, t = sched_clock();
u64 rnd = (long) t;
for (; (sched_clock() < (t + X) && i < MINLOOPS; tmp += SOMETHING, i++)
rnd = some_useful_rng_algo(rnd, tmp, sched_clock());
return rnd;
}
Tune X and MINLOOPS to your needs and place the call of random_init()
to a point where most sane systems have reached the point where a high
resolution sched_clock is available and the system is
preemtible. That's the case quite early in the boot process. Add a
synchronization point to finalize that before we have any serious
user.
Even if no high resolution sched clock is available at this point the
randomness of the call versus the breakout of the loop will be unique
per boot process and way better than anything we have right now all
across the architecture space.
Add some randomness injection from the sched_clock() based runtime of
the various initcalls to it and we have a way better baseline than we
have now for all of our architectures.
Enforcing some early RTC availability for the sake of randomness does
not make sense when we do not exploit better sources which are
available on all systems in the first place.
Thanks,
tglx
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-13 0:54 ` Thomas Gleixner
2014-03-13 1:01 ` Thomas Gleixner
@ 2014-03-13 2:38 ` joeyli
2014-03-13 3:11 ` H. Peter Anvin
2014-03-13 3:41 ` H. Peter Anvin
2 siblings, 1 reply; 41+ messages in thread
From: joeyli @ 2014-03-13 2:38 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Rafael J. Wysocki, Julian Wollrath, x86, LKML, Rafael J. Wysocki,
H. Peter Anvin, John Stultz, Ted Ts'o, Linus Torvalds
於 四，2014-03-13 於 01:54 +0100，Thomas Gleixner 提到：
> On Thu, 13 Mar 2014, Rafael J. Wysocki wrote:
> > Thus follow the original idea to execute acpi_early_init() before
> > efi_enter_virtual_mode() to help the EFI people for now and we can
> > revisit the other problem that commit 73f7d1ca3263 attempted to
> > address in the future (if really necessary).
>
> It's not necessary at all. In fact we really want to get rid of the
> arch specific cmos stuff which is an historical leftover.
>
> I talked to John Stultz earlier today and he agrees that there are
> only a few trivial things to add to the RTC subsystem to make this
> work.
>
I sent rtc-acpitad driver for RTC subsystem on last month, I will send
second version.
For using TAD to set wall clock is because in ACPI 5.0 spec, there have
a "CMOS RTC Not Present" flag in FADT to indicate OSPM should use TAD
when this flag set:
CMOS RTC Not Present
If set, indicates that the CMOS RTC is either not implemented, or
does not exist at the legacy addresses. OSPM uses the Control
Method Time and Alarm Namespace device instead.
So, the original thinking of patch is using TAD to replace CMOS
interface in kernel for access RTC. The timekeeping_init() is the
earliest function to access CMOS RTC, that's why move TAD before it.
I hope can discuss about "CMOS RTC Not Present" flag. If hardware vendor
set this flag in FADT, should we avoid to access CMOS RTC interface in
any kernel code?
> >From the timekeeping POV there is absolutely no need to set the wall
> clock time early. The kernel boot phase does not care about wall time
> at all. We should have it done before we hit userspace, but not even
> that is a hard requirement.
I agree! If kernel boot phase does not care about wall time, then we
don't need parse DSDT for access TAD too early.
>
> That TAD/EFI time mess is not going to happen before that is solved.
>
> Thanks,
>
> tglx
>
ACPI TAD return local time and timezone information so kernel can adjust
wall time then don't need userspace involve.
Thanks a lot!
Joey Lee
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-12 23:49 ` Thomas Gleixner
2014-03-13 0:13 ` Rafael J. Wysocki
@ 2014-03-13 2:56 ` joeyli
1 sibling, 0 replies; 41+ messages in thread
From: joeyli @ 2014-03-13 2:56 UTC (permalink / raw)
To: Thomas Gleixner, Rafael J. Wysocki
Cc: Julian Wollrath, x86, LKML, Rafael J. Wysocki, H. Peter Anvin
於 四，2014-03-13 於 00:49 +0100，Thomas Gleixner 提到：
> On Thu, 13 Mar 2014, Rafael J. Wysocki wrote:
> > I agree, and we need to fix that for 3.14. Patch is appended.
>
> You beat me by a few minutes. Was about to send out the same, just
> with a more spicy changelog :)
>
> > ---
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Subject: ACPI / init: Invoke early ACPI initialization later
> >
> > Commit 73f7d1ca3263 (ACPI / init: Run acpi_early_init() before
> > timekeeping_init()) optimistically moved the early ACPI initialization
> > before timekeeping_init(), but that didn't work, because it broke fast
> > TSC calibration for Julian Wollrath on Thinkpad x121e (and most likely
> > for others too). The reason is that acpi_early_init() enables the SCI
> > and that interferes with the fast TSC calibration mechanism.
> >
> > Thus follow the original idea to execute acpi_early_init() before
> > efi_enter_virtual_mode() to help the EFI people for now and we can
> > revisit the other problem that commit 73f7d1ca3263 attempted to
> > address in the future (if really necessary).
>
> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
>
>
Acked-by: Lee, Chun-Yi <jlee@suse.com>
Thanks a lot!
Joey Lee
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-13 2:38 ` joeyli
@ 2014-03-13 3:11 ` H. Peter Anvin
2014-03-13 3:55 ` joeyli
0 siblings, 1 reply; 41+ messages in thread
From: H. Peter Anvin @ 2014-03-13 3:11 UTC (permalink / raw)
To: joeyli, Thomas Gleixner
Cc: Rafael J. Wysocki, Julian Wollrath, x86, LKML, Rafael J. Wysocki,
John Stultz, Ted Ts'o, Linus Torvalds
On 03/12/2014 07:38 PM, joeyli wrote:
>
> I sent rtc-acpitad driver for RTC subsystem on last month, I will send
> second version.
>
> For using TAD to set wall clock is because in ACPI 5.0 spec, there have
> a "CMOS RTC Not Present" flag in FADT to indicate OSPM should use TAD
> when this flag set:
>
> CMOS RTC Not Present
>
Bullsh*t. The TAD should be used if it is present, it has nothing to do
with this flag.
-hpa
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-13 0:54 ` Thomas Gleixner
2014-03-13 1:01 ` Thomas Gleixner
2014-03-13 2:38 ` joeyli
@ 2014-03-13 3:41 ` H. Peter Anvin
2 siblings, 0 replies; 41+ messages in thread
From: H. Peter Anvin @ 2014-03-13 3:41 UTC (permalink / raw)
To: Thomas Gleixner, Rafael J. Wysocki
Cc: joeyli, Julian Wollrath, x86, LKML, Rafael J. Wysocki,
John Stultz, Ted Ts'o, Linus Torvalds
On 03/12/2014 05:54 PM, Thomas Gleixner wrote:
>
> From the timekeeping POV there is absolutely no need to set the wall
> clock time early. The kernel boot phase does not care about wall time
> at all. We should have it done before we hit userspace, but not even
> that is a hard requirement.
>
This is a key observation, I believe.
-hpa
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-13 3:11 ` H. Peter Anvin
@ 2014-03-13 3:55 ` joeyli
2014-03-13 3:59 ` H. Peter Anvin
0 siblings, 1 reply; 41+ messages in thread
From: joeyli @ 2014-03-13 3:55 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Thomas Gleixner, Rafael J. Wysocki, Julian Wollrath, x86, LKML,
Rafael J. Wysocki, John Stultz, Ted Ts'o, Linus Torvalds
於 三，2014-03-12 於 20:11 -0700，H. Peter Anvin 提到：
> On 03/12/2014 07:38 PM, joeyli wrote:
> >
> > I sent rtc-acpitad driver for RTC subsystem on last month, I will send
> > second version.
> >
> > For using TAD to set wall clock is because in ACPI 5.0 spec, there have
> > a "CMOS RTC Not Present" flag in FADT to indicate OSPM should use TAD
> > when this flag set:
> >
> > CMOS RTC Not Present
> >
>
> Bullsh*t. The TAD should be used if it is present, it has nothing to do
> with this flag.
>
> -hpa
>
>
So do not care "CMOS RTC Not Present", if TAD is present then we use it
instead of CMOS RTC in all kernel code? or we still can use CMOS RTC?
Regards
Joey Lee
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-13 3:55 ` joeyli
@ 2014-03-13 3:59 ` H. Peter Anvin
2014-03-13 4:12 ` joeyli
0 siblings, 1 reply; 41+ messages in thread
From: H. Peter Anvin @ 2014-03-13 3:59 UTC (permalink / raw)
To: joeyli
Cc: Thomas Gleixner, Rafael J. Wysocki, Julian Wollrath, x86, LKML,
Rafael J. Wysocki, John Stultz, Ted Ts'o, Linus Torvalds
On 03/12/2014 08:55 PM, joeyli wrote:
>
> So do not care "CMOS RTC Not Present", if TAD is present then we use it
> instead of CMOS RTC in all kernel code? or we still can use CMOS RTC?
>
Why would we use *both*!? How would that possibly make sense?
-hpa
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-13 3:59 ` H. Peter Anvin
@ 2014-03-13 4:12 ` joeyli
2014-03-13 8:12 ` Thomas Gleixner
0 siblings, 1 reply; 41+ messages in thread
From: joeyli @ 2014-03-13 4:12 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Thomas Gleixner, Rafael J. Wysocki, Julian Wollrath, x86, LKML,
Rafael J. Wysocki, John Stultz, Ted Ts'o, Linus Torvalds
於 三，2014-03-12 於 20:59 -0700，H. Peter Anvin 提到：
> On 03/12/2014 08:55 PM, joeyli wrote:
> >
> > So do not care "CMOS RTC Not Present", if TAD is present then we use it
> > instead of CMOS RTC in all kernel code? or we still can use CMOS RTC?
> >
>
> Why would we use *both*!? How would that possibly make sense?
>
> -hpa
>
Yes, it does not make sense for using both.
I switched the code in get_rtc_time() set_rtc_time() to TAD when it
present, just make sure I'm on the right path.
Thanks a lot!
Joey Lee
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-13 4:12 ` joeyli
@ 2014-03-13 8:12 ` Thomas Gleixner
2014-03-13 8:59 ` joeyli
0 siblings, 1 reply; 41+ messages in thread
From: Thomas Gleixner @ 2014-03-13 8:12 UTC (permalink / raw)
To: joeyli
Cc: H. Peter Anvin, Rafael J. Wysocki, Julian Wollrath, x86, LKML,
Rafael J. Wysocki, John Stultz, Ted Ts'o, Linus Torvalds
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1156 bytes --]
On Thu, 13 Mar 2014, joeyli wrote:
> 於 三，2014-03-12 於 20:59 -0700，H. Peter Anvin 提到：
> > On 03/12/2014 08:55 PM, joeyli wrote:
> > >
> > > So do not care "CMOS RTC Not Present", if TAD is present then we use it
> > > instead of CMOS RTC in all kernel code? or we still can use CMOS RTC?
> > >
> >
> > Why would we use *both*!? How would that possibly make sense?
> >
> > -hpa
> >
>
> Yes, it does not make sense for using both.
>
> I switched the code in get_rtc_time() set_rtc_time() to TAD when it
> present, just make sure I'm on the right path.
No, you're not. get/set_rtc_time() is a complete trainwreck and as I
said before it should move into the rtc subsystem.
There is no reason at all to keep that stuff in the arch specific
code. It's there for historical reasons and that does not justify to
add more mess to it.
So the right thing to do is:
1) Add eventually missing functionality to the RTC subsystem
2) Move the arch specific cmos stuff to the rtc subsystem as proper
drivers
3) Add TAD there after #2 has been completed.
Any attempt to add TAD to arch/x86 is NACKed unconditionally.
Thanks,
tglx
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
2014-03-13 8:12 ` Thomas Gleixner
@ 2014-03-13 8:59 ` joeyli
0 siblings, 0 replies; 41+ messages in thread
From: joeyli @ 2014-03-13 8:59 UTC (permalink / raw)
To: Thomas Gleixner
Cc: H. Peter Anvin, Rafael J. Wysocki, Julian Wollrath, x86, LKML,
Rafael J. Wysocki, John Stultz, Ted Ts'o, Linus Torvalds
於 四，2014-03-13 於 09:12 +0100，Thomas Gleixner 提到：
> On Thu, 13 Mar 2014, joeyli wrote:
> > 於 三，2014-03-12 於 20:59 -0700，H. Peter Anvin 提到：
> > > On 03/12/2014 08:55 PM, joeyli wrote:
> > > >
> > > > So do not care "CMOS RTC Not Present", if TAD is present then we use it
> > > > instead of CMOS RTC in all kernel code? or we still can use CMOS RTC?
> > > >
> > >
> > > Why would we use *both*!? How would that possibly make sense?
> > >
> > > -hpa
> > >
> >
> > Yes, it does not make sense for using both.
> >
> > I switched the code in get_rtc_time() set_rtc_time() to TAD when it
> > present, just make sure I'm on the right path.
>
> No, you're not. get/set_rtc_time() is a complete trainwreck and as I
> said before it should move into the rtc subsystem.
>
> There is no reason at all to keep that stuff in the arch specific
> code. It's there for historical reasons and that does not justify to
> add more mess to it.
Fully understand now. Thanks for your explanation.
>
> So the right thing to do is:
>
> 1) Add eventually missing functionality to the RTC subsystem
>
> 2) Move the arch specific cmos stuff to the rtc subsystem as proper
> drivers
>
> 3) Add TAD there after #2 has been completed.
>
> Any attempt to add TAD to arch/x86 is NACKed unconditionally.
>
> Thanks,
>
> tglx
Does there have any people already start the work of #1 and #2?
Thanks
Joey Lee
^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2014-03-13 9:01 UTC | newest]
Thread overview: 41+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-10 10:04 [RESEND] Fast TSC calibration fails with v3.14-rc1 and later Julian Wollrath
2014-03-10 10:27 ` Paul Bolle
2014-03-10 14:06 ` Thomas Gleixner
2014-03-10 15:28 ` Paul Bolle
2014-03-10 17:04 ` Thomas Gleixner
2014-03-10 18:32 ` Paul Bolle
2014-03-10 18:57 ` Thomas Gleixner
2014-03-10 19:19 ` Paul Bolle
2014-03-10 20:50 ` Thomas Gleixner
2014-03-10 23:06 ` Paul Bolle
2014-03-11 16:02 ` Thomas Gleixner
2014-03-11 13:27 ` Julian Wollrath
2014-03-10 10:39 ` Thomas Gleixner
2014-03-11 13:29 ` Julian Wollrath
2014-03-11 13:56 ` Thomas Gleixner
2014-03-11 17:15 ` Julian Wollrath
2014-03-12 4:00 ` joeyli
2014-03-12 10:20 ` Julian Wollrath
2014-03-12 13:52 ` joeyli
2014-03-12 11:20 ` Rafael J. Wysocki
2014-03-12 13:30 ` Rafael J. Wysocki
2014-03-12 13:55 ` Julian Wollrath
2014-03-12 15:41 ` joeyli
2014-03-12 16:20 ` Thomas Gleixner
2014-03-12 16:23 ` Thomas Gleixner
2014-03-12 16:39 ` Thomas Gleixner
2014-03-12 23:27 ` Rafael J. Wysocki
2014-03-12 23:49 ` Thomas Gleixner
2014-03-13 0:13 ` Rafael J. Wysocki
2014-03-13 2:56 ` joeyli
2014-03-13 0:54 ` Thomas Gleixner
2014-03-13 1:01 ` Thomas Gleixner
2014-03-13 2:38 ` joeyli
2014-03-13 3:11 ` H. Peter Anvin
2014-03-13 3:55 ` joeyli
2014-03-13 3:59 ` H. Peter Anvin
2014-03-13 4:12 ` joeyli
2014-03-13 8:12 ` Thomas Gleixner
2014-03-13 8:59 ` joeyli
2014-03-13 3:41 ` H. Peter Anvin
2014-03-12 14:00 ` joeyli
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox