Date: Fri, 2 Jun 1995 22:21:52 -0500 (CDT) From: "Gil Kloepfer Jr." <gil@limbic.ssdl.com> To: bugs@FreeBSD.org Subject: Update on kern/466 + more Message-ID: <199506030321.WAA23819@limbic.ssdl.com>
next in thread | raw e-mail | index | archive | help
Okay... Here are the gory details on my continuing problems with installing
2.0.5-A on an ESDI drive with some bad blocks...
As suggested previously, I disabled sector sparing by low-level formatting
the disk with the option off in the controller. We're now back to the
physical geometry of the disk.
Turned on verbose mode...
First problem I noticed right away was with the partition table editor.
I don't know about the rest of you, but I get different flag values every
time I enter and exit this beast. Because of this, it's extremely hard
to tell if I've selected "bad block handling" or not. It seems like if
you press the B key more than once, you start creating all sorts of
interesting values for 'flag'... This also happens with the "set active
partition" ... so I would look at this a bit and see if the flag bits
are being toggled right. Eventually I did select what I wanted here--
60MB (existing) DOS partition, and the rest of the disk for FreeBSD.
Set-up the slices, as mentioned before: 20MB /, 32MB sw, 80MB /usr, 10MB /var,
120MB /source. This worked as advertised.
Did everything else...you know all this by now, if you've been through the
installation as much as I have... :)
Went to Install ... started checking for bad blocks as it should be. I
looked over at the debug screen to see what was going on.
The first nasty I noticed is that it looked like it was trying to write
the bad block file off the end of the disk. I'm not 100% sure about this
(sure would be nice to get to a shell prompt...)...but in any case, it
had a disk error each time it tried to do its magic with the bad block
file. I'm not going to pretend to know what it was doing here -- I'm
trying to relay as much as I can before it all went off the screen. I'm
supping -current now to see if I can provide some more intelligent
feedback...
Anyhow, bad block scanning then went as it should -- there's about 36 bad
sectors on this disk, as I recall...and this looked about right. That's
a new first for bad144 -- it never used to detect the bad blocks right.
BUT...when it was done scanning for bad blocks (at least this is what
appeared to have happened), it SIG11'd (memory fault) and tried to dump
core to the floppy and obviously failed (out of space). The last message
from bad144 was:
Block: 536861 will be marked BAD.
>From here, I can do nothing but reboot the machine by hitting escape.
Answering questions only produces nasty error messages and out of space
errors. If you get an error back from a program like bad144, I'd say
that in most cases you can abort the installation.
There are several problems I see with the bad144 stuff that gives me a
bad (no pun intended) feeling. First off, I it took me a while but
I finally discovered that the offsets it was reporting at the beginning
(when bad144 first ran) are relative to the beginning of the FreeBSD
slice. It looks like it's trying to put a bad block table at the end
of my 1223 cyl. disk. Back a long time ago, this was not a good thing
because of the BIOS 1024 cyl limitations. The other thing I recall
is that when you made the disklabel, you were suppose to leave some
space before the end of the FreeBSD slice for the bad144 table. I
don't know if this has changed, but I didn't do this when I used the
label editor, and it didn't say I had to either. In any case, I think
I may be off in left field about the memory fault, but I thought that
bringing this up may raise the red flag about some old problems that
may need to be addressed.
It takes a good part of an hour or so to low-level format this disk...
so I don't want to do what I'm about to suggest unless necessary. My
controller has a 63 sector translation mode that allows drives with >1024
cyl to be used (works like IDE translation works now). I want to avoid
using this because it just complicates debugging ("is it the controller
or FreeBSD causing the problem?") and makes it hard to take advantage
of the physical geometry of the disk.
Not to harp on this much more ... I enabled sector sparing way back
when bad144 was just not reliable and I found myself spending hours
building a system. It has worked up though 2.0-RELEASE... so something
is different that keeps it from working in 2.0.5-ALPHA. I don't see
any need to go to sector sparing (and waste disk space) if bad144 works,
but it seems like it still is kind of in a funny state yet. I'm more
than happy to help, but I'm going to need some way of finding the
offending part of bad144 that's causing the problem.
Hope this helps.
--
Gil Kloepfer
e-mail: gil@SSDL.COM
WWW: http://www.ssdl.com/~gil/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506030321.WAA23819>