vxworks, errno=0x3d0002, OBJ_UNAVAILABLE, what gives?

[Pete J Story]

I am using sockets on vxworks. Occasionally I get a failure indication
from write(2), and errno is then set to the magic number 0x3d0002, which
most vxworks users will recognise from a task listing. This number comes
from objLib, and means "S_objLib_OBJ_UNAVAILABLE". But what does it
mean in terms of my write call? Has it worked, or has it not? If not,
what am I supposed to do about it?

Any ideas?

pe...@fof.nft.no

PS, this is an *old* vxworks, 5.0.2b on sparc. I can't upgrade, because
it is really vadsworks (for Ada) and there is no newer version for Ada
usage.

[Jean Pierre Calvez]

[Jean Pierre Calvez]

I encounter a similar phenomenon. I am testing a serial driver and get
S_objLib_OBJ_TIMEOUT during a read. This is not an error generated by the driver.
Has it to do with the system interface between user software and drivers?

I am working with the release 5.1.1 of vxworks on a MVME147 CPU board.

[Jean Pierre Calvez]

A correction to my precedent post. My error was due to a timeout occuring on a
semaphore in the driver.

Errors on semaphore cause messages of the kind: "S_objLib_XXXXX".
I have constated this on version 5.0.1 and version 5.1.1.

[Joe Bonaker]

pe...@fof.nft.no (Pete J Story) writes:

>I am using sockets on vxworks. Occasionally I get a failure indication
>from write(2), and errno is then set to the magic number 0x3d0002, which
>most vxworks users will recognise from a task listing. This number comes
>from objLib, and means "S_objLib_OBJ_UNAVAILABLE". But what does it
>mean in terms of my write call? Has it worked, or has it not? If not,
>what am I supposed to do about it?

jpca...@ifremer.fr (Jean Pierre Calvez) responds:

>I encounter a similar phenomenon. I am testing a serial driver and get
>S_objLib_OBJ_TIMEOUT during a read. This is not an error generated by the driver.
>Has it to do with the system interface between user software and drivers?

[Next post....]

This example illustrates one of my frustrations with VxWorks'
well-intended, module-level descriptive errnos: "too much of a good
thing," as the underlying, inter-task objects' errors are propogated to
callers. This works great in the simple case where each error results
in perror() printouts to reveal the root of the problem. But in cases
where some errors are considered "soft," e.g., timeouts or NO_WAIT
contention, this approach burdens the driver/library service provider
(or more likely, its users) with enumeration of all possible
descriptive errors. In general, the VxWorks man pages are remiss in
defining errnos and associated conditions. The driver or library
developer must "hunt and peck" to determine exactly what errnos are
generated by the underlying semaphore/queue objects under certain
failure scenarios, else propogate these undocumented errors to the
users.

We developed a serial driver which sat on a mutual exlusion semaphore.
A non-blocking read/write operation's semTake(2) errnos had to be
caught by the driver and mapped into more conventional EWOULDBLOCK or
EIO errnos to allow the driver user to take appropriate action based on
the errno. Based on available VxWorks documentation, our driver
developer had no idea that S_objLib_OBJ_UNAVAILABLE would be the errno
resultant from a NO_WAIT semTake() when the sempaphore was busy.
Fortunately, the VxWorks shell made it fairly painless to stimulate the
semaphore busy condition and discover the resultant errno.

Guess I'm lobbying for better enumeration and description of errnos in
the VxWorks man pages. This would allow a driver/library developer
the option of propogating errnos or mapping them to more conventional,
Unix errnos.

Joe B.