Re: Extreme system overhead on large IP27

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Atsushi,

It could be that I am seeing a similar issue on the
SWARM board (sb1250) as well. Your patch removed the
shifts for mip_hpt_frequency from
arch/mips/sibyte/sb1250/time.c and in the
sb1250_hpt_read(). The Sibyte HPT is 1 Mhz. However,
when I added those shifts back, I did not see any
issues with the system clock. I could possibly try out
your patch with lower clocksource shift values and see
if the system clock is still wrong.

Btw, the clocksource changes seem to work well on the
BCM 1480 based board. 

Thanks,
Manish Lachwani


--- Atsushi Nemoto <anemo@xxxxxxxxxxxxx> wrote:

> On Wed, 25 Oct 2006 17:45:04 +0900 (JST), Atsushi
> Nemoto <anemo@xxxxxxxxxxxxx> wrote:
> > > 2. Timekeeping is broken. The clock in
> /proc/driver/rtc seems correct, but
> > > the system clock advances at about 1/16 of real
> time.
> > 
> > Is this problem still happen if you disabled
> CONFIG_OPROFILE ?
> 
> I think I found the problem at last.
> 
> static struct clocksource clocksource_mips = {
> 	.name		= "MIPS",
> 	.rating		= 250,
> 	.read		= read_mips_hpt,
> 	.shift		= 24,
> 	.is_continuous	= 1,
> };
> 
> This shift value is too large for ip27 HPT
> (1.25MHz).
> 
> 	temp = (u64) NSEC_PER_SEC <<
> clocksource_mips.shift;
> 	do_div(temp, mips_hpt_frequency);
> 	clocksource_mips.mult = (unsigned)temp;
> 
> If mips_hpt_frequency is less than 0x1000000
> (16777216), temp would be
> larger than possible 32bit value.  I'll cook a patch
> later but until
> then you can use lesser shift value, for example,
> 20.
> 
> ---
> Atsushi Nemoto
> 
> 



[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux