info needed for check_bugs

info needed for check_bugs

[naveen yadav]

Hi all ,

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. ?

or how can i fix this issue.

Re: info needed for check_bugs

[Ralf Baechle]

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