[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cpu_switch() panics in 2.1-amiga




Hi again.. just thought I'd pop in and update this thread.


The bad news is that I still have the problem with cpu_switch panics.  I
did manage to catch a crash dump or two and from what I could tell things
looked ok (though I'm no guru).  I ran a memory test for about 16 hours with
no glitches found.  I swapped back to generic and the built-in port for a
few days and had no panics.  Swapped back to my kernel and the MF ports and
started getting panics again.  So much for a week.

The good news is that I have found a way to reliably cause the panic.  I've
found that every time the system crashed it was during a ppp session,
typically just after an attempt to start it up.  Looking at the connect
logs on my ISP's side, I noticed that all the crashes had occured after a
loss of carrier (as opposed to an orderly pppd-negotiated shutdown).  I've
since found that I can induce the system to panic at will by establishing
the ppp link and cycling power to the modem.  It does not seem to matter
whether or not there is any data being transferred at the time.

If I try the ppp/cycle modem trick on the built-in port, I lock the machine
up tight.  The three-finger salute is all it responds to after that.. no
ddb or anything.  I'm not sure how to reconcile this with the fact that
using tty00 on generic seemed far more stable than on the new kernal.  Other
than changing the SER[IO]_BUFSIZE I didn't change anything.. just got rid
of a bunch of stuff.

So far, it only crashes when I've established a link with pppd.  If I use
cu to manually log in to my shell account at my ISP and cycle the modem it
does NOT drop me into the debugger, or even wedge cu.  However, while using
cu I did get an odd entry in /var/log/messages:

... "awk /bsd: call_sicallback: 35484 more dynamic structures 35488 total"

I had just started up cu at 57600b on ttyA0 and was talking to the modem
trying to induce a fifo error (an at&v is typically enough).  That worked,
so I got out and tried cu again at 115200.  At that point I thought cu had
hung since I didn't get the "connected" message.  I hit return a couple
times, then reached over and toggled power to the modem.  Then I got the
above message on the screen and the "connected" message from cu.  After
that, everything behaved normally.  This only happened once, though I tried
a few times to get it to happen again.   

I tracked this message down to machdep.c, but it's not obvious what it means.
Anyone care to enlighten me?  Is this related to my panic problem or a red
herring?


Anyways, any suggestions on the next step?  I don't have the skill to track
this down if it's a driver<->kernel thing.  I started looking at the pppd
source, but so far nothing obvious leaps out at me as being wrong there.


TIA,

   -John