dem@uwslh.UUCP (David E. Miran) (05/05/89)
We have a VAX-11/750 running 4.3 BSD unix and are attempting to install
an Exabyte tape system with a CMD Technologies controller which emulates a
TMSCP device. Our main configuration includes:
A System industries disk system with a builtin massbus adaptor working as hp0-3
A System industries tape system (also massbus) as ht0.
A whole pile of Emulex multiplexors emulating dmf32's (and one real dmf32).
And an assortment of other stuff which I think is unrelated to the problem.
When we configure the tmscp driver (exactly as the book says) to generate a new
unix and attempt to boot the system we get the following strange behavior:
The configuration routine finds the disks and tape drive (ht0), finds the
tmscp device and drive, gets as far as the third of our 13 dmf emulations
and dies with: "trap type 9: panic: protection fault".
If we try the same experiment with the tmscp board removed (and a proper double
width continuity card installed) we get the exact same crash even though
the configure routine does know that there is no tmscp device.
The crash seems to be caused by simply having the tmscp device configured.
I have tried the following experiments looking for a cure based on hints
and ideas from other people:
1. Guessing maybe some address conflict, I moved all of the dmf device
addresses up 100 (octal) and changed the tmscp board to be at the base
of the floating address space. No improvement. Kernels configured with
the tmscp driver crash, ones without the tmscp driver run whether the
tmscp board is installed or not.
2. Someone suggested changing the order of my configuration file so the tmscp
device is probed last. However, the system still probes for devices in
the same order. And the same crash happens at the same place.
If anyone has any ideas as to what is going on I would appreciate some clues.
The fact that we see the same crash regardless of whether the tmscp board is
present is the real mystery. That and the fact that the crash occurs while
probing the dmf32's.
--
David E. Miran ...!{rutgers,ucbvax,harvard}!uwvax!uwslh!dem
Wisconsin State Hygiene Lab or dem%uwslh.uucp@cs.wisc.edu
University of Wisconsin (608) 262-0019
465 Henry Mall
Madison, WI 53706chris@mimsy.UUCP (Chris Torek) (05/06/89)
In article <423@uwslh.UUCP> dem@uwslh.UUCP (David E. Miran) writes: >We have a VAX-11/750 running 4.3 BSD unix and are attempting to install >an Exabyte tape system with a CMD Technologies controller which emulates a >TMSCP device. Bleah. (I hate TMSCP almost as much as MSCP :-) ) The TMSCP driver in 4.3BSD (and in 4.3-tahoe) is based on an early Ultrix driver and simply does not work. (It works for a few special cases. It crashes with a TK70 on a uVAX 3x00, after about the third operation. Rather than fix it, I intend to replace it completely; the current code is an unmaintainable mess, inherited from the old UDA/RA driver.) The crash you described sounds suspiciously like a 4.3BSD-tahoe bug rather than a 4.3BSD bug; that bug is simply that someone accidently changed dmf_uballoc[ui->ui_ubanum] to dmf_uballoc[ui->ui_unit] but that does not strike until open() time, not probe(). Looking at the tmscpprobe() code shows nothing helpful---if the board is not installed, it should time out after about ten seconds. >Someone suggested changing the order of my configuration file so the tmscp >device is probed last. However, the system still probes for devices in >the same order. This is very odd. The system probes in the order of ubdinit[] (in ioconf.c); ubdinit[] is built based on the order in the config file. It sounds as though the kernels built in /sys/FOOVAX are not the kernels being booted. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris