lis_stropen error

[Alvarez, Angel]

Hi guys
First of all, I am a completly neophyte to LiS
I'm not developer, just a Linux administrator
I'm using LiS because it is a requirement to install IBM Communications
Server in SuSE SLES8 kernel 2.4.21-292-smp LiS 2.16 + patch provide by
IBM and CS 6.2
I found this error in the messages.log
May 2 02:05:30 snet0001lx kernel: lis_stropen(...)#6295804
May 2 02:05:30 snet0001lx kernel: >> open_mods() error (-16)
...
until
May 2 09:48:49 snet0001lx kernel: lis_stropen(...)#6372652
May 2 09:48:49 snet0001lx kernel: >> open_mods() error (-16)

I was searching in google but had no info available
Can you help me??
Any suggestion will be appreciated
thanks in advance

PS:this is the second message. I can't view the archives at
http://gsyc.escet.urjc.es/mailarchive/linux-streams

403 error (forbidden)

[Steve Schefter]

Hi Angel.

Post by Alvarez, Angel
I'm using LiS because it is a requirement to install IBM Communications
Server in SuSE SLES8 kernel 2.4.21-292-smp LiS 2.16 + patch provide by
IBM and CS 6.2
I found this error in the messages.log
May 2 02:05:30 snet0001lx kernel: lis_stropen(...)#6295804
May 2 02:05:30 snet0001lx kernel: >> open_mods() error (-16)
...
until
May 2 09:48:49 snet0001lx kernel: lis_stropen(...)#6372652
May 2 09:48:49 snet0001lx kernel: >> open_mods() error (-16)

Unfortunately, it doesn't appear to be a problem within LiS, just
reported by LiS.

LiS' open_mods() calls lis_qopen() which in turn calls the open
routines of the modules associated with the devices being opened.
It is one of the module's open routines (part of CS?) that is
reporting error 16 (EBUSY).

Note that this path is only followed when an existing stream is
being reopened. Given the error EBUSY, reopening may not be
supported by that module. It may be that you need to change some
configuration to use /dev/XX1 and /dev/XX2 rather than both using
/dev/XX1. Or it may be that the /dev entry is built incorrectly
and should be a cloning device (have the major number of the
clone driver and the min number equal to the add-on module's
major).

In any event, it looks like the problem is CS-specific.

Post by Alvarez, Angel
PS:this is the second message. I can't view the archives at
http://gsyc.escet.urjc.es/mailarchive/linux-streams

You can see the archive at:
http://www.mail-archive.com/linux-streams%40gsyc.escet.urjc.es/

Regards,
Steve

------------------------------------------------------------------------
Steve Schefter phone: [phone] x26
The Software Group Limited fax: [phone]
642 Welham Road, email: ***@wanware.com
Barrie, Ontario CANADA L4N 9A1 Web: www.wanware.com

[Brian F. G. Bidulock]

Steve,

SVR 4.2 STREAMS modules do no return negative error numbers, they
return MODOPENFAIL, which is translated to ENXIO when returned to
the opening process. LiS does not comply to SVR 4.2 because it
does not accept a positive error code. Almost everywhere you point
LiS has an error. This is just an example where someone happened
to point.

Linux Fast-STREAMS accepts positive error numbers, but also will
accept negative error numbers for compatibility with broken LiS
modules and drivers.

--brian

Post by Steve Schefter
Hi Angel.

Post by Alvarez, Angel
I'm using LiS because it is a requirement to install IBM Communications
Server in SuSE SLES8 kernel 2.4.21-292-smp LiS 2.16 + patch provide by
IBM and CS 6.2
I found this error in the messages.log
May 2 02:05:30 snet0001lx kernel: lis_stropen(...)#6295804
May 2 02:05:30 snet0001lx kernel: >> open_mods() error (-16)
...
until
May 2 09:48:49 snet0001lx kernel: lis_stropen(...)#6372652
May 2 09:48:49 snet0001lx kernel: >> open_mods() error (-16)

Unfortunately, it doesn't appear to be a problem within LiS, just
reported by LiS.
LiS' open_mods() calls lis_qopen() which in turn calls the open
routines of the modules associated with the devices being opened.
It is one of the module's open routines (part of CS?) that is
reporting error 16 (EBUSY).
Note that this path is only followed when an existing stream is
being reopened. Given the error EBUSY, reopening may not be
supported by that module. It may be that you need to change some
configuration to use /dev/XX1 and /dev/XX2 rather than both using
/dev/XX1. Or it may be that the /dev entry is built incorrectly
and should be a cloning device (have the major number of the
clone driver and the min number equal to the add-on module's
major).
In any event, it looks like the problem is CS-specific.

Post by Alvarez, Angel
PS:this is the second message. I can't view the archives at
http://gsyc.escet.urjc.es/mailarchive/linux-streams

http://www.mail-archive.com/linux-streams%40gsyc.escet.urjc.es/
Regards,
Steve
------------------------------------------------------------------------
Steve Schefter phone: [phone] x26
The Software Group Limited fax: [phone]
Barrie, Ontario CANADA L4N 9A1 Web: www.wanware.com
_______________________________________________
Linux-streams mailing list
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams

[Steve Schefter]

Post by Brian F. G. Bidulock
SVR 4.2 STREAMS modules do no return negative error numbers, they
return MODOPENFAIL, which is translated to ENXIO when returned to
the opening process. LiS does not comply to SVR 4.2 because it
does not accept a positive error code. Almost everywhere you point
LiS has an error. This is just an example where someone happened
to point.

Does SVR 4.2 Streams say that MODOPENFAIL is a postive number?

Your Streams programer's guide is a little more up to date than
mine (System V/3.2). Mine indicates that >= 0 should be returned
for success and OPENFAIL (must therefore be a negative number)
for error. In my modules, I return OPENFAIL but as evidenced by
the IBM modules, not everyone does that.

The other references I have at hand are Solaris and UnixWare.
Solaris docs indicate that "The return value from open is 0 for
success and an error number for failure". UnixWare does likewise
but specifically lists error codes (eg EACCESS, EADDRINUSE)
which, on Linux, translate to negative numbers.

If something other than OPENFAIL is coming out of the open
routine, it's the module that's doing that, not LiS.
In my opinion, Dave made a good choice in looking for _any_
negative number. It could be strict about making sure that
the driver returned OPENFAIL/MODOPENFAIL, but that would break
drivers being ported from other OSes. And it begs the question
about what Streams would do if the driver returned neither >= 0
nor OPENFAIL/MODOPENFAIL. Indicate a error back to the app
(which is what the driver is trying to do)?

Steve

------------------------------------------------------------------------
Steve Schefter phone: [phone] x26
The Software Group Limited fax: [phone]
642 Welham Road, email: ***@wanware.com
Barrie, Ontario CANADA L4N 9A1 Web: www.wanware.com

[Brian F. G. Bidulock]

Steve,

SVR 4.2 STREAMS Programmer's Guide: Section 6.5 Design Guidlines,
6.5.1 Modules and Drivers, 6.5.1.1 Rules for Open/Close Routines,

2. The open routine should return zero on success and an error number on
failure. ...

Under UNIX, error numbers are not negative.

On the POSIX ioctl manual page, only ENXIO is returned when the push
of a module fails. Thus OPENFAIL (sorry, not MODOPENFAIL).

--brian

Post by Steve Schefter

Post by Brian F. G. Bidulock
SVR 4.2 STREAMS modules do no return negative error numbers, they
return MODOPENFAIL, which is translated to ENXIO when returned to
the opening process. LiS does not comply to SVR 4.2 because it
does not accept a positive error code. Almost everywhere you point
LiS has an error. This is just an example where someone happened
to point.

Does SVR 4.2 Streams say that MODOPENFAIL is a postive number?
Your Streams programer's guide is a little more up to date than
mine (System V/3.2). Mine indicates that >= 0 should be returned
for success and OPENFAIL (must therefore be a negative number)
for error. In my modules, I return OPENFAIL but as evidenced by
the IBM modules, not everyone does that.
The other references I have at hand are Solaris and UnixWare.
Solaris docs indicate that "The return value from open is 0 for
success and an error number for failure". UnixWare does likewise
but specifically lists error codes (eg EACCESS, EADDRINUSE)
which, on Linux, translate to negative numbers.
If something other than OPENFAIL is coming out of the open
routine, it's the module that's doing that, not LiS.
In my opinion, Dave made a good choice in looking for _any_
negative number. It could be strict about making sure that
the driver returned OPENFAIL/MODOPENFAIL, but that would break
drivers being ported from other OSes. And it begs the question
about what Streams would do if the driver returned neither >= 0
nor OPENFAIL/MODOPENFAIL. Indicate a error back to the app
(which is what the driver is trying to do)?
Steve
------------------------------------------------------------------------
Steve Schefter phone: [phone] x26
The Software Group Limited fax: [phone]
Barrie, Ontario CANADA L4N 9A1 Web: www.wanware.com