From owner-freebsd-current Wed Oct 1 17:36:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA19406 for current-outgoing; Wed, 1 Oct 1997 17:36:23 -0700 (PDT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.54]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA19400; Wed, 1 Oct 1997 17:36:18 -0700 (PDT) Received: (from kargl@localhost) by troutmask.apl.washington.edu (8.8.7/8.8.5) id RAA00335; Wed, 1 Oct 1997 17:38:49 -0700 (PDT) From: "Steven G. Kargl" Message-Id: <199710020038.RAA00335@troutmask.apl.washington.edu> Subject: netatalk broken in -current To: wollman@freebsd.org Date: Wed, 1 Oct 1997 17:38:48 -0700 (PDT) Cc: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Garrett, [cc'd to freebsd-current] Netatalk is broken in -current. I've tracked the problem down to commits made on Aug 16. A kernel built with sources cvsup'd with *default host=cvsup.FreeBSD.org *default base=/freebsd *default prefix=/freebsd *default release=cvs tag=. *default delete use-rel-suffix *default date=97.08.16.00.00.00 boots and netatalk works. If date= is changed to 97.08.17.00.00.00, then the resulting kernel claims that the netatalk protocols are not supported. I believe that this problem arose with some of the changes to src/sys/netatalk/ddp_usrreq.c. ----------------------------- 1.9 Sat Aug 16 19:15:33 1997 by wollman Diffs to 1.8 Fix all areas of the system (or at least all those in LINT) to avoid storing socket addresses in mbufs. (Socket buffers are the one exception.) A number of kernel APIs needed to get fixed in order to make this happen. Also, fix three protocol families which kept PCBs in mbufs to not malloc them instead. Delete some old compatibility cruft while we're at it, and add some new routines in the in_cksum family. ----------------------------- Unfortunately, it looks like massive changes went into cleaning up the use of mbufs, so I don't know where to look to fix the problem. -- Steve finger kargl@troutmask.apl.washington.edu http://troutmask.apl.washington.edu/~kargl/sgk.html