11 Dec
2015
11 Dec
'15
5:50 p.m.
Exciting stuff for a Friday night, right? Here's a visual aid in case
you're needing further inspiration:
https://www.instagram.com/p/_K-zHhHvLn78Qu5ijWqMf-HBem1LKMLaEdI1c0/ The
M2333K is the smaller one on the left with the green and yellow lights on.
I'm booting from rl0, which contains the tuhs 2.9.1 rl02 image I wrote with
vtserver earlier.
I want to use my nice, roomy smd disk so I can pull in all the sources and
recompile stuff and I've managed to get this *so* close to working but I'm
getting
xp0a: hard error bn xxxx cs2=1100 <MXF, IR> er1=0
on every single block when I try to mkfs /dev/xp0a 4800
This disk was working fine years ago via MSCP attached to the 11/73 (before
I lost the Micro/11 power supply).
Anyway, I referred to
http://bitsavers.trailing-edge.com/pdf/emulex/SC2151001-CC_SC21tech_Jan87.p…
to set the emulation on the Emulex card for two rm03s and they're showing
up in xxdp's zrmlb1 formatter, though they won't format there, screensful
of errors.
I think I set the m2333k to 32 sectors, per this manual:
http://manx.classiccmp.org/collections/antonio/chrisq/B03P-4760-0101A_-_M23…
Because XXDP is reputed to be really strict, I figured that was normal and
then tried the Emulex on-board formatting procedure against both xp0 and
xp4 and they formatted perfectly without error. Guess the Emulex on-board
stuff doesn't bother verifying much?
So I think that maybe I've misunderstood the hard sectoring / sector sizing
thing. Does anyone remember the gist of it and would you be able to
describe? Do you see any other mistakes?
thx
jake
11 Dec
11 Dec
7:28 p.m.
On Fri, Dec 11, 2015 at 8:50 PM, Jacob Ritorto <jacob.ritorto at gmail.com> wrote:
Exciting stuff for a Friday night, right?
It is!
Nice!
xp0a: hard error bn xxxx cs2=1100 <MXF, IR>
er1=0
on every single block when I try to mkfs /dev/xp0a 4800
I can't help you with M2333K specifics, but do you get anything
meaningful if you use 'dd' on the raw disk, first to read, then to
write?
ISTR /dev/xp0c or /dev/xp0g might be the "all the disk" partition. It
doesn't really matter _which_ partition you are trying to read from,
but might as well start at the beginning and allow it to go to the
end.
If you can't read a block at the OS level, you probably won't be able
to write it to drop a filesystem on it (I'm sure there are imaginable
scenarios where that's possible, but for a simple smoke test, just try
to read one block with dd and pipe it to 'od'. I can't remember if od
is available on 2BSD, but dd is most likely there since I think I
remember using it to stuff bootblocks at the fronts of disks). Of
course there are several imaginable scenarios where you could read but
not write. Write but not read is far, far less conceivable.
-ethan
9:33 p.m.
On 12/11/15 5:50 PM, Jacob Ritorto wrote:
Exciting stuff for a Friday night, right? Here's
a visual aid in case
you're needing further inspiration:
https://www.instagram.com/p/_K-zHhHvLn78Qu5ijWqMf-HBem1LKMLaEdI1c0/ The
M2333K is the smaller one on the left with the green and yellow lights on.
I'm booting from rl0, which contains the tuhs 2.9.1 rl02 image I wrote with
vtserver earlier.
I want to use my nice, roomy smd disk so I can pull in all the sources and
recompile stuff and I've managed to get this *so* close to working but I'm
getting
xp0a: hard error bn xxxx cs2=1100 <MXF, IR> er1=0
on every single block when I try to mkfs /dev/xp0a 4800
This disk was working fine years ago via MSCP attached to the 11/73 (before
I lost the Micro/11 power supply).
Anyway, I referred to
http://bitsavers.trailing-edge.com/pdf/emulex/SC2151001-CC_SC21tech_Jan87.p…
to set the emulation on the Emulex card for two rm03s and they're showing
up in xxdp's zrmlb1 formatter, though they won't format there, screensful
of errors.
I think I set the m2333k to 32 sectors, per this manual:
http://manx.classiccmp.org/collections/antonio/chrisq/B03P-4760-0101A_-_M23…
Because XXDP is reputed to be really strict, I figured that was normal and
then tried the Emulex on-board formatting procedure against both xp0 and
xp4 and they formatted perfectly without error. Guess the Emulex on-board
stuff doesn't bother verifying much?
So I think that maybe I've misunderstood the hard sectoring / sector sizing
thing. Does anyone remember the gist of it and would you be able to
describe? Do you see any other mistakes?
thx
jake
I'm not an expert with SMD drives and I've never used your particular
controller (I have a slightly newer Emulex in my 11/44) but here's a
couple of things I noted while leafing through the SC21 manual you linked:
1.) The SC21's format does *no* verification at all. It lays down an
initial format and that's it. It doesn't create the bad-block list
(more on that later).
2.) Section 6 of the manual lists a set of modifications (patches) that
need to be made to XXDP diagnostics in order for them to work properly
with the SC21. This includes the ZRMAC0 formatter form RM02/RM03.
You'll likely need to apply them; hopefully you can find the required
versions to hack...
3.) In addition to setting the sector size/sector count on the Fujitsu,
did you also configure the SC21 for the appropriate drive? (see Appendix
A) I don't see an M2333 listed there specifically, but there might be
something with a similar (or identical) geometry you can use instead.
Regarding the bad-block list: You are going to need this to be
generated properly, and the only way to do that is to run the
appropriate XXDP formatter and exercisers. If you have the bad block
list for the drive, hopefully one of the diags will let you enter it,
otherwise I suggest running *many* passes of the exercisers until they
stop finding bad blocks.
After you have that step done, you will need to have a 2.9.1BSD kernel
that's been compiled with bad block support, otherwise BSD will simply
ignore bad sectors and assume the whole disk is good -- which will cause
bad things to happen as soon as something is written over a bad sector.
(Apologies if any of the above is already old-hat; just trying to cover
all the bases I know of...)
- Josh
12 Dec
12 Dec
8:53 a.m.
On 12/11/15 9:33 PM, Josh Dersch wrote:
On 12/11/15 5:50 PM, Jacob Ritorto wrote:
I'll also add that in order to create a filesystem on the new disk using
mkfs, you'll need to have run the 2.9BSD 'disklabel' program on it to
create the disk label (partition map). You can do this via vtserver,
it's covered in the manual. Obviously this can only happen after you've
managed to format/exercise the disk :).
- Josh
Exciting stuff for a Friday night, right?
Here's a visual aid in case
you're needing further inspiration:
https://www.instagram.com/p/_K-zHhHvLn78Qu5ijWqMf-HBem1LKMLaEdI1c0/ The
M2333K is the smaller one on the left with the green and yellow
lights on.
I'm booting from rl0, which contains the tuhs 2.9.1 rl02 image I
wrote with
vtserver earlier.
I want to use my nice, roomy smd disk so I can pull in all the
sources and
recompile stuff and I've managed to get this *so* close to working
but I'm
getting
xp0a: hard error bn xxxx cs2=1100 <MXF, IR> er1=0
on every single block when I try to mkfs /dev/xp0a 4800
This disk was working fine years ago via MSCP attached to the 11/73
(before
I lost the Micro/11 power supply).
Anyway, I referred to
http://bitsavers.trailing-edge.com/pdf/emulex/SC2151001-CC_SC21tech_Jan87.p…
to set the emulation on the Emulex card for two rm03s and they're
showing
up in xxdp's zrmlb1 formatter, though they won't format there,
screensful
of errors.
I think I set the m2333k to 32 sectors, per this manual:
http://manx.classiccmp.org/collections/antonio/chrisq/B03P-4760-0101A_-_M23…
Because XXDP is reputed to be really strict, I figured that was
normal and
then tried the Emulex on-board formatting procedure against both xp0 and
xp4 and they formatted perfectly without error. Guess the Emulex
on-board
stuff doesn't bother verifying much?
So I think that maybe I've misunderstood the hard sectoring / sector
sizing
thing. Does anyone remember the gist of it and would you be able to
describe? Do you see any other mistakes?
thx
jake
I'm not an expert with SMD drives and I've never used your particular
controller (I have a slightly newer Emulex in my 11/44) but here's a
couple of things I noted while leafing through the SC21 manual you
linked:
1.) The SC21's format does *no* verification at all. It lays down an
initial format and that's it. It doesn't create the bad-block list
(more on that later).
2.) Section 6 of the manual lists a set of modifications (patches)
that need to be made to XXDP diagnostics in order for them to work
properly with the SC21. This includes the ZRMAC0 formatter form
RM02/RM03. You'll likely need to apply them; hopefully you can find
the required versions to hack...
3.) In addition to setting the sector size/sector count on the
Fujitsu, did you also configure the SC21 for the appropriate drive?
(see Appendix A) I don't see an M2333 listed there specifically, but
there might be something with a similar (or identical) geometry you
can use instead.
Regarding the bad-block list: You are going to need this to be
generated properly, and the only way to do that is to run the
appropriate XXDP formatter and exercisers. If you have the bad block
list for the drive, hopefully one of the diags will let you enter it,
otherwise I suggest running *many* passes of the exercisers until they
stop finding bad blocks.
After you have that step done, you will need to have a 2.9.1BSD kernel
that's been compiled with bad block support, otherwise BSD will simply
ignore bad sectors and assume the whole disk is good -- which will
cause bad things to happen as soon as something is written over a bad
sector.
(Apologies if any of the above is already old-hat; just trying to
cover all the bases I know of...)
- Josh
9 Feb
9 Feb
7:36 a.m.
Thanks for the replies, fellows. Just to (maybe) put this thread to bed
for a while and summarize: I didn't manage to get the m2333k disks to talk
to the sc21-BMG controller. I think it had to do with an incompatible
number of bytes per sector - no matter how I set up the disk's sectoring,
the controller continued to generate errors. Just too much coming in with
every read, it seemed, and it didn't matter how you sliced and diced it,
the logic's just not there to make these two talk nice. I think an MSCP
SMD controller would take care of this as it's possible to configure
geometry in a more dynamic way. I ended up spinning up my other Fuji160
(listed as supported in the sc21bm manual) and getting things going.
Miraculously, its surfaces were in such great shape that it actually passed
xxdp zrmlb0 (iirc). Sadly its bearings are making noise, so I can't risk
keeping it on much. I don't think there's a viable way to re-lubricate the
beast, but let me know if you think there is.
Also, correction of above: note that 2.9.1BSD was *before* disklabels and
the drivers and kernel are compiled statically with disk layout information
hard-coded in.
Anyway, thanks again, all! My 11/34 is actually working pretty well and I
now have a full 2.9BSD distribution loaded and functioning! I've even
recompiled the kernel and replaced the generic one with something more slim
and tuned to my site needs. Hoping to set up SL/IP next to try and get
some networking to the machine, but fearing that the 11/34 might just be
too darned small to run tcp at all.
--jake
3239
days inactive
3298
days old
4 comments
3 participants
participants (3)
-
derschjo＠gmail.com -
ethan.dicks＠gmail.com -
jacob.ritorto＠gmail.com