On Tue, 2009-11-10 at 01:34 +0100, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
[Patch is now also available in 'for-upstream']
ipipe_test_pipeline_from is not atomic /wrt reading the current cpu
number (or an offset for the per-cpu area) and actually reading the
virtualized interrupt
Philippe Gerum wrote:
On Tue, 2009-11-10 at 01:34 +0100, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
[Patch is now also available in 'for-upstream']
ipipe_test_pipeline_from is not atomic /wrt reading the current cpu
number (or an offset for the per-cpu area) and actually reading the
On Tue, 2009-11-10 at 11:43 +0100, Jan Kiszka wrote:
Philippe Gerum wrote:
On Tue, 2009-11-10 at 01:34 +0100, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
[Patch is now also available in 'for-upstream']
ipipe_test_pipeline_from is not atomic /wrt reading the current cpu
number (or an
Philippe Gerum wrote:
On Tue, 2009-11-10 at 12:33 +0100, Jan Kiszka wrote:
Philippe Gerum wrote:
On Tue, 2009-11-10 at 11:43 +0100, Jan Kiszka wrote:
[...]
Oh, *_hw_smp is new, isn't it? Do we need to wrap it for older I-pipes?
Yes, it was introduced to solve the SMP migration issue
[Patch is now also available in 'for-upstream']
ipipe_test_pipeline_from is not atomic /wrt reading the current cpu
number (or an offset for the per-cpu area) and actually reading the
virtualized interrupt state. Work around this by disabling hard IRQs
while accessing this service.
This fixes
Jan Kiszka wrote:
[Patch is now also available in 'for-upstream']
ipipe_test_pipeline_from is not atomic /wrt reading the current cpu
number (or an offset for the per-cpu area) and actually reading the
virtualized interrupt state. Work around this by disabling hard IRQs
while accessing this
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
[Patch is now also available in 'for-upstream']
ipipe_test_pipeline_from is not atomic /wrt reading the current cpu
number (or an offset for the per-cpu area) and actually reading the
virtualized interrupt state. Work around this by disabling