linde@srcsip.UUCP (Larry Linde) (10/09/85)
Is anyone running Bsd 4.2 on a vax 11/785? If so do you have any
problems with it just hanging (both single and multi user mode).
It seems that it does it faster if you start getting the system
busy with several tasks? Are there any changes that a standard
BSD 4.2 kernal must have made to it to run on a 785? We are running
just fine on several 750's and 780's The configuration of the 785 is
as follows:
11/785 cpu
12mb memory (i know it only sees 8mb)
ra81
ra60
tu80
il1010 (interlan ethernet card)
and
unconfigured.
dr11-wc
tu81
dmz32
This the the gerneric kernal that is hanging so it is not any
mods that I have made. Also yes we have a source license.
Also while i am at it does anyone have a driver for the tu81?
If so how do i obtain it?
--
============================================================================
I Usenet:{philabs,ihnp4!umn-cs}!srcsip!linde /Larry Linde MN17-234 I
I Arpanet: Linde@HI-MULTICS / 2600 Ridgway Pky. I
I US-SNAIL: / Mpls, MN 55413 I
============================================================================chuqui@nsc.UUCP (Chuq Von Rospach) (10/13/85)
In article <1513@srcsip.UUCP> linde@srcsip.UUCP (Larry Linde) writes: >Is anyone running Bsd 4.2 on a vax 11/785? If so do you have any >problems with it just hanging (both single and multi user mode). We are running 4.2 on our 785 (the enhanced BRL release 3 version). The only two problems I have with it are an occasional silly message out of syslogd (I've mentioned this recently on the net already) and having the network stop on occasion. What I THINK is happening, and haven't had time to track down, is that the kernel DELAY() routine is implemented by a register countdown loop. With the 785 significantly faster than a 780, a DELAY() loop that is cut too finely may simply not be long enough in all cases, and I think my ethernet board drops an interrupt on the floor. If your machine is simply going away (total responsiveness except to console ^P commands) you might try finding the macro definition and doubling the delay loop. I haven't had time to do that, but it couldn't hurt (could it?) That seems to be the only place that the processor change could be visible to the operating system (there really ought to be a way to build a decent delay routine without making processor speed assumptions... sigh.) chuq -- :From the caverns of the Crystal Cave: Chuq Von Rospach Currently: nsc!chuqui@decwrl.ARPA {decwrl,hplabs,ihnp4,pyramid}!nsc!chuqui Soon to be: ..!sun!<somethingorother> Our time is past -- it is a time for men, not magic. Come, let us leave this world to the usurpers and rest our weary bones....
chris@umcp-cs.UUCP (Chris Torek) (10/17/85)
In article <3252@nsc.UUCP> chuqui@nsc.UUCP (Chuq Von Rospach) writes: > the kernel DELAY() routine is implemented by a register countdown > loop. ... there really ought to be a way to build a decent delay > routine without making processor speed assumptions... With the 8600 support in 4.3, the `DELAY' macro now multiplies your delay by the CPU speed factor, this having been gleaned from the per-cpu data structures during autoconfig. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
roy@phri.UUCP (Roy Smith) (10/17/85)
> there really ought to be a way to build a decent > delay routine without making processor speed assumptions > Chuq Von Rospach (Currently: nsc!chuqui@decwrl.ARPA) How about during the (very) early boot stages, you set a hardware real-time timer for 1 second then start counting up from zero? When you get the interrupt you have the speed of the processor in trivial_for_loops per second. Divide this by 1000, save the result, and you can then calculate processor-independent ms-range delay loops whenever you have to. This doesn't help if you really want a delay *macro*, but I'm assuming that if you want a 5ms delay, you don't care about the function call overhead. -- Roy Smith <allegra!phri!roy> System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016