On 6/7/05, Josh Tolbert <hemi@puresimplicity.net> wrote:
> On Tue, Jun 07, 2005 at 09:06:03AM -0700, Andy Ruhl wrote:
> > Hey Josh.
> >
> > Try to get trace output, which you will only be able to type in.
>=20
> [snip]
>=20
> > Andy
>=20
> Hi Andy,
>=20
> I am home from work now, so a trace output follows:
>=20
> cpu_Debugger() at netbsd:panic+0x98
> panic() at netbsd:gaps_dmamap_sync+0x1bc
> gaps_dmamap_sync() at netbsd:rtk_rxeof+0x334
> rtk_rxeof() at netbsd:rtk_watchdog+0x3a
> rtk_watchdog() at netbsd:if_slowtimo+0x3c
> if_slowtimo() at netbsd:softclock+0x1e0
> softclock() at netbsd:hardclock+0x4ba
> hardclock() at netbsd:sh4_clock_intr+0x16
> sh4_clock_intr() at netbsd:intc_intr+0x54
> intc_intr() at 0x8c000680
> () at 0
>=20
> I tried sync before running the trace, but I got an rtk0: watchdog timeou=
t and
> another copy of the original panic message.
>=20
> Is there anything else I can provide?

Not really. I'm definitely no kernel hacker, but best I can tell is
that all this is is a network error that caused a panic, probably in
swap somewhere (wild, wild guess because I'm not as smart as I think I
am). I'm not sure if this is supposed to happen or not, but it could
very well be that the error would be fatal whether you got a panic or
not so the panic may be moot. Have you seen this more than once?

Remember, our old rule of thumb was to run the adapter at 10baseT
because 10baseT is fast enough to saturate the bus it lives on anyway
(if I'm remembering right).

Andy