Frederick Bruckman wrote:
>On Wed, 30 Oct 2002, Daniel R. Killoran,Ph.D. wrote:
>
>>  >On Wed, 30 Oct 2002, Daniel R. Killoran,Ph.D. wrote:
>>  >
>>  >That's something. What about the original kernel with no adb devices?
>>  >That would be interesting if it still fails.
>>
>>  Tried that, with everything on the ADB bus unplugged at the computer.
>>  It hung in the exact same place.
>>
>>  It occurs to me that, a long time ago (1.4.1 I think), I discovered
>>  that the kernel would hang on boot if it was compiled with DEBUG
>>  disabled, but would boot ok with DEBUG enabled. I posted this to this
>>  list at the time, but nobody had any suggestions. I have been
>>  compiling my kernels ever since with DEBUG enabled. I wonder if the
>>  kernel from the ftp site was compiled with DEBUG disabled?
>
>Yes, and SMALLRAM has DEBUG disabled, too, so that's not it. You can
>see for yourself -- the configs are under cvs control.
>
>For a while there, making any single change was liable to change the
>initial time/scaling loop, which could consistently cause the adb
>driver to hang up. The clue was in the "cpu: delay factor" at the top
>of the kernel messages: kernels with one "delay factor" consistently
>worked, while kernels with the other "delay factor" didn't. It always
>looked like the last change you made was responsible, but it wasn't.
>Scott added a directive to line up the code that calculates the delay
>factor on a cache line, and that seems to have fixed that. Does your
>"delay factor" change with the working kernel vs. the good kernel?

Alas, both SMALLRAM and GENERICSBC show the same "Delay Factor"(332)

I forgot to mention that GENERICSBC DID boot ONCE (It was the second 
try) but has hung ever since, always at that same place.


Dan Killoran