Q-bus tape drive problems

Dan Ts'o dan at rna.UUCP
Sat Sep 21 02:49:23 AEST 1985


In article <8100003 at uiucdcs> goldberg at uiucdcs.Uiuc.ARPA writes:
>
>Is there anyone running 2.9 on a 22-bit Q-bus system using any 18-bit
>DMA devices?  In particular, I have a TM-11 emulator that only does
>18-bit addressing.  Rebooting every time I want to use the raw device
>is a royal pain.  Suggestions or code greatfully appreciated.  Thanks
>in advance for any assistance.
>
>			     Phil Goldberg
>			     217-333-7620
>			   goldberg at Uiuc.ARPA
>	       ...!{ihnp4,convex,pur-ee}!uiucdcs!goldberg

	I can think of two solutions.
	1) Buy hardware. There exists Qbus maps which map the 18-bit Qbus
		to the 22-bit Q-bus, analogous to a Unibus map. This of
		courses assumes that the cost of the map (~$1500) doesn't
		exceed a new controller for your tape (if you can get one,
		is it formatted ?) Of course, other 18-bit devices would
		then work as well, after modifying their drivers. Oh, and
		you'll probably need a second Qbus chassis to serve as the
		18-bit backplane.

	Well, that solution isn't great unless you have a huge investment in
	18-bit devices.

	2) Try to lock each program that requires access to raw devices in
	low-core (18-bit memory). This assumes you have some 18-bit memory
	left (that the kernel is not using for its code, data, or buffers).

	I don't remember, but I believe 2.9BSD still has the V7 lock() and
	phys() call.

	Using phys(), modify the kernel to allocate a buffer in 18-bit
	space and modify your program, dd(1) for example, to use that
	buffer, calling phys().

	A better way, modify the lock() call, (a VERY simple mod) to
	return the address where your program is locked. Then loop on
	lock()/unlock() until your program is locked into 18-bit space.
	You may require some other manipulation in between lock()'s to
	insure that some swapping/memory shuffling is done to increase
	your chances of being locked into 18-bit space.

	We have used the last technique quite successfully. I can send
	you the modified lock() system call.

	I don't know of better solutions.


					Cheers,
					Dan Ts'o
					Dept. Neurobiology
					Rockefeller Univ.
					1230 York Ave.
					NY, NY 10021
					212-570-7671
					...cmcl2!rna!dan
					rna!dan at cmcl2.arpa



More information about the Comp.bugs.2bsd mailing list