Pat O'Rourke wrote:
> > The "stuck" message just means that the spin_lock() routine (really
> > debug_spin_lock()) thinks that it has waited too long to get the particular
> > lock.
>
> In looking over debug_spin_lock() I see that it uses a hard coded value as
> an indicator of "too long":
>
> stuck = 1L << 28;
>
> Is it possible that this value (as large as it is) is too small for some of
> the newer CPUs?
>
It's possible, but if I recall Jay correctly the "ticks" is constant on all
Alphas (other than Rawhide, where it's 1200 instead of 1024), it's just the
clock multiplier that's different. Of course, it wouldn't be the first time I
didn't understand something Jay said, either... ;)
Really tho', this is just a debugging message. The only reason people are only
seeing it on Alpha is that the printk() only exists in the Alpha version of
spin_lock() and spin_unlock(). Every other architecture is probably seeing the
same types of issues, just their spin_lock() doesn't go to these lengths to tell
them. And considering that now we now have the lockmeter package from SGI (only
on ia32 and Alpha right now, but other ports are quite possible) some of this
debugging usefulness is gone. I've asked about turning off the DEBUG_SPINLOCK
at least on Alpha, but we'll see what happens.
If you really don't like the messages, you can either: 1) turn off
DEBUG_SPINLOCK and DEBUG_RWLOCK in spinlock.h or 2) change the length of time it
takes before a message is printed. I can see either, both, or none depending on
how you look at it. In the end, the default isn't up to me, but we're all free
to change it as we please. ;)
>
> > > Sometimes, the machine goes completely catatonic and should be
> > > resetted. Less often the system really crashes. My estimate is that
>
> There may be situations (e.g. certain paths during interrupt handling) where
> doing a printk to the console is a bad idea. I have seen this on the other
> OSs.
>
Yup - that could be quite bad I'd think. Certainly possible that could cause
problems I'd guess. Maybe another reason to turn off the DEBUG code? As above,
we'll see how the owners of the code feel. Time will tell...
- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:24 EST