On Thursday, Mar 27, 2003, at 07:05 US/Central, Bryan Rittmeyer wrote:
> On Thu, Mar 27, 2003 at 12:38:15PM +0000, Gianni Tedesco wrote:
>> Machine is a 7544 (rev 2.1) tibook.
That's probably the 7455
> my patch has only been tested on the 750CX, and there's enough voodoo
> involved that it probably needs some mods before working on other CPUs.
> the first step is to check the 7544 user's manual, and see if its
> perfmon register definitions are the same as the 750CX's.
I'm 99.9% positive that the counters are different. In my experience,
every new microarchitecture has a completely different set of counters.
Also, I'm betting the 7455 has more counters, since there are 6 on
there, vs 4 on all the other counter-enabled PowerPCs.
> if not, you'll need to either a) add framework for multiple ppc chips
> or b) just hack my patch to work on only the 7544. a) is preferable.
>> when i do opcontrol --start everything gets fscked up, clock stops,
>> processes hang, can't reboot.
> yeah. due to some bad PPC errata it takes a cheap stunt to implement
> oprofile: switching between decrementer and perfmon for driving the
> Linux timer_interrupt(). if the perfmon ctr is misconfigured, the
> scheduler never runs (dead box).
> there may be a nicer approach but AFAIK nobody has found one yet.
Earlier on the list, the possibility of using the performance interrupt
with the timebase was proposed. I don't think the full ramifications
of that have been discussed, but it seems to me that this could be done
automatically by the perfmon_request_irq() function. This could even
be done using one of the counters. I think that function needs to set
up the counter, though. The controlling driver could then modify the
counters if it wanted so that the interrupt came from something other
than the timebase. Otherwise, you get this crashing thing on all
microarchitectures prior to the 7410 rev 1.3, if the user didn't
configure the counters properly. From the sounds of it, the 750cx line
is affected as well.
Also, I have concerns about how the decrementer is disabled. It looks
like it would be possible for the decrementer to keep going until the
next time the interrupt is called. If, by some awful coincidence, this
occurred 1 cycle before the first perfmon interrupt, wouldn't the
errata manifest? Is there a more effective way to disarm the
decrementer, so it doesn't interrupt? Or should the driver just make
sure that it waits for the decrementer to fire one last time before
enabling the pmon interrupt? Another option would be to call
timer_interrupt from within perfmon_request_irq().
>> Any ideas? Should this even work on this machine? Maybe if you could
>> give me the date you checked out oprofile code, I could get the same
>> version as you, and narrow this down?
This code won't work properly on your machine, since the 7455 has
substantially different counters. Though you could, of course, use it,
being careful to match the event numbers with 7455 descriptions.
> my patches are against 3/25/2003 oprofile cvs, and linux-2.4-benh
> from around 3/07/2003. latest is -v0003 oprofile and -v0002 kernel
> at http://bryanr.org/linux/oprofile/
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> oprofile-list mailing list