Subject: SYSCALL_DEBUG and latency...
To: None <email@example.com, firstname.lastname@example.org>
From: Mark Abene <email@example.com>
Date: 02/15/2001 04:21:16
I've just done several tests on my Magnum, based on the odd behavior that
enabling SYSCALL_DEBUG typically allows a successful boot to a single-user
shell. Testing the theory of introduced latency, I've inserted DELAY calls
as high as 1 second where scdebug_call and scdebug_ret would be called from
arch/mips/mips/syscall.c. The tests were unsuccessful. It would seem the
sheer latency introduced by SYSCALL_DEBUG does not account for the successful
booting. It may prove to be more of a memory issue than one of timing.
It's hard to say right now. What is true is that the machine is no longer
ping-able when the problem occurs, so there may be a general DMA issue, or
an outright problem with the sonic ethernet driver. I was curious as to
why in the sonic's DMA initialization in arch/arc/jazz/dma.c, no DMA channel
register set is specified, and most sonic DMA functions are set to null
functions. Is the sonic's memory-mapped buffer the only thing it accesses
via DMA? And is the sonic's DMA use NOT controllable by an R4030 DMA channel?
I plan on trying an ISA ethernet card as soon as I have the opportunity, to
see if the problem is specifically with the sonic, or a more generalized