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

[j0hnchann@h0me.net (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