Hi all,
Quick question, how does the new ata driver handle bad blocks?
I've been tracking -current since around Nov 99 but haven't
seen this come up.
I have a drive which I know has some bad blocks. I install 3.2 (just
cause its laying around), use bad block scan in sysinstall everything's
fine (it finds the bad blocks), I can cvs, build and install -current on it.
Build and install a kernel (with the new ata driver), reboot, still no probs,
until I find a bad block :) At this point it dosen't ignore the block but
tries to access it, it does give up after a few attempts. So, perhaps its not
happy with the 3.2 bad block info, so I try; bad144 -v -s ad0 (the output is
attached). It looks like it finds the bad blocks with no problems, but, when
I reboot, it can't mount root;
[device probe snip]
Mounting root from ufs:/dev/ad0d1a
ad0: bad sector table not supported
ad0s1: bad sector table not supported
Root mount failed: 22
Mounting root from ufs:/dev/wd0s1a
wd0: bad sector table not supported
wd0s1: bad sector table not supported
Root mount failed: 22
Mounting root from ufs:/dev/wd0a
wd0: bad sector table not supported
wd0s1: bad sector table not supported
Root mount failed: 22
Manual root filesystem specification:
<fstype>:<device> Mount <device> using filesystem <fstype>
eg. ufs:/dev/da0s1a
? List valid disk boot devices
<empty line> Abort manual input
>>>
Here's the trace, if its useful;
(kgdb) bt
#0 Debugger (msg=0xc025fea9 "manual escape to debugger")
at ../../i386/i386/db_interface.c:319
#1 0xc02257e6 in scgetc (sc=0xc02bed80, flags=1)
at ../../dev/syscons/syscons.c:3134
#2 0xc02236b3 in sccngetch (flags=0) at ../../dev/syscons/syscons.c:1544
#3 0xc022354a in sccngetc (dev=0xc02a6340) at ../../dev/syscons/syscons.c:1470
#4 0xc014d07d in cngetc () at ../../kern/tty_cons.c:406
#5 0xc015cd55 in gets (cp=0xc0324f04 "s") at ../../kern/vfs_conf.c:280
#6 0xc015ccb2 in vfs_mountroot_ask () at ../../kern/vfs_conf.c:254
#7 0xc015ca47 in vfs_mountroot (junk=0x0) at ../../kern/vfs_conf.c:154
#8 0xc0127ec8 in mi_startup (framep=0xc0324fb4) at ../../kern/init_main.c:217
I can't think of what else might be useful (its 2:30am here ATM) :)
It was cvs'd and built a few days ago, but I haven't noticed anything
commited that would affect this since then.
Anyways, coherency isn't my strong point at 2:30am :) If anyone would
like further details (or to flame me), I'll be back in the morning :)
Cheers,
Kent Ibbetson
[EMAIL PROTECTED]
bad144.log
