From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c460a62c19b2c0ab X-Google-Attributes: gid103376,public X-Google-Thread: 114c38,c460a62c19b2c0ab X-Google-Attributes: gid114c38,public From: jhassett@my-dejanews.com Subject: Re: SCSI disk problems - Don't know where to begin Date: 1998/10/23 Message-ID: <70qtu7$7ua$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 404405604 References: <70lj95$s66$1@nnrp1.dejanews.com> X-Http-Proxy: 1.0 x11.dejanews.com:80 (Squid/1.1.22) for client 192.31.86.34 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Fri Oct 23 21:54:15 1998 GMT Newsgroups: comp.os.vxworks,comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (X11; U; SunOS 5.5.1 sun4m) Date: 1998-10-23T00:00:00+00:00 List-Id: 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