Mike Smith wrote:
> > I've played around changing the spinloop to using DELAY (like the Linux model),
> > but this didn't prevent the controller from either "just" locking up or
> > crashing the whole machine with it. Changing various other places in a similar
> > manner (like replacing the bcopy() in amr_quartz_get_work() with similar
> > code as in the linux driver to wait for 0xFF to clear) didn't do the trick
> > either.
>
> Can you try instead the changes that I just committed to -current? I
> think that the problem shows up when the controller is heavily loaded;
> your patch will keep the load on the controller down, which may mask the
> 'real' bug.
Just recently (this evening), I was able to get our controller to lock
up with the latest patch. Previously, with that patch installed, I
must not have been able to tickle the bug just right, and I believe
that Mike based his decision to make that mod based on my lack of a
lockup, which always happened quickly. That's what made me think that
we'd solved it, but I guess I just got "lucky" on the previous lockups
that happened very quickly, making me think it was more easily
reproduceable that it actually is.
It sounds like Markus may be onto something.
-Brian
--
Brian Dean [EMAIL PROTECTED]
SAS Institute Inc. [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
