From owner-freebsd-hackers  Tue Jun  6 07:00:55 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id HAA20875
          for hackers-outgoing; Tue, 6 Jun 1995 07:00:55 -0700
Received: from haywire.DIALix.COM (peter@haywire.DIALix.COM [192.203.228.65])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA20868
          for <hackers@freebsd.org>; Tue, 6 Jun 1995 07:00:44 -0700
Received: (from peter@localhost) by haywire.DIALix.COM (8.6.12/8.6.12/DIALix) id WAA26547; Tue, 6 Jun 1995 22:00:36 +0800
Date: Tue, 6 Jun 1995 22:00:34 +0800 (WST)
From: Peter Wemm <peter@haywire.DIALix.COM>
To: hackers@freebsd.org
Subject: Doom!  It's dangerous...
Message-ID: <Pine.SV4.3.91.950606215422.6655B-100000@haywire.DIALix.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: hackers-owner@freebsd.org
Precedence: bulk

Try compiling your kernel with "options DIAGNOSTIC" and see how quickly 
it blows up.

It appears to be passing vnodes around to functions that are expecting 
them to be locked, but in fact, are not locked (eg: ufs_access, while 
trying to load /lib/ld.so).

Alas, we can't see the source to see if it's an isolated bug or somthing 
that's more prolific.

Also, it causes compile warnings if you compile with "options KTRACE".
Something is suspect in the COMPAT_LINUX code in i386/trace.c

But, at last, I've almost got it working.. All I need to figure out now, 
is why it comes up in about 4 colours.. (black, grey, white, and red).  
It's definately running on a 256 colour server (all to itself even).

Also, I binary edited /lib/ld.so so that the resolv+ resolver in the 
linux libc doesn't get it's knickers in a knot over the freebsd format 
/etc/host.conf

Cheers,
-Peter