🚀 go-pugleaf

From article <3396@ursa-major.SPDCC.COM>, by dyer@spdcc.COM (Steve Dyer):
- 
-Since the IBM H310 drive is (I thought) simply a repackaging of the Maxtor
-4380E, I obtained one of these.  I set the jumpers identically to existing
-H310 drives in accordance with the IBM installation manual, and proceeded
-to format the drive.  It gave a write error on each track (sector=1 SCT=34),
-and one which didn't disappear with repeated formats, and the drive gave
-errors trying to run newfs under AOS 4.3.  This was attempted on two
-different RT systems, jumpers inspected by different individuals, and the
-results were identical.  There has been talk of the need for a shortened
-index pulse by the IBM controller, but a Maxtor support person in Austin
-told me that recent drives (which this one is) shouldn't need any modification.

It's not a drive problem, but rather backlevel microcode on your EESDI
board.  The microcode upgrade is available from IBM; I'll see if I can
find the part number in the Ivory Letters tomorrow.  The upgrade consists
of a replacement 27128 on the controller board.

I can't comment on the Maxtor, but we're using LOTS of CDC Wren V drives
here.  You have to use the STANDALONE FORMAT, not something that you can
run under 4bsd.  Shut your system down, reboot and hit cntrl-c when it
comes back up and waits for you to specify what to boot.  This should
give you the stand alone utilities.  REMEMBER that drives start at hd(0),
so you don't format the wrong drive ... that could spoil your whole day.
You're also going to have to enter the bad blocks from the manufacterer
test by hand.  Bletch.

-- 
Ed Clarke
uunet!bywater!acheron!clarke 

In article <3396@ursa-major.SPDCC.COM> dyer@ursa-major.SPDCC.COM (Steve Dyer) writes:
...
>results were identical.  There has been talk of the need for a shortened
>index pulse by the IBM controller, but a Maxtor support person in Austin
>told me that recent drives (which this one is) shouldn't need any modification.

I was told several months ago by Maxtor San Jose technical support that
hardware modifications would no longer be necessary, but the jumpering
would have to be changed to work with the sortened index pulse.  San
Jose technical support number (at least it was 2 months ago) is
408-432-1700.  If they can't help you after a few calls, you can
usually talk directly to one of the design engineers who has memorized
the timing and layout of the 4380E interface and control boards.


David Gungner
gungner@cs.ucla.edu    
ucla machine perception lab   213-825-6121

In article <613@acheron.UUCP> clarke@acheron.UUCP (Ed Clarke) writes:
>It's not a drive problem, but rather backlevel microcode on your EESDI
>board.  The microcode upgrade is available from IBM; I'll see if I can
>find the part number in the Ivory Letters tomorrow.  The upgrade consists
>of a replacement 27128 on the controller board.

Wow.  Let's see.  When my system autoconfigs, it presents the following
message:
hdc0: card level 0x4b microcode level 0x55 configuration bits 0xc1

>You have to use the STANDALONE FORMAT, not something that you can
>run under 4bsd.

Yep.  Good old sautil/format.  That's what I've been using.

Keep me posted on the microcode upgrade.

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu

In article <3404@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes:
>Wow.  Let's see.  When my system autoconfigs, it presents the following
>message:
>hdc0: card level 0x4b microcode level 0x55 configuration bits 0xc1
>
>>You have to use the STANDALONE FORMAT, not something that you can
>>run under 4bsd.
>
>Yep.  Good old sautil/format.  That's what I've been using.
>
>Keep me posted on the microcode upgrade.
>
>-- 
>Steve Dyer
>dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
>dyer@arktouros.mit.edu

Microcode level 0x55 is fine.  You got one of the new cards.  When the EESDI
was first released, it hardcoded IBM disk parameters.  You have a newer
card that has the microcode that polls the disk for parameters.

Are you sure you modifed all of the necessary kernel files?

Are you sure that you have your drive jumpers/dip switches set to drive
select 2 and the right number of sectors per track?

Good luck, and if you have further problems give me a call or send me 
a note with all of the kernel changes that you made to incorporate your
Maxtor drive.

Note that I have only used Wren V and Priam disks on the RT.

--------------------------------------------------------------------------------
| Jacob M. Parnas                      | DISCLAIMER: The above message is from |
| IBM Thomas J. Watson Research Center | me and is not from my employer.  IBM  |
| Arpanet: jparnas@ibm.com             | might completely disagree with me.    |
| Bitnet: jparnas@yktvmx.bitnet        \---------------------------------------|
| Home: ..!uunet!bywater!acheron!archet!larouch!jparnas | Phone: (914) 945-1635|
--------------------------------------------------------------------------------

In article <170@arnor.UUCP> jparnas@arnor.UUCP (Jacob Parnas) writes:
>Are you sure you modifed all of the necessary kernel files?

Well, it's not clear to me what kernel files have to be changed when running
the standalone formatter.  :-)

>Are you sure that you have your drive jumpers/dip switches set to drive
>select 2 and the right number of sectors per track?

All jumpers were made to agree with other IBM H310 drives.  This was
done with two different Maxtor 4380E drives and cross checked by
another guy.  Drive select was 2.  Both drives misbehaved identically--
the formatter gave the same error on each track.  We even tried this on
another RT (same microcode level).  No difference.  I was operating
under the assumption that the IBM H310 drive, which is labelled with
"Maxtor 4380E" on its backside, is the same as a late-model Maxtor
4380E which I can buy from a distributor.  If all the disk geometries
agree, and the configuration record produced by the formatter is
correct, it isn't clear to me what kernel files would need to be
changed.  It should look, smell and taste like a H310.

Do you think there is a remote possibility that:

	0.) The jumpers for a H310 and an OEM 4380E mean different things
	    (no indication of this whatsoever from Maxtor.)  Seems unlikely.

	1.) the AOS 12/88 formatter messes up with formatting ESDI disks?

	2.) I have an IBM 114mb disk as my boot disk.  I run the formatter
	    by typing ^C from the boot record.  At that point, the EESDI
	    controller had to have polled drive 0 and got ITS attributes.
	    I, of course, are interested in formatting drive 1.  Would
	    that mess it up?

	3.) I assume there's a separate AIX/RT hard disk formatter program
	    available.  Perhaps that might work better.  I'm sure I can borrow
	    this from the IBM folks at MIT/Project Athena, if I know what disk
	    from the AIX or diagnostic set to ask for.  Any leads?

>Good luck, and if you have further problems give me a call or send me 
>a note with all of the kernel changes that you made to incorporate your
>Maxtor drive.

Thanks, I might take you up on that, barring any fresh suggestions!

>Note that I have only used Wren V and Priam disks on the RT.

Gasp, sputter...  And here I thought I was being CONSERVATIVE by buying
the same drive as IBM sold!  :-)

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu

In article <3434@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes:
>In article <170@arnor.UUCP> jparnas@arnor.UUCP (Jacob Parnas) writes:
>>Are you sure you modifed all of the necessary kernel files?
>
>Well, it's not clear to me what kernel files have to be changed when running
>the standalone formatter.  :-)

By kernel files, I meant files under /usr/sys.  For instance, the stand
alone formatter must be rebuilt to be able to deal with new disk drives.
Its source lives in /usr/sys/standca.  You must change /usr/sys/standca/hd.c 
Then make in /usr/sys/standca, which will result in a new boot.out that you
can copy to /boot.

>>Are you sure that you have your drive jumpers/dip switches set to drive
>>select 2 and the right number of sectors per track?
 
>All jumpers were made to agree with other IBM H310 drives.  This was
>done with two different Maxtor 4380E drives and cross checked by
>another guy.  Drive select was 2.  Both drives misbehaved identically--
>the formatter gave the same error on each track.  We even tried this on
>another RT (same microcode level).  No difference.  I was operating
>under the assumption that the IBM H310 drive, which is labelled with
>"Maxtor 4380E" on its backside, is the same as a late-model Maxtor
>4380E which I can buy from a distributor.  If all the disk geometries
>agree, and the configuration record produced by the formatter is
>correct, it isn't clear to me what kernel files would need to be
>changed.  It should look, smell and taste like a H310.
 
I haven't used any Maxtor 4380E drives, so I can't comment on how to set
them up.  I think that IBM does sometimes have third party vendors modify
the drives that they sell as IBM drives.

>Do you think there is a remote possibility that:
>
>	0.) The jumpers for a H310 and an OEM 4380E mean different things
>	    (no indication of this whatsoever from Maxtor.)  Seems unlikely.
 
Could be.  I really don't know.

>	1.) the AOS 12/88 formatter messes up with formatting ESDI disks?

I haven't had any problems with the 12/88 formatter using Wren V and 
Priam 638 drives.

>	2.) I have an IBM 114mb disk as my boot disk.  I run the formatter
>	    by typing ^C from the boot record.  At that point, the EESDI
>	    controller had to have polled drive 0 and got ITS attributes.
>	    I, of course, are interested in formatting drive 1.  Would
>	    that mess it up?

I'm pretty sure that isn't the problem.  I often use hd70e drives as a boot
drive, hit ^C at the boot prompt and format other types of drives.

>	3.) I assume there's a separate AIX/RT hard disk formatter program
>	    available.  Perhaps that might work better.  I'm sure I can borrow
>	    this from the IBM folks at MIT/Project Athena, if I know what disk
>	    from the AIX or diagnostic set to ask for.  Any leads?
 
I doubt this will help.  Many AIX users here use the 4.3 BSD AOS sautil to
do the initial format of their drives.

>>Good luck, and if you have further problems give me a call or send me 
>>a note with all of the kernel changes that you made to incorporate your
>>Maxtor drive.
>
>Thanks, I might take you up on that, barring any fresh suggestions!
>
>>Note that I have only used Wren V and Priam disks on the RT.
>
>Gasp, sputter...  And here I thought I was being CONSERVATIVE by buying
>the same drive as IBM sold!  :-)
>
>-- 
>Steve Dyer
>dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
>dyer@arktouros.mit.edu

I would do the following:

1.  Make sure that you are using a version of the boot program that knows
    about your drive.

2.  If that doesn't work, try to contact the people at Maxtor that would know
    about modifications that may have been made on the Maxtor drives that
    were shipped as IBM drives.  It may be that they changed something like
    the inter-sector gap or sync-field length or something like that to
    work with the EESDI/HESDI controller.  Or they may have just changed
    the jumper/dip switch configuration for IBM drives, or maybe just
    changed them since without saying so in the documentation. (I think
    this was done on the CDC Wren V's).

3.  If that doesn't work, try to get hold of a CDC Wren V or Priam 638,
    modify /vmunix and /boot in the same places as you did for the
    Maxtor and see if it works.  That way, you'll have a good idea if
    you are modifying the system code in the right places.

Hope that helps,

--------------------------------------------------------------------------------
| Jacob M. Parnas                      | DISCLAIMER: The above message is from |
| IBM Thomas J. Watson Research Center | me and is not from my employer.  IBM  |
| Arpanet: jparnas@ibm.com             | might completely disagree with me.    |
| Bitnet: jparnas@yktvmx.bitnet        \---------------------------------------|
| Home: ..!uunet!bywater!acheron!larouch!jparnas | Phone: (914) 945-1635       |
--------------------------------------------------------------------------------

In article <3396@ursa-major.SPDCC.COM> dyer@ursa-major.SPDCC.COM (Steve Dyer) writes:
>It gave a write error on each track (sector=1 SCT=34),
>and one which didn't disappear with repeated formats, and the drive gave
>errors trying to run newfs under AOS 4.3.

I wrote the EESDI hd driver and format code for AOS 4.3.  That was long ago,
and by now I've forgotten 99% of how it works.  W/o digging into the code,
here's my idea of what the source of your trouble is:

The EESDI disks for the RT, as shipped by IBM, have a "hidden defect table" at
the 18th sector on the 2nd track of the 1st cylinder.  See disk(4) man page.
I suspect your troubles result from the fact that your disks do not have such
a table on them.  Format(8) uses the presence or absence of such a table to
decide whether there is a hidden sector at the end of each track.  Ie format
adjusts its idea of the number of sectors per track if the table is present.

PS: I'll be at USENIX next week.

Conrad Minshall uunet!ibmsupt!conrad (415)8554454 conrad@ibmpa.tcspa.ibm.com
         None of the above represents IBM's Official Policy, etc.