[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cpu_switch() panics in 2.1-amiga
> From: John Grant <jmgrant@primenet.com>
> Date: Thu, 5 Mar 1998 03:53:34 -0800 (PST)
> 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).
You might have hit the nail right there. A quick glance at kern/tty*.c
reveals that the modem line state change routine ttymodem() is used
both from the standard line discipline and ppp. Furthermore
ttymodem() does stuff that *seems* to be standard
line-discipline-centric. It'd be nice to have this area reviewed for
correctness wrt this scenario. Personally I cannot do anything for 1.5
weeks (finishing up at work for vacation, and then going to ski).
I don't know mhy mfc is more picky than ser, or other serial drivers
on other architectures. To me it looked like an MI problem
(hmm.. maybe we are seeing interrupt level inversion on the amiga...
not impossible at all)
> ... "awk /bsd: call_sicallback: 35484 more dynamic structures 35488 total"
>
> 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?
It's not an error, just a diagnostic printout telling that you have
quite some interrupt load. The machine got interrupts in a pace that
was higher than the rate at which it handled the interrupts. It seems
to me your CPU is to weak to cope with that baudrate. But, I am
somewhat confused over what it could be that was in that burst of
characters. Maybe buffered up characters from your former ppp
connection? That ttymodem() call flushes queues, but i am not
sure it flushes the right ones wrt the different line disciplines that
are in use.
> 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.
pppd should not be able to do such bad things, it's just an
application. This is a kernel problem, hopefully solvable but if
noone else jumps the gun, I doubt I will find time to fix it before
2.3 :-( I hope to, but I cannot promise. I have lot queued up.
Niklas