Re: Final pre-2.0.31.. Expect this to be same as real 2.0.31

Leonard N. Zubkoff (
Tue, 9 Sep 1997 09:08:59 -0700

Date: Tue, 09 Sep 1997 08:56:02 -0500
From: Doug Ledford <>

Geesh, I would hope that would solve the problem ;) The aic7xxx_reset code
has two embedded udelay(1000); calls in it, but the forwarding shouldn't
blow up any more since you just embedded 10 million udelay(10) calls for a
timeout :)

How long does it really take to run that anyway? Isn't the udelay somewhat,
ummm..... non-deterministic at that usage level? Unless I'm off on my
calculations, 10,000,000 iterations of what is suppossed to be 10/1,000,000
of a second comes out to be 100 seconds total. Did you really intend it to
be that long, or am I misfiguring things here?

Well, I actually dropped it to 60 seconds in the version I'm running right now.
That this panic was ever hit means that there is far more interrupt latency
possible than I originally considered when I was first developing the deadlock
patch. I really should have revisited that code before now, but there was no
indication that the previous waiting loop was insufficient. The only reason
for a timeout at all is so that a message can still be printed if the bootstrap
CPU never accepts the kernel lock. O(60 seconds) is consistent with the other
timeouts in the deadlock code.