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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Wed, 11 Nov 2009 17:34:23 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Soeren Sandmann <sandmann@...mi.au.dk>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, tglx@...utronix.de,
	acme@...hat.com, rosted@...dmis.org, paulus@...ba.org
Subject: Re: Hard lockup with timer events

On Wed, Nov 11, 2009 at 02:23:01PM +0100, Peter Zijlstra wrote:
> On Wed, 2009-11-11 at 05:50 +0100, Frederic Weisbecker wrote:
> > On Thu, Oct 29, 2009 at 08:15:03PM +0100, Soeren Sandmann wrote:
> > > Hi,
> > > 
> > > This program
> > > 
> > >         http://www.daimi.au.dk/~sandmann/lockup.c
> > > 
> > > locks up hard for me on a Pentium 4 in 32 bit mode, with the hrtimer
> > > patches applied (-tip for example).
> > > 
> > > What the program does is spawn a thread that just spins, and then 400
> > > threads that each create a performance counter of type
> > > PERF_COUNT_SW_CPU_CLOCK and a sample period of 1000000 and a
> > > sample_type of
> > > 
> > >         PERF_SAMPLE_IP | PERF_SAMPLE_TID | PERF_SAMPLE_CALLCHAIN
> > > 
> > > These threads then map the event buffer and read it continuously.
> > > 
> > > It does not apparently lock up if SAMPLE_CALLCHAIN is removed; also I
> > > cannot get it to lock up on Core 2 Duo in either 32 or 64 bit mode.
> > > 
> > > 
> > > Soren
> > 
> > 
> > 
> > It locks up hard for me too, no more blinking cursor, nothing.
> > I've attached my config, it's against tip:master from yesterday.
> 
> What kind of cpu does your laptop have? The .config seems to suggest a
> Core2. Which would make Soeren's report of not being able to trash a
> 64bit core2 'interesting' ;-)


Nop it's a Pentium Dual Core :)

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Pentium(R) Dual  CPU  T2310  @ 1.46GHz
stepping	: 13
cpu MHz		: 800.000
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr 
sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl 
est tm2 ssse3 cx16 xtpr pdcm lahf_lm
bogomips	: 2925.95
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

--
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