linux-mips
[Top] [All Lists]

Re: info needed for check_bugs

To: naveen yadav <yad.naveen@gmail.com>
Subject: Re: info needed for check_bugs
From: Ralf Baechle <ralf@linux-mips.org>
Date: Mon, 7 Jun 2010 14:27:01 +0100
Cc: linux-mips@linux-mips.org, kernelnewbies@nl.linux.org
In-reply-to: <AANLkTimKPVhpBzKehbm9MAzYJ4rewsQ1kSRrw8Bw8B7i@mail.gmail.com>
References: <AANLkTimKPVhpBzKehbm9MAzYJ4rewsQ1kSRrw8Bw8B7i@mail.gmail.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.20 (2009-08-17)
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

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