[parisc-linux] Mysterious hangs with parisc

[Joel Soete]

Kyle McMartin wrote:
> On Thu, Jul 06, 2006 at 06:22:40PM +0000, Joel Soete wrote:
> 
>> [<000000001011cc08>] smp_do_timer+0x70/0x80
> 
> 
> You're running an SMP kernel.
> 
Yes ;-)

> time.c:
> 
> static inline unsigned long
> gettimeoffset (void)
> {
> #ifndef CONFIG_SMP
> 	/*
> 	 * FIXME: This won't work on smp because jiffies are updated by cpu 0.
> 	 *    Once parisc-linux learns the cr16 difference between processors,
> 	 *    this could be made to work.
> 	 */
> 
> 	long last_tick;
> 	long elapsed_cycles;
> 
> 	/* it_value is the intended time of the next tick */
> 	last_tick = cpu_data[smp_processor_id()].it_value;
> 
> 	/* Subtract one tick and account for possible difference between
> 	 * when we expected the tick and when it actually arrived.
> 	 * (aka wall vs real)
> 	 */
> 	last_tick -= clocktick * (jiffies - wall_jiffies + 1);
> 	elapsed_cycles = mfctl(16) - last_tick;
> 
> 	/* the precision of this math could be improved */
> 	return elapsed_cycles / (PAGE0->mem_10msec / 10000);
> #else
> 	return 0;
> #endif
> }
> 
> Now let's look at the comment for James' change:
> 
> <quote>
> Apparently gettimeoffset can return small negative values (usually in
> the 100us range).  If xtime.tv_nsec is accidentally less than this,
> though (a fortunately unlikely event) it triggers the loop forever.
> 
> I've added a test and correct adjustment for this case.  It has a
> warning printk in there which I'd like to leave for the time being
> just in case this problem implicates some other part of the kernel.
> </quote>
> 
> I don't see 0 being a small negative value. ;-)
> 
> James' fix only applied to UP builds. :)
> 
Ok I missed this detail <(

> Cheers,
> 	Kyle M.
> 
> 
Thanks,
	Joel