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.
Leonard