lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 17 Jul 2014 01:18:36 +0200
From:	Dietmar Eggemann <dietmar.eggemann@....com>
To:	Bruno Wolff III <bruno@...ff.to>
CC:	Josh Boyer <jwboyer@...hat.com>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

On 16/07/14 21:54, Bruno Wolff III wrote:
> On Wed, Jul 16, 2014 at 21:17:32 +0200,
>    Dietmar Eggemann <dietmar.eggemann@....com> wrote:
>> Hi Bruno and Josh,
>>
>>>From the issue, I see that the machine making trouble is an Xeon (2
>> processors w/ hyper-threading).
>>
>> Could you please share:
>>
>> cat /proc/cpuinfo and
>
> I have attached it to the bug and to this message.
>
>> cat /proc/schedstat (kernel config w/ CONFIG_SCHEDSTATS=y)
>
> It looks like that isn't set for my previous builds and I'll need to
> set it for my next test build.
>
>> Could you also put the two BUG_ON lines into build_sched_groups()
>> [kernel/sched/core.c] wo/ the cpumask_clear() and setting
>> sg->sgc->capacity to 0 and share the possible crash output as well?
>
> I can try a new build with this. I can probably get results back tomorrow
> before I leave for work. The crashes happen too early in the boot process
> for me to easily capture output as text. I can slow things down to take
> pictures though.
>

That would be helpful. Thanks. I saw that you have CONFIG_SCHED_DEBUG 
enabled.

So the output of

$ cat /proc/sys/kernel/sched_domain/cpu*/domain*/*

would be handy too.

The difference to the Intel machine I tested on is that yours is a "dual 
single core CPU with hyper-threading' and mine is a 'dual core with 
hyper-threading'

yours:
$ cat cpuinfo.out | grep '^physical\|^core\|^cpu cores'
physical id	: 0
core id		: 0
cpu cores	: 1
physical id	: 3
core id		: 0
cpu cores	: 1
physical id	: 0
core id		: 0
cpu cores	: 1
physical id	: 3
core id		: 0
cpu cores	: 1

mine:
$ cat /proc/cpuinfo | grep '^physical\|^core\|^cpu cores'
physical id	: 0
core id		: 0
cpu cores	: 2
physical id	: 0
core id		: 0
cpu cores	: 2
physical id	: 0
core id		: 1
cpu cores	: 2
physical id	: 0
core id		: 1
cpu cores	: 2

Just to make sure, you do have 'CONFIG_X86_32=y' and '# CONFIG_NUMA is 
not set' in your build?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ