From: paul@pentode.uucp (Paul Walker) Subject: Large SCSI drive on Apollo Date: Wed, 2 Dec 1998 05:47:48 GMT I recently purchased a 4.57GB drive for my DN5500. When I first invol'd it, the reported capacity was about 270MB. This also happened on a DN4500 as well. After some investigation, I was able to get the drive to invol just fine, and get the full capacity on either machine (of course, the 4500 had to see the drive as two 2GB drives). I solicited the help of another Domain/OS user (thank you very much for being an "alpha" test site). He was successful in using the same technique to put a 9.09GB drive on a 425t. Here are the details on why it doesn't work with the standard kernel, and how the problem was fixed ... Invol gets drive capacity information from the disk_$pv_assign_n kernel call. Here are disk_$pv_assign_n results with 'stock' kernels: Drive System Type Reported Blocks ----- ------ ---- --------------- 8760 4500 608 a0f8c 4.5G 4500 71b 417a3 4.5G 5500 71b 105e8 2.1G 3500 7d6 1ff0c0 4.5G 4500 701 4417A3 (patched kernel) 4.5G 5500 701 1105e8 (patched kernel) The read capacity command of the mts tool shows that the 4.5G drive reports a capacity of 8924999 (0x882f47) blocks, with a block size of 512 bytes. The problem is that the kernel code that determines the capacity of a physical volume is not written for capacities that exceed 2^32 bytes. In the case of the 4.5G drive, the capacity is 8,924,999*512 bytes, which comes to 4,569,599,488, or 0x1105e8e00. This number exceeds 32 bits, and becomes 0x105e8e00, which divides by the page size of the node to become either 0x105e8 or 0x417a3 blocks. Note that the DN4500 has a 1K page size, and the DN5500 has a 4K page size. The simplest fix for the problem is to reorder the code that does the multiply/divide. The compiler generates two LSR instructions for the division. If one of these is moved to operate on the blocksize, then the multiply won't overflow. ********************************************************************************* Kernel code that determines number of blocks ... Note that it will overflow for a large drive. Can we reorder the operations? 7A423CD0: MOVE.l (a2),d0 * d0 = numblocks 7A423CD2: MULS.l ($4,a2),d0 * d0 *= blocksize 7A423CD8: MOVE.l d0,d1 * d1=d0 7A423CDA: LSR.l #$8,d1 * d1 /= 4096 (page size) 7A423CDC: LSR.l #$4,d1 * 7A423CDE: MOVE.l d1,($FFFFFFE0,a6) * local_b_per_pvol = d1 Here is a proposed reordering that will support drives up to 1000G, assuming that the blocksize is 512 bytes: MOVE.l ($4,a2),d0 * d0 = blocksize LSR.l #$8,d0 * d0 /= 256 (assumes blocksize is multiple of 256) MULS.l (a2),d0 * d0 *= numblocks MOVE.l d0,d1 * d1=d0 LSR.l #$4,d1 * d1 /= 16 MOVE.l d1,($FFFFFFE0,a6) * local_b_per_pvol = d1 ********************************************************************************* The d_type is still returned incorrectly. It appears that for SCSI drives, Domain/OS uses the lower byte of this field to indicate the capacity, in 1E7 byte blocks. For example, 0x7d6 is the proper d_type for a 2.1GB drive, and 0xd6 comes to 214. Netstat reports this drive as a 2140MB drive. This scheme allows a capacity of 255E7 bytes (about 2.5GB). This would be reported by netstat as a 2550MB SCSI disk. The code-reordering I've done results in the low byte of the d_type field being divided by an additional 256. So a drive with a 2.56GB capacity will be reported as 10MB. So will a 5.11GB drive. However, a 5.12GB drive will be reported as 20MB, and a 9.09GB drive will be reported as 30MB. If the division results in a zero, then 1 is substituted. If the result is too large, then 0x700 is substituted. This won't happen until the capacity exceeds 255*256*1E7 bytes (approx. 652.8GB). There doesn't seem to be an easy way to correct the kernel in this respect, but the error doesn't seem to cause a problem, so I'll let it be. Even if it could be fixed, there is a range problem (2.56GB limit) in the current representation that HPollo chose. A complete fix of this could extend to many areas in Domain/OS, besides the kernel and netstat. Using the patched kernel all of the time will cause "standard" drives to be mis-reported by netstat, as well as the large drives. So far, this is the only downside I've seen to using the patched kernel all of the time. ********************************************************************************* I have written a program that makes the kernel patch that is described above. It operates directly on the kernel image in /sau?*/domain_os. It searches for the specific code segment that is listed, and changes it. If the code segment is found more than once, no patch is made, because I don't know which segment is the appropriate one to change. The algorithm is described in the program's source code. If you are interested in trying the program, send me an Email. I would like to have a few more people try this out before I make a general release of the code. I also welcome any discussion on this subject. [ Ed note: The program is called kbs_patch and is available from the UM Apollo Archive. - Jim Rees ] Paul Walker -- Paul Walker Note: I hate spam - if you want to send mail to me, remove the alphabetic letter sequence that has been interleaved into my address, starting with the first 'a', to the 'r'. From: "Joe Avila" Subject: Re: High Capacity Drives Date: Sun, 09 Aug 1998 08:13:03 GMT Hello Everyone, I have an update to my high capacity drive adventure that I orginally inquired about a couple of weeks ago. I was finally successfull in formatting and using a 4.3G drive on my 433t running SR10.3.5.15 (this is no joke). I thought some of you would like to hear about the details of my experience. On SR10.3.5.15 fully patched with patch kit PD97_MBP09 I was able to format a 4.3Gig drive on my 433t. This drive was a Seagate ST15150N. The format was done with online invol and I had to make no special changes to the drive firmware whatsoever. It worked right out of the box (except for setting the SCSI id). Here is the drive description as reported by scsi_info: Target 5: Device Type: Disk Vendor: SEAGATE Product: ST15150N Rev Level: 0023 ANSI version compliance: SCSI-2 Features supported: Synchronous Data Xfer; Linked Commands; Cacheing; Command Queueing; 0 bytes of vendor unique data After running option 7 of invol (initialize bad spot list) and formatting the drive, I initialized the virgin physical volume with the '-f' option and it reported 4166892 kbytes free. After the logical volume was created (1 full partition of 4Gig), I was able to mount the drive and begin using it with no problems. I have yet to run into any as well. The entire process from install to mount took 4 hours. From: root@badgers.demon.co.uk (Tom Brock) Subject: Re: FS: 760mb Apollo Hard Drive w/10.4.1 -OR- Wanted: An apollo that can take a 760mb. Date: 1 Dec 1996 13:51:33 GMT WArning. This is quite long and boring. Many thanks to those who responded to my 'dead' Micropolis 170 post. FYI, DEX reported no errors of any kind when 'RUN WIN -ENTIRE -WRITE' was run on on one example. It took the devil of a time, but convinced me to persevere. A special thanks go to Paul Szabo for pointing out a basic flaw in my knowledge of 'jumper'. My WD7000 was jumpered incorrectly: W4 was in, but that should have had no effect on disks. All the experiments below were done with W4 out. In article <329d470f.8900499@news.goodnet.com>, hunkler@goodnet.com (Tim Hunkler) writes: |> mega-snip |> Thanks Tom! The only problem I see is that the 11858-6 / 12191-7 |> combination that I tried failed and the one that you tried worked!!! |> I enjoyed it :^). I've been doing a lot more playing around with this. I really must get a life. The following applies to attempts to use a WD7000-ASE with a disk formatted by an SMS/OMTI controller. As I mentioned, the first time I tried a WD7000 in a 11858-6/12191-7, I thought it had failed, but it was simply that, for the first self-test only, winchester controller test 0 takes for ever. My log says 'freezes in test 0'. I did not record the elapsed time, but it was many minutes. The same happened with a 11858-10/12191-7 combination. This time I was not prepared to believe it and waited. This persuaded me to try the 11858-6/12191-7 combo again, this time with time taken out to make, a nice chilli. The controller test 0 time is not quite so long in 15652 motherboards. On 11858-6 and up, 15652-1 and up, with 12191-5 and up, the business of involling a disk previously formatted with an SMS/OMTI controller seems to *require* the use of FBS. This is not what I remember from years ago, but this time I've been round the loop several times and recorded the results. Note that in all cases, the *drive* test gives 'read test fails'. Furthermore, invol option 7 (or any other option, for that matter) will give status code 80003 (controller timeout). If one uses FBS, with or without telling it to use existing badspots, it claims that that the badspot list is corrupt, but proceeds nevertheless to format the disk and find all the badspots. The physical addresses differ from those reported by the SMS/OMTI controller, and there are only approximately half as many. My experiments with a Micoprolis 170 showed 45(d) badspots with a WD7000 and 98(d) with the SMS/OMTI. Examples:- WD7000 SMS/OMTI BB0 BB5 BB6 CD0 CD5 CD6 After FBS has done its work, invol works perfectly, But I skipped option 7 for obvious reasons. Also, contrary to my recollection, it was necessary to uss FBS when moving the disk back to SMS/OMTI. Plainly, the physical badspot list (even when empty) is completely incompatible, at least on the Micropolis 170 and 380-FA. I have not tried a MAXTOR 380-FA. I also had some fun with one particular disk. It was Micropolis 380-FA that I bought at a rally for 15 UK pounds. Getting that one to go was wierd. Even FBS refused to work. What did work, though, was invol option 7, but giving it an entirely spurious manually added badspot. I would never have 'thought' of trying this, but I was in exhaustive search mode. Invol option 7 with no manually added badspot had failed completely. Then I could run FBS and find the real badspots. Turns out there are none at all. It's also the quietest Micropolis 380-FA I've come across. I now have all my disks fully functioning. After all that work making the 170s work with WD7000, they are now paired up with SMS/OMTI controllers. As I said, I really must get a life. Tom Brock. -- Home: tomb@badgers.demon.co.uk Work: tomb@roverpte.demon.co.uk From: root@badgers.demon.co.uk (Tom Brock) Subject: Re: FS: 760mb Apollo Hard Drive w/10.4.1 -OR- Wanted: An apollo that can take a 760mb. Date: 24 Nov 1996 10:57:04 GMT Maybe you weren't convinced, especially after the post from Harry Selfridge , quoting the authoritative WD7000 word from HP. I began to doubt myself, and went back and tried again. I am speaking to you from a 11858-6 12191-5 with WD7000, 760-FA, 8 Mbytes of RAM, token ring, and 4-plane graphics, running 10.4, December 1992 (no patches). Don't try this with 4 Mbytes of RAM: it takes 10 minutes to boot up. As you can see, it gives a remarkably good impression of a functioning node: not quite up there with a 32 Mbyte DN4500, but nonetheless servicable. As promised, here is the table for the 15652-1 Motherboard Boot WD7000 PROM supported 15652-01 12191-2 No (fails winchester disk self-test 1, just like 11858) 15652-01 12191-5 Yes (boots off 760-FA) 15652-01 12191-7 Yes (boots off 760-FA) Tom Brock. From: "Harry E. Selfridge" Subject: Re: FS: 760mb Apollo Hard Drive w/10.4.1 -OR- Wanted: An apollo that can take a 760mb. Date: Fri, 22 Nov 1996 10:53:23 -0800 ... The minimum cpu revisions for the wd7000 3 function scsi disk controller are as follows: series 4000 rev 25 or later series 3500/3550 Part #11858 rev 9, or part #15862 rev 1 or later series 4500 rev 5 or later series 5500 All From: Tim Hunkler Subject: Re: FS: 760mb Apollo Hard Drive w/10.4.1 -OR- Wanted: An apollo that can take a 760mb. Date: Fri, 22 Nov 1996 01:22:54 -0700 Andrew Kerr wrote: > > I purchased a 760mb apollo hard drive for my 3500 and was awfully > disapointed when I looked at the rev level and noticed a 6. So now I'm > left with a 760mb hard drive and a wd7000. I have the 10.4 and 10.4.1 > tapes, and I can set up the Authorized Area onto the hard drive with my > friends 5500, or maybe an old 3500 that can take this drive if I can > find someone that has one. Is anyone interested? > While I am taking the time to post, I'm looking for a 3500 or better > (preferably a 4500 and up) that can take this hard drive. I've got this > little non-existant budget, so selling the drive would be better, but > I'd sure like to have a new apollo to keep my 3500 company. > Thanks for taking the time to read this, and I'll look forward to any > reply to this post. Don't give up hope yet. It could be that if you upgrade the boot EPROM that you will have better success. I have been trying to figure out exactly what combinations of DN3500/3550 motherboard and boot EPROM it takes to be able to successfully use a WD7000 and here's what I know so far: config motherboard boot WD7000 760MB rev PROM supported disk ------ ----------- ------- --------- ----- #1 015652-4 12191-7 *WORKS* *WORKS* #2 011858-6 12191-2 fails #3 011858-6 12191-7 fails #4 011858-4 12191-2 fails #5 011858-4 12191-7 fails ---reported by Tom Brock, tomb@badgers.demon.co.uk --- #6 015652-1 12191-5 *WORKS* unknown, but 380 works #7 015653-00 12191-7 unknown, but should work #8 011858-6 12191-5 ? #9 011858-10 12191-6 ? It seems that the 015652 and above seem to support the WD7000. Once the WD7000 is supported then both 380MB and 760MB drives should work, as well as SCSI drives with the right patches. Some comments I have received indicate that a motherboard rev of 9 is needed for the WD7000, I can only assume that this refers to the 011858-9 as the 0115642 and above support the WD7000 at a lower rev. Please supply your motherboard part num/rev and boot prom rev and I'll have yet another piece of data. I have reprogrammed the boot EPROM on config #2 and #4 above from rev 2 to rev 7 without any improvement. However, if your motherboard rev is not listed above as a failing one then you might have some luck by upgrading the boot EPROM. I have made HEX file images of the various boot EPROMS that I have that can be used in most popular EPROM programmers and I can upload them for access if the demand is high enough. You'll need a machine that can handle a AM29C512 or AM29512. I also have one DN4000 that was parted-out and so I salvaged the EPROM from that and turned it into a spare 12191-7. I may be persuaded to part with it. Perhaps we can gather yet more input and solve this puzzle completely? If we can get Tom Brock to try 12191-7 boot EPROM in the 011858-10 motherboards along with the WD7000 that would flush out some more data. Anyone else out there with working WD7000 configurations that would not mind popping the cover and reporting motherboard and EPROM rev's???? -- \//// ( o o ) http://www.goodnet.com/~hunkler ======oOO-(.)-OOo============================================== Tim Hunkler (602) 814-4511, hunkler@goodnet.com From: Christian Anzenberger Subject: Re: does DN3500 support 760MB using WD7000 Date: Thu, 31 Oct 1996 12:03:30 +0100 Tim Hunkler wrote: > Has anyone out there successfully used a 760MB drive with a WD7000 > controller on a DN3500? Hello World. YES. The DN3500 was available from factory in this configuration. For upgrading you need the following revisions: DN3500 CPU 011858 Rev. 09 DN4000 CPU 009992 Rev. 25 DN4500 CPU 013031 Rev. 05 DN5500 all DN3000 is not supported. Jumper settings see UM Apollo Archive. Have fun. Have success. Chris. From: szabo_p@maths.su.oz.au (Paul Szabo) Subject: Re: does DN3500 support 760MB using WD7000 Date: 31 Oct 1996 20:39:36 GMT I think those CPU part numbers and revision numbers are slightly out. My view of them (which may in fact be mistaken): DN3500 CPU 011858 Rev. 09 DN3500 CPU 015652 all DN4000 CPU 009992 Rev. 22 DN4500 CPU 013031 all DN5500 A1631-66001 all DN3000 is not supported. For jumper settings see the /systest/ssr_util/jumper program. Hope this helps. From: thompson@PAN.SSEC.HONEYWELL.COM ((jt) John Thompson) Newsgroups: comp.sys.apollo Subject: re: SCSI disks on 5500? Date: Thu, 27 Aug 92 17:18:59 EDT Organization: The Internet > I've read the faq, but it doesn't make the answer to this question entirely > clear. Can I connect an external SCSI disk to a DN5500 with a WD7000 > controller? If so, is there any limitation on the size (eg 1.2GB)? Is the > process for involing etc.. the same as for a 425t? OK -- let's make it clear then. You can not hook up any SCSI disk drives to a WD7000 controller. In fact, you can't use SCSI drives on any Apollo machine except the DN2500 (the 9000/4xx is an HP/Apollo box). You CAN hook up up to 2 ESDI drives to a WD7000 controller. There are only three (?) drives that are supported, though -- the Maxtor 8760E (697MB), the Maxtor 4380E (329MB FastActuator) and the Micropolis(?) 170MB drive. The controller can apparently figure out what's on the other end, and act appropriately, so there aren't jumpers for the drive type itself. I think I've heard that you can add different drive types as your two drives (e.g. a 697MB and a 329MB drive). You CAN install up to 2 WD7000 controllers in your system (DN3500/DN4500/DN5500). The SCSI bus _must_ be disabled on the second controller. You CAN install a SCSI cartridge drive or floppy, but only if you do not have a non-SCSI one in place. If you have a non-SCSI tape/floppy, you must disable the SCSI bus. If the SCSI bus is enabled, you CAN add up to 7 SCSI devices total of CD-ROMS, 4mm drives, 8mm drives, and 9-track drives. I'm not sure whether the 4mm drives are explicitly supported, but I'm almost certain that I read somewhere that they work. I've read that SCSI device 0 is reserved for the cartridge/floppy drive, but that might have changed. The 8mm tape drives must be SCSI ids 1,2,3, or 4. These correspond to devices rmts8, 9, 10, and 11 (12-14 for non-rewinding devices). Although wbak is not officially supported on 8mm drives, it works fine at 10.3+ (and at 10.2?). Use m0 for SCSI id 1, m1 for SCSI id 2, etc. There is a long pause before it starts writing the tape with wbak. The tar and omniback packages work just fine (as do lots of other vendors' backup packages, I'm sure). Clearer? -- jt -- John Thompson Design Services Engineer / Sys-Admin Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com From: thomasm@news.enet.net (Michael A. Thomas) Newsgroups: comp.sys.apollo Subject: Re: Connecting two disks to an Apo Date: 19 Jan 1995 20:46:00 -0700 Organization: Evergreen Communications Phoenix, AZ ---Deleted text regarding 380MB FA disk on OMTI controller > >I'd really like to make this disk work, and get a definitive statement >as to whether an OMTI controller supports two-disk configurations... > >Thanks in advance for any help ! > >Naoto Horii / naoto@geis.geis.com > I can tell you that the OMTI controller will definitely support a 2nd disk drive. The secret is to install jumper W5 on the controller, this will enable the drive to talk to a 2nd ESDI disk. The 11914 controller works well with a 2nd disk and my documentation indicates that the 10119 and the 10741 (DN4000) should also work. It is also possible to mix drive types, i.e. a 170MB and 380MB. Disk to disk copies using the cpt command will also produce bootable disks, though I haven't tried this with different sizes of disk drives. If you examine the drive select jumpers on your first drive you will discover that it is set to DS1. The Apollo system expects the boot device to be strapped as disk #1, although all of the software will refer to it as drive #0. Your second disk must be strapped as disk #2 and of course the software and diagnostics will see it as drive #1. The previous statements only apply to the 'straight-through' style of daisy chain cable. If you've stolen a PC style of daisy chain which will usually have a 'twist' in the cable near the 2nd drive connector, you will need to strap both drives as DS2. The PC style cable will convert one of the DS2 settings to a DS1, via the twist, for the controller. Confusing, eh? Terminating doesn't seem to be a big issue. I've had the first drive terminated, the second, both and neither. Usually doesn't seem to cause any problems, but in reality it is probably best to terminate the last physical drive on the cable. If you install your second drive in an external case instead of simply laying it on it's side on top of the power supply, you will need to power it up before applying power to the system. Seems to work just like SCSI, the controller likes to find the *all* of the drives when it finishes it's own post (power-on self test). BTW, watch the little red led on the controller, if it doesn't go out after a few seconds it has failed it's own post and is defective. I've only played around with a couple of 'non-apollo' drives, but the biggest problem was jumper 31 on the drive logic board. This jumper is for hard or soft sectoring and should be out for the OMTI controller. I believe it is in for the WD7000. The jumpers 16-29 are for setting up the number of bytes per sector, 16 being a binary 1, 17 a 2, 18 a 4, and so on. BTW this doesn't seem to bother the Apollo's that much, I once set up a drive for only 512 bytes per sector and it formatted and ran just fine! Confused the heck out of the users who would interpret the block count as the amount of free space left. Surprised me that it even worked. If you have access to another Apollo there is a utility with some of the jumper information required. Just set your working directory to /systest/ssr_util and invoke jumper. Hope this helps some, Mike From: vera@fanaraaken.Stanford.EDU (James S. Vera) Newsgroups: comp.periphs,comp.sys.apollo Subject: Priam 7050 Hard Drives and Apollo DN300 shoeboxes Date: Fri, 29 Mar 91 23:27:10 EST I recently began a search for facts about the hard drives in our Apollo DN300 shoeboxes. After much search I am reporting back on what (little) I have learned. First off the hard drive in my shoebox is a Priam 7050-41. As many of you know Priam is not quite what it used to be and it turns out that a company called Sequel (sp?) +1.408.987.1533 now handles the drives. Joe Grove in technical support told me the following: Drive Interface ----- --------- 7050-11 Priam Proprietary 7050-21 SMD 7050-41 ANSI X3.101 Kathy in Sales said she would sell me the interface board to change my 7050-41 to a 7050-21 for $500 and she seemed willing to deal (maybe $250). [if for some reason I was dieing for a small SMD drive the Minicomputer exchange sells an unused 84MB drive for $125]. Closure: 1) Unless it turns out that ANSI X3.101 to anything-useful converters these drives are probably boat anchors. 2) The rumor that the drives are ST-506 compatable is unfortunately almost certainly wrong. 3) Someone on the net sent me a list of the pin outs for the drive which he obtained from some Apollo literature. The pin outs did not exactly match the pin outs in the ANSI X3.101 literature. (Why? I dont know). Thats all I know. -- James S. Vera | Internet |Standard Disclaimers Stanford University|vera@fanaraaken.stanford.edu|Blah Blah Blah Blah Bellcore |vera2@rigel.cc.bellcore.com |vvv My WARNING vvv I am an ASSU Graduate Senator, Engineering & Earth Sci. Be Suspicious! Date: Sat, 30 Mar 91 12:26:29 -0800 From: James S. Vera To: rees@citi.umich.edu (Jim Rees) Subject: Re: Priam 7050 Hard Drives and Apollo DN300 shoeboxes In-Reply-To: Your message of Sat, 30 Mar 91 12:16:00 -0500. <9103301717.AA02310@pisa.citi.umich.edu> Here's the pin outs I have: James ------------- Table 1, Pin Assignments from ANSI X3.101 Signal Ground Pin Pin Signal Name Signal Source ---------------------------------------------------------------------- 1 Ground --- CONTROL BUS 2 10 Bit 0, Select Attn Device 0 Host/Device 3 10 Bit 1, Select Attn Device 1 Host/Device 4 10 Bit 2, Select Attn Device 2 Host/Device 5 10 Bit 3, Select Attn Device 3 Host/Device 6 10 Bit 4, Select Attn Device 4 Host/Device 7 10 Bit 5, Select Attn Device 5 Host/Device 8 10 Bit 6, Select Attn Device 6 Host/Device 9 10 Bit 7, Select Attn Device 7 Host/Device 11 12 Parity (optional) Host/Device 13 14 SELECT OUT/ATTN IN STROBE Host 15 16 COMMAND REQUEST Host 17 18 PARAMETER REQUEST Host 19 20 BUS DIRECTION OUT Host 21 22 PORT NABLE Host 23 24 ADDRESS MARK CONTROL (optional) Host 25 26 READ GATE Host 27 28 WRITE GATE Host 29 30 BUS ACKNOWLEDGE Device 31 32 INDEX Device 33 34 SECTOR/ADDRESS MARK DETECTED Device 35 36 ATTENTION Device 37 36 BUSY Device 39 38 READ DATA + Device 40 38 READ DATA - Device 42 41 READ/REFERENCE CLOCK + Device 43 41 READ/REFERENCE CLOCK - Device 45 44 WRITE CLOCK + Host 46 44 WRITE CLOCK - Host 48 47 WRITE DATA + Host 49 47 WRITE DATA - Host 50 Ground ---