Subject: SYSCALL_DEBUG and latency...
To: None <port-arc@netbsd.org, port-mips@netbsd.org>
From: Mark Abene <phiber@radicalmedia.com>
List: port-arc
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
problem.

Cheers,
-Mark