From: Chirag Jog <chirag@linux.vnet.ibm.com>
To: Sven-Thorsten Dietrich <sven@thebigcorporation.com>
Cc: Sripathi Kodi <sripathik@in.ibm.com>, linux-rt-users@vger.kernel.org
Subject: Re: Fwd: -rt and PowerPC
Date: Mon, 31 Dec 2007 09:56:23 +0530 [thread overview]
Message-ID: <20071231042623.GA8421@linux.vnet.ibm.com> (raw)
In-Reply-To: <1198859012.12074.0.camel@sven.thebigcorporation.com>
Hi,
* Sven-Thorsten Dietrich <sven@thebigcorporation.com> [2007-12-28 08:23:32]:
> On Wed, 2007-12-26 at 09:53 +0530, Chirag Jog wrote:
> > * sven@thebigcorporation.com <sven@thebigcorporation.com> [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 <sripathik@in.ibm.com>
> > >
> > > 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
next prev parent reply other threads:[~2007-12-31 4:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-24 6:10 Fwd: -rt and PowerPC Sripathi Kodi
[not found] ` <562556514-1198501255-cardhu_decombobulator_blackberry.rim.net-1487612076-@bxe137.bisx.prod.on.blackberry>
2007-12-26 4:23 ` Chirag Jog
2007-12-28 16:23 ` Sven-Thorsten Dietrich
2007-12-31 4:26 ` Chirag Jog [this message]
2007-12-31 2:57 ` Paul E. McKenney
2007-12-31 15:44 ` Sripathi Kodi
2007-12-31 16:43 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071231042623.GA8421@linux.vnet.ibm.com \
--to=chirag@linux.vnet.ibm.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=sripathik@in.ibm.com \
--cc=sven@thebigcorporation.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.