Bug 78952

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)
Gecko/20011128 Netscape6/6.2.1

Description of problem:
    LTC1453-CS/Linux fails to start on RedHat Adv. Server 2.1

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
Hardware Environment: IA-32 RH AS 2.1

Software Environment:RH AS2.1


Steps to Reproduce:
1.Install RedHad Advance Server
2.Install Open Streams LiS (Streams)
3.Install Communications Server for Linux V6.001
4.try to start Communications Server (sna start) and it fails
	

Actual Results:  Failure reported in error log. Traces show the sna device
drivers are reporting "Device or resource busy"

Expected Results:  Cs/Linux should start. It has successfully started on:
and Linux kernels
- RH7.2 (2.4.7)
- RH7.3 (2.4.18)
- RH8.0 (2.4.18)
- SuSE 8.0 (2.4.18)
- SuSE 8.1 (2.4.19)
- SuSE Linux Enterprise Server (2.4.19)

Additional info:

Additional Information: This problem is blocking a larger roll out of the
Branch Server product for Linux project. The Cs/Linux is needed for the Red hat
Adv. 2.1 system with WAS, DB/2 and a suite of other applications.
Here is more details. The question at the end NEEDS TO BE ADDRESSED by Red Hat
Development:

We have reproduced the problem here with the same symptoms as you have seen.
However the cause appears to be O/S related and we would like you to use
your contacts within Redhat to see if you can get assistance before we
investigate further.

The drivers are loaded correctly (with insmod). The first driver that we
talk to is the non-streams trace driver /dev/sna_trace (snapixt). We issue
an open followed by a number of ioctls from the snaerrlog daemon prior to
starting up the Streams part of the product. On RH AS2.1 we see the
following behaviour:
- The open appears to be sent correctly from the daemon to our driver and an
OK return code of 0 causes a file handle to be assigned.
- The first ioctl that we issue does not get received by our driver's ioctl
code (as indicated by printks we have added). However the O/S replies with
an OK (0) return code.
- The second and subsequent ioctl calls arrive at our open routine in the
driver rather than our ioctl routine where we reject it with EBUSY (since we
only allow one open to this driver). This return code is reported back to
the daemon. This causes CS/Linux to fail to start.

You can reproduce the problem by using snaldmod or just loading snapix0 and
snapixt (and mknod of /dev/sna_trace) and running snaerrlog directly as
root. A failure is indicated by this program exiting. I have modified the
snaerrlog to ignore one bad return code and introduce 1 second delays
between the ioctl calls, I enclose the strace output.

Before I go to the next step of diagnostics which would be to try and write
a cut down driver and daemon that show this problem I wanted to find out if
this was a known issue with ioctls. Note that we are not using the
recommended _IO* macros to define command codes but using our own private
values, my understanding is that this should be OK.

Question:Is there something different about the RH AS 2.1 (2.4.9) that prevents
ioctls working in drivers?

 Additional comments from the submitter
We have found additional Linux Kernel information regarding this problem. It
appears the the 2.5.47 kernel has changed so that the sna drivers cannot
initiate. We need to find what changed so as to isolate a fix around what the
new mechanism is for starting drivers on the new kernel.

Attached are 2 e-mails from developers and I am attaching the logs supplied:

I have been playing around with a 2.5.47 kernel (generic
development kernel, not in any released distribution) to
see how CS/Linux would do on it.  The latest LiS does fine
on this kernel, so after making some changes to snalinux.c
and cc_snalinux I was able to generate an isolation module
and load the CS/Linux drivers.  Then I did 'sna start' and
got the same "Device Busy" message that we are seeing on
RHAS2.1.

Can you send me the debug snaerrlog and instructions so I
can confirm that it is the same cause?

If it is the same cause we would know that it is because of
a kernel change made by RedHat for AS2.1 that is being rolled
into the 2.5.* development kernels and which would eventually
find its way into a 2.6 production kernel.

------- Additionally ----------
Looks the same to me:


RedHat AS 2.1 started with the same base as RedHat 7.2,
but obviously they changed it (otherwise why have an AS2.1
to begin with).  Whether the changes flowed from AS2.1
into the 2.5 kernel or the other way around is irrelavent,
I think examples of both could be found.  The point is that
the change which affects CS/Linux was a deliberate one,
and one that was accepted by Linus & others for inclusion
in 2.5 and later.  Now if we can find what that change was
we would have a better chance of knowing how to work with it.

additional comment re attachment