• Please review our updated Terms and Rules here

SCSI2SD help

tradde said:
Well, that didn't work. I made the partition just under 2GB. I also did a chsum of
the original Simh file and the transferred to my Linux box. Matches so it copied
Ok and matches in size. Guess RSTS doesn't want to be run on my 11/84.
I could try overwriting my one 2GB SCSI drive, but I don't want to lose my
BSD disk. I have no other 50 pin SCSI drives that are small.
Click to expand...

If you have other scratch SCSI drives you can use and the only issue is that they are too large in capacity, you can use sg3_utils ( http://sg.danny.cz/sg/sg3_utils.html ) to soft resize the drive capacity down to smaller limits. I have used that several times with some 9GB SCSI drives to use them with 2.11BSD and RSTS/E 10.1 with a CMD CQD-220/TM on my 11/73 systems.

Example:
sg_format --resize --count=2097152 pd1

I believe all this effectively does is change the value that is returned in a READ CAPACITY command. It doesn't actually reformat the drive.

-Glen
 
For real SCSI drives larger than 2gb, you can also use a SCSI Mode Page Editor,
to change the drive capacity that the drive reports to the controller/OS.

I have done this with some IBM drives, as well as some Barracudas.

When you say that you've already partitioned your logical drive below 2gb,
what does your controller do with the rest of the available space?

Let's say the controller creates DU0, with 2gb of space.
Does it automatically create a second emulated drive with 6gb of space?

If so, that could also cause RSTS/E to crash during boot,
as it has to enumerate and size all of the drives on the controller.
 
TiggerLAS said:
For real SCSI drives larger than 2gb, you can also use a SCSI Mode Page Editor,
to change the drive capacity that the drive reports to the controller/OS.

I have done this with some IBM drives, as well as some Barracudas.

When you say that you've already partitioned your logical drive below 2gb,
what does your controller do with the rest of the available space?

Let's say the controller creates DU0, with 2gb of space.
Does it automatically create a second emulated drive with 6gb of space?

If so, that could also cause RSTS/E to crash during boot,
as it has to enumerate and size all of the drives on the controller.
Click to expand...

I only told the SCSI2SD to only use ~2GB of the 8GB. I don't know what
happens to the rest. I am not even sure it shows up anywhere. When I boot
on Linux it shows up as /dev/sdd since I already have a /dev/sdc. Would the
bootstrap be smart enough to report an actual error if a partition was
too large? This is a "trap 4" error
that I get.
 
Have you tried taking it down even further -- down to 500MB, perhaps,
just to see if it gives you the same results ?
 
gslick said:
If you have other scratch SCSI drives you can use and the only issue is that they are too large in capacity, you can use sg3_utils ( http://sg.danny.cz/sg/sg3_utils.html ) to soft resize the drive capacity down to smaller limits. I have used that several times with some 9GB SCSI drives to use them with 2.11BSD and RSTS/E 10.1 with a CMD CQD-220/TM on my 11/73 systems.

Example:
sg_format --resize --count=2097152 pd1

I believe all this effectively does is change the value that is returned in a READ CAPACITY command. It doesn't actually reformat the drive.

-Glen
Click to expand...

Am I to understand that this will permanently (ie: survives power off) let me reduce the capacity reported by the drive? This would be _wonderful_! I have a bunch of scsi drives that are just too big to install RSTS on, even though my CQD220A lets me present one drive as four "volumes".
 
Roe said:
Am I to understand that this will permanently (ie: survives power off) let me reduce the capacity reported by the drive? This would be _wonderful_! I have a bunch of scsi drives that are just too big to install RSTS on, even though my CQD220A lets me present one drive as four "volumes".
Click to expand...

This result of this is non-volatile and persists across power cycling the hard drive.

This is the example I have used for a VAXStation 3100 to resize the capacity of a drive to exactly 1GB as the system doesn't natively support drives larger than that:

sg_format --resize --count=2097152 pd1
(where the "pd1" identifies the target drive and can vary depending on the system configuration)

For use with a PDP-11 system with a CMD CQD-220 or similar controllers I might pick a capacity that matches that of an RD54. There is only so much disk space you will probably ever use on a PDP-11 even with something like 2.11BSD with all of the source code installed from tape.

-Glen
 
TiggerLAS said:
Have you tried taking it down even further -- down to 500MB, perhaps,
just to see if it gives you the same results ?
Click to expand...

What I plan next is to dump the BSD image to the SCSI2SD and then put the RSTS image on the actual
disk and see if it boots. If it does I am fine with that configuration. If not it will tell me something for
the next step.
 
How did you create the RSTS/E image that you are trying to boot on the 11/84? Did you install from scratch to a simulated disk from simulated tape images in SIMH? If you have any means to try to install from physical tape to disk on the real 11/84 I wonder if that might give any additional clues.

I have one M8190 KDJ11-B CPU board that installs and runs 2.11BSD just fine, but if I try to install RSTS/E 10.1 with that CPU board I get a fatal error message during installation. I wonder what would happen if I were to install with a different CPU board and then try to boot on the board that generates the error message.

Maybe this was the error message, I'd have to try it again to check:
This DCJ11 cannot be used in conjunction with an FPJ11 accelerator.
Contact Field Service for FCO kit EQ-01440-02 to correct the problem.
 
gslick said:
How did you create the RSTS/E image that you are trying to boot on the 11/84? Did you install from scratch to a simulated disk from simulated tape images in SIMH? If you have any means to try to install from physical tape to disk on the real 11/84 I wonder if that might give any additional clues.

I have one M8190 KDJ11-B CPU board that installs and runs 2.11BSD just fine, but if I try to install RSTS/E 10.1 with that CPU board I get a fatal error message during installation. I wonder what would happen if I were to install with a different CPU board and then try to boot on the board that generates the error message.

Maybe this was the error message, I'd have to try it again to check:
This DCJ11 cannot be used in conjunction with an FPJ11 accelerator.
Contact Field Service for FCO kit EQ-01440-02 to correct the problem.
Click to expand...
I created it with Simh just as you say. Same way I created the BSD 2.11 image. It
runs just fine under Simh. I have no way to load any type of tape on my 11/84.
That would be very useful right now I think.

I am also trying to install RSTS 10.1 and get an error. Looked at the CPU error
register I see a value of 20 which says it's an IO bus timeout. That seems odd
unless the SCSI2SD is too slow for something?

My error is:

Unexpected trap through the vector at 000004 (this is followed by a register dump).

Then: Fatal RSTS/E system initialization error!

The fatal error occurred during the bootstrap phase of
the initialization; there is no recovery.
 
I am going to try a v9.6 image to see if that makes any difference. I doubt it.
I also tried some changes to the system but nothing helped in any way.
Wish I could get RSTS to provide more info than a trap message.
 
TiggerLAS said:
Can you post a memory map, printed from the KDJ11 interactive menu ? ("M" at the main prompt.)
Click to expand...

I can't print anything, but I did write down the memory map. It has changed slightly with my last reconfig.

I am going to try a build for an RA81 that will fit on the 1GB drive. If that doesn't work it may
be something specific to my system
 
TiggerLAS said:
Can you post a memory map, printed from the KDJ11 interactive menu ? ("M" at the main prompt.)
Click to expand...

15.206 Mhz
CPU Options FPA

Memory Map

Start End Size CSR CSR Type Bus
00000000 77777776 2048 17772100 ECC PMI
10000000 17757776 2040 17772102 ECC PMI

I/O Page Map

Start End
17760040 17760046
17765000 17765776 CPU ROM or EEPROM
17766150 17765152 UDA 50
17770200 17770376 UNIBUS MAP
17772100 17772102 MEMORY CSR
17772150 17772152 UC17
17772200 17772276 SUPERVISOR I & D PDR/PAR's
17772300 17772376 KERNEL I & D PDR/PAR's
17772516 MMR3
17773000 17773776 CPU ROM OR UBA ROM
17774510 17774516
17776700 17776746
17777514 17777516
17777520 17777524 BCSR, PCR, BCR/BDR
17777546 CLOCK PSR
17777560 17777566 CONSOLE SLU
17777572 17777576 MMR0, 1, 2
17777600 17777676 USER I & D PDR/PAR's
17777730 17777734 DCSR, DDR, KMER
17777744 17777752 MSCR, CLR, MREG, Hit/Miss
17777766 CPU ERROR
17777772 PIRQ
17777776 PSW


I believe this is correct, but could have typo'd on a few.
 
Of course trying a smaller size disk (RA81) did not help. As I kind of expected after
suggesting it. I don't know what else to check or change.
 
tradde said:
Of course trying a smaller size disk (RA81) did not help. As I kind of expected after
suggesting it. I don't know what else to check or change.
Click to expand...

I believe I have solved the primary problem as RSTS now boots. It's the default monitor so only
has room for 10 jobs so fails on starting a few. I can't login for some reason, but that doesn't
bother me now as I can copy back my full sysgen.

The problem stemmed from my having a Spectra Logic 111-Plus card installed from quite
some time ago. Back when I still had two SMD Eagle drives I was trying to boot. It never
caused any problems but obviously RSTS didn't like it. I pulled the card finally thinking
that might be causing an issue and poof RSTS booted. Well, it didn't like the drive on
DU0 and reported it disabled. Then it booted. Not sure about the DU0 thing yet. I am
now going to recopy my full sysgen and see what happens.
 
Would that have been the device listed at 17776700 - 17776746?
I think those are hard-coded at VEC 254. Not sure if that was causing the issue, or not.
Truthfully, I don't recall if RSTS/E 10.1 still supports RM/RP drives, or not.
I know they dropped RP02/RP03 support back at v9.7. . .

I see a UDA50 sitting at a non-standard address as well.
RSTS/E would probably want to see that at 17760334,
as a secondary MSCP controller.
 
TiggerLAS said:
Would that have been the device listed at 17776700 - 17776746?
I think those are hard-coded at VEC 254. Not sure if that was causing the issue, or not.
Truthfully, I don't recall if RSTS/E 10.1 still supports RM/RP drives, or not.
I know they dropped RP02/RP03 support back at v9.7. . .

I see a UDA50 sitting at a non-standard address as well.
RSTS/E would probably want to see that at 17760334,
as a secondary MSCP controller.
Click to expand...

Yes, the Spectra Logic card was at 177776700. It is
very hard to change the jumpers on the UDA50 as it's
two cards and the two short jumpers at the top seem
very inflexible. I did it with the board in the box and
removed the cards in front. But it's hard to change
them and verify what's what. I will see what I can
do. Thanks.
 
gslick said:
This result of this is non-volatile and persists across power cycling the hard drive.


For use with a PDP-11 system with a CMD CQD-220 or similar controllers I might pick a capacity that matches that of an RD54. There is only so much disk space you will probably ever use on a PDP-11 even with something like 2.11BSD with all of the source code installed from tape.

-Glen
Click to expand...

This works perfectly. I resized a 15000 rpm HP scsi drive to 8GB, split that into 4 2GB "hard disks" on the CQD220A, and installed RSTS with no problem at all; also 2.11BSD unix, RT11, and XXDP 2.5.

I'm pretty sure this is now just about the fastest pdp11/93 system ever built!
 
You must log in or register to reply here.
Back
Top