Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!jato!hanauma.jpl.nasa.gov!hyc
From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
Newsgroups: comp.sys.alliant
Subject: TCP/IP kernel code
Message-ID: <1991Mar27.225630.6796@jato.jpl.nasa.gov>
Date: 27 Mar 91 22:56:30 GMT
Sender: news@jato.jpl.nasa.gov
Organization: SAR Systems Development and Processing, JPL
Lines: 16
Nntp-Posting-Host: hanauma.jpl.nasa.gov

Are there any Alliant kernel hackers reading this group? I've just recompiled
the Reno BSD TCP release and tried to shoe-horn it into our Concentrix 5.6
kernel, but despite hunting down all the unresolved symbols and other interesting
problems, I can't get the system running. 

A bus error occurs in the LCK_exclusive routine, invoked from in_pcballoc,
invoked from tcp_attach. I know that the inpcb has a system lockid in the
structure, but I didn't expect that any TCP-level code had to worry about it.
in_pcballoc appears to be passing a null address into LCK_exclusive. Where
does this lockid variable get initialized? Browsing the symbol tables of the
Concentrix tcp modules doesn't yield any references to this lockid, so why
is it being initialized OK with the Concentrix code but not with the new
TCP? Please save me from another few hours with adb and ddt!
-- 
  -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA
	Disclaimer: How would I know, I just got here!