Hi, * Sven-Thorsten Dietrich <[EMAIL PROTECTED]> [2007-12-28 08:23:32]:
> On Wed, 2007-12-26 at 09:53 +0530, Chirag Jog wrote: > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-12-24 13:00:30]: > > > > Hi, > > Sorry for top-posting the last email. Have not learned how to inline on > the Blackberry. > > Comments below. > > > > Do you have DEBUG and LOCKDEP configured? > > CONFIG_PREEMPT_DEBUG is enabled > > but LOCKDEP is not. > > > > > > -----Original Message----- > > > From: Sripathi Kodi <[EMAIL PROTECTED]> > > > > > > We are trying to get a ppc64 box booted with the -rt kernel. > > > > > > Tried the latest 2.6.24-rc5-rt1 kernel. > > > > > > Everything goes well [ kernel boots up etc] until the services > > > start coming up. > > > It takes a lot of time at Starting udev. > > > After which either services take too long to start or we get > > > SEGFAULT. > > I have seen this exact behavior with lockdep enabled on earlier x86-SMP > Kernels. I saw the issue predominantly on larger SMP machines, but it > behaved much like a race. This was observed on 2.6.21 Kernels, I will > try and verify whether .23 has the same behavior. > > We eventually bisected it down to CONFIG_PROVE_LOCKING, but I wasn't > totally convinced whethere the root cause was in lockdep, or > elsewhere. > > > > > > > This is easily reproducible. Also if we get a chance to login; > > > simple commands like ls, vi etc take either too long or get > > > SEGFAULT. > > > > > > > Booting the kernel with maxcpus=1 or turning off SMP, doesn't > > > solve the problem. > > > > > Hmmm, so have you COMPILED-out SMP, or just booted with nosmp? > > It might help narrowing this down to compile a UP Kernel. We have tried both options, compiled out SMP and boot with maxcpus=1. Similar results. Sripathi also tried with turning off HIGH_RES_TIMERS but didn't seem to help. The system took forever to come up. > > Thanks > > Sven <snip> -- Cheers, Chirag Jog - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
