dodgson@cs.wmich.edu (Harry Dodgson) (03/24/89)
First some system specs, then the question. We have a VAX 11/750, 4Meg memory, dectape on cpu, (2) RA81 drives, and a TU80 tape drive. We run BSD 4.3 Unix -Generic-. The system currently sets the microcode rev level at 98. The DEC rep will be in this Tuesday to upgrade the microcode to level 103. He doesn't know anything about Unix. I don't have any idea of how to get this onto the drives either. Does anyone know what I have to do to get the code from his tape onto the RA81s? -- Harry Dodgson Jr. Internet: dodgson@cs.wmich.edu Western Michigan University (35.132.4.1) Computer Science Department Voice: (616) 387-5803 Kalamazoo, MI 49008
hakanson@mist.cs.orst.edu (Marion Hakanson) (03/24/89)
One can use arff(1) to manipulate VAX console media. I have done just
that to extract a new microcode file from a tu58 cassette on the 750
which we no longer have. Just before we got rid of the fellow, they
installed a boot prom upgrade which caused it to look for the ucode
file on the tu58 at power-on boot time. This takes forever, so having
the 4.3bsd boot(1) patch (which we did a long, long time ago) do the
ucode loading from disk is preferable (leaving out the cassette makes
the prom skip trying the ucode load).
Please don't anyone ask me for the aforementioned patch -- I haven't
got it readily accessible anymore, and it's probably part of 4.3-tahoe
anyway (just a guess).
--
Marion Hakanson Domain: hakanson@cs.orst.edu
UUCP : {hp-pcd,tektronix}!orstcs!hakansonchris@mimsy.UUCP (Chris Torek) (03/26/89)
In article <485@cs.wmich.edu> dodgson@cs.wmich.edu (Harry Dodgson) writes: >We have a VAX 11/750 ... We run BSD 4.3 Unix -Generic-. (which I assume means a kernel compiled from /sys/conf/GENERIC; you really should compile a machine-specific kernel.) >The system currently sets the microcode rev level at 98. >The DEC rep will be in this Tuesday to upgrade the microcode to >level 103. He doesn't know anything about Unix. ... He can find out, via DEC's internal courses on Ultrix. As far as I know, the Ultrix boot code still uses the 4BSD-style microcode patch sequence. At any rate: If you look at /sys/stand/boot.c, you will find a section of code labelled with the comment `750 Patchable Control Store magic'. This code attempts to open the file `/pcs750.bin' on the same partiton from which will read `/vmunix'. If the file exists, it is assumed to be a PCS file and its contents are stored to the PCS. The file /pcs750.bin that came with your 4.3BSD tape is the rev 98 patch. You have several alternatives. You can (a) ignore the new microcode; (b) load the new microcode from TU58 every boot; or (c) copy the new microcode to /pcs750.bin. I think we can skip (a). (b) is painfully slow. That leaves option (c), which is the best all around. The first trick is reading the microcode from TU58. This is best done with the machine up in single user mode. The `arff' utility can read TU58 cassettes. Type # mount /tmp (if you keep /tmp on another partition) # cd /tmp # arff tvf /dev/tu0 (print a list of what is on the TU58) (you do not actually need the f option and /dev/tu0; arff normally looks at /dev/floppy, which is the same device anyway. Maybe some day I will fix this to be `/dev/console-media' :-) .) At this point, you have to find the patch file yourself. I have no real idea what it will be called, just a guess: `pcs750.bin' or `pcs103.bin'. Assuming the latter: # arff xvf /dev/tu0 pcs103.bin You now have a file /tmp/pcs103.bin. Assuming this is in the same format as /pcs750.bin, you can then do the following: # cd / # mv pcs750.bin pcs750.bin.rev99 # cp /tmp/pcs103.bin pcs750.bin.103 # ln pcs750.bin.103 pcs750.bin This leaves the original in pcs750.bin.rev99, in case you need it later. The only thing left then is to reboot. There is one problem. If the new pcs750.bin makes the machine fail to boot, you need some way to recover. One is to go back to the distribution tape and load a mini-root. This is painful. There are some nicer alternatives. The simplest depends on the fact that you have two disks. Instead of putting pcs750.bin.103 in ra0a:/, you can put it in ra1a:/ (along with a copy of /vmunix), and then boot from ra1a: >>>B/3 Boot : ra(0,8)vmunix loading 11/750 microcode: new rev level = 103 240096+114004+106828 start 0x16a4 ... This assumes you have an ra1a. (We make a practise here of keeping an alternate root file system on one other drive wherever we have at least two drives. If you have /tmp on ra1a, that would suffice too.) If the RA81 partitions in /boot match those in your kernel, you can put the microcode in any partition of either drive and boot from there. (Some boots have different ideas; check the offsets in /sys/stand/uda.c vs. those in /sys/vaxuba/uda.c. Yet another reason for disk labels....) If all else fails, you can cheat and put it in a partition that starts at offset 0 on ra1, and boot from ra1c (ra(0,10)). If, for some reason, you choose option (b), you will have to rename or remove (renaming is suggested) /pcs750.bin, or /boot will promptly downgrade your machine before loading /vmunix. One other alternative is to build a new /boot, installed as /boot1 or /boot.new or ..., which reads pcs750.bin.103 (an easy change to /sys/stand/boot.c), and boot /boot1: >>>B/3 Boot : ra(0,0)boot1 Updating 11/750 microcode: new rev level = 98 Boot : ra(0,0)vmunix Updating 11/750 microcode: new rev level = 103 [sizes, etc] When you decide that everything works, rename pcs750.bin.103 as pcs750.bin, remove /boot1, and you are all set. (The `boot1' technique works well for testing new /boot programs as well; it is what I used for testing my QDSS standalone console driver.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
heins@atanasoff.cs.iastate.edu (Leeland Heins) (03/29/89)
In article <485@cs.wmich.edu> dodgson@cs.wmich.edu (Harry Dodgson) writes: > > First some system specs, then the question. >We have a VAX 11/750, 4Meg memory, dectape on cpu, (2) RA81 drives, >and a TU80 tape drive. We run BSD 4.3 Unix -Generic-. >The system currently sets the microcode rev level at 98. > >The DEC rep will be in this Tuesday to upgrade the microcode to >level 103. He doesn't know anything about Unix. I don't have ** opinion on :-) ** Does any DEC rep ever say anything but "buy VMS"? :-) >any idea of how to get this onto the drives either. Does anyone >know what I have to do to get the code from his tape onto the RA81s? If I'm not mistaken the microcode goes onto your TU58 boot tape that goes into your 750's console, not onto the RA81. The TU58 is the small (and slllooowww) tape cartidge that makes a lot of noise when you turn your 750 on from a cold start as it displays the messages on your console device (usually a DECWriter III). You should be able to use 'dd' to copy the files to the TU58... on second thought, it might be better to read the section in the BSD docs on "Installing and Operating 4.3BSD on the VAX" about making a console boot tape. I've done this before (over a year ago) on our old 730 which also uses a TU58 as its console tape. On second thought, if the 'tape' he is talking about is a TU58 cartrige, you can use the console 'COPY' command to copy the new files onto your boot tape (make sure to make a backup of it with COPY first though!). >-- >Harry Dodgson Jr. Internet: dodgson@cs.wmich.edu >Western Michigan University (35.132.4.1) >Computer Science Department Voice: (616) 387-5803 >Kalamazoo, MI 49008 Lee Heins, EXNET Programmer Iowa State U. Extension ..!hplabs!hp-lsd!atanasoff!heins
roy@phri.UUCP (Roy Smith) (03/30/89)
dodgson@cs.wmich.edu (Harry Dodgson) writes: > The DEC rep will be in this Tuesday to upgrade the microcode to > level 103. He doesn't know anything about Unix. Some number of years ago, when our 750 was fairly new, DEC came out with a "rev 7" upgrade, which was some minor change in the memory controller having to do with catching cache parity errors, or something like that (I don't remember exactly, but the details are not that important). DEC insisted on installing it on our 750 and I foolishly let them. The result was weeks (or was it months?) of agony. It never worked right and DEC insisted on putting the blame on the fact that we were running Unix. Eventually, after GOK how many board swaps, they got us a board that worked, claiming that they were special-testing boards to find ones that ran under Unix. When I say I "foolishly" let them install it, what I mean is that until they did the upgrade, we didn't have any problems; we never had the symptoms that the upgrade was supposed to cure and after the upgrade we had *lots* of problems. My advice is to ask DEC just *why* they want to install the new microcode, and don't let them unless they have a damn good reason. If your machine works as it is, what do you have to gain by changing something? heins@atanasoff.cs.iastate.edu (Leeland Heins) writes: > ** opinion on :-) ** Does any DEC rep ever say anything but "buy VMS"? :-) I saw an interesting statistic in (of all places) MacWEEK (21 March 1989, page 60). They did a (somewhat silly) survey of Macs connected to bigger machines at 269 "very large Macintosh sites". They found that of Vaxen with "connected" Macs, 54% run only Ultrix (which I take to mean Unix of various flavors), 37% run a mix of Ultrix and VMS, and only 1% run strictly VMS. They didn't mention if these were academic or commercial sites. I hope this doesn't start another VMS vs. Unix war. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@phri.nyu.edu "The connector is the network"
rta@pixar.UUCP (Rick Ace) (03/31/89)
In article <3729@phri.UUCP>, roy@phri.UUCP (Roy Smith) writes: > Some number of years ago, when our 750 was fairly new, DEC came out > with a "rev 7" upgrade, which was some minor change in the memory controller > having to do with catching cache parity errors, or something like that (I > don't remember exactly, but the details are not that important). DEC > insisted on installing it on our 750 and I foolishly let them. > > The result was weeks (or was it months?) of agony. It never worked > right and DEC insisted on putting the blame on the fact that we were running > Unix. Eventually, after GOK how many board swaps, they got us a board that > worked, claiming that they were special-testing boards to find ones that ran > under Unix. When I say I "foolishly" let them install it, what I mean is > that until they did the upgrade, we didn't have any problems; we never had > the symptoms that the upgrade was supposed to cure and after the upgrade we > had *lots* of problems. > > My advice is to ask DEC just *why* they want to install the new > microcode, and don't let them unless they have a damn good reason. If your > machine works as it is, what do you have to gain by changing something? I suspect DEC will answer like this: "Because Field Service will soon refuse to support Vax-11/750 systems that are not up to Rev 7." This is true of hardware and software alike. It makes no economic sense for a vendor to support previous versions of products when the current versions are supersets of their predecessors. Now in Roy's case, the Rev 7 upgrade did not deliver a superset of what it replaced. However, it's probably true that DEC had no idea that things were going to get worse when they did the upgrade. (As an example, Field Service upgraded two 750s at NYIT to Rev 7 a few years ago, and outside of my having to figure out how to make 4.2bsd load the microcode, both upgrades went smoothly.) Roy, the best thing you could have done was to demand that DEC commit to a date (as early as you bargain for) by which they will either make Rev 7 work or return you to your previous revision level. If the local F-S manager won't buy into that, talk to his/her superior(s) until you get satisfaction. Rick Ace Pixar 3240 Kerner Blvd, San Rafael CA 94901 ...!{sun,ucbvax}!pixar!rta
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/31/89)
In article <3623@pixar.UUCP> rta@pixar.UUCP (Rick Ace) writes: >However, it's >probably true that DEC had no idea that things were going to >get worse when they did the upgrade. Doubtful. It's a well-known and unfortunate fact of life that many changes in DEC hardware and software are done mostly to break third-party products. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ARPA: dhesi@bsu-cs.bsu.edu
roy@phri.UUCP (Roy Smith) (03/31/89)
In article <3623@pixar.UUCP> rta@pixar.UUCP (Rick Ace) writes: > It makes no economic sense for a vendor to support previous versions of > products when the current versions are supersets of their predecessors. > [...] Roy, the best thing you could have done was to demand that DEC > commit to a date (as early as you bargain for) by which they will either > make Rev 7 work or return you to your previous revision level. Rick is, of course, right. In the end, what happened was essentially what Rick suggested; I demanded that if they couldn't fix they they had to put it back to how it was before they started, which eventually they did (fix it, that is). For the record, once the bugs were ironed out, it did work, and has worked fine for years since. Those of you who have followed my rantings over the years know that I'm pretty cynical when it comes to DEC field service; sometimes I get carried away. As a case in point, on the AppleTalk network I try to administer, I don't let anybody plug in a Mac unless they are running the latest version of the system software (or, in the case of 6.0, the latest version that I decree to be working properly). I suppose some people get pissed at me when I demand that they upgrade their system software when what they are running now works fine for them. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@phri.nyu.edu "The connector is the network"
john@frog.UUCP (John Woods) (04/02/89)
In article <3729@phri.UUCP>, roy@phri.UUCP (Roy Smith) writes: > 1989, page 60). They did a (somewhat silly) survey of Macs connected to > bigger machines at 269 "very large Macintosh sites". They found that of > Vaxen with "connected" Macs, 54% run only Ultrix (which I take to mean Unix > of various flavors), 37% run a mix of Ultrix and VMS, and only 1% run > strictly VMS. The remaining 8% are still waiting for the "Happy VAX" icon to appear on the console screen... :-) -- John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu Remainder Khomeini!