SCSI disk problems - Don't know where to begin

SCSI disk problems - Don't know where to begin

[krichey]

I am writing some data extraction code in Ada (Greenhills) in a VxWorks,
PowerPC, VME card cage system, with a SCSI disk.  VME-167 cards
Also there are some C tasks.

At some point (it varies, and doesn't happen every time) the best we can tell
our SCSI disk is waiting on an interrupt and hanging.  My Ada task is
just sitting there taking minutes for individual i/o statements to complete.

We have gotten the following statements on the screen
(all three at the same time)-
interrupt: ncr810: SCSI bus gross error
interrupt: ncr810Intr: unrecoverable error - re-starting-SIOP
(from one of our C tasks)
(tScsiTask): ncr810InitEvent: invalid event type (99)
---

We have checked stack sizes for blown stacks, no problems are indicated here.

When the error occurs (some times on init, some times several minutes into
recording) during a write we have seen a write error (number of bytes reported
written does not match those sent) and we have seen a time out.

One guess is something is 'jumping its bounds' and messing up memory where the
device driver resides- but what?  Any ideas?


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: SCSI disk problems - Don't know where to begin

[dennison]

In article <70lj95$s66$1@nnrp1.dejanews.com>,
  krichey@nswc.navy.mil wrote:
> I am writing some data extraction code in Ada (Greenhills) in a VxWorks,
> PowerPC, VME card cage system, with a SCSI disk.  VME-167 cards
> Also there are some C tasks.
>
> At some point (it varies, and doesn't happen every time) the best we can tell

That generally is the hallmark of a race condition. You may want to go back
over the code to make sure *any* object accessed by more than one task
(except via a rendezvous) either has a "pragma atomic", or is placed in a
protected type.

> One guess is something is 'jumping its bounds' and messing up memory where the
> device driver resides- but what?  Any ideas?

If you suspect that, try to catch it happening. If you are using AdaMulti,
check out the section on "Watchpoints" in the debugger command list in your
AdaMulti reference manual. You should be able to set the debugger up to stop
any task that tries to modify a designated area of memory. In my AdaMulti for
Windows Reference Manual (v 1.8.8), the relevant discussion is on page 252.

Race conditions happen to the best of us. But if a rougue task is really
trashing other's code space, that's a different matter entirely. Whoever wrote
that code is in dire need of a "swirlee". >:-)

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: SCSI disk problems - Don't know where to begin

[jhassett]

In article <70lj95$s66$1@nnrp1.dejanews.com>,
  krichey@nswc.navy.mil wrote:
> I am writing some data extraction code in Ada (Greenhills) in a VxWorks,
> PowerPC, VME card cage system, with a SCSI disk.  VME-167 cards
> Also there are some C tasks.
>
> At some point (it varies, and doesn't happen every time) the best we can tell
> our SCSI disk is waiting on an interrupt and hanging.  My Ada task is
> just sitting there taking minutes for individual i/o statements to complete.

A couple of our projects are working with Green Hills Ada and VxWorks,
and PowerPC is one of their targets.  I've heard that the restrictions
imposed on interrupt services routines by VxWorks lead to serious
limitations on any Ada subprograms called in the interrupt state.
Perhaps you know about this, but just in case you don't, here is my
understanding of the situation:

Under VxWorks, interrupts are handled outside of any (VxWorks) task's
context.  This is evidently done to avoid the overhead of task context
switching.  Unfortunately, the Green Hills Ada compiler seems to be
designed with the assumption that there is always a task ID available,
but this is not true in the interrupt state.  Besides the usual
restrictions imposed by VxWorks (no blocking operations, no I/O through
device drivers, no FP coprocessor operations), we've been told by
Green Hills that subprograms called in the interrupt state must not
have exception handlers, and must be compiled with runtime checks
suppressed.  Apparently there are attempts to access the task control
block when setting up exception handling or when preparing to do the
runtime checks.

I have no idea whether a failure to comply with these restrictions could
lead to the symptoms you've seen, but you need to know about this in any
case.

- Jim Hassett

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: SCSI disk problems - Don't know where to begin

[John Chann]

In article <70qtu7$7ua$1@nnrp1.dejanews.com>, jhassett@my-dejanews.com wrote:
>In article <70lj95$s66$1@nnrp1.dejanews.com>,
>  krichey@nswc.navy.mil wrote:
>> I am writing some data extraction code in Ada (Greenhills) in a VxWorks,
>> PowerPC, VME card cage system, with a SCSI disk.  VME-167 cards
>> Also there are some C tasks.
>>
>> At some point (it varies, and doesn't happen every time) the best we can tell
>> our SCSI disk is waiting on an interrupt and hanging.  My Ada task is
>> just sitting there taking minutes for individual i/o statements to complete.
>
>A couple of our projects are working with Green Hills Ada and VxWorks,
>and PowerPC is one of their targets.  I've heard that the restrictions
>imposed on interrupt services routines by VxWorks lead to serious
>limitations on any Ada subprograms called in the interrupt state.
>Perhaps you know about this, but just in case you don't, here is my
>understanding of the situation:
>
>Under VxWorks, interrupts are handled outside of any (VxWorks) task's
>context.  This is evidently done to avoid the overhead of task context
>switching.  Unfortunately, the Green Hills Ada compiler seems to be
>designed with the assumption that there is always a task ID available,
>but this is not true in the interrupt state.  Besides the usual
>restrictions imposed by VxWorks (no blocking operations, no I/O through
>device drivers, no FP coprocessor operations), we've been told by
>Green Hills that subprograms called in the interrupt state must not
>have exception handlers, and must be compiled with runtime checks
>suppressed.  Apparently there are attempts to access the task control
>block when setting up exception handling or when preparing to do the
>runtime checks.
>
>I have no idea whether a failure to comply with these restrictions could
>lead to the symptoms you've seen, but you need to know about this in any
>case.
>
>- Jim Hassett

Please be aware that ISRs in vxWorks should be as short as possible, most ISRs 
just handle the hardware and grab volatile data then release a high priority 
task with a semGive then exit. Holding the system in the ISR whilst you 
contemplate your navel destroys determinism and blocks other IRQs at the same 
or lower priority. 

I'd be very very surprised if Green Hills didn't have some very good advice 
in this area.

To return specifically to the original question; if you want to know where 
your system has gone off to hide then I suggest you try WindView which will 
show you what is going on. 

JRC

John Chann
California, USA