Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Oct 1996 00:52:40 -0700 (PDT)
From:      "Bryan K. Ogawa" <bkogawa@primenet.com>
To:        freebsd-questions@freebsd.org
Subject:   2.1.5, BROKEN_KEYBOARD_RESET, and AHA-2840 VLB = overwrite super , block on reboot
Message-ID:  <Pine.BSI.3.94.961002004057.23046B-100000@foo.primenet.com>

Next in thread | Raw E-Mail | Index | Archive | Help

Hi.

First, I'd like to thank Doug White for the info on why BootEasy on my wd0
couldn't find my partition, but the BootEasy on the SCSI disk could (it
was a geometry problem on wd0 -- to fix, you need to reformat the drive
with the proper geometry--I found out that the Boot floppy can do this,
although you lose the contents of your drive when you do it).

That now works fine.

Unfortunately, I have traced another problem.

This motherboard is using one of the IBM 486 'Blue Lightning' chips, which
apparently doesn't respond to the keyboard reset.  I added
BROKEN_KEYBOARD_RESET to the kernel, and recompiled.

With the new kernel in place, the system works fine.  Unfortunately,
whenever FreeBSD triggers a reboot (e.g. shutdown -r or pressing a key on
the console after shutdown -h), the SCSI drive loses its super block.

I have confirmed that this happens only when FreeBSD triggers the reset,
and not when the system is reset via the reset button.  Waiting for a
while after the shutdown -h for the controller to write out its cache
doesn't matter.  I also noticed that the drive light on the SCSI drive
(which is in its own housing) flashes briefly after the system resets.

This reliably appears to destroy the entire super block--fsck cannot
run on the drive (no magic number), and instructs me to manually fsck the
drive (which will not work unless I use fsck -b 32 /dev/rsd0e ).  The fsck
only finds the superblock corrupted (after the first time, when I think it
found some damage to the original superblock), and offers to copy back the
superblock for me.

Has anyone experienced this problem?  I'm using an Adaptec 2840 VLB, which
may be part of the problem (it appears to use the ahc0 driver, although
the apparent disk write occurs before the system actually starts booting,
when the Adaptec seems to be scanning its drives).  Could this be
happening because the reset trys to pull all of system memory?


bryan k ogawa  <bkogawa@primenet.com>   http://www.primenet.com/~bkogawa/




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.94.961002004057.23046B-100000>