You hardly can interpret it. QSSL can. What I was suggested once is:
Thank-you all for your comments.
I talked with VersaLogic about the port and interrupt usage for their board.
The board has interrupts to spare, and they recommend using different
interrupts. The configuration I posted was blessed by VersaLogic.
The kernel panic may not be from the serial at all, but something else. I’m
just trying to narrow down what I’ve done in that last couple of months that
makes the kernel unhappy.
Supposing I can get a clean dump of the panic message, how do you interrupt
it?
Regards,
Steve
“Akhilesh Mritunjai” <~mritun~@REMOVETHISBIT.me.iitb.ac.in.ANDTHISLASTBIT
wrote in message news:ankvla$oj1$> 1@inn.qnx.com> …
Hi Steve
I can’t help diagnosing your problem but can tell how to log the message.
- Wire a null modem cable from one of the serial ports to another
computer
(preferably running QNX).
- Edit your buildfile and start kernel and startup-* with the -K (iirc.
sorry I’m in windows right now) flag “on both of them” to tell them to
dump
info on the specified serial port. Boot using image made from this
buildfile.
- On the other computer just run “cat /dev/serN | tee kernel.log” and
watch
till the kernel panics. (N == serial port number).
NB. You’ll probably have to experiement a bit on which port to choose for
communication on the ‘problem’ side, because kernel might not be able to
send data from the ‘problematic’ port.
HTH
–
Regards
Dear community,
We’ve implemented a fairly straight-forward application on a Versalogic
Bobcat PC-104, four serial ports, DOC. The app has been running fine for
months. The only significant change we’ve made recently is to enable all
four ports. Below is the details
driver: devc-tser8250 3f8,4 2f8,3 3e8,5 2e8,7
com1: port:3f8, interrupt:4
com1: port:2f8, interrupt:3
com1: port:3e8, interrupt:5
com1: port:2e8, interrupt:7
I don’t know if enabling four ports is a factor, however we’re
experiencing
kernel panics every few hours/days.
Question: how do we do a post-mortem on a kernal panic? Is there a log
file
we could get some information on? If we compile with debug, maybe the
line
of code? Wouldn’t that be nice! In any event, my app should never crash
the
kernel. Sometimes the kernel locks up, all services and our app locked
as
well, no message on the console. Sometimes, it’s nice enough to show a
"blue
screen" of information, stack, registers, etc.
Your kind reply will be appreciated!
Regards,
Steve Wagner
\