On Thu, 17 Mar 2016, Jens Axboe wrote:
> On 03/17/2016 09:42 AM, Jens Axboe wrote:
> > On 03/17/2016 05:01 AM, Thomas Gleixner wrote:
> > > On Thu, 17 Mar 2016, Peter Zijlstra wrote:
> > > > On Thu, Mar 17, 2016 at 12:39:46PM +0100, Thomas Gleixner wrote:
> > > > > But we have to clarify and
On Thu, 17 Mar 2016, Jens Axboe wrote:
> On 03/17/2016 09:42 AM, Jens Axboe wrote:
> > On 03/17/2016 05:01 AM, Thomas Gleixner wrote:
> > > On Thu, 17 Mar 2016, Peter Zijlstra wrote:
> > > > On Thu, Mar 17, 2016 at 12:39:46PM +0100, Thomas Gleixner wrote:
> > > > > But we have to clarify and
On Thu, 17 Mar 2016, Jens Axboe wrote:
> On 03/17/2016 01:20 PM, Thomas Gleixner wrote:
> > > This might be better, we need to start at -1 to not miss the first one...
> > > Still untested.
> >
> > > +static inline struct blk_mq_ctx *next_ctx(struct request_queue *q, int
> > > *i)
> > > +{
> > >
On Thu, 17 Mar 2016, Jens Axboe wrote:
> On 03/17/2016 01:20 PM, Thomas Gleixner wrote:
> > > This might be better, we need to start at -1 to not miss the first one...
> > > Still untested.
> >
> > > +static inline struct blk_mq_ctx *next_ctx(struct request_queue *q, int
> > > *i)
> > > +{
> > >
On 03/17/2016 01:20 PM, Thomas Gleixner wrote:
On Thu, 17 Mar 2016, Jens Axboe wrote:
On 03/17/2016 09:42 AM, Jens Axboe wrote:
On 03/17/2016 05:01 AM, Thomas Gleixner wrote:
On Thu, 17 Mar 2016, Peter Zijlstra wrote:
On Thu, Mar 17, 2016 at 12:39:46PM +0100, Thomas Gleixner wrote:
But we
On 03/17/2016 01:20 PM, Thomas Gleixner wrote:
On Thu, 17 Mar 2016, Jens Axboe wrote:
On 03/17/2016 09:42 AM, Jens Axboe wrote:
On 03/17/2016 05:01 AM, Thomas Gleixner wrote:
On Thu, 17 Mar 2016, Peter Zijlstra wrote:
On Thu, Mar 17, 2016 at 12:39:46PM +0100, Thomas Gleixner wrote:
But we
On Fri, 2016-03-18 at 12:55 +0100, Thomas Gleixner wrote:
> Does the patch below fix the wreckage?
Yup, all better.
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 643dbdccf4bc..c5ac71276076 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
On Fri, 2016-03-18 at 12:55 +0100, Thomas Gleixner wrote:
> Does the patch below fix the wreckage?
Yup, all better.
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 643dbdccf4bc..c5ac71276076 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
On Thu, Mar 17, 2016 at 10:52:20AM +0100, Peter Zijlstra wrote:
> Mar 17 17:34:30 myhost kernel: smpboot: CPU0: AMD Opteron(TM) Processor 6274
> (family: 0x15, model: 0x1, stepping: 0x2)
> Mar 17 17:34:30 myhost kernel: Performance Events: Fam15h core perfctr,
> Broken BIOS detected, complain to
On Thu, Mar 17, 2016 at 10:52:20AM +0100, Peter Zijlstra wrote:
> Mar 17 17:34:30 myhost kernel: smpboot: CPU0: AMD Opteron(TM) Processor 6274
> (family: 0x15, model: 0x1, stepping: 0x2)
> Mar 17 17:34:30 myhost kernel: Performance Events: Fam15h core perfctr,
> Broken BIOS detected, complain to
On Fri, Mar 18, 2016 at 05:11:54AM +0100, Mike Galbraith wrote:
> On Thu, 2016-03-17 at 10:52 +0100, Peter Zijlstra wrote:
>
> > Andreas; Borislav said to Cc you since you wrote all this.
> > The issue is that Linux assumes:
> >
> > > nr_logical_cpus = nr_cores * nr_siblings
>
> It also
On Fri, Mar 18, 2016 at 05:11:54AM +0100, Mike Galbraith wrote:
> On Thu, 2016-03-17 at 10:52 +0100, Peter Zijlstra wrote:
>
> > Andreas; Borislav said to Cc you since you wrote all this.
> > The issue is that Linux assumes:
> >
> > > nr_logical_cpus = nr_cores * nr_siblings
>
> It also
On Thu, Mar 17, 2016 at 09:56:05AM +0800, Xiong Zhou wrote:
> On Wed, Mar 16, 2016 at 11:26 PM, Thomas Gleixner wrote:
> > Can you please provide a full boot log and the output of 'cat
> > /proc/cpuinfo' ?
Mar 17 17:34:30 myhost kernel: smpboot: Max logical packages: 1
Mar
On Thu, Mar 17, 2016 at 09:56:05AM +0800, Xiong Zhou wrote:
> On Wed, Mar 16, 2016 at 11:26 PM, Thomas Gleixner wrote:
> > Can you please provide a full boot log and the output of 'cat
> > /proc/cpuinfo' ?
Mar 17 17:34:30 myhost kernel: smpboot: Max logical packages: 1
Mar 17 17:34:30 myhost
On Thu, Mar 17, 2016 at 12:39:46PM +0100, Thomas Gleixner wrote:
> But we have to clarify and document whether holes in cpu_possible_mask are not
> allowed at all or if code like the above is simply broken.
So the general rule is that cpumasks can have holes, and exempting one
just muddles the
On Thu, Mar 17, 2016 at 12:39:46PM +0100, Thomas Gleixner wrote:
> But we have to clarify and document whether holes in cpu_possible_mask are not
> allowed at all or if code like the above is simply broken.
So the general rule is that cpumasks can have holes, and exempting one
just muddles the
On 03/17/2016 01:30 PM, Thomas Gleixner wrote:
On Thu, 17 Mar 2016, Jens Axboe wrote:
On 03/17/2016 01:20 PM, Thomas Gleixner wrote:
This might be better, we need to start at -1 to not miss the first one...
Still untested.
+static inline struct blk_mq_ctx *next_ctx(struct request_queue *q,
On 03/17/2016 01:30 PM, Thomas Gleixner wrote:
On Thu, 17 Mar 2016, Jens Axboe wrote:
On 03/17/2016 01:20 PM, Thomas Gleixner wrote:
This might be better, we need to start at -1 to not miss the first one...
Still untested.
+static inline struct blk_mq_ctx *next_ctx(struct request_queue *q,
On Thu, 17 Mar 2016, Peter Zijlstra wrote:
> On Thu, Mar 17, 2016 at 12:39:46PM +0100, Thomas Gleixner wrote:
> > But we have to clarify and document whether holes in cpu_possible_mask are
> > not
> > allowed at all or if code like the above is simply broken.
>
> So the general rule is that
On Thu, 17 Mar 2016, Peter Zijlstra wrote:
> On Thu, Mar 17, 2016 at 12:39:46PM +0100, Thomas Gleixner wrote:
> > But we have to clarify and document whether holes in cpu_possible_mask are
> > not
> > allowed at all or if code like the above is simply broken.
>
> So the general rule is that
Hi,
On Thu, Mar 17, 2016 at 7:39 PM, Thomas Gleixner wrote:
> B1;2802;0cOn Thu, 17 Mar 2016, Peter Zijlstra wrote:
>
>> On Thu, Mar 17, 2016 at 11:21:24AM +0100, Thomas Gleixner wrote:
>> > On Thu, 17 Mar 2016, Peter Zijlstra wrote:
>> >
>> > > Could you please try? I'm not
Hi,
On Thu, Mar 17, 2016 at 7:39 PM, Thomas Gleixner wrote:
> B1;2802;0cOn Thu, 17 Mar 2016, Peter Zijlstra wrote:
>
>> On Thu, Mar 17, 2016 at 11:21:24AM +0100, Thomas Gleixner wrote:
>> > On Thu, 17 Mar 2016, Peter Zijlstra wrote:
>> >
>> > > Could you please try? I'm not sure how this would
B1;2802;0cOn Thu, 17 Mar 2016, Peter Zijlstra wrote:
> On Thu, Mar 17, 2016 at 11:21:24AM +0100, Thomas Gleixner wrote:
> > On Thu, 17 Mar 2016, Peter Zijlstra wrote:
> >
> > > Could you please try? I'm not sure how this would explain your loop
> > > device bug fail, but it certainly pointed
B1;2802;0cOn Thu, 17 Mar 2016, Peter Zijlstra wrote:
> On Thu, Mar 17, 2016 at 11:21:24AM +0100, Thomas Gleixner wrote:
> > On Thu, 17 Mar 2016, Peter Zijlstra wrote:
> >
> > > Could you please try? I'm not sure how this would explain your loop
> > > device bug fail, but it certainly pointed
On Fri, 2016-03-18 at 14:32 +0100, Peter Zijlstra wrote:
> On Fri, Mar 18, 2016 at 01:39:16PM +0100, Mike Galbraith wrote:
> > On Fri, 2016-03-18 at 11:15 +0100, Peter Zijlstra wrote:
>
> > > Ah, did you actually disable HT in the BIOS, or just skip the HT
> > > enumeration by saying nr_cpus=64
On Fri, 2016-03-18 at 14:32 +0100, Peter Zijlstra wrote:
> On Fri, Mar 18, 2016 at 01:39:16PM +0100, Mike Galbraith wrote:
> > On Fri, 2016-03-18 at 11:15 +0100, Peter Zijlstra wrote:
>
> > > Ah, did you actually disable HT in the BIOS, or just skip the HT
> > > enumeration by saying nr_cpus=64
On Wed, 16 Mar 2016, Xiong Zhou wrote:
> full log , bisect log and config are attached.
Can you please provide a full boot log and the output of 'cat /proc/cpuinfo' ?
Thanks,
tglx
On Wed, 16 Mar 2016, Xiong Zhou wrote:
> full log , bisect log and config are attached.
Can you please provide a full boot log and the output of 'cat /proc/cpuinfo' ?
Thanks,
tglx
On Thu, Mar 17, 2016 at 12:51:20PM +0100, Peter Zijlstra wrote:
> On Thu, Mar 17, 2016 at 12:39:46PM +0100, Thomas Gleixner wrote:
> > But we have to clarify and document whether holes in cpu_possible_mask are
> > not
> > allowed at all or if code like the above is simply broken.
>
> So the
On Thu, Mar 17, 2016 at 12:51:20PM +0100, Peter Zijlstra wrote:
> On Thu, Mar 17, 2016 at 12:39:46PM +0100, Thomas Gleixner wrote:
> > But we have to clarify and document whether holes in cpu_possible_mask are
> > not
> > allowed at all or if code like the above is simply broken.
>
> So the
On Fri, Mar 18, 2016 at 01:39:16PM +0100, Mike Galbraith wrote:
> On Fri, 2016-03-18 at 11:15 +0100, Peter Zijlstra wrote:
> > Ah, did you actually disable HT in the BIOS, or just skip the HT
> > enumeration by saying nr_cpus=64 (knowing that all the siblings are
> > last)?
>
> It's disabled in
On Fri, Mar 18, 2016 at 01:39:16PM +0100, Mike Galbraith wrote:
> On Fri, 2016-03-18 at 11:15 +0100, Peter Zijlstra wrote:
> > Ah, did you actually disable HT in the BIOS, or just skip the HT
> > enumeration by saying nr_cpus=64 (knowing that all the siblings are
> > last)?
>
> It's disabled in
On 03/17/2016 05:01 AM, Thomas Gleixner wrote:
On Thu, 17 Mar 2016, Peter Zijlstra wrote:
On Thu, Mar 17, 2016 at 12:39:46PM +0100, Thomas Gleixner wrote:
But we have to clarify and document whether holes in cpu_possible_mask are not
allowed at all or if code like the above is simply broken.
On 03/17/2016 05:01 AM, Thomas Gleixner wrote:
On Thu, 17 Mar 2016, Peter Zijlstra wrote:
On Thu, Mar 17, 2016 at 12:39:46PM +0100, Thomas Gleixner wrote:
But we have to clarify and document whether holes in cpu_possible_mask are not
allowed at all or if code like the above is simply broken.
On Fri, Mar 18, 2016 at 05:11:54AM +0100, Mike Galbraith wrote:
> On Thu, 2016-03-17 at 10:52 +0100, Peter Zijlstra wrote:
>
> > Andreas; Borislav said to Cc you since you wrote all this.
> > The issue is that Linux assumes:
> >
> > > nr_logical_cpus = nr_cores * nr_siblings
>
> It also
On Fri, Mar 18, 2016 at 05:11:54AM +0100, Mike Galbraith wrote:
> On Thu, 2016-03-17 at 10:52 +0100, Peter Zijlstra wrote:
>
> > Andreas; Borislav said to Cc you since you wrote all this.
> > The issue is that Linux assumes:
> >
> > > nr_logical_cpus = nr_cores * nr_siblings
>
> It also
On 03/17/2016 09:42 AM, Jens Axboe wrote:
On 03/17/2016 05:01 AM, Thomas Gleixner wrote:
On Thu, 17 Mar 2016, Peter Zijlstra wrote:
On Thu, Mar 17, 2016 at 12:39:46PM +0100, Thomas Gleixner wrote:
But we have to clarify and document whether holes in
cpu_possible_mask are not
allowed at all or
On 03/17/2016 09:42 AM, Jens Axboe wrote:
On 03/17/2016 05:01 AM, Thomas Gleixner wrote:
On Thu, 17 Mar 2016, Peter Zijlstra wrote:
On Thu, Mar 17, 2016 at 12:39:46PM +0100, Thomas Gleixner wrote:
But we have to clarify and document whether holes in
cpu_possible_mask are not
allowed at all or
On Thu, 17 Mar 2016, Peter Zijlstra wrote:
> Could you please try? I'm not sure how this would explain your loop
> device bug fail, but it certainly pointed towards broken.
It definitely does not explain it. The wreckage that topo stuff causes is that
it disables a cpu, but that really is not a
On Thu, 17 Mar 2016, Peter Zijlstra wrote:
> Could you please try? I'm not sure how this would explain your loop
> device bug fail, but it certainly pointed towards broken.
It definitely does not explain it. The wreckage that topo stuff causes is that
it disables a cpu, but that really is not a
On Fri, 2016-03-18 at 11:15 +0100, Peter Zijlstra wrote:
> On Fri, Mar 18, 2016 at 05:11:54AM +0100, Mike Galbraith wrote:
> > On Thu, 2016-03-17 at 10:52 +0100, Peter Zijlstra wrote:
> >
> > > Andreas; Borislav said to Cc you since you wrote all this.
> > > The issue is that Linux assumes:
> > >
On Fri, 2016-03-18 at 11:15 +0100, Peter Zijlstra wrote:
> On Fri, Mar 18, 2016 at 05:11:54AM +0100, Mike Galbraith wrote:
> > On Thu, 2016-03-17 at 10:52 +0100, Peter Zijlstra wrote:
> >
> > > Andreas; Borislav said to Cc you since you wrote all this.
> > > The issue is that Linux assumes:
> > >
On Fri, 18 Mar 2016, Mike Galbraith wrote:
> On Thu, 2016-03-17 at 10:52 +0100, Peter Zijlstra wrote:
>
> > Andreas; Borislav said to Cc you since you wrote all this.
> > The issue is that Linux assumes:
> >
> > > nr_logical_cpus = nr_cores * nr_siblings
>
> It also seems to now assume that
On Fri, 18 Mar 2016, Mike Galbraith wrote:
> On Thu, 2016-03-17 at 10:52 +0100, Peter Zijlstra wrote:
>
> > Andreas; Borislav said to Cc you since you wrote all this.
> > The issue is that Linux assumes:
> >
> > > nr_logical_cpus = nr_cores * nr_siblings
>
> It also seems to now assume that
On Thu, 2016-03-17 at 10:52 +0100, Peter Zijlstra wrote:
> Andreas; Borislav said to Cc you since you wrote all this.
> The issue is that Linux assumes:
>
> > nr_logical_cpus = nr_cores * nr_siblings
It also seems to now assume that if SMT is possible, it's enabled.
Below is my 8 socket
On Thu, 2016-03-17 at 10:52 +0100, Peter Zijlstra wrote:
> Andreas; Borislav said to Cc you since you wrote all this.
> The issue is that Linux assumes:
>
> > nr_logical_cpus = nr_cores * nr_siblings
It also seems to now assume that if SMT is possible, it's enabled.
Below is my 8 socket
On Thu, Mar 17, 2016 at 11:21:24AM +0100, Thomas Gleixner wrote:
> On Thu, 17 Mar 2016, Peter Zijlstra wrote:
>
> > Could you please try? I'm not sure how this would explain your loop
> > device bug fail, but it certainly pointed towards broken.
>
> It definitely does not explain it. The
On Thu, Mar 17, 2016 at 11:21:24AM +0100, Thomas Gleixner wrote:
> On Thu, 17 Mar 2016, Peter Zijlstra wrote:
>
> > Could you please try? I'm not sure how this would explain your loop
> > device bug fail, but it certainly pointed towards broken.
>
> It definitely does not explain it. The
48 matches
Mail list logo