Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 Oct 1998 20:37:18 -0500 (EST)
From:      John Fieber <jfieber@indiana.edu>
To:        msmith@FreeBSD.ORG
Cc:        nash@mcs.net, emulation@FreeBSD.ORG
Subject:   Sybase update
Message-ID:  <Pine.BSF.4.02A.9810022017020.1057-100000@fallout.campusview.indiana.edu>

next in thread | raw e-mail | index | archive | help
Alex Nash and I have narrowed the problem with the Sybase server
considerably. In fact, via an unacceptable hack it actually
works.

The problem is asynchronous i/o on a socket.  As part of the
initialization, the server sets up a socket for client
connections which looks all okay and installs as SIGIO handler.
Everything about the initialization look okay and compares well
with a syscall trace generated on a Linux box...pretty much all
differences can be explained.

Unfortunately never receives a SIGIO when a client connects.
Watching the network shows a standard opening and closing of the
TCP link but no response from the server.

THE HACK: once the server is started, lookup the PID and
continouously fire SIGIOs at it, eg:

  $ while true; do kill -IO <pid>; done

and voilla! the server works!  UGLY isn't it?  :-)

Here is a snippet of the syscall trace where the socket is setup
(this is the linux one, much more readable than the FreeBSD one):

 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
 setsockopt(5, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
 setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
 getpid()		     = 1191
 ioctl(5, SIOCSPGRP[, 1191]) = 0
 fcntl(5, F_SETOWN, 1191)    = 0
 fcntl(5, F_SETFL, O_RDONLY|O_NONBLOCK|O_ASYNC) = 0
 bind(5, {sin_family=AF_INET, sin_port=htons(5000), sin_addr=inet_addr("192.168.129.58")}, 16) = 0
 listen(5, 128) 	     = 0

Two things I've had to change:
 
  * The SIGIO and SIGURG values in linux.h were reversed.  I
    think they must have come from an incorrect man page (I found 
    one on the net that had them wrong).

  * F_SETFL didn't handel the O_ASYNC option.  I added support
    to F_GETFL as well.
  
Note that fixing the second without fixing the first resulted in a
panic suggesting that somewhere in the kernel, there must be some
action on the signals.

At this point I'm getting a little over my head so any ideas of what
to try next are most welcome.  It would be super if 3.0 could
ship "Sybase ready" which would grease the rails for lobbying
Sybase to either loosen the License or give us a native version.

On the client side things are better.  The only hangup is that if
uname(2) returns a fully qualified internet name, the client library
gets confused about the local host name and most applications just
bail out at that point.  I stuck a quick hack that truncates the
hostname at the first period which makes it work, but that seems a
little drastic.

-john



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-emulation" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.02A.9810022017020.1057-100000>