powerpc mvme5500 clock off by factor of 150
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().
>> That means "PPC_Set_decrementer" isn't called with anything other
>> than the initial -1, and so the decrementer value should always be
> 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.
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
HD Associates, Inc.
More information about the users