lockmeter
[Top] [All Lists]

porting lockmeter to Sparc

To: <lockmeter@xxxxxxxxxxx>
Subject: porting lockmeter to Sparc
From: "John Hawkes" <hawkes@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 15 Nov 1999 09:59:43 -0800
Sender: owner-lockmeter@xxxxxxxxxxx
> From: Frank Hofmann - Sun Germany Technical Solution Center -
>          Munich <Frank.Hofmann@xxxxxxxxxxxxxxx>
...
> With lockmeter, initial loading stops after the message "Now booting
the
> kernel", so problems must start in a very early phase. I've not yet
tried
> to add printk()'s to narrow down where it blocks.

My guess is that the expanded CONFIG_LOCKMETER locks or unlocks are in
error -- that is, the failure lies either in some change you have made
in spinlock.h or smp.h, or more likely in the verbose locking or
unlocking in lockmeter.c.

Be careful when inserting printk()'s, since that code uses spinlocks and
you'll encounter the same error.

One way to debug this is to narrow down the error to either the locking
or to the unlocking, or to the spinlocks vs. the MR locks.  You can, for
example, go into spinlock.h and turn one of those:
   #ifdef CONFIG_LOCKMETER
around the redefinition of the locks, or the redefinition of the
unlocks, into:
   #ifdef CONFIG_LOCKMETER_not
and recompile, thus reverting that lock or unlock back to the
traditional known-to-work instruction sequence.  Once you've narrowed it
down to "spinlock lock" or "MRlock unlock", then you can stare at the
smaller hunk of lockmeter.c code.

Yes, it is cumbersome to debug this when just enabling the
CONFIG_LOCKMETER causes the system boot to hang.

> A question aside: What's EXPORT_SYMBOL actually doing

I am informed that the EXPORT_SYMBOL changes are necessary in order for
a loadable module to find the correct lockmeter.c lock/unlock routines.
I confess that the particular kernels I was building for x86 used no
modules, and I don't have firsthand knowledge of the problem.

John Hawkes


<Prev in Thread] Current Thread [Next in Thread>
  • porting lockmeter to Sparc, John Hawkes <=