Hi,
I have a Geode based system which boots into DOS then QNX using
loadqnx.exe.
QNX frequently slows down then freezes when I start the serial driver:
- it sometimes comes back to normal after about 2 minutes.
- when it comes back or doesn’t freeze, the serial ports work fine.
- sometimes the freeze doesn’t happen right away, but only a few minutes
after starting the serial driver
- no freeze whatsoever without the serial driver
- while it’s slowing down before freezing, if I type fast enough to
kill the serial driver, it comes back to normal.
- using the serial port under DOS before starting QNX seems to increase
the chances of a freeze occuring.
- while it’s frozen, the keyboard is not responding (including the caps
lock led when pressing the key)
- I used hogs while the system is slowing down, no process was showing CPU
usage.
I understand the problem may be specific to the hardware I’m using, but I
still wanted to see if anybody would have experienced something
similar, or hear any comments.
Thanks
S. Pamphri wrote:
Hi,
I have a Geode based system which boots into DOS then QNX using
loadqnx.exe.
QNX frequently slows down then freezes when I start the serial driver:
- it sometimes comes back to normal after about 2 minutes.
- when it comes back or doesn’t freeze, the serial ports work fine.
- sometimes the freeze doesn’t happen right away, but only a few
minutes after starting the serial driver
- no freeze whatsoever without the serial driver
- while it’s slowing down before freezing, if I type fast enough to
kill the serial driver, it comes back to normal.
- using the serial port under DOS before starting QNX seems to
increase the chances of a freeze occuring.
- while it’s frozen, the keyboard is not responding (including the
caps lock led when pressing the key)
- I used hogs while the system is slowing down, no process was
showing CPU usage.
I understand the problem may be specific to the hardware I’m using,
but I still wanted to see if anybody would have experienced something
similar, or hear any comments.
For some reason the UART’s used to implement async serial communication
ports have a long history of strange misbehaviour. It may be that your UART
gets in a bad mood sometimes and produces nearly endless streams of
interrupts, thus blocking out all other system activity.
If you really have to work with this hardware, you might consider trying to
write a serial driver that doesn’t use interrupts, but does periodic polling
instead. Very inefficient, but it might resolve the problem.
–
Bert Menkveld
Bert reminded me of something, although I doubt it is the problem. I
recall some time ago a similar QNX 2 issue. The problem was that
some control pins were left floating. They caused the continual
firing of change of state interrupts, which had a big impact on the
system. There are two possible solutions. Turning off hardware
flow control might (or might not) cause the driver to mask these
interrupts. The more robust solution would be to drive the control
pins to ground.
On Tue, 26 Sep 2006 09:31:46 -0400, Bert Menkveld wrote:
It may be that your UART
gets in a bad mood sometimes and produces nearly endless streams of
interrupts, thus blocking out all other system activity.
Thanks for the answer.
Is there any easy way to check how many interrupts are triggered, a la
/proc/interrupts under Linux, or do I have to hack the serial driver to
report it somehow?
to write a serial driver that doesn’t use interrupts, but does periodic
polling instead. Very inefficient, but it might resolve the problem.
My ports are using a rather low baud rate, so it could be a solution.
Thanks.
S. Pamphri wrote:
On Tue, 26 Sep 2006 09:31:46 -0400, Bert Menkveld wrote:
It may be that your UART
gets in a bad mood sometimes and produces nearly endless streams of
interrupts, thus blocking out all other system activity.
Thanks for the answer.
Is there any easy way to check how many interrupts are triggered, a la
/proc/interrupts under Linux, or do I have to hack the serial driver
to report it somehow?
Not that I know of. It wouldn’t take long to add a counter to the serial
driver’s interrupt handler, though it might take a little longer to find a
way to report the counter’s value.
You could also write your own little program to attach to the same
interrupt, since QNX will invoke all the attached handlers for a given
interrupt.
Have you also tried Mitch’s suggestion of tying the serial port control
lines to ground?
to write a serial driver that doesn’t use interrupts, but does
periodic polling instead. Very inefficient, but it might resolve
the problem.
My ports are using a rather low baud rate, so it could be a solution.
Thanks.
Let us know what you find out.
–
Bert
S. Pamphri wrote:
Hi,
I have a Geode based system which boots into DOS then QNX using
loadqnx.exe.
QNX frequently slows down then freezes when I start the serial driver:
… list of lockup conditions …
I understand the problem may be specific to the hardware I’m using, but I
still wanted to see if anybody would have experienced something
similar, or hear any comments.
Damn right it’s the Geode alright. It don’t have any legacy hardware aside from the processor core itself. There is prolly a correct way to handle the comports on the Geode just like there is for all the rest of it’s hardware but if the OS tries to access any legacy devices then it’ll emulate the port/memory accesses via the BIOS and a mode switch for each instance. Effectively like a bus fault of the worst order. (Lots of guessing by me)
If you can lock the BIOS image into cache memory you should get some improvement. Better still, find out if there is a comport driver that is written just for the Geode.
Evan