From owner-freebsd-current  Sun Nov 23 11:03:58 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA24745
          for current-outgoing; Sun, 23 Nov 1997 11:03:58 -0800 (PST)
          (envelope-from owner-freebsd-current)
Received: from mom.hooked.net (root@mom.hooked.net [206.80.6.10])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA24740
          for <current@freebsd.org>; Sun, 23 Nov 1997 11:03:54 -0800 (PST)
          (envelope-from garbanzo@hooked.net)
Received: from fish.hooked.net (garbanzo@fish.hooked.net [206.80.6.48])
	by mom.hooked.net (8.8.5/8.8.5) with SMTP id LAA19664
	for <current@freebsd.org>; Sun, 23 Nov 1997 11:03:53 -0800 (PST)
Date: Sun, 23 Nov 1997 19:03:53 +0000 (GMT)
From: Alex <garbanzo@hooked.net>
To: current@freebsd.org
Subject: Weird hanging problem
Message-ID: <Pine.BSI.3.95.971123185533.29418A-100000@fish.hooked.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

I'm running a make world from about three weeks ago, and noticed
that when I use a kernel I generated from Mr. Gibbs's cam
snapshot of 11/13 that everything works just fine, and dandy.
Switching to a snapshot from 11/17 causes random hangs when I do
biff y;fetchmail -d0 on one console, and load pine on another (the bovine
rc5 client is on another console).  The weird thing is that the machine
isn't hung, but it takes about 40 seconds for it to switch vts (which it
only will do once), alt-ctrl-del won't work, and the {num|caps|scroll}lock
lights do work.  This forces a tap of the reset button :(  I thought maybe
it was Mr Gibbs's code, but I tried a kernel from sources cvsup'd on the
22nd (identical config, except sd vs da and ahc_tagenable and scbpaging  
have been disabled) and got the same result.

< semi rant >
On a side note, I switched some stuff around in the scsi bios, which makes
scsi id 1 = 0x80 and id 0 = 0x81, so I can boot off id 1.  This means,
that root will be on {sd|da}0, when the Booteasy thingy thinks it is on
{sd|da}1.  Even with a root on {da|sd} 0, the booteasy manager will
overide this, and panic the kernel.  To me this seems broken, even if this
_is_ the desired operation.  I think it should at least try whatever root
on is suggesting.
</rant>

Any help would be appreciated.

- alex