On Tue, 1 Jun 1999, Colin Wood wrote:

> yep, that's the kind of thing that some other people are seeing as well.
> apparently the delay timing on the newer ADB hardware is quite sensitive,
> and having the wrong delay factor completely blows the 3ms timing loop in
> adb_direct.c.  now _why_ the delay factor is different from one kernel to
> the next is a completely different (and more interesting) question....

The problem with delay() is interesting, but it's not the whole
answer. I tried forcing a value for delay, and results were still
inconsistent. The fun one is when you get a kernel that boots half of
the time, basically at random. I also built a little countdown test
into my kernel, to test both long and short delays. It's always pretty
close, no matter what number it comes up with for the delay factor.

There doesn't seem to be anything critical about that 3ms timing loop.
It's just waiting for the bus to complete it's reset. Values of 2ms
and 4ms seemed to work for me (840AV): Guy Santiagla reported that
only 4ms worked on the Quadra 610. The same set of kernels that worked
with 2ms and 4ms failed at 3ms. Think about that.

Now take a hard look at adb_cuda_tickle(). It's a watchdog timer for
the Cuda hardware. If the Cuda really needs a watchdog, maybe there's
a bug in the hardware. If so, adb_reinit() needs a watchdog, too.