lkml.org 
[lkml]   [2000]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.3.43-pre[25] do not work with HIGHMEM=64GB
Christoph Rohland wrote:
>
> Hi Ingo,
>
> Ingo Molnar <mingo@chiara.csoma.elte.hu> writes:
>
> > > I tried plain 2.3.43-pre2 with pagecache in GFP_USER and it came up
> > > but failed later with:
> >
> > > >>EIP; c0114dc8 <smp_invalidate_interrupt+78/a0> <=====
> >
> > ok, this is the TLB-flush bug (hopefully) fixed in pre5-2.3.43. So could
> > you try pre5 with pagecache on GFP_USER?
> >
> > plus i've attached Stephen's fix for a nasty 64GB bug which caused his
> > (and my) kernels to fail similarly. (i'll let it up to Stephen to release
> > the fix publicly)
>
> With Stevens patch 2.3.43-5 works again for me.
>
> But during shm tests I get:
>
> Trace; c022b2cc <call_spurious_interrupt+253b/91b7>
> Trace; c0228d0e <call_invalidate_interrupt+5/b>
> Trace; c011a41b <schedule+40b/b34>

I think they are ok, just over sensitive debugging checks. How many of
them did you get? If the back trace always contains schedule(), and none
of them is before <schedule+0x405>, then we are ok.


CPU0: CPU1:
runs threadA
page stealer, tries to free a page
from threadA
begins to switch from threadA to threadB
reads threadA->cpu_vm_mask.
changes cpu_tlbstate & cr3
*
* I assume that a hardware interrupt arrives here,
* otherwise the race is to tiny.
*
sends the IPI to the cpu_vm_mask
IPI arrives, and prints the stack dump

Ingo, do you agree?

--
Manfred

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

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.035 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site