On Fri, Jan 29, 2010 at 09:05:41PM -0500, Ralf Baechle wrote: > On Fri, Jan 29, 2010 at 10:21:19AM -0800, Guenter Roeck wrote: > > > On Fri, Jan 29, 2010 at 01:06:20PM -0500, Ralf Baechle wrote: > > > On Fri, Jan 29, 2010 at 09:11:46AM -0800, David Daney wrote: > > > > > > > >So first question would be: Has anyone successfully loaded a 64 > > > > >bit mips kernel with 2.6.32 and a page size of 16k or 64k ? This > > > > >would at least help me reducing the problem to sb1. > > > > > > > > Yes, I routinely run with both 64K and 16K page sizes on 2.6.32 and > > > > 2.6.33-rc*. I have not seen any crashes that can not be easily > > > > explained. > > > > > > I can reproduce it with today's 14b7baff3eb4b1b46a592630e6f85ded9264798a. > > > 4K page size works ok, 16K without IPv6 works ok and 16K with IPv6 crashes. > > > Note, I was testing with a non-16K capable userland so ok means userland is > > > reached. > > > > > Yes, I forgot to mention that IPv6 needs to be enabled. That has nothing to do > > with the problem, though. IPv6 enabled just means that the percpu code needs to > > allocate more memory. This memory allocation then crashes. > > > > > Either way, that's good enought to look into things. > > > > > Did you see the problem on a bcm1250/1480 or with some other mips core ? > > That was on R10000. > According to Wikipedia, R10k has a 44 bit virtual memory size limit. So I think we have two options, assuming we go with the approach I used in the patch I sent out yesterday. We could either set the default to 44 bit and override it with larger values for processors like the Octeon, or go with a large default (eg with the 60 bit I proposed in the patch) and override it with smaller values as needed (ie pretty much for all CPUs). Seems to me if we would have fewer exceptions if we set the default to 44 bit. Also, it would probably be better if the number of bits is too low for a given CPU, since it would not result in a crash. So I would prefer to use 44 bit as default. Thoughts ? Guenter
