From owner-cvs-all  Thu Nov 19 10:12:01 1998
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id KAA00851
          for cvs-all-outgoing; Thu, 19 Nov 1998 10:12:01 -0800 (PST)
          (envelope-from owner-cvs-all@FreeBSD.ORG)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA00822;
          Thu, 19 Nov 1998 10:11:59 -0800 (PST)
          (envelope-from paul@FreeBSD.org)
From: Paul Richards <paul@FreeBSD.ORG>
Received: (from paul@localhost)
	by freefall.freebsd.org (8.8.8/8.8.5) id KAA03802;
	Thu, 19 Nov 1998 10:12:04 -0800 (PST)
Date: Thu, 19 Nov 1998 10:12:04 -0800 (PST)
Message-Id: <199811191812.KAA03802@freefall.freebsd.org>
To: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject: cvs commit: src/sys/boot/common bcache.c
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

paul        1998/11/19 10:12:04 PST

  Modified files:
    sys/boot/common      bcache.c 
  Log:
  This fixes a bug in the bcache code whereby false cache hits occur
  the first time block 0 is read. This fix initialises the block
  numbers to -1 which isn't the most correct thing for a daddr_t but
  it isn't likely to cause a problem in the boot blocks and it could
  do with a more thought out fix later.
  
  The bug is probably benign on the i386 but on the alpha it can
  cause initial file opens to fail. This is the cause of the "can't
  open /boot/boot.conf" errors.
  
  It appears on the alpha because of a number of combining factors.
  On the alpha the LABELSECTOR is 0 so block 0 needs to be read in
  from the media. The first time this happens you get a false hit
  because the bc_blkno field is zero initially. Also, the timestamp
  check against this cache hit succeeds because on the alpha a hacked
  getsecs() function can return 0 when it starts counting so that
  the zero initial timestamp + BCACHE_TIMEOUT is greater than the
  current time until getsecs() has counted passed BCACHE_TIMEOUT.
  
  The overall effect is that the first open() that occurs gets a
  false cache hit and returns garbage to the bd_strategy() function
  which then fails the open() call. This false hit then stays in the
  cache until BCACHE_TIMEOUT getsecs() ticks have passed; all open()
  calls during this time fail.
  
  This explains why you can generally access the media by the time
  you get to interp() and start issuing commands but the earlier
  attempts to run the boot scripts are failing.
  
  It's possible that this is causing the problem switching to the
  mfsroot floppy as well but I haven't confirmed that.
  
  Revision  Changes    Path
  1.4       +4 -2      src/sys/boot/common/bcache.c

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