dyer@spdcc.COM (Steve Dyer) (05/29/89)
I've asked this before, but now I have some bad experience which I'd
like to share, and hopefully get some information in return.
The cost of IBM ESDI disks is completely out of line with my budget, so
I've been looking at less expensive means of upgrading my machine.
The hd.c disk driver looks fairly flexible at accepting disks of varying
geometries, and in fact I've used a number of different ST506 disk drives
with the AT disk controller. I hoped that the same would be true for the
EEDSI controller.
I purchased a Miniscribe 9380E 300mb disk drive. Unfortunately, there
seems to be a fatal incompatibility between it and the IBM EESDI
controller: not only will the drive fail to be recognized at the very
outset ("can't init drive") by the AOS 4.3 format program, but the act
of attaching the controller to the drive seems to destroy something in
the drive electronics. For example, a drive which formats OK on a 386
system will no longer work after it's been attached to the RT's EESDI
controller. This has been verified with two different Miniscribe units.
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.
I'll be trying another unit shortly to ensure that this isn't a sample
defect, but I am puzzled.
Anyway, thank God for a patient dealer. Be careful out there. If I have
any good news, I'll pass it on.
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.educlarke@acheron.UUCP (Ed Clarke) (05/30/89)
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
gungner@maui.cs.ucla.edu (David Gungner) (05/30/89)
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
dyer@spdcc.COM (Steve Dyer) (05/30/89)
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
jparnas@arnor.UUCP (Jacob Parnas) (06/02/89)
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| --------------------------------------------------------------------------------
dyer@spdcc.COM (Steve Dyer) (06/02/89)
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
jparnas@larouch.UUCP (Jacob Parnas) (06/04/89)
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 | --------------------------------------------------------------------------------
conrad@ibmpa.UUCP (Conrad Minshall) (06/10/89)
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.
jparnas@larouch.UUCP (Jacob Parnas) (06/13/89)
In article <1269@ibmpa.UUCP> conrad@ibmpa.UUCP (Conrad Minshall) writes: >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. > >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. > >Conrad Minshall uunet!ibmsupt!conrad (415)8554454 conrad@ibmpa.tcspa.ibm.com > None of the above represents IBM's Official Policy, etc. I been able to format raw CDC/Imprimis Wren V disk drives and Priam 638 drives, with all 36 sectors/track used with no problems. We've done this on literally dozens of drives and never had that problem. Try setting your jumpers/dip switches to use 36 sectors per track and tell format to use all 36 sectors/track and not use the hidden defect table. I found that at least CDC Wren V usually have under a dozen bad sectors on them (often just 3-6), so it doesn't seem worth using the hidden defect table. The few extra seeks shouldn't be noticed, plus you should gain about an extra 10 Megabytes on a 380 MB disk. ------------------------------------------------------------------------------ | Jacob M. Parnas | DISCLAIMER: The above message is from | | IBM Thomas J. Watson Research Ctr. | 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 | ------------------------------------------------------------------------------