TUHS

tuhs@tuhs.org

6 participants
6532 discussions

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

re: Raise of interrupt level necessary

by Dennis Ritchie

Wolfgang Helbig wondered, > While studying the V6 kernel, I search for some rules as when to raise > the interrupt priority level (IPL). I came up with something like this: > A kernel process needs to raise the IPL if a change of data must be atomic and might > be accessed (not necessarily changed) by an IRS. > In light of this rule, some raising of interrupts seem unnecessary: > - In m40.s changes of the user space segmentation registers are bracketed by raising > and lowering the IPL, although these registers are never accessed by an ISR. > - Likewise, in m40.s, just before the trap routine checks the runrun flag and > restores r0, r1 and the user stackpointer, it raises the IPL. I can't see what > possibly should go wrong, if being interrupted while restoring the values. It's quite possible that the code is unnecessarily cautious. In general one does not want an interrupt while something sensitive is in a half-changed state (for example, some of the addressing registers changed, or a stack half-switched). 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. It's been a long time since I've looked at this, however. Dennis

22 years, 6 months

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

by Robertdkeys＠aol.com

I upgraded my MVII KA630 critters to MVIII KA650 critters. The disk controllers in them are the old Webster or Sigma WQESD/4 and SCD-RQD11/EC (same boards). When I upgraded the cpu/ram on one of the machines, and tried to use the onboard formatter rs232 port, the port gave crazy spaces and backspaces continuously after the initial boot signon msg into the controller formatter prom. Changing it to a DQ696 controller and the problem went away. On a second machine, with KA650, it has a tendency to give uda controller initialization errors about 50% of the time when booting. Is there an endemic problem with this style 4 port controller running too fast with a KA650 compared to a KA630 cpu? It sure feels like that. It would be a bummer to have to use the slower cpus on these machines....(:+{{..... Anone else run into these kinds of problems? Ultrix seems to handle it better than Tahoe. It might be speed in the hardware and slight differences in drivers? Any suggestions or thoughts appreciated. Thanks Bob

22 years, 6 months

Re: [pups] 2.11BSD images for Simh

by Andru Luvisi

>From Warren: > > These file are now in the Unix Archive on minnie.tuhs.org in > PDP-11/Boot_Images/2.11_on_Simh > > The mirror sites should pick them up soon. >

22 years, 6 months

Re: [TUHS] Re: non-broken 4.3BSD set?

by msokolov＠ivan.Harhan.ORG

Robertdkeys(a)aol.com wrote: > I am wondering if > a dd image of a working few start blocks on a > disk could be copied over to a raw formatted > disk from the tape copy, before the miniroot > went on, as part of the boot/install process? This should work. > Michael, what are your thoughts on setting up > the disks, reasonably? Well, every time I need to do this, I do some history reenactment, as this is how Quasijarus Project was originally bootstrapped. I first install Ultrix on the VAX, then write a Tahoe/Quasijarus disk label to the boot disk (by compiling disklabel under Ultrix), and then do the normal 4.3-QJ0a install, at which point the standalone system sees the label and is happy. MS

22 years, 6 months

Re: [TUHS] Re: non-broken 4.3BSD set?

by msokolov＠ivan.Harhan.ORG

Robertdkeys(a)aol.com wrote: > Great! Keep me in mind for any testing if you > need it. I currently don't need any testing that I can't do myself, but thanks anyway. > I still am curious as to how many on the lists > are actually running such critters, currently, > on Quasijarus or on Ultrix. Well, Harhan is still up as you can see, despite the incessant bills... Pretty much all my work on Quasijarus since 4.3-QJ0a has been on operational issues, i.e., issues that don't matter much for hobbyists but become important when you use it operationally for your mission-critical computing. All my VAXen are running current unreleased code. The Internet feed is WorldCom/UUNET with a Quasijarus-based router. I wrote all the code for the latter, which will hopefully appear in 4.3-QJ1. I also have an MV3100 running Ultrix whose sole purpose is to interface an Exabyte 8 mm SCSI tape drive to my cluster. Doing backups on TK50s is prohibitively expensive. Some day I hope to find time to port 4.3-Quasijarus to it. > Did you arrive at any reasonable way to do the > initial disklabels and boot blocks so one can > install Quasijarus directly? That was and still is planned for 4.3-QJ1. 4.3-QJ0a and 4.3-QJ0b "officially" support bootstrap only on DEC RA disks. Two of my running MicroVAXen are equipped with the latter (RA72s). I also run one with ESDI disks, as I have equipped many MicroVAXen in the past. I bootstrap the latter via Ultrix (see my other reply). MS

22 years, 6 months

Re: [TUHS] Re: non-broken 4.3BSD set?

by Robertdkeys＠aol.com

That is what I do. After several failures, I find that using first NetBSD-1.4.1 boot to both label and install boot blocks, followed by second, NetBSD-1.2 boot and edlabel to trim the labels back to something akin to a Tahoe style label, seems to be the only way that works reliably. The label 1.4.1 writes is different from the Tahoe label, in that it computes incorrect c partition sizes. It does write something that I think is bootblock related that seems to must be there for Quasijarus to boot on my hardware. I am not sure exactly what it is, but using just the 1.2 edlabel does not seem to work reliably. The 1.2 edlabel seems to write a correct c size partition, though, after the 1.4.1 bits are put on. I ought to dd off the binary bits and see what is actually being written. But, the above seems to work, for me, and got my crashed disks back up a few minutes ago, after hours of prom formatting....(:+{{..... Anyway, that is how I get the machine up. If there is a better or easier way, someone holler. I am wondering if a dd image of a working few start blocks on a disk could be copied over to a raw formatted disk from the tape copy, before the miniroot went on, as part of the boot/install process? An undersized disk label with reasonably sized a and b partitions and a small but installable h partition (big enough for the usr tarball to fit on) should allow a bootable system to be installed. From that it could be set up on a second disk with correctly sized labels. Or, when the tape was written, a selection of disk boot/label images could be set up and a correct one written to the boot tape for the target disk install. What other ways could this be done? Michael, what are your thoughts on setting up the disks, reasonably? Thanks Bob

22 years, 6 months

Re: [TUHS] Re: non-broken 4.3BSD set?

by Robertdkeys＠aol.com

Great! Keep me in mind for any testing if you need it. I have 4 Qbus VAXentoyz that mostly just sit and play, when the HD's stay up. Of late ESDI drives have been giving me fits, but maybe I can scrounge up a few more in the local MooU surplus feeding frenzy diving pits. Maybe, someday, some scsi mscp cards might float up from the depths! (dream on.....(:+}}...) I still am curious as to how many on the lists are actually running such critters, currently, on Quasijarus or on Ultrix. I mostly play with mine, doing some roffing and TeXing, and porting a few minor tidbits. Did you arrive at any reasonable way to do the initial disklabels and boot blocks so one can install Quasijarus directly? The only clean way I can do it is to use two other OS installs that put enough bits there that Quasijarus is happy. There ought to be an easier way. Anyway, keep me posted as to when Quasijarus 0b might become reality. Thanks Bob Keys

22 years, 6 months

Re: [TUHS] Re: non-broken 4.3BSD set?

by msokolov＠ivan.Harhan.ORG

Robertdkeys(a)aol.com wrote: > It was Q0A. Has there been any later development > of it, of interest? Yes, there has been. The only problem is that I still haven't managed (in 3 years) to find time to spin it into a release. :-( There is some hope, though, that I'll find a bit of time (enough to spin out the 4.3-QJ0b release) this winter. MS

22 years, 6 months

Re: [TUHS] Re: non-broken 4.3BSD set?

by Robertdkeys＠aol.com

It was Q0A. Has there been any later development of it, of interest? Thanks Bob

22 years, 6 months

Oops.

by Andru Luvisi

Sorry. Wrong list. That was meant for PUPS. Andru -- Andru Luvisi, Programmer/Analyst Quote Of The Moment: Just once, I wish we would encounter an alien menace that wasn't immune to bullets. -- The Brigadier, "Dr. Who"

22 years, 6 months

Re: [TUHS] Re: non-broken 4.3BSD set?

by msokolov＠ivan.Harhan.ORG

Robertdkeys(a)aol.com wrote: > [...] I just used the quasijarus > 0a source tarball (that is supposed to be Tahoe) [...] It is. > Out of curiosity, anyone still running a 4.3BSD > box? I had a couple microVAXes up with it until > my ESDI drives went bellyup a few days back. Do you mean the plain original 4.3 or enhanced versions like 4.3-Quasijarus? The plain original 4.3 doesn't run on MicroVAXen, so if you had 4.3 on yours, it must have been *some* enhanced version. MS

22 years, 6 months

Re: [pups] 2.11BSD images for Simh

by Andru Luvisi

>From Warren: > > These file are now in the Unix Archive on minnie.tuhs.org in > PDP-11/Boot_Images/2.11_on_Simh > > The mirror sites should pick them up soon. >

22 years, 6 months

Re: non-broken 4.3BSD set?

by Robertdkeys＠aol.com

The src tarball in the archives is only 35k or something like that, so it is mostly gone. At one time, I thought it was more there. Since I was only needing the dwb section out of the sources, to power up a dwb suite on an ancient ultrix box, I just used the quasijarus 0a source tarball (that is supposed to be Tahoe) for the bits I needed. It worked. But, for the record, it might be nice to have a complete, unbroken set, if it still exists, and the bits can be rounded up. Out of curiosity, anyone still running a 4.3BSD box? I had a couple microVAXes up with it until my ESDI drives went bellyup a few days back. (Ice storms and power glitches ate the drives.) I have maybe 30mb of ports of this and that (gzip, gmake, psroff, TeX, and other things) that I would donate to the archives if there was any interest. MicroVAXen are a cheap way of playing old BSD....(:+}}... Thanks Bob

22 years, 6 months

RE: [pups] Boot_Images and the networking activated version of Simh

by Fred N. van Kempen

Warren, Oh, I see Andru already uploaded it to Minnie as well.. OK.. Thanks, Andru! --fred > -----Original Message----- > From: Warren Toomey [mailto:wkt@minnie.tuhs.org] > Sent: Saturday, December 07, 2002 6:08 AM > To: Andru Luvisi > Cc: pups(a)minnie.tuhs.org > Subject: Re: [pups] Boot_Images and the networking activated > version of > Simh > > > In article by Andru Luvisi: > > All righty. I have: > > A working boot image for a networked 2.11BSD system inside simh. > > Some perl scripts for working with simh tape images. > > simh startup script for booting the networked image. > > simh startup script for booting from the install tape. > > Some basic instructions for how to get the thing going > (not a substitute > > for reading the simh docs and knowing something about UNIX). > > > > I emailed Warren but he seems to be unavailable right now. > > > > So, who's got an archive I can upload it to? > > Try anonymous ftp to minnie.tuhs.org, directory incoming/unix. > > Sorry, I've been busy! > Warren > _______________________________________________ > PUPS mailing list > PUPS(a)minnie.tuhs.org > http://minnie.tuhs.org/mailman/listinfo/pups >

22 years, 7 months

raise of interrupt level necessary

by Wolfgang Helbig

Hi, While studying the V6 kernel, I search for some rules as when to raise the interrupt priority level (IPL). I came up with something like this: A kernel process needs to raise the IPL if a change of data must be atomic and might be accessed (not necessarily changed) by an IRS. In light of this rule, some raising of interrupts seem unnecessary: - In m40.s changes of the user space segmentation registers are bracketed by raising and lowering the IPL, although these registers are never accessed by an ISR. - Likewise, in m40.s, just before the trap routine checks the runrun flag and restores r0, r1 and the user stackpointer, it raises the IPL. I can't see what possibly should go wrong, if being interrupted while restoring the values. I'd appreciate any help from someone with more experience in kernel programming. Greetings, Wolfgang Helbig

22 years, 7 months

RE: [pups] Boot_Images and the networking activated version of Simh

by Fred N. van Kempen

People, DO note that the Ethernet operations of SimH heavily depend on the proper workings AND configuration of a Packet Filter driver for your platform, so, something like BPF, EFILT, NetFLT or WinPCAP (for Win32). Try running a test app for that stuff BEFORE trying to run SimH/ENET stuff.. if the test app works OK, you can start figuring out why SimH/ENET doesn't work on your system. I have *three* network cards the drivers of which DO NOT support promisc mode. Which obviously results in WinPCAP (they're PCI cards under Win2K) not functioning properly, and, thus, same for SimH/ENET. --fred > -----Original Message----- > From: Andru Luvisi [mailto:luvisi@andru.sonoma.edu] > Sent: Friday, November 29, 2002 8:02 AM > To: gregg(a)levine.name > Cc: pups(a)minnie.tuhs.org > Subject: Re: [pups] Boot_Images and the networking activated > version of > Simh > > > On Thu, 28 Nov 2002, Gregg C Levine wrote: > > Hello from Gregg C Levine > > Just out of curiosity, can the boot images stored in the > folders that > > are under that name, actually support this new version of > Simh? That is > > the PDP-11 emulator. What would be necessary to enable that > function? It > > looks as if one of them, is aware of the device, since I believe the > > image was made on a machine which has the appropriate card > installed in > > it, but after that I'm lost. > > I would be happy to share mine, but it doesn't work. ;-) > > The thing that strikes me as really weird is that I know a guy who is > running VMS with networking on the simh VAX emulator. As I > understand it, > the the VAX and PDP-11 emulators use the same code for the ethernet > controller. > > Andru > -- > Andru Luvisi, Programmer/Analyst > > Quote Of The Moment: > Truth is hard to find and harder to obscure. > > _______________________________________________ > PUPS mailing list > PUPS(a)minnie.tuhs.org > http://minnie.tuhs.org/mailman/listinfo/pups >

22 years, 7 months

Re: [pups] 2.11BSD networking on simh

by Steven M. Schultz

Hi - > From: Andru Luvisi <luvisi(a)andru.sonoma.edu> > I have gotten 2.11 installed on simh, I have it recognizing the simulated > ethernet card, and everything appears correct except the packets just > aren't getting in and out. The simh documentation says that the DELQA > card is better than the DEQNA, but I was unable to get the DELQA (qt) > driver to recognize the card. When I compiled the kernel to use the DEQNA There are TWO variants of the DELQA as I recall. One was referred to as the "turbo" verion (I think it was called the DELQA-YM) and the if_qt driver was developed and tested specifically for, and only for, that variant. The normal DELQA and DEQNA should use the if_qe driver. > I have configured 2.11BSD with: > A valid IP address on the network the host is on. > The same netmask, broadcast, and gateway as the host. > I am running the emulator as root. > > The docs say you won't be able to talk between the host and the emulated Hmmm, that seems strange. Using P11 I talk between the host (the machine running the emulator program) and the "PDP11" all the time. Ah, it has to do with ARP handling I suspect. I know that with P11 it's IP only and thus ARP packets do not traverse the emulated ethernet card. If that is the case with simh as well then on the PDP11 side you might have to do what I did and install arp entries for everything on the local lan with which the PDP11 is going to communicate. That way the 11 already knows the 'mac' address and does not need ARP (which doesn't work thru the emulated ethernet) at all. > machine, so my test for each configuration has been pinging the gateway, > which I know responds to pings since I can ping it from the host. Ah, but on the host did you publish an ARP entry so that the host will arp for the PDP11? I think that is required. I would tinker around with installing published/proxy arp entries and seeing what happens. Cheers, Steven Schultz sms(a)2bsd.com

22 years, 7 months

[pups] Boot_Images and the networking activated version of Simh

by Gregg C Levine

Hello from Gregg C Levine Just out of curiosity, can the boot images stored in the folders that are under that name, actually support this new version of Simh? That is the PDP-11 emulator. What would be necessary to enable that function? It looks as if one of them, is aware of the device, since I believe the image was made on a machine which has the appropriate card installed in it, but after that I'm lost. ------------------- Gregg C Levine hansolofalcon(a)worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda )

22 years, 7 months

[pups] 2.11BSD networking on simh

by Andru Luvisi

I have gotten 2.11 installed on simh, I have it recognizing the simulated ethernet card, and everything appears correct except the packets just aren't getting in and out. The simh documentation says that the DELQA card is better than the DEQNA, but I was unable to get the DELQA (qt) driver to recognize the card. When I compiled the kernel to use the DEQNA (qe) driver and set the card up in DEQNA mode, the emulated card and its ethernet address were correctly detected. I have configured 2.11BSD with: A valid IP address on the network the host is on. The same netmask, broadcast, and gateway as the host. I am running the emulator as root. I have attached the DEQNA to the appropriate ethernet card. I can see the ethernet card go into promiscuous mode when I start the emulator. I have tested it with SANITY=ON and SANITY=OFF. The docs say you won't be able to talk between the host and the emulated machine, so my test for each configuration has been pinging the gateway, which I know responds to pings since I can ping it from the host. I have been over both the 2.11BSD docs and the simh docs several times and as far as I can tell I am doing everything correctly. I would appreciate any hints that any of you can offer. Thanks, Andru Quote Of The Moment: Appel's method avoids making a large number of small trampoline bounces by occasionally jumping off the Empire State Building. -- Henry G. Baker, "Cheney on the M.T.A."

22 years, 7 months

Re: [pups] Looking for binary distribution of v7

by Mario Premke

Thanks a lot - it works ... I am delighted !!! ---------- > Von: Frank Wortner <frank(a)wortner.com> > An: Mario Premke <Mario.Premke(a)epost.de>; pups(a)minnie.tuhs.org > Betreff: Re: [pups] Looking for binary distribution of v7 > Datum: Montag, 18. November 2002 03:59 > > on 11/17/02 1:24 PM, Mario Premke at Mario.Premke(a)epost.de wrote: > > > Nevertheless, mounting the file and boot dl0: leads to the boot-prompt @ > > After typing unix the boot-prompt appears again - does the kernel have a > > different name ? > > boot dl0 > @boot <- you type "boot" and press "enter" or "return" in reply > New Boot, known device are hp ht rk rl rp tm vt > : rl(0,0)rl2unix <- you type "rl(0,0)rl2unix" and press return > mem = 177856 > # <- you are now in "single user" mode > <- press "control-d" to go to multiuser mode > <- (the normal mode of operation) > Restricted rights: Use, duplication, or disclosure > is subject to restrictions stated in your contract with > Western Electric Company, Inc. > Thu Sept 22 06:26:09 EDT 1988 > > login: root <- login as "root" > # <- Have fun ... > <- You did make a backup of the disk image before you started, > <- right? ;-) > > If you want to make things easier, your first command should be: > > # cp /rl2unix /unix > > Now you will be able to type "rl(0,0)unix" instead of "rl(0,0)rl2unix". Ps > and other commands that need to read the system namelist also expect the > kernel image to be named /unix. > > Enjoy! > > > > -- > Frank > > "Plez cnoke if an rnsr is not reqid." > Sign on Owl's Door, "Winnie the Pooh" > > > _______________________________________________ > PUPS mailing list > PUPS(a)minnie.tuhs.org > http://minnie.tuhs.org/mailman/listinfo/pups

22 years, 7 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