Hi -
I’m using QNX 6.3 SP2 and have installed an NI gpib card. I’m currently
evaluating a driver for the card. During the eval tests, I occasionally
hit a snag - the app shoots to 100%CPU and locks, forcing a hard reboot.
That’s a problem with the driver and/or my app - but that’s beside the
point now.
After these reboots the machine is in a bad way. The machine on boot is
very very slow and nearly unresponsive. I’ve found that by disabling the
enumerators for ISA, USB and PCMCIA the machine will become responsive,
but it seems to lose sight of the fact that it has a Radeon video card,
and asks me to reconfigure screen resolution with a VESA driver. Once I
boot, the machine is reponsive but networking does not work. Fortunately
that is recoverable - I can resurrect networking and make the machine
useable once more.
When I leave the machine off overnight and try again in the morning, it
boots fine, with the radeon driver (after running crttrap). Seems like a
heat-related problem with the card? I left it powered off for over an
hour yesterday to cool off, but the problem didn’t resolve. Overnight
worked.
Can anyone give me hints to try and diagnose this problem? I’m a linux
user, but QNX is a bit foreign to me.
Is there a way to diagnose what is slowing down the boot? Can I boot in
a “debug” mode?
How about log files - sloginfo only gives me info on the current boot -
does QNX save logs from earlier boots?
If there’s more info I can give please let me know,
Dan
That sounds like you have a card which is interrupting continuously.
If that continues after a system reset, the card is defective.
Check for IRQ and interrupt problems.
You mention disabling the ISA enumerator. Is this an ISA device?
This sounds like trouble from the bad old era of dumb ISA cards,
like the National Instruments 181060-01, AT-GPIB, circa 1992, available at
fine surplus stores everywhere.
John Nagle
Dan Sperka wrote:
Hi -
I’m using QNX 6.3 SP2 and have installed an NI gpib card. I’m currently
evaluating a driver for the card. During the eval tests, I occasionally
hit a snag - the app shoots to 100%CPU and locks, forcing a hard reboot.
That’s a problem with the driver and/or my app - but that’s beside the
point now.
After these reboots the machine is in a bad way. The machine on boot is
very very slow and nearly unresponsive. I’ve found that by disabling the
enumerators for ISA, USB and PCMCIA the machine will become responsive,
but it seems to lose sight of the fact that it has a Radeon video card,
and asks me to reconfigure screen resolution with a VESA driver. Once I
boot, the machine is reponsive but networking does not work. Fortunately
that is recoverable - I can resurrect networking and make the machine
useable once more.
When I leave the machine off overnight and try again in the morning, it
boots fine, with the radeon driver (after running crttrap). Seems like a
heat-related problem with the card? I left it powered off for over an
hour yesterday to cool off, but the problem didn’t resolve. Overnight
worked.
Can anyone give me hints to try and diagnose this problem? I’m a linux
user, but QNX is a bit foreign to me.
Is there a way to diagnose what is slowing down the boot? Can I boot in
a “debug” mode?
How about log files - sloginfo only gives me info on the current boot -
does QNX save logs from earlier boots?
If there’s more info I can give please let me know,
Dan
Thanks for your reply.
Nope - its an NI PCI gpib card.
I’ll swap out the card and see if that helps.
How would I check for IRQ and interrupt problems?
I have no idea why disabling the ISA enumerator would make a difference
but it clearly does. My only guess was that the driver messed with /dev
space in a way that … well led to all this. The fact that other
hardware (e.g. the video card) seems to have been affected hints at
this, but I have no idea why or how it would happen. Just a hunch.
Dan
John Nagle wrote:
That sounds like you have a card which is interrupting continuously.
If that continues after a system reset, the card is defective.
Check for IRQ and interrupt problems.
You mention disabling the ISA enumerator. Is this an ISA device?
This sounds like trouble from the bad old era of dumb ISA cards,
like the National Instruments 181060-01, AT-GPIB, circa 1992, available at
fine surplus stores everywhere.
John Nagle
Dan Sperka wrote:
Hi -
I’m using QNX 6.3 SP2 and have installed an NI gpib card. I’m
currently evaluating a driver for the card. During the eval tests, I
occasionally hit a snag - the app shoots to 100%CPU and locks, forcing
a hard reboot. That’s a problem with the driver and/or my app - but
that’s beside the point now.
After these reboots the machine is in a bad way. The machine on boot
is very very slow and nearly unresponsive. I’ve found that by
disabling the enumerators for ISA, USB and PCMCIA the machine will
become responsive, but it seems to lose sight of the fact that it has
a Radeon video card, and asks me to reconfigure screen resolution with
a VESA driver. Once I boot, the machine is reponsive but networking
does not work. Fortunately that is recoverable - I can resurrect
networking and make the machine useable once more.
When I leave the machine off overnight and try again in the morning,
it boots fine, with the radeon driver (after running crttrap). Seems
like a heat-related problem with the card? I left it powered off for
over an hour yesterday to cool off, but the problem didn’t resolve.
Overnight worked.
Can anyone give me hints to try and diagnose this problem? I’m a linux
user, but QNX is a bit foreign to me.
Is there a way to diagnose what is slowing down the boot? Can I boot
in a “debug” mode?
How about log files - sloginfo only gives me info on the current boot
- does QNX save logs from earlier boots?
If there’s more info I can give please let me know,
Dan
ISA enumerator probably tries to identify some “known” devices by poking at
some “known” registers. That can result in all kinds of nasty stuff on
modern systems…
“Dan Sperka” <djsperka@ucdavis.edu> wrote in message
news:eadok8$ebt$1@inn.qnx.com…
Thanks for your reply.
Nope - its an NI PCI gpib card.
I’ll swap out the card and see if that helps.
How would I check for IRQ and interrupt problems?
I have no idea why disabling the ISA enumerator would make a difference
but it clearly does. My only guess was that the driver messed with /dev
space in a way that … well led to all this. The fact that other
hardware (e.g. the video card) seems to have been affected hints at this,
but I have no idea why or how it would happen. Just a hunch.
Dan
John Nagle wrote:
That sounds like you have a card which is interrupting continuously.
If that continues after a system reset, the card is defective.
Check for IRQ and interrupt problems.
You mention disabling the ISA enumerator. Is this an ISA device?
This sounds like trouble from the bad old era of dumb ISA cards,
like the National Instruments 181060-01, AT-GPIB, circa 1992, available
at
fine surplus stores everywhere.
John Nagle
Dan Sperka wrote:
Hi -
I’m using QNX 6.3 SP2 and have installed an NI gpib card. I’m currently
evaluating a driver for the card. During the eval tests, I occasionally
hit a snag - the app shoots to 100%CPU and locks, forcing a hard reboot.
That’s a problem with the driver and/or my app - but that’s beside the
point now.
After these reboots the machine is in a bad way. The machine on boot is
very very slow and nearly unresponsive. I’ve found that by disabling the
enumerators for ISA, USB and PCMCIA the machine will become responsive,
but it seems to lose sight of the fact that it has a Radeon video card,
and asks me to reconfigure screen resolution with a VESA driver. Once I
boot, the machine is reponsive but networking does not work. Fortunately
that is recoverable - I can resurrect networking and make the machine
useable once more.
When I leave the machine off overnight and try again in the morning, it
boots fine, with the radeon driver (after running crttrap). Seems like a
heat-related problem with the card? I left it powered off for over an
hour yesterday to cool off, but the problem didn’t resolve. Overnight
worked.
Can anyone give me hints to try and diagnose this problem? I’m a linux
user, but QNX is a bit foreign to me.
Is there a way to diagnose what is slowing down the boot? Can I boot in
a “debug” mode?
How about log files - sloginfo only gives me info on the current boot -
does QNX save logs from earlier boots?
If there’s more info I can give please let me know,
Dan
Hi Dan,
I have planned to use a NI GPIB card on the CPCI Bus.
You mentioned a driver you are evaluating for QNX.
What kind of driver is it? Is it shipped with the card or is it some
third party?
Please tell us your evaluation result.
Thanks,
steve
Hi, I am in a similar situation as sthiel. Actually I already bought
the NI GPIB card, but NI does not have a driver for QNX. So, I
bought a DDK for GPIB and I am about to start working on building a
new driver based on the examples in the DDK.
Before I purchased the card, I did search around for any company that
provides a GPIB driver for QNX but found none. It seems like Dan
Sperka found a driver for a NI GPIB card. Could you please provide
me with your source? Thanks a bunch for anybody’s input.
There exists a QNX driver for GPIB developed by Andre Koppel Software
in Europe. (Thanks to sthiel for the info.) I requested a demo
driver and just received it a few days ago. But I have not tested it
yet. The link is http://www.swd.de/products/catalogue/index_en.html.
Click on “SWD GmbH GmbH” and then click on “GPIP for
QNX4/QNX6 Software(Andre Koppel) (SWD)”. It’s about US $1000
and above.
Before I was able to get a demo driver from the source mentioned
above, I was successfully able to have my QNX test application to
communicate (initialize, send commands, and send/receive data) with
my GPIB devices (I tested with two – 436A Power Meter and 8672A
Synthesized Signal Generator).
The GPIB board I purchased from NI was PCI-GPIB / TNT5004. And I also
purchased a NI 488 DDK from NI. I ported the other OS examples in the
DDK to QNX. I don’t have a fully developed driver per se because I
did not implement a resource manager type of driver. (Maybe in time
I may do that.) Instead, I just had the ported driver directly
linked to my application when building. This is OK for me since my
requirement has only one process/thread handling all GPIB devices
serially.