Scenario:
Power up system - takes ages to run. When completely booted
it turns out that Dev32 is taking 88% of processor time and
Fsys.diskonchip 6%.
Reboot system (either using reset switch or
ctrl-shift-alt-del) and it works normally.
This seemed odd. It was repeatable - ie. 1st boot after power-on
failed.
The processor card was then moved to another system and powered-on.
Reboot chkfsys found disk corruption, fixed some and then gave up failing
to read some block or other. On subsequent reboot the disk-on-chip is no
longer bootable.
The problem is now gone but can anyone offer an explanation?
Thanks in advance
William Morris
wrm@innovation-tk.com
Without knowing what was actually running on your system my guess would be
that
Dev32 was servicing alot of requests from the device drivers. Perhaps
interrupts on
the serial port, etc. I would also suspect a configuration problem in the
QNX OS.
What computer is this running on? I take it that you had to reload the DOC
since
the DOC was no longer bootable. This reload may have fixed your problem
“William Morris” <wrm@innovation-tk.com> wrote in message
news:9oseli$9s4$1@inn.qnx.com…
Scenario:
Power up system - takes ages to run. When completely booted
it turns out that Dev32 is taking 88% of processor time and
Fsys.diskonchip 6%.
Reboot system (either using reset switch or
ctrl-shift-alt-del) and it works normally.
This seemed odd. It was repeatable - ie. 1st boot after power-on
failed.
The processor card was then moved to another system and powered-on.
Reboot chkfsys found disk corruption, fixed some and then gave up failing
to read some block or other. On subsequent reboot the disk-on-chip is no
longer bootable.
The problem is now gone but can anyone offer an explanation?
Thanks in advance
William Morris
wrm@innovation-tk.com
Ivan Bannon <ivan.bannon@rjginc.com> wrote:
Without knowing what was actually running on your system my guess would be
that Dev32 was servicing alot of requests from the device drivers.
Perhaps interrupts on the serial port, etc.
That could be so. The chksys call, where the problem first
becomes apparent is after the serial drivers have been
started.
I would also suspect a configuration problem in the QNX OS.
What do you have in mind here?
What computer is this running on?
A PC104 module from DigitalLogic mounted on a custom
motherboard.
I take it that you had to reload the DOC since the DOC was no longer
bootable. This reload may have fixed your problem
That is so. Unfortunately it doesn’t explain the
original problem.
Thanks for replying
Regards
William Morris
wrm@innovation-tk.com
“William Morris” <wrm@innovation-tk.com> wrote in message
news:9outsd$8ar$1@inn.qnx.com…
Ivan Bannon <> ivan.bannon@rjginc.com> > wrote:
Without knowing what was actually running on your system my guess would
be
that Dev32 was servicing alot of requests from the device drivers.
Perhaps interrupts on the serial port, etc.
That could be so. The chksys call, where the problem first
becomes apparent is after the serial drivers have been
started.
I would also suspect a configuration problem in the QNX OS.
What do you have in mind here?
Basically the command line options for starting say the serial or parallel
drivers,
pseudo terminals, network drivers, etc. Take a close look at your sysinit
script
to see if an interrupt or I/O port may have been defined incorrectly.
What computer is this running on?
A PC104 module from DigitalLogic mounted on a custom
motherboard.
Just curious, what functionality is on the PC104 module and what is on the
motherboard. Meaning controllers, video, serial chips, etc.
I take it that you had to reload the DOC since the DOC was no longer
bootable. This reload may have fixed your problem
That is so. Unfortunately it doesn’t explain the
original problem.
No it doesn’t, it just makes it harder to analyze it > 
Thanks for replying
Regards
William Morris
wrm@innovation-tk.com
Ivan Bannon <ivan.bannon@rjginc.com> wrote:
Just curious, what functionality is on the PC104 module and what is on the
motherboard. Meaning controllers, video, serial chips, etc.
The module contains the video chip, two serial one parallel port,
network port. The motherboard adds another set if 16 serial ports,
some RS422 ports and an interface to a proprietary bus structure.
Since last posting, the technician working on the rack tells me that
reprogramming the DOC worked but the problem returned. It later
transpired that the supply rails were a bit low - tweaking those by
0.2V cured the problem entirely.
In fact, although this may be premature, some seemingly unrelated
total hang-up problems we have been having seem to be supply related,
Noise getting into the supplies has been seen to make a system freeze
completely with no warnings emitted by Proc (previously thought
culpable).
Thanks for your help.
Regards
William Morris
wrm@innovation-tk.com