Re: [PATCH v3 6/6] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system

On 02/18/19 at 11:24am, Mike Travis wrote: > Hi Baoquan, > > There was a breakage in the TSC code (for UV) where the change was to > introduce an early TSC "adjustment". This bypassed the UV auto setting of > TSC by BIOS because it came before the UV init code could indicate that the > TSC was

Re: [PATCH v3 6/6] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system

Hi Baoquan, There was a breakage in the TSC code (for UV) where the change was to introduce an early TSC "adjustment". This bypassed the UV auto setting of TSC by BIOS because it came before the UV init code could indicate that the TSC was already in sync. (I believe I already sent you a

Re: [PATCH v3 6/6] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system

Hi Mike, On 02/16/19 at 10:00pm, Baoquan He wrote: > On SGI UV system, kernel often hangs when KASLR is enabled. Disabling > KASLR makes kernel work well. I wrap codes which calculate the size of the direct mapping section into a new function calc_direct_mapping_size() as Ingo suggested. This

[PATCH v3 6/6] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system

On SGI UV system, kernel often hangs when KASLR is enabled. Disabling KASLR makes kernel work well. The back trace is: kernel BUG at arch/x86/mm/init_64.c:311! invalid opcode: [#1] SMP [...] RIP: 0010:__init_extra_mapping+0x188/0x196 [...] Call Trace: init_extra_mapping_uc+0x13/0x15