Re: setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms

2019-08-08 Thread Lendacky, Thomas
Hi Thomas, On 8/8/19 4:08 PM, Thomas Gleixner wrote: > Tom, > > On Thu, 8 Aug 2019, Lendacky, Thomas wrote: >> On 8/8/19 3:36 PM, Thomas Gleixner wrote: >>> On Thu, 1 Aug 2019, Lendacky, Thomas wrote: On 8/1/19 5:13 AM, Thomas Gleixner wrote: > 2.1.9 Timers > > Each

Re: setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms

2019-08-08 Thread Thomas Gleixner
Tom, On Thu, 8 Aug 2019, Lendacky, Thomas wrote: > On 8/8/19 3:36 PM, Thomas Gleixner wrote: > > On Thu, 1 Aug 2019, Lendacky, Thomas wrote: > >> On 8/1/19 5:13 AM, Thomas Gleixner wrote: > >>>2.1.9 Timers > >>> > >>> Each core includes the following timers. These timers do not vary in >

Re: setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms

2019-08-08 Thread Lendacky, Thomas
Hi Thomas, On 8/8/19 3:36 PM, Thomas Gleixner wrote: > Tom, > > On Thu, 1 Aug 2019, Lendacky, Thomas wrote: >> On 8/1/19 5:13 AM, Thomas Gleixner wrote: >>>2.1.9 Timers >>> >>> Each core includes the following timers. These timers do not vary in >>> frequency regardless of the

Re: setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms

2019-08-08 Thread Thomas Gleixner
Tom, On Thu, 1 Aug 2019, Lendacky, Thomas wrote: > On 8/1/19 5:13 AM, Thomas Gleixner wrote: > > 2.1.9 Timers > > > >Each core includes the following timers. These timers do not vary in > >frequency regardless of the current P-state or C-state. > > > >* Core::X86::Msr::TSC; the

Re: setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms

2019-08-01 Thread Lendacky, Thomas
On 8/1/19 5:13 AM, Thomas Gleixner wrote: > On Thu, 1 Aug 2019, Li, Aubrey wrote: >> On 2019/8/1 16:13, Thomas Gleixner wrote: >>> The point is that it does not matter which vendor a CPU comes from. The >>> kernel does support legacyless boot when the frequencies are known. Whether >>> that's

Re: setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms

2019-08-01 Thread Thomas Gleixner
On Thu, 1 Aug 2019, Daniel Drake wrote: > On Thu, Aug 1, 2019 at 3:16 PM Aubrey Li wrote: > However, the only way this can be called is from hpet_enable(). > > hpet_enable() is called from 2 places: > 1. From hpet_time_init(). This is the default x86 timer_init that >

Re: setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms

2019-08-01 Thread Thomas Gleixner
On Thu, 1 Aug 2019, Li, Aubrey wrote: > On 2019/8/1 16:13, Thomas Gleixner wrote: > > The point is that it does not matter which vendor a CPU comes from. The > > kernel does support legacyless boot when the frequencies are known. Whether > > that's currently possible on that particular CPU is a

Re: setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms

2019-08-01 Thread Daniel Drake
On Thu, Aug 1, 2019 at 3:16 PM Aubrey Li wrote: > No, the platform needs a global clock event, can you turn on some other > clock source on your platform, like HPET? Thanks Audrey and Thomas for the quick hints! I double checked under Windows - it seems to be using a HPET there. Also there is

Re: setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms

2019-08-01 Thread Li, Aubrey
On 2019/8/1 16:13, Thomas Gleixner wrote: > On Thu, 1 Aug 2019, Aubrey Li wrote: >> On Thu, Aug 1, 2019 at 3:35 PM Thomas Gleixner wrote: >>> >>> On Thu, 1 Aug 2019, Aubrey Li wrote: On Thu, Aug 1, 2019 at 2:26 PM Daniel Drake wrote: > global_clock_event is NULL here. This is a "reduced

Re: setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms

2019-08-01 Thread Thomas Gleixner
On Thu, 1 Aug 2019, Aubrey Li wrote: > On Thu, Aug 1, 2019 at 3:35 PM Thomas Gleixner wrote: > > > > On Thu, 1 Aug 2019, Aubrey Li wrote: > > > On Thu, Aug 1, 2019 at 2:26 PM Daniel Drake wrote: > > > > global_clock_event is NULL here. This is a "reduced hardware" ACPI > > > > platform so

Re: setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms

2019-08-01 Thread Aubrey Li
On Thu, Aug 1, 2019 at 3:35 PM Thomas Gleixner wrote: > > On Thu, 1 Aug 2019, Aubrey Li wrote: > > On Thu, Aug 1, 2019 at 2:26 PM Daniel Drake wrote: > > > global_clock_event is NULL here. This is a "reduced hardware" ACPI > > > platform so acpi_generic_reduced_hw_init() has set timer_init to

Re: setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms

2019-08-01 Thread Thomas Gleixner
On Thu, 1 Aug 2019, Aubrey Li wrote: > On Thu, Aug 1, 2019 at 2:26 PM Daniel Drake wrote: > > global_clock_event is NULL here. This is a "reduced hardware" ACPI > > platform so acpi_generic_reduced_hw_init() has set timer_init to NULL, > > avoiding the usual codepaths that would set up

Re: setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms

2019-08-01 Thread Thomas Gleixner
Daniel, On Thu, 1 Aug 2019, Daniel Drake wrote: > Working with a new consumer laptop based on AMD R7-3700U, we are > seeing a kernel panic during early boot (before the display > initializes). It's a new product and there is no previous known > working kernel version (tested 5.0, 5.2 and current

Re: setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms

2019-08-01 Thread Aubrey Li
On Thu, Aug 1, 2019 at 2:26 PM Daniel Drake wrote: > > Hi, > > Working with a new consumer laptop based on AMD R7-3700U, we are > seeing a kernel panic during early boot (before the display > initializes). It's a new product and there is no previous known > working kernel version (tested 5.0, 5.2

setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms

2019-08-01 Thread Daniel Drake
Hi, Working with a new consumer laptop based on AMD R7-3700U, we are seeing a kernel panic during early boot (before the display initializes). It's a new product and there is no previous known working kernel version (tested 5.0, 5.2 and current linus master). We may have also seen this problem