[BISECTED] v4.15-rc: Boot regression on x86_64/AMD

[BISECTED] v4.15-rc: Boot regression on x86_64/AMD

[Aaro Koskinen]

Hi,

After v4.14, I've been unable to boot my AMD compilation box with the
v4.15-rc mainline Linux. It just ends up in a silent reboot loop.

I bisected this to:

commit fa564ad9636651fd11ec2c79c48dee844066f73a
Author: Christian König <christian.koenig@amd.com>
Date:   Tue Oct 24 14:40:29 2017 -0500

    x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f, 60-7f)

System details:

[    0.000000] DMI: MSI MS-7699/760GA-P43(FX) (MS-7699)   , BIOS V1.3 10/14/2014
[...]
[    0.070000] smpboot: CPU0: AMD FX(tm)-6350 Six-Core Processor (family: 0x15, model: 0x2, stepping: 0x0)

If you need more info, please tell what you need.

With the current mainline (rc6+), I have done the following reverts to
get a bootable system:

    Revert "x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f, 
60-7f)"
    This reverts commit fa564ad9636651fd11ec2c79c48dee844066f73a.

    Revert "x86/PCI: Fix infinite loop in search for 64bit BAR placement"
    This reverts commit 470195f82e4ea550b7c37736a12bf3fa565295ea.

    Revert "x86/PCI: Only enable a 64bit BAR on single-socket AMD Family 15h"
    This reverts commit a19e2696135efb471981c1ae1ec3cb2b70c41a2e.

A.

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

[Linus Torvalds]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

On Fri, Jan 5, 2018 at 2:04 PM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
>
> After v4.14, I've been unable to boot my AMD compilation box with the
> v4.15-rc mainline Linux. It just ends up in a silent reboot loop.
>
> I bisected this to:
>
> commit fa564ad9636651fd11ec2c79c48dee844066f73a
> Author: Christian König <christian.koenig@amd.com>
> Date:   Tue Oct 24 14:40:29 2017 -0500
>
>     x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f, 60-7f)

Hmm. That was reported to break boot earlier already.

The breakage was supposedly fixed by three patches from Christian:

  a19e2696135e: "x86/PCI: Only enable a 64bit BAR on single-socket AMD
Family 15h"

  470195f82e4e:  "x86/PCI: Fix infinite loop in search for 64bit BAR placement"

and a third one that was apparently never applied.

I'm not sure why that third patch was never applied, I'm including it here.

Does the system work for you if you apply that patch (instead of
reverting all of them)?

I wonder why that patch wasn't applied, but if it doesn't fix things,
I think we do need to revert it all.

Christian? Bjorn?

                 Linus

[-- Attachment #2: 0003-x86-PCI-limit-the-size-of-the-64bit-BAR-to-256GB.patch --]
[-- Type: text/x-patch, Size: 1192 bytes --]

From e5d5c9682aa02a6b9c0c6bd446d433b924441679 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
Date: Tue, 28 Nov 2017 10:02:35 +0100
Subject: [PATCH 3/3] x86/PCI: limit the size of the 64bit BAR to 256GB
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This avoids problems with Xen which hides some memory resources from the
OS and potentially also allows memory hotplug while this fixup is
enabled.

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 arch/x86/pci/fixup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index c817ab85dc82..149adbc7f2a3 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -701,7 +701,7 @@ static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
 	res->name = "PCI Bus 0000:00";
 	res->flags = IORESOURCE_PREFETCH | IORESOURCE_MEM |
 		IORESOURCE_MEM_64 | IORESOURCE_WINDOW;
-	res->start = 0x100000000ull;
+	res->start = 0xbd00000000ull;
 	res->end = 0xfd00000000ull - 1;
 
 	/* Just grab the free area behind system memory for this */
-- 
2.11.0

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

[Aaro Koskinen]

Hi,

On Fri, Jan 05, 2018 at 04:00:25PM -0800, Linus Torvalds wrote:
> On Fri, Jan 5, 2018 at 2:04 PM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> > After v4.14, I've been unable to boot my AMD compilation box with the
> > v4.15-rc mainline Linux. It just ends up in a silent reboot loop.
> >
> > I bisected this to:
> >
> > commit fa564ad9636651fd11ec2c79c48dee844066f73a
> > Author: Christian König <christian.koenig@amd.com>
> > Date:   Tue Oct 24 14:40:29 2017 -0500
> >
> >     x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f, 60-7f)
> 
> Hmm. That was reported to break boot earlier already.
> 
> The breakage was supposedly fixed by three patches from Christian:
> 
>   a19e2696135e: "x86/PCI: Only enable a 64bit BAR on single-socket AMD
> Family 15h"
> 
>   470195f82e4e:  "x86/PCI: Fix infinite loop in search for 64bit BAR placement"
> 
> and a third one that was apparently never applied.
> 
> I'm not sure why that third patch was never applied, I'm including it here.
> 
> Does the system work for you if you apply that patch (instead of
> reverting all of them)?

Yes, I think it now works.

When booting with kexec from v4.14:
89876f275e8d562912d9c238cd888b52065cf25c alone ==> boot fails.
89876f275e8d562912d9c238cd888b52065cf25c and the patch ==> boot OK.

However, I noticed I cannot do multiple kexecs in a row - it works only
once, and the second one just silently fails/reboots the CPU regardless
what the kernel is. But this behaviour is already the same with v4.14. :-/

A.

> I wonder why that patch wasn't applied, but if it doesn't fix things,
> I think we do need to revert it all.
> 
> Christian? Bjorn?
> 
>                  Linus

> From e5d5c9682aa02a6b9c0c6bd446d433b924441679 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
> Date: Tue, 28 Nov 2017 10:02:35 +0100
> Subject: [PATCH 3/3] x86/PCI: limit the size of the 64bit BAR to 256GB
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> This avoids problems with Xen which hides some memory resources from the
> OS and potentially also allows memory hotplug while this fixup is
> enabled.
> 
> Signed-off-by: Christian König <christian.koenig@amd.com>
> ---
>  arch/x86/pci/fixup.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> index c817ab85dc82..149adbc7f2a3 100644
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c
> @@ -701,7 +701,7 @@ static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
>  	res->name = "PCI Bus 0000:00";
>  	res->flags = IORESOURCE_PREFETCH | IORESOURCE_MEM |
>  		IORESOURCE_MEM_64 | IORESOURCE_WINDOW;
> -	res->start = 0x100000000ull;
> +	res->start = 0xbd00000000ull;
>  	res->end = 0xfd00000000ull - 1;
>  
>  	/* Just grab the free area behind system memory for this */
> -- 
> 2.11.0
> 

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

[Aaro Koskinen]

Hi,

On Sat, Jan 06, 2018 at 04:10:38AM +0200, Aaro Koskinen wrote:
> On Fri, Jan 05, 2018 at 04:00:25PM -0800, Linus Torvalds wrote:
> > On Fri, Jan 5, 2018 at 2:04 PM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> > > After v4.14, I've been unable to boot my AMD compilation box with the
> > > v4.15-rc mainline Linux. It just ends up in a silent reboot loop.
> > >
> > > I bisected this to:
> > >
> > > commit fa564ad9636651fd11ec2c79c48dee844066f73a
> > > Author: Christian König <christian.koenig@amd.com>
> > > Date:   Tue Oct 24 14:40:29 2017 -0500
> > >
> > >     x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f, 60-7f)
> > 
> > Hmm. That was reported to break boot earlier already.
> > 
> > The breakage was supposedly fixed by three patches from Christian:
> > 
> >   a19e2696135e: "x86/PCI: Only enable a 64bit BAR on single-socket AMD
> > Family 15h"
> > 
> >   470195f82e4e:  "x86/PCI: Fix infinite loop in search for 64bit BAR placement"
> > 
> > and a third one that was apparently never applied.
> > 
> > I'm not sure why that third patch was never applied, I'm including it here.
> > 
> > Does the system work for you if you apply that patch (instead of
> > reverting all of them)?
> 
> Yes, I think it now works.
> 
> When booting with kexec from v4.14:
> 89876f275e8d562912d9c238cd888b52065cf25c alone ==> boot fails.
> 89876f275e8d562912d9c238cd888b52065cf25c and the patch ==> boot OK.

I also re-tested with normal reboot/reset and BIOS boot (just to eliminate
any kexec side-effects), and the results are the same. The patch
"x86/PCI: limit the size of the 64bit BAR to 256GB" is fixing the boot
on my system.

A.

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

[Christian König]

Am 06.01.2018 um 13:02 schrieb Aaro Koskinen:
> Hi,
>
> On Sat, Jan 06, 2018 at 04:10:38AM +0200, Aaro Koskinen wrote:
>> On Fri, Jan 05, 2018 at 04:00:25PM -0800, Linus Torvalds wrote:
>>> On Fri, Jan 5, 2018 at 2:04 PM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
>>>> After v4.14, I've been unable to boot my AMD compilation box with the
>>>> v4.15-rc mainline Linux. It just ends up in a silent reboot loop.
>>>>
>>>> I bisected this to:
>>>>
>>>> commit fa564ad9636651fd11ec2c79c48dee844066f73a
>>>> Author: Christian König <christian.koenig@amd.com>
>>>> Date:   Tue Oct 24 14:40:29 2017 -0500
>>>>
>>>>      x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f, 60-7f)
>>> Hmm. That was reported to break boot earlier already.
>>>
>>> The breakage was supposedly fixed by three patches from Christian:
>>>
>>>    a19e2696135e: "x86/PCI: Only enable a 64bit BAR on single-socket AMD
>>> Family 15h"
>>>
>>>    470195f82e4e:  "x86/PCI: Fix infinite loop in search for 64bit BAR placement"
>>>
>>> and a third one that was apparently never applied.
>>>
>>> I'm not sure why that third patch was never applied, I'm including it here.
>>>
>>> Does the system work for you if you apply that patch (instead of
>>> reverting all of them)?
>> Yes, I think it now works.
>>
>> When booting with kexec from v4.14:
>> 89876f275e8d562912d9c238cd888b52065cf25c alone ==> boot fails.
>> 89876f275e8d562912d9c238cd888b52065cf25c and the patch ==> boot OK.
> I also re-tested with normal reboot/reset and BIOS boot (just to eliminate
> any kexec side-effects), and the results are the same. The patch
> "x86/PCI: limit the size of the 64bit BAR to 256GB" is fixing the boot
> on my system.

Ah, crap. We left this one out because it was just a hacky shoot into 
the dark to potentially avoid problems.

Please provide me with a full dmesg of the system and the content of 
/proc/iomem.

The most likely root cause is that your BIOS is buggy and reporting some 
nonsense to the OS.

We either need to indeed limit the new PCI root window to 256GB or find 
a better way to detect problematic BIOS versions.

Thanks in advance,
Christian.

>
> A.

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

[Aaro Koskinen]

Hi,

On Sat, Jan 06, 2018 at 05:47:10PM +0100, Christian König wrote:
> Am 06.01.2018 um 13:02 schrieb Aaro Koskinen:
> > On Sat, Jan 06, 2018 at 04:10:38AM +0200, Aaro Koskinen wrote:
> > > On Fri, Jan 05, 2018 at 04:00:25PM -0800, Linus Torvalds wrote:
> > > > On Fri, Jan 5, 2018 at 2:04 PM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> > > > > After v4.14, I've been unable to boot my AMD compilation box with the
> > > > > v4.15-rc mainline Linux. It just ends up in a silent reboot loop.
> > > > > 
> > > > > I bisected this to:
> > > > > 
> > > > > commit fa564ad9636651fd11ec2c79c48dee844066f73a
> > > > > Author: Christian König <christian.koenig@amd.com>
> > > > > Date:   Tue Oct 24 14:40:29 2017 -0500
> > > > > 
> > > > >      x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f, 60-7f)
> > > > Hmm. That was reported to break boot earlier already.
> > > > 
> > > > The breakage was supposedly fixed by three patches from Christian:
> > > > 
> > > >    a19e2696135e: "x86/PCI: Only enable a 64bit BAR on single-socket AMD
> > > > Family 15h"
> > > > 
> > > >    470195f82e4e:  "x86/PCI: Fix infinite loop in search for 64bit BAR placement"
> > > > 
> > > > and a third one that was apparently never applied.
> > > > 
> > > > I'm not sure why that third patch was never applied, I'm including it here.
> > > > 
> > > > Does the system work for you if you apply that patch (instead of
> > > > reverting all of them)?
> > > Yes, I think it now works.
> > > 
> > > When booting with kexec from v4.14:
> > > 89876f275e8d562912d9c238cd888b52065cf25c alone ==> boot fails.
> > > 89876f275e8d562912d9c238cd888b52065cf25c and the patch ==> boot OK.
> > I also re-tested with normal reboot/reset and BIOS boot (just to eliminate
> > any kexec side-effects), and the results are the same. The patch
> > "x86/PCI: limit the size of the 64bit BAR to 256GB" is fixing the boot
> > on my system.
> 
> Ah, crap. We left this one out because it was just a hacky shoot into the
> dark to potentially avoid problems.
> 
> Please provide me with a full dmesg of the system and the content of
> /proc/iomem.

$ cat /proc/iomem
00000000-00000fff : Reserved
00001000-0009f3ff : System RAM
0009f400-0009ffff : Reserved
000a0000-000bffff : PCI Bus 0000:00
000c0000-000cefff : Video ROM
000d0000-000dffff : PCI Bus 0000:00
000e4000-000fffff : Reserved
  000f0000-000fffff : System ROM
00100000-cff8ffff : System RAM
  01000000-01a01fff : Kernel code
  01a02000-0208d13f : Kernel data
  02819000-02899fff : Kernel bss
cff90000-cff9dfff : ACPI Tables
cff9e000-cffdffff : ACPI Non-volatile Storage
cffe0000-cfffffff : Reserved
d0000000-dfffffff : PCI Bus 0000:00
  d0000000-dfffffff : PCI Bus 0000:01
    d0000000-dfffffff : 0000:01:05.0
e0000000-efffffff : pnp 00:07
f0000000-febfffff : PCI Bus 0000:00
  fdf00000-fdffffff : PCI Bus 0000:02
    fdff8000-fdffbfff : 0000:02:00.0
      fdff8000-fdffbfff : r8169
    fdfff000-fdffffff : 0000:02:00.0
      fdfff000-fdffffff : r8169
  fe8f4000-fe8f7fff : 0000:00:14.2
    fe8f4000-fe8f7fff : ICH HD audio
  fe8fa000-fe8fafff : 0000:00:14.5
    fe8fa000-fe8fafff : ohci_hcd
  fe8fb000-fe8fbfff : 0000:00:13.1
    fe8fb000-fe8fbfff : ohci_hcd
  fe8fc000-fe8fcfff : 0000:00:13.0
    fe8fc000-fe8fcfff : ohci_hcd
  fe8fd000-fe8fdfff : 0000:00:12.1
    fe8fd000-fe8fdfff : ohci_hcd
  fe8fe000-fe8fefff : 0000:00:12.0
    fe8fe000-fe8fefff : ohci_hcd
  fe8ff400-fe8ff4ff : 0000:00:13.2
    fe8ff400-fe8ff4ff : ehci_hcd
  fe8ff800-fe8ff8ff : 0000:00:12.2
    fe8ff800-fe8ff8ff : ehci_hcd
  fe8ffc00-fe8fffff : 0000:00:11.0
    fe8ffc00-fe8fffff : ahci
  fe900000-feafffff : PCI Bus 0000:01
    fe900000-fe9fffff : 0000:01:05.0
    feae0000-feaeffff : 0000:01:05.0
  feb00000-febfffff : PCI Bus 0000:03
    febfe000-febfffff : 0000:03:00.0
      febfe000-febfffff : xhci-hcd
fec00000-fec003ff : IOAPIC 0
fec10000-fec1001f : pnp 00:05
fed00000-fed003ff : HPET 2
  fed00000-fed003ff : PNP0103:00
fee00000-fee00fff : Local APIC
  fee00000-fee00fff : pnp 00:04
ffb80000-ffbfffff : pnp 00:05
ffe00000-ffffffff : Reserved
100000000-41fffffff : System RAM
bd00000000-fcffffffff : PCI Bus 0000:00

$ dmesg
[    0.000000] Linux version 4.15.0-rc6-pc-los_367ea-00117-gf7ba459f (aaro@amd-fx-6350) (gcc version 7.2.0 (GCC)) #1 SMP Sat Jan 6 18:55:19 EET 2018
[    0.000000] Command line: 
[    0.000000] random: get_random_u32 called from bsp_init_amd+0x131/0x180 with crng_init=0
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009f3ff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009f400-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e4000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000cff8ffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000cff90000-0x00000000cff9dfff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000cff9e000-0x00000000cffdffff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000cffe0000-0x00000000cfffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ffe00000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000041fffffff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] random: fast init done
[    0.000000] SMBIOS 2.6 present.
[    0.000000] DMI: MSI MS-7699/760GA-P43(FX) (MS-7699)   , BIOS V1.3 10/14/2014
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] e820: last_pfn = 0x420000 max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-EFFFF uncachable
[    0.000000]   F0000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 000000000000 mask FFFF80000000 write-back
[    0.000000]   1 base 000080000000 mask FFFFC0000000 write-back
[    0.000000]   2 base 0000C0000000 mask FFFFF0000000 write-back
[    0.000000]   3 disabled
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] TOM2: 0000000430000000 aka 17152M
[    0.000000] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[    0.000000] e820: update [mem 0xd0000000-0xffffffff] usable ==> reserved
[    0.000000] e820: last_pfn = 0xcff90 max_arch_pfn = 0x400000000
[    0.000000] Base memory trampoline at [        (ptrval)] 99000 size 24576
[    0.000000] Using GB pages for direct mapping
[    0.000000] BRK [0x0289b000, 0x0289bfff] PGTABLE
[    0.000000] BRK [0x0289c000, 0x0289cfff] PGTABLE
[    0.000000] BRK [0x0289d000, 0x0289dfff] PGTABLE
[    0.000000] BRK [0x0289e000, 0x0289efff] PGTABLE
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000000F8D00 000014 (v00 ACPIAM)
[    0.000000] ACPI: RSDT 0x00000000CFF90000 00003C (v01 7699MS A7699100 20141014 MSFT 00000097)
[    0.000000] ACPI: FACP 0x00000000CFF90200 000084 (v01 7699MS A7699100 20141014 MSFT 00000097)
[    0.000000] ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x0000000000000000/0x1 (20170831/tbfadt-658)
[    0.000000] ACPI: DSDT 0x00000000CFF90660 009E5E (v01 A7699  A7699100 00000100 INTL 20051117)
[    0.000000] ACPI: FACS 0x00000000CFF9E000 000040
[    0.000000] ACPI: APIC 0x00000000CFF90390 00010C (v01 7699MS A7699100 20141014 MSFT 00000097)
[    0.000000] ACPI: MCFG 0x00000000CFF904A0 00003C (v01 7699MS OEMMCFG  20141014 MSFT 00000097)
[    0.000000] ACPI: OEMB 0x00000000CFF9E040 000072 (v01 7699MS A7699100 20141014 MSFT 00000097)
[    0.000000] ACPI: HPET 0x00000000CFF9A660 000038 (v01 7699MS OEMHPET  20141014 MSFT 00000097)
[    0.000000] ACPI: SSDT 0x00000000CFF9A6A0 0013CE (v01 A M I  POWERNOW 00000001 AMD  00000001)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] tsc: Fast TSC calibration using PIT
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
[    0.000000]   DMA32    [mem 0x0000000001000000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x000000041fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000001000-0x000000000009efff]
[    0.000000]   node   0: [mem 0x0000000000100000-0x00000000cff8ffff]
[    0.000000]   node   0: [mem 0x0000000100000000-0x000000041fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000041fffffff]
[    0.000000] On node 0 totalpages: 4128558
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 21 pages reserved
[    0.000000]   DMA zone: 3998 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 13247 pages used for memmap
[    0.000000]   DMA32 zone: 847760 pages, LIFO batch:31
[    0.000000]   Normal zone: 51200 pages used for memmap
[    0.000000]   Normal zone: 3276800 pages, LIFO batch:31
[    0.000000] Reserved but unavailable: 98 pages
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] IOAPIC[0]: apic_id 22, version 33, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8300 base: 0xfed00000
[    0.000000] smpboot: Allowing 6 CPUs, 0 hotplug CPUs
[    0.000000] e820: [mem 0xd0000000-0xffdfffff] available for PCI devices
[    0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.000000] setup_percpu: NR_CPUS:6 nr_cpumask_bits:6 nr_cpu_ids:6 nr_node_ids:1
[    0.000000] percpu: Embedded 41 pages/cpu @        (ptrval) s129560 r8192 d30184 u262144
[    0.000000] pcpu-alloc: s129560 r8192 d30184 u262144 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 - - 
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 4064026
[    0.000000] Kernel command line: 
[    0.000000] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes)
[    0.000000] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[    0.000000] Memory: 16139304K/16514232K available (10248K kernel code, 564K rwdata, 2452K rodata, 7636K init, 516K bss, 374928K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS: 4352, nr_irqs: 472, preallocated irqs: 16
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [tty0] enabled
[    0.000000] ACPI: Core revision 20170831
[    0.000000] ACPI: 2 ACPI AML tables successfully acquired and loaded
[    0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484873504 ns
[    0.000000] hpet clockevent registered
[    0.000000] APIC: Switch to symmetric I/O mode setup
[    0.000000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.050000] tsc: Fast TSC calibration failed
[    0.080000] tsc: Unable to calibrate against PIT
[    0.080000] tsc: using HPET reference calibration
[    0.080000] tsc: Detected 3899.988 MHz processor
[    0.080000] Calibrating delay loop (skipped), value calculated using timer frequency.. 7799.97 BogoMIPS (lpj=38999880)
[    0.080000] pid_max: default: 32768 minimum: 301
[    0.080000] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes)
[    0.080000] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes)
[    0.080000] CPU: Physical Processor ID: 0
[    0.080000] CPU: Processor Core ID: 0
[    0.080000] mce: CPU supports 7 MCE banks
[    0.080000] LVT offset 1 assigned for vector 0xf9
[    0.080000] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
[    0.080000] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512, 1GB 0
[    0.080000] Freeing SMP alternatives memory: 28K
[    0.100000] smpboot: CPU0: AMD FX(tm)-6350 Six-Core Processor (family: 0x15, model: 0x2, stepping: 0x0)
[    0.100000] Performance Events: Fam15h core perfctr, AMD PMU driver.
[    0.100000] ... version:                0
[    0.100000] ... bit width:              48
[    0.100000] ... generic registers:      6
[    0.100000] ... value mask:             0000ffffffffffff
[    0.100000] ... max period:             00007fffffffffff
[    0.100000] ... fixed-purpose events:   0
[    0.100000] ... event mask:             000000000000003f
[    0.100000] Hierarchical SRCU implementation.
[    0.100000] smp: Bringing up secondary CPUs ...
[    0.100000] x86: Booting SMP configuration:
[    0.100000] .... node  #0, CPUs:      #1
[    0.100000] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
[    0.100000]  #2 #3 #4 #5
[    0.102745] smp: Brought up 1 node, 6 CPUs
[    0.102745] smpboot: Max logical packages: 1
[    0.102745] smpboot: Total of 6 processors activated (46799.85 BogoMIPS)
[    0.110421] devtmpfs: initialized
[    0.110421] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.110421] futex hash table entries: 2048 (order: 5, 131072 bytes)
[    0.110421] NET: Registered protocol family 16
[    0.110438] cpuidle: using governor menu
[    0.110438] ACPI: bus type PCI registered
[    0.110438] PCI: Using configuration type 1 for base access
[    0.110438] PCI: Using configuration type 1 for extended access
[    0.113063] ACPI: Added _OSI(Module Device)
[    0.113063] ACPI: Added _OSI(Processor Device)
[    0.113063] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.113063] ACPI: Added _OSI(Processor Aggregator Device)
[    0.113063] ACPI: Executed 4 blocks of module-level executable AML code
[    0.120009] ACPI: Interpreter enabled
[    0.120009] ACPI: (supports S0 S5)
[    0.120009] ACPI: Using IOAPIC for interrupt routing
[    0.120009] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.120021] ACPI: Enabled 5 GPEs in block 00 to 1F
[    0.121070] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.121108] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    0.121143] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
[    0.121252] PCI host bridge to bus 0000:00
[    0.121283] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
[    0.121313] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
[    0.121344] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[    0.121376] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff window]
[    0.121409] pci_bus 0000:00: root bus resource [mem 0xd0000000-0xdfffffff window]
[    0.121441] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfebfffff window]
[    0.121473] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.121510] pci 0000:00:00.0: [1022:9600] type 00 class 0x060000
[    0.121592] pci 0000:00:01.0: [1022:9602] type 01 class 0x060400
[    0.121672] pci 0000:00:05.0: [1022:9605] type 01 class 0x060400
[    0.121690] pci 0000:00:05.0: enabling Extended Tags
[    0.121740] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
[    0.121792] pci 0000:00:06.0: [1022:9606] type 01 class 0x060400
[    0.121809] pci 0000:00:06.0: enabling Extended Tags
[    0.121862] pci 0000:00:06.0: PME# supported from D0 D3hot D3cold
[    0.121928] pci 0000:00:11.0: [1002:4390] type 00 class 0x01018f
[    0.121949] pci 0000:00:11.0: reg 0x10: [io  0xc000-0xc007]
[    0.121957] pci 0000:00:11.0: reg 0x14: [io  0xb000-0xb003]
[    0.121965] pci 0000:00:11.0: reg 0x18: [io  0xa000-0xa007]
[    0.121973] pci 0000:00:11.0: reg 0x1c: [io  0x9000-0x9003]
[    0.121981] pci 0000:00:11.0: reg 0x20: [io  0x8000-0x800f]
[    0.121990] pci 0000:00:11.0: reg 0x24: [mem 0xfe8ffc00-0xfe8fffff]
[    0.122009] pci 0000:00:11.0: set SATA to AHCI mode
[    0.122114] pci 0000:00:12.0: [1002:4397] type 00 class 0x0c0310
[    0.122131] pci 0000:00:12.0: reg 0x10: [mem 0xfe8fe000-0xfe8fefff]
[    0.122232] pci 0000:00:12.1: [1002:4398] type 00 class 0x0c0310
[    0.122250] pci 0000:00:12.1: reg 0x10: [mem 0xfe8fd000-0xfe8fdfff]
[    0.122354] pci 0000:00:12.2: [1002:4396] type 00 class 0x0c0320
[    0.122375] pci 0000:00:12.2: reg 0x10: [mem 0xfe8ff800-0xfe8ff8ff]
[    0.122448] pci 0000:00:12.2: supports D1 D2
[    0.122449] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot
[    0.122507] pci 0000:00:13.0: [1002:4397] type 00 class 0x0c0310
[    0.122525] pci 0000:00:13.0: reg 0x10: [mem 0xfe8fc000-0xfe8fcfff]
[    0.122628] pci 0000:00:13.1: [1002:4398] type 00 class 0x0c0310
[    0.122646] pci 0000:00:13.1: reg 0x10: [mem 0xfe8fb000-0xfe8fbfff]
[    0.122750] pci 0000:00:13.2: [1002:4396] type 00 class 0x0c0320
[    0.122771] pci 0000:00:13.2: reg 0x10: [mem 0xfe8ff400-0xfe8ff4ff]
[    0.122844] pci 0000:00:13.2: supports D1 D2
[    0.122845] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot
[    0.122905] pci 0000:00:14.0: [1002:4385] type 00 class 0x0c0500
[    0.123037] pci 0000:00:14.1: [1002:439c] type 00 class 0x01018a
[    0.123056] pci 0000:00:14.1: reg 0x10: [io  0x0000-0x0007]
[    0.123065] pci 0000:00:14.1: reg 0x14: [io  0x0000-0x0003]
[    0.123073] pci 0000:00:14.1: reg 0x18: [io  0x0000-0x0007]
[    0.123081] pci 0000:00:14.1: reg 0x1c: [io  0x0000-0x0003]
[    0.123089] pci 0000:00:14.1: reg 0x20: [io  0xff00-0xff0f]
[    0.123107] pci 0000:00:14.1: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
[    0.123138] pci 0000:00:14.1: legacy IDE quirk: reg 0x14: [io  0x03f6]
[    0.123168] pci 0000:00:14.1: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
[    0.123198] pci 0000:00:14.1: legacy IDE quirk: reg 0x1c: [io  0x0376]
[    0.123302] pci 0000:00:14.2: [1002:4383] type 00 class 0x040300
[    0.123326] pci 0000:00:14.2: reg 0x10: [mem 0xfe8f4000-0xfe8f7fff 64bit]
[    0.123387] pci 0000:00:14.2: PME# supported from D0 D3hot D3cold
[    0.123438] pci 0000:00:14.3: [1002:439d] type 00 class 0x060100
[    0.123556] pci 0000:00:14.4: [1002:4384] type 01 class 0x060401
[    0.123643] pci 0000:00:14.5: [1002:4399] type 00 class 0x0c0310
[    0.123661] pci 0000:00:14.5: reg 0x10: [mem 0xfe8fa000-0xfe8fafff]
[    0.123766] pci 0000:00:18.0: [1022:1600] type 00 class 0x060000
[    0.123821] pci 0000:00:18.1: [1022:1601] type 00 class 0x060000
[    0.123875] pci 0000:00:18.2: [1022:1602] type 00 class 0x060000
[    0.123927] pci 0000:00:18.3: [1022:1603] type 00 class 0x060000
[    0.123984] pci 0000:00:18.4: [1022:1604] type 00 class 0x060000
[    0.124037] pci 0000:00:18.5: [1022:1605] type 00 class 0x060000
[    0.124129] pci 0000:01:05.0: [1002:9616] type 00 class 0x030000
[    0.124138] pci 0000:01:05.0: reg 0x10: [mem 0xd0000000-0xdfffffff pref]
[    0.124141] pci 0000:01:05.0: reg 0x14: [io  0xd000-0xd0ff]
[    0.124145] pci 0000:01:05.0: reg 0x18: [mem 0xfeae0000-0xfeaeffff]
[    0.124153] pci 0000:01:05.0: reg 0x24: [mem 0xfe900000-0xfe9fffff]
[    0.124169] pci 0000:01:05.0: supports D1 D2
[    0.124226] pci 0000:00:01.0: PCI bridge to [bus 01]
[    0.124258] pci 0000:00:01.0:   bridge window [io  0xd000-0xdfff]
[    0.124259] pci 0000:00:01.0:   bridge window [mem 0xfe900000-0xfeafffff]
[    0.124262] pci 0000:00:01.0:   bridge window [mem 0xd0000000-0xdfffffff 64bit pref]
[    0.124294] pci 0000:02:00.0: [10ec:8168] type 00 class 0x020000
[    0.124316] pci 0000:02:00.0: reg 0x10: [io  0xe800-0xe8ff]
[    0.124335] pci 0000:02:00.0: reg 0x18: [mem 0xfdfff000-0xfdffffff 64bit pref]
[    0.124347] pci 0000:02:00.0: reg 0x20: [mem 0xfdff8000-0xfdffbfff 64bit pref]
[    0.124412] pci 0000:02:00.0: supports D1 D2
[    0.124413] pci 0000:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.150018] pci 0000:00:05.0: PCI bridge to [bus 02]
[    0.150051] pci 0000:00:05.0:   bridge window [io  0xe000-0xefff]
[    0.150054] pci 0000:00:05.0:   bridge window [mem 0xfdf00000-0xfdffffff 64bit pref]
[    0.150097] pci 0000:03:00.0: [1912:0014] type 00 class 0x0c0330
[    0.150137] pci 0000:03:00.0: reg 0x10: [mem 0xfebfe000-0xfebfffff 64bit]
[    0.150264] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold
[    0.180019] pci 0000:00:06.0: PCI bridge to [bus 03]
[    0.180053] pci 0000:00:06.0:   bridge window [mem 0xfeb00000-0xfebfffff]
[    0.180122] pci 0000:00:14.4: PCI bridge to [bus 04] (subtractive decode)
[    0.180161] pci 0000:00:14.4:   bridge window [io  0x0000-0x0cf7 window] (subtractive decode)
[    0.180162] pci 0000:00:14.4:   bridge window [io  0x0d00-0xffff window] (subtractive decode)
[    0.180163] pci 0000:00:14.4:   bridge window [mem 0x000a0000-0x000bffff window] (subtractive decode)
[    0.180164] pci 0000:00:14.4:   bridge window [mem 0x000d0000-0x000dffff window] (subtractive decode)
[    0.180165] pci 0000:00:14.4:   bridge window [mem 0xd0000000-0xdfffffff window] (subtractive decode)
[    0.180166] pci 0000:00:14.4:   bridge window [mem 0xf0000000-0xfebfffff window] (subtractive decode)
[    0.180179] pci_bus 0000:00: on NUMA node 0
[    0.180507] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 7 10 *11 12 14 15)
[    0.180507] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 *11 12 14 15)
[    0.180507] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 *10 11 12 14 15)
[    0.180507] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 *10 11 12 14 15)
[    0.180507] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 7 10 11 12 14 15) *0, disabled.
[    0.180507] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 11 12 14 15) *0, disabled.
[    0.180507] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 12 14 15)
[    0.180522] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14 15) *0, disabled.
[    0.180649] pci 0000:01:05.0: vgaarb: setting as boot VGA device
[    0.180649] pci 0000:01:05.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
[    0.180649] pci 0000:01:05.0: vgaarb: bridge control possible
[    0.180649] vgaarb: loaded
[    0.180649] SCSI subsystem initialized
[    0.180649] libata version 3.00 loaded.
[    0.180649] ACPI: bus type USB registered
[    0.180649] usbcore: registered new interface driver usbfs
[    0.180649] usbcore: registered new interface driver hub
[    0.180649] usbcore: registered new device driver usb
[    0.180649] Linux video capture interface: v2.00
[    0.180649] pps_core: LinuxPPS API ver. 1 registered
[    0.181047] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.181101] Advanced Linux Sound Architecture Driver Initialized.
[    0.181101] PCI: Using ACPI for IRQ routing
[    0.181101] PCI: pci_cache_line_size set to 64 bytes
[    0.181101] e820: reserve RAM buffer [mem 0x0009f400-0x0009ffff]
[    0.181101] e820: reserve RAM buffer [mem 0xcff90000-0xcfffffff]
[    0.181101] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
[    0.181101] hpet0: 4 comparators, 32-bit 14.318180 MHz counter
[    0.182363] clocksource: Switched to clocksource hpet
[    0.182363] pnp: PnP ACPI init
[    0.182363] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.182383] pnp 00:01: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.182383] pnp 00:02: [dma 0 disabled]
[    0.182383] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active)
[    0.182383] pnp 00:03: [dma 0 disabled]
[    0.182383] pnp 00:03: Plug and Play ACPI device, IDs PNP0400 (active)
[    0.182383] system 00:04: [mem 0xfec00000-0xfec00fff] could not be reserved
[    0.182383] system 00:04: [mem 0xfee00000-0xfee00fff] has been reserved
[    0.182383] system 00:04: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.182383] system 00:05: [io  0x04d0-0x04d1] has been reserved
[    0.182383] system 00:05: [io  0x040b] has been reserved
[    0.182383] system 00:05: [io  0x04d6] has been reserved
[    0.182383] system 00:05: [io  0x0c00-0x0c01] has been reserved
[    0.182383] system 00:05: [io  0x0c14] has been reserved
[    0.182383] system 00:05: [io  0x0c50-0x0c51] has been reserved
[    0.182383] system 00:05: [io  0x0c52] has been reserved
[    0.182383] system 00:05: [io  0x0c6c] has been reserved
[    0.182383] system 00:05: [io  0x0c6f] has been reserved
[    0.182383] system 00:05: [io  0x0cd0-0x0cd1] has been reserved
[    0.182383] system 00:05: [io  0x0cd2-0x0cd3] has been reserved
[    0.182383] system 00:05: [io  0x0cd4-0x0cd5] has been reserved
[    0.182383] system 00:05: [io  0x0cd6-0x0cd7] has been reserved
[    0.182383] system 00:05: [io  0x0cd8-0x0cdf] has been reserved
[    0.182383] system 00:05: [io  0x0800-0x089f] has been reserved
[    0.182383] system 00:05: [io  0x0b00-0x0b0f] has been reserved
[    0.182383] system 00:05: [io  0x0b20-0x0b3f] has been reserved
[    0.182383] system 00:05: [io  0x0900-0x090f] has been reserved
[    0.182383] system 00:05: [io  0x0910-0x091f] has been reserved
[    0.182383] system 00:05: [io  0xfe00-0xfefe] has been reserved
[    0.182383] system 00:05: [mem 0xffb80000-0xffbfffff] has been reserved
[    0.182383] system 00:05: [mem 0xfec10000-0xfec1001f] has been reserved
[    0.182383] system 00:05: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.182383] system 00:06: [io  0x0e80-0x0f5f] has been reserved
[    0.182383] system 00:06: [io  0x0ae0-0x0aef] has been reserved
[    0.182383] system 00:06: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.182383] system 00:07: [mem 0xe0000000-0xefffffff] has been reserved
[    0.182383] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.182383] system 00:08: [mem 0x00000000-0x0009ffff] could not be reserved
[    0.182383] system 00:08: [mem 0x000c0000-0x000cffff] could not be reserved
[    0.182383] system 00:08: [mem 0x000e0000-0x000fffff] could not be reserved
[    0.182411] system 00:08: [mem 0x00100000-0xcfffffff] could not be reserved
[    0.182442] system 00:08: [mem 0xfec00000-0xffffffff] could not be reserved
[    0.182476] system 00:08: Plug and Play ACPI device, IDs PNP0c01 (active)
[    0.182552] pnp: PnP ACPI: found 9 devices
[    0.188540] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[    0.188587] pci 0000:00:01.0: PCI bridge to [bus 01]
[    0.188618] pci 0000:00:01.0:   bridge window [io  0xd000-0xdfff]
[    0.188655] pci 0000:00:01.0:   bridge window [mem 0xfe900000-0xfeafffff]
[    0.188686] pci 0000:00:01.0:   bridge window [mem 0xd0000000-0xdfffffff 64bit pref]
[    0.188720] pci 0000:00:05.0: PCI bridge to [bus 02]
[    0.188750] pci 0000:00:05.0:   bridge window [io  0xe000-0xefff]
[    0.188782] pci 0000:00:05.0:   bridge window [mem 0xfdf00000-0xfdffffff 64bit pref]
[    0.188817] pci 0000:00:06.0: PCI bridge to [bus 03]
[    0.188847] pci 0000:00:06.0:   bridge window [mem 0xfeb00000-0xfebfffff]
[    0.188880] pci 0000:00:14.4: PCI bridge to [bus 04]
[    0.188919] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
[    0.188920] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
[    0.188921] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
[    0.188922] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff window]
[    0.188923] pci_bus 0000:00: resource 8 [mem 0xd0000000-0xdfffffff window]
[    0.188924] pci_bus 0000:00: resource 9 [mem 0xf0000000-0xfebfffff window]
[    0.188925] pci_bus 0000:01: resource 0 [io  0xd000-0xdfff]
[    0.188926] pci_bus 0000:01: resource 1 [mem 0xfe900000-0xfeafffff]
[    0.188927] pci_bus 0000:01: resource 2 [mem 0xd0000000-0xdfffffff 64bit pref]
[    0.188928] pci_bus 0000:02: resource 0 [io  0xe000-0xefff]
[    0.188929] pci_bus 0000:02: resource 2 [mem 0xfdf00000-0xfdffffff 64bit pref]
[    0.188930] pci_bus 0000:03: resource 1 [mem 0xfeb00000-0xfebfffff]
[    0.188931] pci_bus 0000:04: resource 4 [io  0x0000-0x0cf7 window]
[    0.188932] pci_bus 0000:04: resource 5 [io  0x0d00-0xffff window]
[    0.188933] pci_bus 0000:04: resource 6 [mem 0x000a0000-0x000bffff window]
[    0.188934] pci_bus 0000:04: resource 7 [mem 0x000d0000-0x000dffff window]
[    0.188935] pci_bus 0000:04: resource 8 [mem 0xd0000000-0xdfffffff window]
[    0.188935] pci_bus 0000:04: resource 9 [mem 0xf0000000-0xfebfffff window]
[    0.188977] NET: Registered protocol family 2
[    0.189082] TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.189288] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.189491] TCP: Hash tables configured (established 131072 bind 65536)
[    0.189556] UDP hash table entries: 8192 (order: 6, 262144 bytes)
[    0.189636] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes)
[    0.189744] NET: Registered protocol family 1
[    0.189877] RPC: Registered named UNIX socket transport module.
[    0.189908] RPC: Registered udp transport module.
[    0.189937] RPC: Registered tcp transport module.
[    0.189966] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.189999] pci 0000:00:01.0: MSI quirk detected; subordinate MSI disabled
[    1.210112] pci 0000:00:18.1: adding root bus resource [mem 0xbd00000000-0xfcffffffff 64bit pref window]
[    1.210155] pci 0000:01:05.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
[    1.210326] PCI: CLS 64 bytes, default 64
[    1.214499] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    1.214536] software IO TLB [mem 0xcbf90000-0xcff90000] (64MB) mapped at [000000002a7eea47-00000000bdff5781]
[    1.214574] amd_uncore: AMD NB counters detected
[    1.214757] LVT offset 0 assigned for vector 0x400
[    1.214851] perf: AMD IBS detected (0x000000ff)
[    1.216805] workingset: timestamp_bits=62 max_order=22 bucket_order=0
[    1.222075] NET: Registered protocol family 38
[    1.222136] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[    1.222170] io scheduler noop registered
[    1.222235] io scheduler cfq registered (default)
[    1.222755] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[    1.222796] ACPI: Power Button [PWRB]
[    1.222853] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[    1.222887] ACPI: Power Button [PWRF]
[    1.225056] Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
[    1.245689] 00:02: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[    1.246015] Non-volatile memory driver v1.3
[    1.246046] Linux agpgart interface v0.103
[    1.246087] [drm] radeon kernel modesetting enabled.
[    1.246323] [drm] initializing kernel modesetting (RS780 0x1002:0x9616 0x1462:0x7699 0x00).
[    1.246375] resource sanity check: requesting [mem 0x000c0000-0x000dffff], which spans more than PCI Bus 0000:00 [mem 0x000d0000-0x000dffff window]
[    1.246415] caller pci_map_rom+0x58/0xe0 mapping multiple BARs
[    1.247096] ATOM BIOS: B43106
[    1.247141] radeon 0000:01:05.0: VRAM: 256M 0x00000000C0000000 - 0x00000000CFFFFFFF (256M used)
[    1.247176] radeon 0000:01:05.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF
[    1.247213] [drm] Detected VRAM RAM=256M, BAR=256M
[    1.247243] [drm] RAM width 32bits DDR
[    1.247507] [TTM] Zone  kernel: Available graphics memory: 8069666 kiB
[    1.247538] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[    1.247568] [TTM] Initializing pool allocator
[    1.247599] [TTM] Initializing DMA pool allocator
[    1.247645] [drm] radeon: 256M of VRAM memory ready
[    1.247675] [drm] radeon: 512M of GTT memory ready.
[    1.247705] [drm] Loading RS780 Microcode
[    1.247773] [drm] radeon: power management initialized
[    1.247804] [drm] GART: num cpu pages 131072, num gpu pages 131072
[    1.251658] [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
[    1.251734] radeon 0000:01:05.0: WB enabled
[    1.251773] radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x00000000a0000c00 and cpu addr 0x00000000c1a5f558
[    1.251806] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    1.251835] [drm] Driver supports precise vblank timestamp query.
[    1.251865] radeon 0000:01:05.0: radeon: MSI limited to 32-bit
[    1.251910] [drm] radeon: irq initialized.
[    1.284070] [drm] ring test on 0 succeeded in 1 usecs
[    1.284360] [drm] ib test on ring 0 succeeded in 0 usecs
[    1.284572] [drm] Radeon Display Connectors
[    1.284611] [drm] Connector 0:
[    1.284641] [drm]   VGA-1
[    1.284671] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[    1.284704] [drm]   Encoders:
[    1.284734] [drm]     CRT1: INTERNAL_KLDSCP_DAC1
[    1.284765] [drm] Connector 1:
[    1.284794] [drm]   HDMI-A-1
[    1.284824] [drm]   HPD3
[    1.284854] [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[    1.284886] [drm]   Encoders:
[    1.284916] [drm]     DFP3: INTERNAL_KLDSCP_LVTMA
[    1.326374] [drm] fb mappable at 0xD0141000
[    1.326407] [drm] vram apper at 0xD0000000
[    1.326436] [drm] size 5242880
[    1.326464] [drm] fb depth is 24
[    1.326493] [drm]    pitch is 5120
[    1.326577] fbcon: radeondrmfb (fb0) is primary device
[    1.410320] Console: switching to colour frame buffer device 160x64
[    1.420034] radeon 0000:01:05.0: fb0: radeondrmfb frame buffer device
[    1.420192] [drm] Initialized radeon 2.50.0 20080528 for 0000:01:05.0 on minor 0
[    1.420693] ahci 0000:00:11.0: version 3.0
[    1.420899] ahci 0000:00:11.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode
[    1.421005] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ccc 
[    1.421902] scsi host0: ahci
[    1.422231] scsi host1: ahci
[    1.422355] scsi host2: ahci
[    1.422615] scsi host3: ahci
[    1.422687] ata1: SATA max UDMA/133 abar m1024@0xfe8ffc00 port 0xfe8ffd00 irq 22
[    1.422788] ata2: SATA max UDMA/133 abar m1024@0xfe8ffc00 port 0xfe8ffd80 irq 22
[    1.422885] ata3: SATA max UDMA/133 abar m1024@0xfe8ffc00 port 0xfe8ffe00 irq 22
[    1.422982] ata4: SATA max UDMA/133 abar m1024@0xfe8ffc00 port 0xfe8ffe80 irq 22
[    1.423129] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    1.423260] r8169 0000:02:00.0: can't disable ASPM; OS doesn't have ASPM control
[    1.423758] r8169 0000:02:00.0 eth0: RTL8168evl/8111evl at 0x00000000ce8e8d69, d4:3d:7e:dd:03:d5, XID 0c900800 IRQ 24
[    1.423894] r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[    1.424012] PPP generic driver version 2.4.2
[    1.424117] PPP Deflate Compression module registered
[    1.424223] usbcore: registered new interface driver cdc_ether
[    1.424308] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.424389] ehci-pci: EHCI PCI platform driver
[    1.424589] ehci-pci 0000:00:12.2: EHCI Host Controller
[    1.424665] ehci-pci 0000:00:12.2: new USB bus registered, assigned bus number 1
[    1.424760] ehci-pci 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
[    1.424879] ehci-pci 0000:00:12.2: debug port 1
[    1.424967] ehci-pci 0000:00:12.2: irq 17, io mem 0xfe8ff800
[    1.460067] ehci-pci 0000:00:12.2: USB 2.0 started, EHCI 1.00
[    1.460237] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    1.460321] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.460410] usb usb1: Product: EHCI Host Controller
[    1.460470] usb usb1: Manufacturer: Linux 4.15.0-rc6-pc-los_367ea-00117-gf7ba459f ehci_hcd
[    1.460570] usb usb1: SerialNumber: 0000:00:12.2
[    1.460729] hub 1-0:1.0: USB hub found
[    1.463608] hub 1-0:1.0: 6 ports detected
[    1.466696] ehci-pci 0000:00:13.2: EHCI Host Controller
[    1.469576] ehci-pci 0000:00:13.2: new USB bus registered, assigned bus number 2
[    1.472484] ehci-pci 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
[    1.475359] ehci-pci 0000:00:13.2: debug port 1
[    1.478292] ehci-pci 0000:00:13.2: irq 19, io mem 0xfe8ff400
[    1.520035] ehci-pci 0000:00:13.2: USB 2.0 started, EHCI 1.00
[    1.523012] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[    1.525934] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.528888] usb usb2: Product: EHCI Host Controller
[    1.531877] usb usb2: Manufacturer: Linux 4.15.0-rc6-pc-los_367ea-00117-gf7ba459f ehci_hcd
[    1.534989] usb usb2: SerialNumber: 0000:00:13.2
[    1.538173] hub 2-0:1.0: USB hub found
[    1.541274] hub 2-0:1.0: 6 ports detected
[    1.544443] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.547563] ohci-pci: OHCI PCI platform driver
[    1.550735] ohci-pci 0000:00:12.0: OHCI PCI host controller
[    1.553855] ohci-pci 0000:00:12.0: new USB bus registered, assigned bus number 3
[    1.557030] ohci-pci 0000:00:12.0: irq 16, io mem 0xfe8fe000
[    1.634182] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[    1.637345] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.640570] usb usb3: Product: OHCI PCI host controller
[    1.643816] usb usb3: Manufacturer: Linux 4.15.0-rc6-pc-los_367ea-00117-gf7ba459f ohci_hcd
[    1.647173] usb usb3: SerialNumber: 0000:00:12.0
[    1.650590] hub 3-0:1.0: USB hub found
[    1.653901] hub 3-0:1.0: 3 ports detected
[    1.657382] ohci-pci 0000:00:12.1: OHCI PCI host controller
[    1.660692] ohci-pci 0000:00:12.1: new USB bus registered, assigned bus number 4
[    1.663913] ohci-pci 0000:00:12.1: irq 16, io mem 0xfe8fd000
[    1.734177] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[    1.737393] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.740647] usb usb4: Product: OHCI PCI host controller
[    1.743957] usb usb4: Manufacturer: Linux 4.15.0-rc6-pc-los_367ea-00117-gf7ba459f ohci_hcd
[    1.747324] usb usb4: SerialNumber: 0000:00:12.1
[    1.750786] hub 4-0:1.0: USB hub found
[    1.751664] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    1.751695] ata4: SATA link down (SStatus 0 SControl 300)
[    1.751732] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    1.752469] ata1.00: ATA-8: TOSHIBA DT01ACA050, MS1OA750, max UDMA/133
[    1.752470] ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[    1.752622] ata3: SATA link down (SStatus 0 SControl 300)
[    1.753340] ata1.00: configured for UDMA/133
[    1.753468] scsi 0:0:0:0: Direct-Access     ATA      TOSHIBA DT01ACA0 A750 PQ: 0 ANSI: 5
[    1.753616] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    1.753674] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[    1.753676] sd 0:0:0:0: [sda] 4096-byte physical blocks
[    1.753686] sd 0:0:0:0: [sda] Write Protect is off
[    1.753688] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    1.753707] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    1.754752] ata2.00: ATAPI: HL-DT-ST DVDRAM GH24NSB0, LN00, max UDMA/133
[    1.756384] ata2.00: configured for UDMA/133
[    1.758444] scsi 1:0:0:0: CD-ROM            HL-DT-ST DVDRAM GH24NSB0  LN00 PQ: 0 ANSI: 5
[    1.772626]  sda: sda1 sda2
[    1.773011] sd 0:0:0:0: [sda] Attached SCSI disk
[    1.793893] sr 1:0:0:0: [sr0] scsi3-mmc drive: 48x/12x writer dvd-ram cd/rw xa/form2 cdda tray
[    1.793895] cdrom: Uniform CD-ROM driver Revision: 3.20
[    1.793991] sr 1:0:0:0: Attached scsi CD-ROM sr0
[    1.794046] sr 1:0:0:0: Attached scsi generic sg1 type 5
[    1.827348] hub 4-0:1.0: 3 ports detected
[    1.831121] ohci-pci 0000:00:13.0: OHCI PCI host controller
[    1.834638] ohci-pci 0000:00:13.0: new USB bus registered, assigned bus number 5
[    1.838165] ohci-pci 0000:00:13.0: irq 18, io mem 0xfe8fc000
[    1.890034] usb 1-1: new high-speed USB device number 2 using ehci-pci
[    1.914185] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
[    1.917746] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.921327] usb usb5: Product: OHCI PCI host controller
[    1.924934] usb usb5: Manufacturer: Linux 4.15.0-rc6-pc-los_367ea-00117-gf7ba459f ohci_hcd
[    1.928628] usb usb5: SerialNumber: 0000:00:13.0
[    1.932378] hub 5-0:1.0: USB hub found
[    1.936029] hub 5-0:1.0: 3 ports detected
[    1.939825] ohci-pci 0000:00:13.1: OHCI PCI host controller
[    1.943408] ohci-pci 0000:00:13.1: new USB bus registered, assigned bus number 6
[    1.947022] ohci-pci 0000:00:13.1: irq 18, io mem 0xfe8fb000
[    2.024181] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
[    2.027765] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.031367] usb usb6: Product: OHCI PCI host controller
[    2.034990] usb usb6: Manufacturer: Linux 4.15.0-rc6-pc-los_367ea-00117-gf7ba459f ohci_hcd
[    2.038681] usb usb6: SerialNumber: 0000:00:13.1
[    2.042503] hub 6-0:1.0: USB hub found
[    2.046161] hub 6-0:1.0: 3 ports detected
[    2.049963] ohci-pci 0000:00:14.5: OHCI PCI host controller
[    2.053593] ohci-pci 0000:00:14.5: new USB bus registered, assigned bus number 7
[    2.057256] ohci-pci 0000:00:14.5: irq 18, io mem 0xfe8fa000
[    2.093908] usb 1-1: New USB device found, idVendor=05e3, idProduct=0723
[    2.097446] usb 1-1: New USB device strings: Mfr=3, Product=4, SerialNumber=0
[    2.101044] usb 1-1: Product: USB Storage
[    2.104658] usb 1-1: Manufacturer: Generic 
[    2.134179] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
[    2.137751] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.141360] usb usb7: Product: OHCI PCI host controller
[    2.144896] usb usb7: Manufacturer: Linux 4.15.0-rc6-pc-los_367ea-00117-gf7ba459f ohci_hcd
[    2.148488] usb usb7: SerialNumber: 0000:00:14.5
[    2.152189] hub 7-0:1.0: USB hub found
[    2.155767] hub 7-0:1.0: 2 ports detected
[    2.159378] uhci_hcd: USB Universal Host Controller Interface driver
[    2.163008] xhci_hcd 0000:03:00.0: Resetting
[    2.230038] tsc: Refined TSC clocksource calibration: 3899.999 MHz
[    2.233609] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x706eb38f3d8, max_idle_ns: 881591117856 ns
[    2.490025] usb 6-2: new full-speed USB device number 2 using ohci-pci
[    2.787145] usb 6-2: New USB device found, idVendor=046a, idProduct=0009
[    2.790867] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.794566] usb 6-2: Product: Cherry Multiboard              
[    2.798260] usb 6-2: Manufacturer: Cherry GmbH                    
[    2.823164] hub 6-2:1.0: USB hub found
[    2.828149] hub 6-2:1.0: 3 ports detected
[    3.160027] usb 6-2.3: new full-speed USB device number 3 using ohci-pci
[    3.240121] clocksource: Switched to clocksource tsc
[    3.270132] xhci_hcd 0000:03:00.0: xHCI Host Controller
[    3.273668] xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 8
[    3.282543] xhci_hcd 0000:03:00.0: hcc params 0x014050cf hci version 0x100 quirks 0x00000410
[    3.286426] usb usb8: New USB device found, idVendor=1d6b, idProduct=0002
[    3.289962] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.293479] usb usb8: Product: xHCI Host Controller
[    3.296995] usb usb8: Manufacturer: Linux 4.15.0-rc6-pc-los_367ea-00117-gf7ba459f xhci-hcd
[    3.300545] usb usb8: SerialNumber: 0000:03:00.0
[    3.304110] hub 8-0:1.0: USB hub found
[    3.307623] hub 8-0:1.0: 4 ports detected
[    3.311256] xhci_hcd 0000:03:00.0: xHCI Host Controller
[    3.314739] xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 9
[    3.318286] usb usb9: We don't know the algorithms for LPM for this host, disabling LPM.
[    3.321902] usb usb9: New USB device found, idVendor=1d6b, idProduct=0003
[    3.325429] usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.328949] usb usb9: Product: xHCI Host Controller
[    3.332491] usb usb9: Manufacturer: Linux 4.15.0-rc6-pc-los_367ea-00117-gf7ba459f xhci-hcd
[    3.336047] usb usb9: SerialNumber: 0000:03:00.0
[    3.339701] hub 9-0:1.0: USB hub found
[    3.343279] hub 9-0:1.0: 4 ports detected
[    3.346954] usbcore: registered new interface driver cdc_acm
[    3.350575] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[    3.354150] usb-storage 1-1:1.0: USB Mass Storage device detected
[    3.357739] usb-storage 1-1:1.0: Quirks match for vid 05e3 pid 0723: 8000
[    3.361380] scsi host4: usb-storage 1-1:1.0
[    3.364974] usbcore: registered new interface driver usb-storage
[    3.368569] usbcore: registered new interface driver ftdi_sio
[    3.372121] usbserial: USB Serial support registered for FTDI USB Serial Device
[    3.372193] usb 6-2.3: New USB device found, idVendor=046a, idProduct=0016
[    3.372194] usb 6-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    3.372195] usb 6-2.3: Product: Cherry Multiboard              
[    3.372196] usb 6-2.3: Manufacturer: Cherry GmbH                    
[    3.389875] usbcore: registered new interface driver option
[    3.393393] usbserial: USB Serial support registered for GSM modem (1-port)
[    3.396998] usbcore: registered new interface driver pl2303
[    3.400542] usbserial: USB Serial support registered for pl2303
[    3.404148] usbcore: registered new interface driver sierra
[    3.407661] usbserial: USB Serial support registered for Sierra USB modem
[    3.411306] i8042: PNP: No PS/2 controller found.
[    3.414860] i8042: Probing ports directly.
[    3.418702] serio: i8042 KBD port at 0x60,0x64 irq 1
[    3.422338] serio: i8042 AUX port at 0x60,0x64 irq 12
[    3.425861] mousedev: PS/2 mouse device common for all mice
[    3.429449] rtc_cmos 00:01: RTC can wake from S4
[    3.433021] rtc_cmos 00:01: rtc core: registered rtc_cmos as rtc0
[    3.436522] rtc_cmos 00:01: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[    3.440113] usbcore: registered new interface driver em28xx
[    3.443616] em28xx: Registered (Em28xx v4l2 Extension) extension
[    3.447083] em28xx: Registered (Em28xx dvb Extension) extension
[    3.450638] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: dm-devel@redhat.com
[    3.454125] sdhci: Secure Digital Host Controller Interface driver
[    3.457570] sdhci: Copyright(c) Pierre Ossman
[    3.468407] input: Cherry GmbH                     Cherry Multiboard               as /devices/pci0000:00/0000:00:13.1/usb6/6-2/6-2.3/6-2.3:1.0/0003:046A:0016.0001/input/input3
[    3.540064] hid-generic 0003:046A:0016.0001: input: USB HID v1.11 Keyboard [Cherry GmbH                     Cherry Multiboard              ] on usb-0000:00:13.1-2.3/input0
[    3.552365] hid-generic 0003:046A:0016.0002: device has no listeners, quitting
[    3.556250] usbcore: registered new interface driver usbhid
[    3.560070] usbhid: USB HID core driver
[    3.564125] usbcore: registered new interface driver snd-usb-audio
[    3.568117] nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
[    3.572093] ip_tables: (C) 2000-2006 Netfilter Core Team
[    3.576038] NET: Registered protocol family 17
[    3.580627] microcode: CPU0: patch_level=0x0600081c
[    3.584474] microcode: CPU1: patch_level=0x0600081c
[    3.589987] snd_hda_codec_realtek hdaudioC0D3: autoconfig for ALC887-VD: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line
[    3.589988] snd_hda_codec_realtek hdaudioC0D3:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    3.589989] snd_hda_codec_realtek hdaudioC0D3:    hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
[    3.589990] snd_hda_codec_realtek hdaudioC0D3:    mono: mono_out=0x0
[    3.589991] snd_hda_codec_realtek hdaudioC0D3:    inputs:
[    3.589992] snd_hda_codec_realtek hdaudioC0D3:      Front Mic=0x19
[    3.589993] snd_hda_codec_realtek hdaudioC0D3:      Rear Mic=0x18
[    3.589994] snd_hda_codec_realtek hdaudioC0D3:      Line=0x1a
[    3.625181] microcode: CPU2: patch_level=0x0600081c
[    3.625317] input: HDA ATI SB Front Mic as /devices/pci0000:00/0000:00:14.2/sound/card0/input6
[    3.625373] input: HDA ATI SB Rear Mic as /devices/pci0000:00/0000:00:14.2/sound/card0/input7
[    3.625425] input: HDA ATI SB Line as /devices/pci0000:00/0000:00:14.2/sound/card0/input8
[    3.625477] input: HDA ATI SB Line Out as /devices/pci0000:00/0000:00:14.2/sound/card0/input9
[    3.625526] input: HDA ATI SB Front Headphone as /devices/pci0000:00/0000:00:14.2/sound/card0/input10
[    3.646899] microcode: CPU3: patch_level=0x0600081c
[    3.650635] microcode: CPU4: patch_level=0x0600081c
[    3.654213] microcode: CPU5: patch_level=0x0600081c
[    3.657838] microcode: Microcode Update Driver: v2.2.
[    3.657842] sched_clock: Marking stable (3657829080, 0)->(3700928096, -43099016)
[    3.665031] registered taskstats version 1
[    3.668923] acpi_cpufreq: overriding BIOS provided _PSD data
[    3.672727] ALSA device list:
[    3.676247]   #0: HDA ATI SB at 0xfe8f4000 irq 16
[    3.682250] Freeing unused kernel memory: 7636K
[    3.685764] Write protecting the kernel read-only data: 16384k
[    3.689990] Freeing unused kernel memory: 2020K
[    3.696384] Freeing unused kernel memory: 1644K
[    3.699891] rodata_test: all tests were successful
[    3.730043] usb 8-1: new full-speed USB device number 2 using xhci_hcd
[    3.927189] usb 8-1: New USB device found, idVendor=0557, idProduct=2008
[    3.931195] usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    3.935196] usb 8-1: Product: USB-Serial Controller D
[    3.939180] usb 8-1: Manufacturer: Prolific Technology Inc. 
[    3.947216] pl2303 8-1:1.0: pl2303 converter detected
[    3.978260] usb 8-1: pl2303 converter now attached to ttyUSB0
[    4.391549] scsi 4:0:0:0: Direct-Access     Generic  STORAGE DEVICE   9451 PQ: 0 ANSI: 0
[    4.395853] sd 4:0:0:0: Attached scsi generic sg2 type 0
[    4.399656] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[    5.230756] usb 9-4: new SuperSpeed USB device number 2 using xhci_hcd
[    5.263735] usb 9-4: New USB device found, idVendor=0951, idProduct=1666
[    5.267633] usb 9-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    5.271495] usb 9-4: Product: DataTraveler 3.0
[    5.275289] usb 9-4: Manufacturer: Kingston
[    5.279060] usb 9-4: SerialNumber: 60A44C3FB03BAF2040000949
[    5.284377] usb-storage 9-4:1.0: USB Mass Storage device detected
[    5.287983] scsi host5: usb-storage 9-4:1.0
[    6.017938] EXT4-fs (sda2): couldn't mount as ext3 due to feature incompatibilities
[    6.021765] EXT4-fs (sda2): couldn't mount as ext2 due to feature incompatibilities
[    6.037300] EXT4-fs (sda2): mounted filesystem with writeback data mode. Opts: (null)
[    6.310512] scsi 5:0:0:0: Direct-Access     KINGSTON DataTraveler 3.0 1.01 PQ: 0 ANSI: 6
[    6.314023] sd 5:0:0:0: Attached scsi generic sg3 type 0
[    6.317574] sd 5:0:0:0: [sdc] 15187968 512-byte logical blocks: (7.78 GB/7.24 GiB)
[    6.321451] sd 5:0:0:0: [sdc] Write Protect is off
[    6.325052] sd 5:0:0:0: [sdc] Mode Sense: 2b 00 10 08
[    6.325183] sd 5:0:0:0: [sdc] Write cache: disabled, read cache: enabled, supports DPO and FUA
[    6.330074]  sdc: sdc1 sdc2
[    6.334474] sd 5:0:0:0: [sdc] Attached SCSI removable disk
[    7.392343] Adding 16745468k swap on /dev/sda1.  Priority:-2 extents:1 across:16745468k 
[    8.252112] r8169 0000:02:00.0 eth0: link down
[    8.252113] r8169 0000:02:00.0 eth0: link down
[   10.967894] r8169 0000:02:00.0 eth0: link up
[   31.454495] random: crng init done

A.

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

[Bjorn Helgaas]

[+cc Boris, Juergen, linux-pci]

On Fri, Jan 5, 2018 at 6:00 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, Jan 5, 2018 at 2:04 PM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
>>
>> After v4.14, I've been unable to boot my AMD compilation box with the
>> v4.15-rc mainline Linux. It just ends up in a silent reboot loop.
>>
>> I bisected this to:
>>
>> commit fa564ad9636651fd11ec2c79c48dee844066f73a
>> Author: Christian König <christian.koenig@amd.com>
>> Date:   Tue Oct 24 14:40:29 2017 -0500
>>
>>     x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f, 60-7f)
>
> Hmm. That was reported to break boot earlier already.
>
> The breakage was supposedly fixed by three patches from Christian:
>
>   a19e2696135e: "x86/PCI: Only enable a 64bit BAR on single-socket AMD
> Family 15h"
>
>   470195f82e4e:  "x86/PCI: Fix infinite loop in search for 64bit BAR placement"
>
> and a third one that was apparently never applied.
>
> I'm not sure why that third patch was never applied, I'm including it here.
>
> Does the system work for you if you apply that patch (instead of
> reverting all of them)?
>
> I wonder why that patch wasn't applied, but if it doesn't fix things,
> I think we do need to revert it all.
>
> Christian? Bjorn?

I didn't apply the third patch ("x86/PCI: limit the size of the 64bit
BAR to 256GB") because (a) we thought it was optional ("just a
precaution against eventual problems"), (b) we didn't have a good
explanation of why 256GB was the correct number, and (c)  it seemed to
be a workaround for a Xen issue that we hoped to fix in a better way.

It does apparently make Aaro's system work, but I still hesitate to
apply it because it's magical -- avoiding the address space from
0x1_00000000 to 0xbd_00000000 makes things work, but we don't know
why.  I assume there's some unreported device in that area, but I
don't think we have any real assurance that the
0xbd_00000000-0xfd_00000000 area we now use is any safer.

I would feel better about this if we made it opt-in via a kernel
parameter and/or some kind of whitelist.  I still don't really *like*
it, since ACPI does provide a mechanism (_PRS/_SRS) for doing this
safely, and we could just say "if you want to use big BARs, the BIOS
should enable big windows or at least make them available via ACPI
resources."  The only problem is that BIOSes don't do that and we
don't yet have Linux support for _PRS/_SRS for host bridges.

I'll prepare a revert as a back-up plan in case we don't come up with
a better solution.

Bjorn

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

[Christian König]

[-- Attachment #1: Type: text/plain, Size: 3754 bytes --]

Am 09.01.2018 um 00:23 schrieb Bjorn Helgaas:
> [+cc Boris, Juergen, linux-pci]
>
> On Fri, Jan 5, 2018 at 6:00 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> On Fri, Jan 5, 2018 at 2:04 PM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
>>> After v4.14, I've been unable to boot my AMD compilation box with the
>>> v4.15-rc mainline Linux. It just ends up in a silent reboot loop.
>>>
>>> I bisected this to:
>>>
>>> commit fa564ad9636651fd11ec2c79c48dee844066f73a
>>> Author: Christian König <christian.koenig@amd.com>
>>> Date:   Tue Oct 24 14:40:29 2017 -0500
>>>
>>>      x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f, 60-7f)
>> Hmm. That was reported to break boot earlier already.
>>
>> The breakage was supposedly fixed by three patches from Christian:
>>
>>    a19e2696135e: "x86/PCI: Only enable a 64bit BAR on single-socket AMD
>> Family 15h"
>>
>>    470195f82e4e:  "x86/PCI: Fix infinite loop in search for 64bit BAR placement"
>>
>> and a third one that was apparently never applied.
>>
>> I'm not sure why that third patch was never applied, I'm including it here.
>>
>> Does the system work for you if you apply that patch (instead of
>> reverting all of them)?
>>
>> I wonder why that patch wasn't applied, but if it doesn't fix things,
>> I think we do need to revert it all.
>>
>> Christian? Bjorn?
> I didn't apply the third patch ("x86/PCI: limit the size of the 64bit
> BAR to 256GB") because (a) we thought it was optional ("just a
> precaution against eventual problems"), (b) we didn't have a good
> explanation of why 256GB was the correct number, and (c)  it seemed to
> be a workaround for a Xen issue that we hoped to fix in a better way.

Just for the record completely agree on that.

> It does apparently make Aaro's system work, but I still hesitate to
> apply it because it's magical -- avoiding the address space from
> 0x1_00000000 to 0xbd_00000000 makes things work, but we don't know
> why.  I assume there's some unreported device in that area, but I
> don't think we have any real assurance that the
> 0xbd_00000000-0xfd_00000000 area we now use is any safer.

Well, I knew why it's not working. The BIOS is not telling us the truth 
about how much memory is installed.

A device above 4GB would actually be handled correctly by the code (see 
the check when we walk over all the existing IO regions).

I tested a bit with Aaro and came up with the attached patch, it adds a 
16GB guard between the end of memory and the new window for the PCIe 
root hub. But I agree with you that this is just a hack and not a real 
solution.

> I would feel better about this if we made it opt-in via a kernel
> parameter and/or some kind of whitelist.  I still don't really *like*
> it, since ACPI does provide a mechanism (_PRS/_SRS) for doing this
> safely, and we could just say "if you want to use big BARs, the BIOS
> should enable big windows or at least make them available via ACPI
> resources."  The only problem is that BIOSes don't do that and we
> don't yet have Linux support for _PRS/_SRS for host bridges.

Well that is the point I disagree on. When the memory map we get from 
the BIOS is not correct it makes no difference if we enable the window 
with the BIOS or by direct programming the hardware.

I will work with Aaron some more to come up with a solution which reads 
the memory map directly from the hardware as well and checks if that is 
valid before doing anything else.

> I'll prepare a revert as a back-up plan in case we don't come up with
> a better solution.

Either that or only enable it when pci=add-root-window is given on the 
kernel commandline.

Just let me know what you prefer and I will hack a patch for this 
together today.

Christian.

> Bjorn


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-x86-PCI-add-16GB-guard-between-end-of-memory-and-new.patch --]
[-- Type: text/x-patch; name="0001-x86-PCI-add-16GB-guard-between-end-of-memory-and-new.patch", Size: 1149 bytes --]

>From 101e157babcef10b91edf91e7e6f03826c2f8ade Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
Date: Tue, 28 Nov 2017 10:02:35 +0100
Subject: [PATCH] x86/PCI: add 16GB guard between end of memory and new PCI
 window
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Add a workaround for buggy BIOS implementations who steal memory for
iGPUs from the OS without reporting it as reserved.

Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
---
 arch/x86/pci/fixup.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index e663d6bf1328..e1bdae2cebb6 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -713,6 +713,10 @@ static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
 		}
 		res->start = conflict->end + 1;
 	}
+	/* Add 16GB guard between end of memory and new PCI window to work
+	 * around buggy BIOS implementations.
+	 */
+	res->start += 0x400000000ull;
 
 	dev_info(&dev->dev, "adding root bus resource %pR\n", res);
 
-- 
2.11.0

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

[Bjorn Helgaas]

[+cc Alex, Dave because this affects the AMDGPU large BAR support]

On Tue, Jan 09, 2018 at 11:37:55AM +0100, Christian König wrote:
> Am 09.01.2018 um 00:23 schrieb Bjorn Helgaas:
> >[+cc Boris, Juergen, linux-pci]
> >
> >On Fri, Jan 5, 2018 at 6:00 PM, Linus Torvalds
> ><torvalds@linux-foundation.org> wrote:
> >>On Fri, Jan 5, 2018 at 2:04 PM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> >>>After v4.14, I've been unable to boot my AMD compilation box with the
> >>>v4.15-rc mainline Linux. It just ends up in a silent reboot loop.
> >>>
> >>>I bisected this to:
> >>>
> >>>commit fa564ad9636651fd11ec2c79c48dee844066f73a
> >>>Author: Christian König <christian.koenig@amd.com>
> >>>Date:   Tue Oct 24 14:40:29 2017 -0500
> >>>
> >>>     x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f, 60-7f)
> >>Hmm. That was reported to break boot earlier already.
> >>
> >>The breakage was supposedly fixed by three patches from Christian:
> >>
> >>   a19e2696135e: "x86/PCI: Only enable a 64bit BAR on single-socket AMD
> >>Family 15h"
> >>
> >>   470195f82e4e:  "x86/PCI: Fix infinite loop in search for 64bit BAR placement"
> >>
> >>and a third one that was apparently never applied.
> >>
> >>I'm not sure why that third patch was never applied, I'm including it here.
> >>
> >>Does the system work for you if you apply that patch (instead of
> >>reverting all of them)?
> >>
> >>I wonder why that patch wasn't applied, but if it doesn't fix things,
> >>I think we do need to revert it all.
> >>
> >>Christian? Bjorn?
> >I didn't apply the third patch ("x86/PCI: limit the size of the 64bit
> >BAR to 256GB") because (a) we thought it was optional ("just a
> >precaution against eventual problems"), (b) we didn't have a good
> >explanation of why 256GB was the correct number, and (c)  it seemed to
> >be a workaround for a Xen issue that we hoped to fix in a better way.
> 
> Just for the record completely agree on that.
> 
> >It does apparently make Aaro's system work, but I still hesitate to
> >apply it because it's magical -- avoiding the address space from
> >0x1_00000000 to 0xbd_00000000 makes things work, but we don't know
> >why.  I assume there's some unreported device in that area, but I
> >don't think we have any real assurance that the
> >0xbd_00000000-0xfd_00000000 area we now use is any safer.
> 
> Well, I knew why it's not working. The BIOS is not telling us the
> truth about how much memory is installed.
> 
> A device above 4GB would actually be handled correctly by the code
> (see the check when we walk over all the existing IO regions).
> 
> I tested a bit with Aaro and came up with the attached patch, it
> adds a 16GB guard between the end of memory and the new window for
> the PCIe root hub. But I agree with you that this is just a hack and
> not a real solution.
> 
> >I would feel better about this if we made it opt-in via a kernel
> >parameter and/or some kind of whitelist.  I still don't really *like*
> >it, since ACPI does provide a mechanism (_PRS/_SRS) for doing this
> >safely, and we could just say "if you want to use big BARs, the BIOS
> >should enable big windows or at least make them available via ACPI
> >resources."  The only problem is that BIOSes don't do that and we
> >don't yet have Linux support for _PRS/_SRS for host bridges.
> 
> Well that is the point I disagree on. When the memory map we get
> from the BIOS is not correct it makes no difference if we enable the
> window with the BIOS or by direct programming the hardware.
> 
> I will work with Aaron some more to come up with a solution which
> reads the memory map directly from the hardware as well and checks
> if that is valid before doing anything else.

I don't agree with this approach.  One goal of UEFI/ACPI is to remove
the need for the OS to directly peek at the hardware for things like
this.

In Aaro's case, the BIOS apparently does not describe all of system
memory in E820.  ACPI r5.0, sec 15.1 describes E820 and it does say
that the the E820 interface "provides a memory map for all of the
installed RAM, and of physical memory ranges reserved by the BIOS,"
so one could argue that Aaro's BIOS is defective because it omits
something.

But I think the intent of the spec is that all non-discoverable
resources available to the OS will be described via E820, UEFI
GetMemoryMap(), ACPI tables, etc.  So I think a BIOS engineer would be
on pretty safe ground to say "Mr. OS, we didn't tell you about X, so 
you should not use X."

And, again with a BIOS engineer's hat on, I would argue that the BIOS
is entitled to use unreported things for its own purposes and rely on
the assumption that the OS will not use them.

So I'm not convinced this is necessarily a BIOS bug.  If we peek at
the hardware directly for things the spec can express, I think we're
making the OS less portable and opening the door to conflicts with the
BIOS.

> >I'll prepare a revert as a back-up plan in case we don't come up with
> >a better solution.
> 
> Either that or only enable it when pci=add-root-window is given on
> the kernel commandline.

I don't like to add new parameters because I think it's an
unreasonable burden on users and it makes it hard for distros, but I
understand the desire to use this functionality.  What would you think
of adding a "pci=big_root_window" parameter that logs an info message
and taints the kernel with TAINT_FIRMWARE_WORKAROUND?  Then there's at
least some clue that we're in uncharted territory.

Bjorn

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

[Christian König]

Am 09.01.2018 um 19:38 schrieb Bjorn Helgaas:
> I don't like to add new parameters because I think it's an
> unreasonable burden on users and it makes it hard for distros, but I
> understand the desire to use this functionality.  What would you think
> of adding a "pci=big_root_window" parameter that logs an info message
> and taints the kernel with TAINT_FIRMWARE_WORKAROUND?  Then there's at
> least some clue that we're in uncharted territory.

Done, patches for this are in your inbox.

Additionally to that I cleaned up the 256GB patch a bit more, e.g. added 
a comment where the 0xfd00000000 limit comes from and updated the commit 
message.

Please review and/or comment,
Christian.

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

[Linus Torvalds]

On Tue, Jan 9, 2018 at 2:37 AM, Christian König
<christian.koenig@amd.com> wrote:
>
> I tested a bit with Aaro and came up with the attached patch, it adds a 16GB
> guard between the end of memory and the new window for the PCIe root hub.
> But I agree with you that this is just a hack and not a real solution.

Guys, that last statement makes no sense.

The *real* hack was that original patch that caused problems.

I mean, just look at it. It has a completely made up - and bad -
default start, and then it tries to forcibly just create the maximum
window it possibly can. Well, not quite, but almost.

Now *THAT* is hacky, and fragile, and a bad idea. It's a fundamentally
bad idea exactly because it assumes

 (a) we have perfect knowledge

 (b) that window that wasn't even enabled or configured in the first
place should be the maximum window.

both of those assumptions seem completely bogus, and seem to have no
actual reason.

This comment in that code really does say it all:

        /* Just grab the free area behind system memory for this */

very lackadaisical.

I agree that the 16GB guard is _also_ random, but it's certainly not
less random or hacky.

But I really wonder why you want to be that close to memory at all.

What was wrong with the patch thgat just put it the hell out of any
normal memory range, and just changed the default start from one
random (and clearly bad) value to _another_ random but at least
out-of-the-way value?

IOW, this change

-       res->start = 0x100000000ull;
+       res->start = 0xbd00000000ull;

really has a relatively solid explanation for it: "pick a high address
that is likely out of the way". That's *much* better than "pick an
address that is right after memory".

Now, could there be a better high address to pick? Probably. It would
be really nice to have a *reason* for the address to be picked.

But honestly, even "it doesn't break Aaro's machine" is a better
reason than many, in the absence of other reasons.

For example, was there a reason for that random 756GB address? Is the
limit of the particular AMD 64-bit bar perhaps at the 1TB mark (and
that "res->end" value is because "close to it, but not at the top")?

So I think "just above RAM" is a _horrible_ default starting point.
The random 16GB guard is _better_, but it honestly doesn't seem any
better than the simpler original patch.

A starting point like "halfway to from the hardware limit" would
actually be a better reason. Or just "we picked an end-point, let's
pick a starting point that gives us a _sufficient_ - but not excessive
- window".

Or any number of other possible starting points. Almost _anything_ is
better than "end of RAM".

That "above end of RAM" might be a worst-case fall-back value (and in
fact, I think that _is_ pretty close to what the PCI code uses for the
case of "we don't have any parent at all, so we'll just have to assume
it's a transparent bridge"), but I don't think it's necessarily what
you should _strive_ for.

So the hackyness of whatever the fix is really should be balanced with
the hackyness of the original patch that introduced this problem.

             Linus

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

[Christian König]

Am 09.01.2018 um 20:18 schrieb Linus Torvalds:
> On Tue, Jan 9, 2018 at 2:37 AM, Christian König
> <christian.koenig@amd.com> wrote:
>> I tested a bit with Aaro and came up with the attached patch, it adds a 16GB
>> guard between the end of memory and the new window for the PCIe root hub.
>> But I agree with you that this is just a hack and not a real solution.
> Guys, that last statement makes no sense.
>
> The *real* hack was that original patch that caused problems.
>
> I mean, just look at it. It has a completely made up - and bad -
> default start, and then it tries to forcibly just create the maximum
> window it possibly can. Well, not quite, but almost.
>
> Now *THAT* is hacky, and fragile, and a bad idea. It's a fundamentally
> bad idea exactly because it assumes
>
>   (a) we have perfect knowledge
>
>   (b) that window that wasn't even enabled or configured in the first
> place should be the maximum window.
>
> both of those assumptions seem completely bogus, and seem to have no
> actual reason.
>
> This comment in that code really does say it all:
>
>          /* Just grab the free area behind system memory for this */
>
> very lackadaisical.
>
> I agree that the 16GB guard is _also_ random, but it's certainly not
> less random or hacky.
>
> But I really wonder why you want to be that close to memory at all.

Actually I don't want to be close to the end of memory at all. It's just 
what I found a certain other OS is doing and I thought: Hey, that has 
the best chance of working...

But yeah, thinking about it I agree with you that this was probably not 
a good idea.

> What was wrong with the patch thgat just put it the hell out of any
> normal memory range, and just changed the default start from one
> random (and clearly bad) value to _another_ random but at least
> out-of-the-way value?

Well Bjorn didn't liked it because I couldn't come up with a good 
explanation why 256GB is a good value in general (it is a good value for 
our particular use case).

> IOW, this change
>
> -       res->start = 0x100000000ull;
> +       res->start = 0xbd00000000ull;
>
> really has a relatively solid explanation for it: "pick a high address
> that is likely out of the way". That's *much* better than "pick an
> address that is right after memory".
>
> Now, could there be a better high address to pick? Probably. It would
> be really nice to have a *reason* for the address to be picked.
>
> But honestly, even "it doesn't break Aaro's machine" is a better
> reason than many, in the absence of other reasons.
>
> For example, was there a reason for that random 756GB address? Is the
> limit of the particular AMD 64-bit bar perhaps at the 1TB mark (and
> that "res->end" value is because "close to it, but not at the top")?

That is actually a hardware limit documented in the BIOS and Kernel 
developers guide for AMD CPUs 
(https://support.amd.com/TechDocs/49125_15h_Models_30h-3Fh_BKDG.pdf).

I should probably add a comment explaining this.

> So I think "just above RAM" is a _horrible_ default starting point.
> The random 16GB guard is _better_, but it honestly doesn't seem any
> better than the simpler original patch.
>
> A starting point like "halfway to from the hardware limit" would
> actually be a better reason. Or just "we picked an end-point, let's
> pick a starting point that gives us a _sufficient_ - but not excessive
> - window".

Well that is exactly what the 256GB patch was doing.

So as long as you are fine with that I'm perfectly fine to use that one.

Christian.

> Or any number of other possible starting points. Almost _anything_ is
> better than "end of RAM".
>
> That "above end of RAM" might be a worst-case fall-back value (and in
> fact, I think that _is_ pretty close to what the PCI code uses for the
> case of "we don't have any parent at all, so we'll just have to assume
> it's a transparent bridge"), but I don't think it's necessarily what
> you should _strive_ for.
>
> So the hackyness of whatever the fix is really should be balanced with
> the hackyness of the original patch that introduced this problem.
>
>               Linus

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

[Linus Torvalds]

On Tue, Jan 9, 2018 at 11:31 AM, Christian König
<christian.koenig@amd.com> wrote:
>>
>> For example, was there a reason for that random 756GB address? Is the
>> limit of the particular AMD 64-bit bar perhaps at the 1TB mark (and
>> that "res->end" value is because "close to it, but not at the top")?
>
> That is actually a hardware limit documented in the BIOS and Kernel
> developers guide for AMD CPUs
> (https://support.amd.com/TechDocs/49125_15h_Models_30h-3Fh_BKDG.pdf).
>
> I should probably add a comment explaining this.

Ok, good. So at least some of those values have reasons.

And yes, documenting it would be great.

>> A starting point like "halfway to from the hardware limit" would
>> actually be a better reason. Or just "we picked an end-point, let's
>> pick a starting point that gives us a _sufficient_ - but not excessive
>> - window".
>
>
> Well that is exactly what the 256GB patch was doing.

Ahh, so 0xbd00000000ull is basically 256GB from the end point, and the
end point is basically specified by hardware.

So yes, I think that's a starting point that can at least be
explained: let's try to make it something "big enough" (and 256GB
seems to be big enough).

Of course, since this is all "pick a random number", maybe that breaks
something _else_.

We do traditionally have a very similar issue for the 32-bit PCI
starting address, where we used to have tons of issues with "we don't
know all resources, we want to try to come up with a range that is out
of the way".

There we try to find a big enough gap in th e820 memory map
(e820_search_gap()), and the end result is pci_mem_start (which is
then exposed as PCIBIOS_MIN_MEM to the PCI resource allocation).

If worst comes to worst, maybe we should look at having something
similar for the full 64-bit range.

             Linus