linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: naveen yadav <yad.naveen@gmail.com>
Cc: linux-mips@linux-mips.org, kernelnewbies@nl.linux.org
Subject: Re: info needed for check_bugs
Date: Mon, 7 Jun 2010 14:27:01 +0100	[thread overview]
Message-ID: <20100607132701.GC728@linux-mips.org> (raw)
In-Reply-To: <AANLkTimKPVhpBzKehbm9MAzYJ4rewsQ1kSRrw8Bw8B7i@mail.gmail.com>

On Mon, Jun 07, 2010 at 06:22:47PM +0530, naveen yadav wrote:

> I am porting 2.6.30.9 to MIPS target. The target boot well, but when
> it reaches to check_bugs() function.
> static inline void check_bugs(void)
> {
> 	unsigned int cpu ;
> 	cpu = smp_processor_id();
> 	cpu_data[cpu].udelay_val = loops_per_jiffy;
> 	check_bugs32();
> #ifdef CONFIG_64BIT
> 	check_bugs64();
> #endif
> }
> 
> the debug outupt print to screen become very slow. kernel boots but it
> print one char in 1 min.
> 
> When i change above function as
> 
> static inline void check_bugs(void)
> {
> 	unsigned int cpu ;
> 	cpu = smp_processor_id();
> 	//cpu_data[cpu].udelay_val = loops_per_jiffy;
> 	check_bugs32();
> #ifdef CONFIG_64BIT
> 	check_bugs64();
> #endif
> }
> 
> it works fine. Is there any side effect with this. ?

I suggest to check that the value of cpu_data[cpu].udelay_va and of
loops_per_jiffy make sense.  It would appear that loops_per_jiffy is zero
on your system which would cause __delay() to loop 2^32 times.  If that
is the case, checkout the timer interrupt's frequency and the BogoMIPS
calibration.

You may also want to verify that your platform actually needs mdelay(),
udelay() or ndelay().  These calls should be considered a kludge for
broken hardware and avoided if possible.

  Ralf

      reply	other threads:[~2010-06-07 13:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-07 12:52 info needed for check_bugs naveen yadav
2010-06-07 13:27 ` Ralf Baechle [this message]

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=20100607132701.GC728@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=kernelnewbies@nl.linux.org \
    --cc=linux-mips@linux-mips.org \
    --cc=yad.naveen@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).