Re: TLI failure

Hi Robert,

our goal is the same to get a XTI application that works with different 
unixes running on linux. We know that this is not an easy task so we try 
to find people that can support that work. We also know that the kernel 
should never crash. What we need are people that at least can encircle 
the problem at userspace. Of course having people that we able to and 
willing to do the non trivial task of trackling down the problem in the 
driver is of way more value. So said we need at least information of the 
last syscall that crashed the system. Furthermore you are running a smp 
system. Did you try with up also? It would also be of great help to know 
whether the problem is smp related or not. Of course it is your decision 
to port your project to sockets. They are working well and are tested by 
millions of users and developers. We definitely do not reach that state 
in one week or two.

Christian

[email protected] schrieb:

>Dear All,
>
>I've been in communication with  Brian Bidulock and Christian Hildner
>regarding problems with XTI.
>
>This is to record my thoughts at present, because I don't know where its
>going, and perhaps some other poor soul will benefit from my experience.
>
>I am using Redhat Linux with a 2.4.21-27.0.2.ELsmp kernel and dual Intel
>processors.
>
>I can configure, make and install the driver. I can run the test programs.
>The original GCOM site indicates that the driver is o.k. with SMP, which
>would tend to be supported by the test programs.
>
>My legacy program from AIX uses tcp. It compiles against the driver. It
>doesn't run.
>The sample programs from HOB compiled after changes to the include files. I
>think that's all I did, but when it ran
>it crashed the kernel on transferring data.
>
>My thought process has worked as follows:-
>
>1 Are there any test programs that come with the driver which do work in
>this situation.
>  a) test-xnet, superficially seems representative. GDB wouldn't 'follow a
>child fork' so it was down
>     to taking a long look at the code. Although this code does execute the
>XTI interface, it does so over a pipe
>     and as a result none of the data structure need to be populated for it
>to run.
>     So its not very representative, and not really a comprehensive test
>for any transport other than a pipe. In the
>     here and now, it would be a brave person who would say thattcp was not
>a driving force.
>  b) test-inet_tcp also seemed a good candidate, but inspection of the code
>(few comments as ever) revealed that
>     it wasn't what I was looking for being more streams based.
>  c) I couldn't find anything else that fitted the bill.
>
>2. I'm sure that the test programs are comprehensive in their own way, but
>they're certainly not all encompassing, and don#t cover tcp over XTI.
>3. Because the test programs work on my SMP box, it might lead me to
>believe that the driver software was sound.
>4. My belief now is that the driver isn't sound, because no user space
>program should bring the system down.
>5. How do I report it? How do I report what! Unless someone has the
>time/machine to debug the driver it is unlilely to get fixed, even if I
>could offer more information about the bug which I can't. I could spend
>project time debugging the driver, but it is becoming more difficult to
>justify the amount of time I am spending not getting
>my legacy code going.
>6. Having spent a fair few days believing that XTI would work on this
>Driver I felt that my project would have been better served by just
>converting the legacy software to sockets.
>7. O.k., so as Christian says its beta, but I've used beta stuff before,
>and at that stage you would expect it to
>be a little better than crashing the system.
>
>At a crossroads... is XTI too old hat? even though this driver software
>isn't finished?
>
>
>
>_______________________________________________
>Linux-streams mailing list
>[email protected]
>http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
>
>  
>