goldberg@uiucdcs.Uiuc.ARPA (09/17/85)
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
dan@rna.UUCP (Dan Ts'o) (09/20/85)
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