TUHS

tuhs@tuhs.org

6532 discussions

RE: [TUHS] re: Raise of interrupt level necessary

by Ian King

Yes, I have v6 running on an 11/34; it's amazing how easy it is to corrupt the filesystem. :-) One of these days, I need to dd another fresh system disk (RK05) off my "sacred copy" of a PUPS image (tediously transferred via 9600 baud serial using Warren's excellent vtserver tools). In any case, why do you ask? - Ian -----Original Message----- From: Wolfgang Helbig [mailto:helbig@Informatik.BA-Stuttgart.DE] Sent: Saturday, December 14, 2002 12:48 AM To: tuhs(a)minnie.tuhs.org Subject: Re: [TUHS] re: Raise of interrupt level necessary [snip] I also removed IPL protection from the return sequence of the trap routine, still works. Testing was done on Bob Supnik's SIMH PDP-11 simulator with only one terminal. By the way, is anyone running V6 on a real PDP-11? [snip]

22 years, 6 months

re: Raise of interrupt level necessary

by Wolfgang Helbig

>Date: Sat, 14 Dec 2002 15:27:40 -0800 Michael Davidson wrote: >If you think that the "rule" is "no ISR can touch user space while >interrupting a kernel process", then it is display() that breaks >the rule. The point is, that this rule leads to somewhat simpler and therefore better code -- breaking the rule calls for some justification. Calling display() from the clock-ISR is the only place where an ISR does not conform to this rule. Greetings Wolfgang Helbig

22 years, 6 months

Re: [TUHS] re: Raise of interrupt level necessary

by Wolfgang Helbig

Dennis, I greatly appreciate your reply. What amazes me most, is the fact that after 20 odd years you still remember those tricky details: >For example, the clock interrupt routine can inspect user >space (for display(), for example, though this is inactive >on the 11/40), and even change it (for profiling). >It does appear that other things (checking for >a direct-from user-mode interrupt) in the clock routine >already guard against these particular problems. To see what happens, I just removed those IPL raising instructions from gword, pword,_savu, _aretu, _copyseg, and _clearseg in m40.s. In fact, it didn't crash the system. At least on my configuration, ISRs don't touch user space while interrupting a kernel process. This rule is broken by the clock ISR, which calls display() unconditionally. Just curious: Is there any other reason beside seeing blinking lights that justifies calling display() 60 times per second and breaking the rule? I also removed IPL protection from the return sequence of the trap routine, still works. Testing was done on Bob Supnik's SIMH PDP-11 simulator with only one terminal. By the way, is anyone running V6 on a real PDP-11? Here is the diff of my modifications to m40.s: # diff m40.s.6 m40.s 44d43 * bis $340,PS 455,456d453 * mov PS,-(sp) * bis $340,PS 472,473d468 * mov PS,-(sp) * bis $340,PS 480d474 * mov (sp)+,PS 485d478 * mov (sp)+,PS 539d531 * bis $340,PS 548d539 * bis $340,PS 594c585 * mov $30340,PS --- . bis $30000,PS 621c612 * mov $30340,PS --- . bis $30000,PS Greetings, Wolfgang Helbig

22 years, 6 months

qbus scsi controllers

by Robertdkeys＠aol.com

I know it causes one to salivate like Pavlov's dogs, even thinking about them, but, anyone know of any qbus scsi controllers that might someday come available at anything like reasonable sorts of guildern de realme? (running and ducking for cover....(:+]].....) Just thought I would check. Thanks Bob

22 years, 6 months

Re: [TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

by Robertdkeys＠aol.com

The particular webster wqesd4 I have looks like about an '86 or so board, from chip dates, and the main chip that is socketed is marked with "ENGR-SAMPLE"...doh.... Maybe I do have a very early board that won't run with a faster cpu. The rom is a part no. 080469-01 REV 01, if that means anything to anyone, as marked on its paper label. The later sigma board does not have the problem. Oh, well, if I have to run it with a KA630 at slo-poke gait, so be it....(:+\\... There are two diodes, one looks like an ordinary silicon rectifier and one looks like a zener of some sort, possibly, off pin 19 of the 74ls240 at position V2 on the board. Those come off the J6 pin 10 of 10, and are in parallel. Thanks Bob

22 years, 6 months

flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

by John Holden

Early ROM revisions on the Webster MSCP controllers were too slow for the KA650 and would often loose interrupts (amoungst other things). Signals such as NPR and BR grants were polled from a pseudo microcode loop which took too long. The RS232 interface doesn't use standard receivers. Check for a 5 volt zener on the input of an 74LS240 (from the 10 pin i/o connector) and add a schottky in parallel (a 1N5818 would do) if one isn't there

22 years, 6 months

flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

by norman＠nose.cs.utoronto.ca

If you can read this, the 4-port Wombat (Webster/Sigma ESDI controller) in the KA650 system through which this mail must pass on its way out is working fine, as it has since I installed it in that system a year and a half ago. According to my notes, I had no trouble communicating with the onboard diagnostic monitor (with the board in another KA650 reserved for system testing). I used the monitor quite a bit, starting it many times, first because it took me a long time to realize that the terminator had been left installed backwards in one of the drives (so the drive wasn't visible to the controller no matter what I did to the cables). I don't think I tried the serial port on the back of the Wombat board; instead I uttered the magic commands to load and run the Wombat communication program on the VAX itself. I'd expect this to be more timing-sensitive than the hardware port. In any case it worked fine. Once the controller could see the disks (and I'd done some formatting and some testing with the diagnostics), I tested the Wombat under my oddball version of UNIX, and found what may be an MSCP implementation botch. A UNIBUS/QBUS MSCP storage port gets only one interrupt vector; it is supposed to set one of two flags to indicate whether it is interrupting because there were no command slots and it freed one, or because there were no messages waiting to be read and it supplied one. The Wombat appeared often to be tardy in setting the `message waiting' flag; my port driver often received an interrupt, checked the flags, found nothing to do, and of course dismissed the interrupt without realizing that the controller had in fact reported an I/O completion. (And of course if I halted the system and took a crash dump I found the flag set. It took some real-time tracing to uncover the problem.) It is easy to work around this--instead of relying on the flag, one can go look at the message descriptors to see if there's a new message-- so that is what my driver now does. I have a vague memory that the original Ultrix MSCP driver, whence the current BSD one is probably descended and the current Ultrix one more distantly, already did it that way. Silly me, I programmed from the protocol spec rather than just blindly copying someone else's unexplained code ... None of this explains why Bob Keys is having trouble, but it does suggest to me that the Wombat firmware might have other subtle bugs that are tickled by particular systems, perhaps even timing-dependent problems. (I haven't checked, but it could well be that the interrupt- flag bug would be invisible to a KA630 because it took a little longer to get to that part of the interrupt routine.) I have two Wombat boards with slightly different firmware. (One is labelled RQD11-EC and its diagnostic monitor calls itself WOMBAT; the other is branded by SpectraLogic, I forget what model it calls itself, but the monitor calls itself SLEUTH.) My notes don't say whether they both displayed the interrupt botch. I do know that communications with the diagnostic monitor worked fine with both. The RQD11-EC claimed to have firmware (or perhaps diagnostic monitor) version 2.38. Norman Wilson Toronto ON

22 years, 6 months

Re: [TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

by Carl Lowenstein

> From: msokolov(a)ivan.Harhan.ORG (Michael Sokolov) > To: tuhs(a)tuhs.org > Subject: Re: [TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650??? > Date: Thu, 12 Dec 02 23:29:58 PST > > Robertdkeys(a)aol.com wrote: > > > Is there an endemic problem with this style 4 > > port controller running too fast with a KA650 > > compared to a KA630 cpu? > > I have no explanation for your problem, but it has nothing to do > with speed. Q-bus is Q-bus, and it follows Q-bus timing, which is > completely independent of the VAX CPU timing. Yes but there might be CPU spin-loop timing to run the serial maintenance port from the ROM bootstrap code of the controller. Not considered good form -- but such things happen. Some early version of the Sigma RQD11 would work in an 11/73 but not a KA630. I no longer remember the exact symptoms, but I was glad that at the time Sigma was only an 80-mile drive from here. carl -- carl lowenstein marine physical lab u.c. san diego clowenst(a)ucsd.edu

22 years, 6 months

Re: [TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

by Robertdkeys＠aol.com

I found out what the problem was.....(sheepishly ducking...(:+\\...). At 3 in the morning I had a typeo in the config file that the old eyeballs did not catch. I had typed in the partitions to allocate to root and swap, as opposed to just the the disks. It compiled fine, but when run, it paniced and dumped itself all over the floor. So much for myopic eyes programming at 3 in the morning..... (:+{{..... Bob

22 years, 6 months

Re: [TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

by msokolov＠ivan.Harhan.ORG

Robertdkeys(a)aol.com wrote: > Is there an endemic problem with this style 4 > port controller running too fast with a KA650 > compared to a KA630 cpu? I have no explanation for your problem, but it has nothing to do with speed. Q-bus is Q-bus, and it follows Q-bus timing, which is completely independent of the VAX CPU timing. Is the new CPU board firmly seated? Nothing broken or disturbed in the backplane when swapping the boards? > Ultrix seems to handle it better than Tahoe. > It might be speed in the hardware and slight > differences in drivers? Ultrix' MSCP code is vastly superior to anything we've ever had in BSD. I plan to lift the MSCP/SCA framework from Ultrix wholesale in Quasijarus down the line. MS

22 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS