On 11/10/2016 09:02 AM, Boris Ostrovsky wrote:
On 11/10/2016 06:13 AM, Thomas Gleixner wrote:
On Thu, 10 Nov 2016, M. Vefa Bicakci wrote:
I have found that your patch unfortunately does not improve the situation
for me. Here is an excerpt obtained from the dmesg of a kernel compiled
with thi
On 11/09/2016 10:57 PM, M. Vefa Bicakci wrote:
[0.002000] mvb: CPU: Physical Processor ID: 0
[0.002000] mvb: CPU: Processor Core ID: 0
[0.002000] mvb: identify_cpu:1112: c: 880013b0a040, c->logical_proc_id:
65535
[0.002000] mvb: __default_cpu_present_to_apicid:612: Returnin
logical package map just works.
Reported-by: "Charles (Chas) Williams" ,
Reported-by: M. Vefa Bicakci
Signed-off-by: Thomas Gleixner
For 4 virtual sockets, 1 core per socket VM:
[0.235459] node #0, CPUs: #1
[0.238579] Disabled fast string operations
[0.238620
On 11/09/2016 11:03 AM, Peter Zijlstra wrote:
On Wed, Nov 09, 2016 at 04:35:51PM +0100, Thomas Gleixner wrote:
Both ACPI and MP specifications require that the APIC id in the respective
tables must be the same as the APIC id in CPUID.
The kernel retrieves the physical package id from the APIC
On 11/08/2016 09:31 AM, Thomas Gleixner wrote:
On Tue, 8 Nov 2016, Charles (Chas) Williams wrote:
[0.016335] topology_update_package_map: apicid 0 pkg 0 cpu 0
[0.016398] smpboot: APIC(0) Converting physical 0 to logical
package 0, cpu 0 (88023fc0a040
On 11/07/2016 03:20 PM, Thomas Gleixner wrote:
On Mon, 7 Nov 2016, Charles (Chas) Williams wrote:
On 11/07/2016 11:19 AM, Thomas Gleixner wrote:
On Wed, 2 Nov 2016, Charles (Chas) Williams wrote:
I don't know why the CPU's phys_proc_id is 2.
max_physical_pkg_id gets initi
On 11/07/2016 11:19 AM, Thomas Gleixner wrote:
On Wed, 2 Nov 2016, Charles (Chas) Williams wrote:
On 11/02/2016 08:25 AM, Sebastian Andrzej Siewior wrote:
I am not sure if this a race with the new hotplug code or something that was
always there. Both (M. Vefa Bicakc and Charles) say that the
On 11/04/2016 02:03 PM, Sebastian Andrzej Siewior wrote:
On 2016-11-04 08:20:37 [-0400], Charles (Chas) Williams wrote:
The initial CPU boots and is identified:
[0.009018] identify_boot_cpu
[0.009174] generic_identify: phys_proc_id is now 0
...
[0.009427] identify_cpu: before c
On 11/03/2016 01:47 PM, Sebastian Andrzej Siewior wrote:
On 2016-11-02 18:47:49 [-0400], Charles (Chas) Williams wrote:
I don't this this is a race. Here is some debugging from the two CPU VM
(2 sockets, 1 core per socket). In identify_cpu() we have:
/* The boot/hotplug
On 11/02/2016 08:25 AM, Sebastian Andrzej Siewior wrote:
I am not sure if this a race with the new hotplug code or something that was
always there. Both (M. Vefa Bicakc and Charles) say that the box boots
sometimes fine (without the patch). smp_store_boot_cpu_info() should have run
before the no
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 come
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
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
Recent 4.8 kernels have been oopsing when running under VMWare:
[2.270203] BUG: unable to handle kernel NULL pointer dereference at
0408
[2.270325] IP: [] rapl_cpu_online+0x59/0x70
[2.270448] PGD 0
[2.270570] Oops: 0002 [#1] SMP
[2.270693] Modules linked in:
[
On Thu, 2015-12-03 at 13:58 +0100, LABBE Corentin wrote:
> On Thu, Dec 03, 2015 at 06:26:31AM -0500, Charles (Chas) Williams wrote:
> > On Thu, 2015-12-03 at 09:06 +0100, LABBE Corentin wrote:
> > > @@ -357,11 +357,11 @@ static int process_status(struct solos_card *card,
>
On Thu, 2015-12-03 at 09:06 +0100, LABBE Corentin wrote:
> @@ -357,11 +357,11 @@ static int process_status(struct solos_card *card, int
> port, struct sk_buff *skb
> if (!str)
> return -EIO;
>
> - ver = simple_strtol(str, NULL, 10);
> - if (ver < 1) {
> + err = ks
On Sat, 2015-10-10 at 21:47 +0200, Tillmann Heidsieck wrote:
> this series fixes two of them. The if(); warning would require
> restructuring the code to a larger extend. Beyond this there remains a
> whooping number of > 2k checkpatch.pl warnings and errors each. Those
> can be grouped into
...
>
On Wed, 2015-09-30 at 13:26 +0200, Arnd Bergmann wrote:
> The zatm_t_hist structure is not used anywhere in the kernel, but is
> exported to user space. As we are trying to eliminate uses of time_t
> in the kernel for y2038 compatibility, the current definition triggers
> checking tools because it
On Fri, 2015-05-15 at 15:02 +, David Laight wrote:
> From: Jason A. Donenfeld
> > Sent: 13 May 2015 19:34
> > Since elt->length is a u8, we can make this variable a u8. Then we can
> > do proper bounds checking more easily. Without this, a potentially
> > negative value is passed to the memcpy
19 matches
Mail list logo
