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
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 packa
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
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 from
> 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 ev
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 pl
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
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
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 CPUHP_PE
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
ru
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: [] rapl_cpu_onl
11 matches
Mail list logo