powerpc mvme5500 clock off by factor of 150

Peter Dufault dufault at hda.com
Tue Mar 8 11:17:59 UTC 2005


On Mar 7, 2005, at 10:46 PM, Till Straumann wrote:

> Peter Dufault wrote:
>>

>> Well, I'm baffled by this.  As I mentioned, I can't enable that 
>> "irq->on()" because I get a stack backtrace when it tries to call it 
>> for the first IRQ, "main irq 56" with "exception handler called for 
>> exception 7".
>
> oops - Kate should debug this (I have no 5500 hardware and no 
> discovery docs). Even
> if the IRQ API is broken by design - once we adopt it we must 
> implement it :-(
>
>>
>> Also, I know "clockOn" is never called during startup because I put 
>> in a dramatic "printk" when it is called and it isn't.
>
> Sure - it's normally called by irq->on().

Right.
>
>>
>>
>> That means "PPC_Set_decrementer" isn't called with anything other 
>> than the initial -1, and so the decrementer value should always be 
>> 2^32.
>
> No. The decrementer is a counter register.

I know, but I wasn't sure that the assembly line in the ISR reloaded 
the clock register or if it auto-reloaded with the previous setting, in 
which case it would always be 2^32.  I'll read up on it.

>
>>
>>
>> So I tried to forceably call clockOn, but regardless of what value I 
>> load using PPC_Set_decrementer I see ticks about every 57 seconds (I 
>> put a printk in the clock tick), at least when it starts up.
>
> Hmm - be careful that your printk doesn't mess up the timing. Could be 
> that the next clock tick is lost
> because it occurs while printk is still executing. In this case, you 
> get a new tick only when the
> decrementer rolls over - still, it's strange - that should only happen 
> every 2^32/fbus*4 ~ 120s


I took out the "printk" and changed it to "XOR" the front-panel LED on 
and off when it entered the clock interrupt.  Here's what happens:

First tick: Just before interrupt driven text comes out from the 
"ticker" task to my serial console.
Second tick: Just after interrupt driven text comes out.
3: +29s
4: +37s
5: +36s
6: +36s
7: +33s

My guess is that the decrementer interrupt just isn't enabled, and that 
something sees it pending and calls the interrupt directly.  For 
example, the final interrupt for the serial output that sees that an 
output queue is empty sees the pending tick and calls the clock 
interrupt.  Does it work that way?  I don't know what could happen 
roughly every 35 seconds after that - does whatever calls the idle task 
check for interrupts every now and then?  It shouldn't, and I don't 
know what other interrupts might be happening.  Does the ethernet have 
a periodic interrupt?

As a matter of fact, we should ignore the first two ticks - if the 
serial interrupt drives the clock tick then it will just look on to me.

I have to try to figure out why "irq->on()" is commented out can't be 
called.  If I can't find it this AM I have to give up - my clients are 
getting restless.

Peter

Peter Dufault
HD Associates, Inc.




More information about the users mailing list