Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-11-03 Thread M. Vefa Bicakci
On 11/02/2016 08:23 PM, Sebastian Andrzej Siewior wrote: > On 2016-11-01 13:15:53 [+0300], M. Vefa Bicakci wrote: >> Hello Sebastian, > > Hi, > >> The patch fixes the kernel oops for me. >> >> I am using a custom 4.8.5-based kernel on Qubes OS R3.2, which is based >> on Xen 4.6.3. Apparently, Xen

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-11-03 Thread M. Vefa Bicakci
On 11/02/2016 08:23 PM, Sebastian Andrzej Siewior wrote: > On 2016-11-01 13:15:53 [+0300], M. Vefa Bicakci wrote: >> Hello Sebastian, > > Hi, > >> The patch fixes the kernel oops for me. >> >> I am using a custom 4.8.5-based kernel on Qubes OS R3.2, which is based >> on Xen 4.6.3. Apparently, Xen

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-11-02 Thread Sebastian Andrzej Siewior
On 2016-11-01 13:15:53 [+0300], M. Vefa Bicakci wrote: > Hello Sebastian, Hi, > The patch fixes the kernel oops for me. > > I am using a custom 4.8.5-based kernel on Qubes OS R3.2, which is based > on Xen 4.6.3. Apparently, Xen also has a similar bug/flaw/quirk regarding > the allocation of

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-11-02 Thread Sebastian Andrzej Siewior
On 2016-11-01 13:15:53 [+0300], M. Vefa Bicakci wrote: > Hello Sebastian, Hi, > The patch fixes the kernel oops for me. > > I am using a custom 4.8.5-based kernel on Qubes OS R3.2, which is based > on Xen 4.6.3. Apparently, Xen also has a similar bug/flaw/quirk regarding > the allocation of

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-11-02 Thread Sebastian Andrzej Siewior
On 2016-11-02 05:16:03 [-0400], Charles (Chas) Williams wrote: > Yes, it does prevent RAPL from starting and loading. From the boot log: please send the whole bootlog. offlist if you want. Sebastian

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-11-02 Thread Sebastian Andrzej Siewior
On 2016-11-02 05:16:03 [-0400], Charles (Chas) Williams wrote: > Yes, it does prevent RAPL from starting and loading. From the boot log: please send the whole bootlog. offlist if you want. Sebastian

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-11-02 Thread Charles (Chas) Williams
On 10/28/2016 04:03 AM, Sebastian Andrzej Siewior wrote: On 2016-10-27 15:00:32 [-0400], Charles (Chas) Williams wrote: I assume "init_rapl_pmus: maxpkg 4" is from init_rapl_pmus() returning topology_max_packages(). So it says 4 but then returns 65535 for CPU 2 and 3. That -1 comes probably

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-11-02 Thread Charles (Chas) Williams
On 10/28/2016 04:03 AM, Sebastian Andrzej Siewior wrote: On 2016-10-27 15:00:32 [-0400], Charles (Chas) Williams wrote: I assume "init_rapl_pmus: maxpkg 4" is from init_rapl_pmus() returning topology_max_packages(). So it says 4 but then returns 65535 for CPU 2 and 3. That -1 comes probably

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-11-01 Thread M. Vefa Bicakci
> On 2016-10-27 15:00:32 [-0400], Charles (Chas) Williams wrote: >> >> [snip] >> >> But sometimes the topology info is correct and if I get lucky, the >> package id could be valid for all the CPU's. Given the behavior, >> I have seen so far it makes me thing the RAPL isn't being emulated. >> So

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-11-01 Thread M. Vefa Bicakci
> On 2016-10-27 15:00:32 [-0400], Charles (Chas) Williams wrote: >> >> [snip] >> >> But sometimes the topology info is correct and if I get lucky, the >> package id could be valid for all the CPU's. Given the behavior, >> I have seen so far it makes me thing the RAPL isn't being emulated. >> So

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-10-28 Thread Sebastian Andrzej Siewior
On 2016-10-27 15:00:32 [-0400], Charles (Chas) Williams wrote: > > I assume "init_rapl_pmus: maxpkg 4" is from init_rapl_pmus() returning > > topology_max_packages(). So it says 4 but then returns 65535 for CPU 2 > > and 3. That -1 comes probably from topology_update_package_map(). Could > > you

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-10-28 Thread Sebastian Andrzej Siewior
On 2016-10-27 15:00:32 [-0400], Charles (Chas) Williams wrote: > > I assume "init_rapl_pmus: maxpkg 4" is from init_rapl_pmus() returning > > topology_max_packages(). So it says 4 but then returns 65535 for CPU 2 > > and 3. That -1 comes probably from topology_update_package_map(). Could > > you

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-10-27 Thread Charles (Chas) Williams
On 10/25/2016 08:22 AM, Sebastian Andrzej Siewior wrote: On 2016-10-21 17:03:56 [-0400], Charles (Chas) Williams wrote: [3.107126] init_rapl_pmus: maxpkg 4 there! vmware bug. It probably worked by chance. Yes, the behavior is a bit random. I assume "init_rapl_pmus: maxpkg 4" is

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-10-27 Thread Charles (Chas) Williams
On 10/25/2016 08:22 AM, Sebastian Andrzej Siewior wrote: On 2016-10-21 17:03:56 [-0400], Charles (Chas) Williams wrote: [3.107126] init_rapl_pmus: maxpkg 4 there! vmware bug. It probably worked by chance. Yes, the behavior is a bit random. I assume "init_rapl_pmus: maxpkg 4" is

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-10-25 Thread Sebastian Andrzej Siewior
On 2016-10-25 14:22:05 [+0200], To Charles (Chas) Williams wrote: > > [3.107263] rapl_cpu_prepare: pmu 880234faa540 cpu 0 pkgid 0 > > [3.107400] rapl_cpu_prepare: pmu 880234faa600 cpu 1 pkgid 2 > > [3.107537] rapl_cpu_prepare: pmu 880234faa6c0 cpu 2 pkgid

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-10-25 Thread Sebastian Andrzej Siewior
On 2016-10-25 14:22:05 [+0200], To Charles (Chas) Williams wrote: > > [3.107263] rapl_cpu_prepare: pmu 880234faa540 cpu 0 pkgid 0 > > [3.107400] rapl_cpu_prepare: pmu 880234faa600 cpu 1 pkgid 2 > > [3.107537] rapl_cpu_prepare: pmu 880234faa6c0 cpu 2 pkgid

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-10-25 Thread Sebastian Andrzej Siewior
On 2016-10-21 17:03:56 [-0400], Charles (Chas) Williams wrote: > I can't get dedicated access to the specific bare metal since it is > running as a dedicated hypervisor. I haven't seen this issue anywhere > else though with the 4.8 kernel. That is something :) > > If a callback (such as

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-10-25 Thread Sebastian Andrzej Siewior
On 2016-10-21 17:03:56 [-0400], Charles (Chas) Williams wrote: > I can't get dedicated access to the specific bare metal since it is > running as a dedicated hypervisor. I haven't seen this issue anywhere > else though with the 4.8 kernel. That is something :) > > If a callback (such as

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-10-21 Thread Charles (Chas) Williams
On 10/21/2016 06:56 AM, Sebastian Andrzej Siewior wrote: On 2016-10-20 16:27:55 [-0400], Charles (Chas) Williams wrote: Recent 4.8 kernels have been oopsing when running under VMWare: can you reproduce this on bare metal? I can't get dedicated access to the specific bare metal since it is

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-10-21 Thread Charles (Chas) Williams
On 10/21/2016 06:56 AM, Sebastian Andrzej Siewior wrote: On 2016-10-20 16:27:55 [-0400], Charles (Chas) Williams wrote: Recent 4.8 kernels have been oopsing when running under VMWare: can you reproduce this on bare metal? I can't get dedicated access to the specific bare metal since it is

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-10-21 Thread Sebastian Andrzej Siewior
On 2016-10-20 16:27:55 [-0400], Charles (Chas) Williams wrote: > Recent 4.8 kernels have been oopsing when running under VMWare: can you reproduce this on bare metal? > [2.270203] BUG: unable to handle kernel NULL pointer dereference at > 0408 > [2.270325] IP: []

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

2016-10-21 Thread Sebastian Andrzej Siewior
On 2016-10-20 16:27:55 [-0400], Charles (Chas) Williams wrote: > Recent 4.8 kernels have been oopsing when running under VMWare: can you reproduce this on bare metal? > [2.270203] BUG: unable to handle kernel NULL pointer dereference at > 0408 > [2.270325] IP: []