kernel panic

QNX Newsgroups (Archives) comp.os.qnx
1

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

2

Steve Wagner wrote:

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.

Your app should never crash the kernel, however, a hardware
misconfiguration can and most often will crash the kernel. I would look
at the hardware config.

Does your multiport serial board “or” the interrupts, or does it really
use 4 seperate interrupts (very wasteful, and uncommon).

Is there any potential for an interrupt conflict with some other device ?

3

Rennie Allen <rallen@csical.com> wrote:

Steve Wagner wrote:

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.

Your app should never crash the kernel, however, a hardware
misconfiguration can and most often will crash the kernel. I would look
at the hardware config.

Does your multiport serial board “or” the interrupts, or does it really
use 4 seperate interrupts (very wasteful, and uncommon).

Another issue might be (if this is still the “we just enabled all
four serial ports” thread) that first of all interrupt 7 is the
“glitch” interrupt, and secondly, some hardware will generate spurious
(and perhaps high frequency) interrupts if some of the lines are
left floating (i.e., leave RI floating and enabled, and it may oscillate
at a high frequency).

Try disabling the ports, or tying down the hardware pins to ground.

Cheers,
-RK

Is there any potential for an interrupt conflict with some other device ?

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

4

Hi Steve

I can’t help diagnosing your problem but can tell how to log the message.

  1. Wire a null modem cable from one of the serial ports to another computer
    (preferably running QNX).

  2. 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.

  3. 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
\

5

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.

  1. Wire a null modem cable from one of the serial ports to another
    computer
    (preferably running QNX).

  2. 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.

  3. 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

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


\

6

You hardly can interpret it. QSSL can. What I was suggested once is:

  1. Redirect debug output to serial port (option to startup), that should
    put kernel panic dump there so it can be captured.
  2. Add +keeplinked attribute to procnto in the boot image, that should
    produce a .sym file when you run mkifs.
  3. When this happens, send the dump, procnto and procnto.sym to your
    support contact.

– igor

Steve Wagner wrote:

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.

  1. Wire a null modem cable from one of the serial ports to another

computer

(preferably running QNX).

  1. 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.

  1. 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




\