Article View: net.bugs.2bsd
Article #268Re: Q-bus tape drive problems
From: Dan Ts'o
Date: Fri, 20 Sep 1985 16:49
Date: Fri, 20 Sep 1985 16:49
59 lines
2836 bytes
2836 bytes
In article <8100003@uiucdcs> goldberg@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@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@cmcl2.arpa
Technical Details
Message-ID:
<439@rna.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!cmcl2!rna!danReferences:
<8100003@uiucdcs>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site rna.UUCP Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!cmcl2!rna!dan From: dan@rna.UUCP (Dan Ts'o) Newsgroups: net.bugs.2bsd Subject: Re: Q-bus tape drive problems Message-ID: <439@rna.UUCP> Date: Fri, 20-Sep-85 12:49:23 EDT Article-I.D.: rna.439 Posted: Fri Sep 20 12:49:23 1985 Date-Received: Sun, 22-Sep-85 06:35:31 EDT References: <8100003@uiucdcs> Reply-To: dan@rna.UUCP (Dan Ts'o) Organization: Rockefeller Neurobiology Lines: 59