[Top] [All Lists]

Re: system lockup with 2.6.29 on Cavium/Octeon

Subject: Re: system lockup with 2.6.29 on Cavium/Octeon
From: Atsushi Nemoto <>
Date: Thu, 21 May 2009 23:50:20 +0900 (JST)
In-reply-to: <>
Original-recipient: rfc822;
References: <> <>
On Wed, 20 May 2009 15:26:04 +0100, Ralf Baechle <> wrote:
> > Now the vmalloc area starts at 0xc000000000000000 and the kernel code
> > and data is all at 0xffffffff80000000 and above. I don't know if the
> > start and end are reasonable values, but I can see some logic as to
> > where they come from. The code path that leads to this is via
> > __vunmap() and __purge_vmap_area_lazy(). So it is not too difficult
> > to see how we end up with values like this.
> Either start or end address is sensible but not the combination - both
> addresses should be in the same segment.  Start is in XKSEG, end in CKSEG2
> and in between there are vast wastelands of unused address space exabytes
> in size.
> > But the size calculation above with these types of values will result
> > in still a large number. Larger than the 32bit "int" that is "size".
> > I see large negative values fall out as size, and so the following
> > tlbsize check becomes true, and the code spins inside the loop inside
> > that if statement for a _very_ long time trying to flush tlb entries.
> >
> > This is of course easily fixed, by making that size "unsigned long".
> > The patch below trivially does this.
> >
> > But is this analysis correct?
> Yes - but I think we have two issues here.  The one is the calculation
> overflowing int for the arguments you're seeing.  The other being that
> the arguments simply are looking wrong.

The wrong combination comes from lazy vunmapping which was introduced
in 2.6.28 cycle.  Maybe we can add new API (non-lazy version of
vfree()) to vmalloc.c to implement module_free(), but I suppose
fallbacking to local_flush_tlb_all() in local_flush_tlb_kernel_range()
is enough().

Atsushi Nemoto

<Prev in Thread] Current Thread [Next in Thread>