renga@perpetua.cs.uoregon.edu (Renganathan Sundararajan) (01/25/91)
Please HELP! A few weeks ago, I posted a message asking for help in accessing a HP 9145 cartridge tape drive connected to a HP 9000/835 system running HP-UX 7.0. I said >We have hp9145 32-track cartridge tape drive and we cannot >access the tape drive using any of the sp. files in >/dec/rct or /dev/ct. The following people responded to my message and a big THANK YOU to all of you. jfk@ais.org (Jim Knight) jim@tiamat.fsc.com (Jim O'Connor) dawn <ledbette@watserv1.uwaterloo.ca> Shankar Unni <shankar@hpclscu.cup.hp.com> R.T.Eames@cc.flinders.edu.au <mgrte@cc.flinders.edu.au> kk@hpl-opus.hpl.hp.com (Konstantinos Konstantinides) bobk@hpcuha.cup.hp.com (Bob Kentwortz) ralfw@hpbbi4.BBN.HP.COM (#Ralf Wiegert) Michaeljon Miller <miller@jeep.dsg.honeywell.com> Jim Sadler <jsadler@misty.boeing.com> robs@hpuamsa.neth.hp.com (Rob Slotemaker CRC) Since tcio produced the following error msgs, tcio(1004): cannot access tape ... ; errno 2 (No such file or directory) tcio(1004): cannot access tape ... ; errno 6 (No such device or address) tcio(1004): cannot access tape ... ; errno 19 (No such device ) almost all the above people suggested creating appropriate device files using mksf, mknod or insf commands. I was also asked to verify that the /etc/devices file contains the approprate entry for the driver (disc0) for cartridge tapes. I tried all the suggestions but I kept getting errno 6. So I hit the HP manuals on Installation and Configuration, System Administration and did a lot of head scratching. Found that for our configuration (HP 835 with 1 non-7914 CT drive, graphics console, no access port card, no graphics animation interface card), CIO slot 0 is supposed to contain the HP/FL card and CIO slot 5 the HP-IB card for a CT drive with HP-IB address 3. (I verified that the address switch on the back of our CTD is set to 3.) The person who installed HP-UX 7.0 had followed the directions and hence /etc/devices file had the following entry. disc0 lu 0 address 4.5.3 b_major 0 c_major 4 and there were device files in /dev/rct and /dev/ct corresponding to the address 4.5.3. File permissions were set properly. Since everything seemed ok, I suspected that 1. either the HP enginners who originally installed the system did not install the HP-IB card in CIO slot 5 for SOME (UNKNOWN) REASON 2. or HP-UX 7.0 UNREASONABLY assumes that the HP-IB card for a given configuration X will be in slot Y in all installations. (More about this at the end.) I finally removed the top and back panels of our machine and peered into the back of the CIO card cage, armed with the CIO diagrams from the manual. This is what I found. Slot numbers are from left, viewed from the back of the CIO card cage. Slot 0 - HP/FL (fiber optic cable coming out) Slot 1 - empty Slot 2 - HP/IB cable to the CTD drive! (Appendix A of "HP 9000 Series: System Administration Series - Installing and Updating HP-UX" lists tables for different configurations and slot 2 is supposed to be ** used only for Mag Tape Drives ** and not for CTDs. HP-IB card for CTDs is supposed to installed in slot 5 for out configuration.) slot 6 - Graphics Interface Card (mid-bus slot 2 and also CIO slot 6) Based on this, I edited the /etc/conf/gen/S800 file and the io stmt in it is as follows: io { cio_ca0 address 4 { hpfl0 address 0 { disc2 lu 0 address 0; disc2 lu 1 address 1; disc2 lu 2 address 2; disc2 lu 3 address 3; disc2 lu 4 address 4; disc2 lu 5 address 5; disc2 lu 6 address 6; disc2 lu 7 address 7; } mux0 lu 0 address 1; hpib0 address 2 { disc0 lu 0 address 3; /* ct drive address is 3 */ disc0 lu 1 address 1; disc0 lu 2 address 2; } mux0 lu 1 address 3; lan0 lu 0 address 4; hpib0 address 5 { disc0 lu 3 address 0; } } graph0 address 8 { display0 lu 0 address 0; } } I recompiled the kernel & installed it following the instructions in the manual, regenerated the device files, rebooted without any problems and the output of lssf /dev/rct/* is as follows. disc0 lu 0 unit 0 section 2 address 4.2.3 ct c0d0s2 disc0 lu 0 unit 1 section 2 address 4.2.3 ct c0d1s2 disc0 lu 1 unit 0 section 2 address 4.2.1 ct c1d0s2 disc0 lu 1 unit 1 section 2 address 4.2.1 ct c1d1s2 disc0 lu 2 unit 0 section 2 address 4.2.2 ct c2d0s2 disc0 lu 2 unit 1 section 2 address 4.2.2 ct c2d1s2 disc0 lu 3 unit 0 section 2 address 4.5.0 ct c3d0s2 disc0 lu 3 unit 1 section 2 address 4.5.0 ct c3d1s2 and ls -lt shows the permissions are ok. crw-rw-rw- 1 bin bin 4 0x400322 Jan 13 18:05 c3d1s2 crw-rw-rw- 1 bin bin 4 0x400302 Jan 13 18:05 c3d0s2 crw-rw-rw- 1 bin bin 4 0x400202 Jan 13 18:05 c2d0s2 crw-rw-rw- 1 bin bin 4 0x400222 Jan 13 18:05 c2d1s2 crw-rw-rw- 1 bin bin 4 0x400122 Jan 13 18:05 c1d1s2 crw-rw-rw- 1 bin bin 4 0x400102 Jan 13 18:05 c1d0s2 crw-rw-rw- 1 bin bin 4 0x400022 Jan 13 18:05 c0d1s2 crw-rw-rw- 1 bin bin 4 0x400002 Jan 13 18:05 c0d0s2 End of our problems? No. All the following commands ls | cpio -o | tcio -ovV -S 8 c0d0s2 ls | cpio -o | tcio -ovV -S 8 c0d1s2 tcio -urv c0d0s2 tcio -urv c0d1s2 hang the process. I cannot kill the process by Ctrl-C or background it by Ctrl-Z and then kill it. I have to kill it from another process and whn I do that the following msg appears on the console after a short time. Diagnostic hardware error from disc0 (at 4.2.3): status = TIMEOUT During all this, the tape drive does nothing. The tape drive doesn't seem to borken. When I powercycle the tape drive, it does a self-test and the indicator at the back shows P 3. 3 is the address of the tape drive, but what does P mean? (I searched for the tape drive manual in our manual lib but couldn't find it). Also when I press the display results switch at the back, the LED display shows U O. What does it mean? (abbrev. for University of Oregon? :-) We had used the very same CTD to install HP-UX 7.0 and I doubt that it is a hardware error despite what tcio says. What do I do next? Now for a complaint: We have another identical machine (software and hardware) and this has a mayfly connected its HP-IB slot 2. We are able to talk to the mayfly despite the fact that the /etc/devices file has the wrong entry for CIO slot 2. My guess is that the mayfly library does not rely on **hard-coded** address (that may have no relationship to the actual configuration, as it turns out in our case) but finds out at run time the slot in which the HP-IB card is installed and uses that slot number (much the same way the transputer toolkit we have on our Mac finds the address of the NuBus slot in which a LINK-II card is installed, by querying each slot). Why does HP-UX not do the same thing? Do we have to go thru all this for each OS version? I am frankly surprised that the people who wrote the kernel didn't think of this or if they did, did not consider it to be important. Why doesn't the installation process simply read the existing configuration file and use the information in it? If the format of the file has changed, the process can back up the old file and create a configuration file in the new format with information about existing devices intact. Please help. Renga -------------------------------------------------------------------- Renga Sundararajan Department of Computer Science University of Oregon Eugene, OR 97403-1202 INTERNET: renga@cs.uoregon.edu CSNET: renga@uoregon.csnet USENET: {decvax, allegra}!tektronix!uoregon!renga -------------------------------------------------------------------- -- -------------------------------------------------------------------- Renga Sundararajan Department of Computer Science University of Oregon Eugene, OR 97403-1202 INTERNET: renga@cs.uoregon.edu CSNET: renga@uoregon.csnet USENET: {decvax, allegra}!tektronix!uoregon!renga --------------------------------------------------------------------
ralfw@hpbbi4.BBN.HP.COM (#Ralf Wiegert) (01/28/91)
>Now for a complaint: We have another identical machine (software and >hardware) and this has a mayfly connected its HP-IB slot 2. >We are able to talk to the mayfly despite the fact that the /etc/devices >file has the wrong entry for CIO slot 2. My guess is that the mayfly The /etc/devices file is only used for insf, mksf, lssf. (devices - file of driver information for insf, mksf, lssf) See man 4 devices. If the major and minor code of the device file is correct you can talk to the device with a wrong /etc/devices file. This is an unofficial statement. Ralf Wiegert
bobk@hpcuha.cup.hp.com (Bob Kentwortz) (02/02/91)
A quick pass through your last summary: P 3 on the back of the 9145 says P (passed self test) 3 (hpib address) your tcio and cpio commands do not give the full path names for the device files you are using (which were correct). use /dev/rct/c0d0s2. I do not know what the U 0 meant for the drive. By the way, rather than regen the kernel, I would have moved the card from slot 2 to 5, but then I'm a h/w person. What you did was fine too. bobk@hpda.hp.com