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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.94.961002004057.23046B-100000>