🚀 go-pugleaf

In article <5417@uwm.edu> jgreco@archimedes.math.uwm.edu (Joe Greco) writes:

Joe> Any 6152 gurus out there?  Here's a question:

Joe> We just put all our 6152's and the server RT on a subnet.  Ethernet suddenly
Joe> bombed, and we started applying the ethernet patches.  Then /etc/suspend
Joe> ceased to function.  Well, to make a long story short, I was messing around
Joe> with the PC-DOS boot program (boot.exe or unix.exe or whatever it's really
Joe> supposed to be called) to try to get it to work.

Hmmm.... Not sure that I qualify as a guru.  Can you provide more details as
to in what way Ethernet 'bombed'?  We used to have mucho ethernet problems
until IBM figured out what was happening and sent a replacement ethernet
driver.  The new driver is one of the patches in the archive at
bikini.cis.ufl.edu.

Joe> Option #16 intrigues me.  Number of coprocessors [1]?  I tried and it will
Joe> allow two as an answer.  Does this imply that a 6152 can handle two
Joe> coprocessor boards?  If so, has it been done?  Any gory details available?
Joe> I don't have the documentation available myself, but Steve looked thru a few
Joe> guides and couldn't find anything about it.

The Dec. '88 Release of AOS 4.3 supports 2 CPUs in and RT 6152.  I do not
know if IBM every released any instructions although I vaguely remember
seeing them drift by some where.  If memory serves, one also needs a
modified version of the 6152 configuration diskette (the one with the
diagnostics) so the bus addresses of the second CPU card can be set.  One
CPU could be used to run the X server leaving the other for more useful
computations.

Joe> Anybody gots any comments?  ;-)

Hope this helps.

--
Dan Ehrlich <ehrlich@cs.psu.edu>/Voice: +1 814 863 1142/FAX: +1 814 865 3176

In comp.sys.ibm.pc.rt article <F?.1.n91@cs.psu.edu>, ehrlich@cs.psu.edu (Dan &) wrote:
:Hmmm.... Not sure that I qualify as a guru.  Can you provide more details as
:to in what way Ethernet 'bombed'?  We used to have mucho ethernet problems
:until IBM figured out what was happening and sent a replacement ethernet
:driver.  The new driver is one of the patches in the archive at
:bikini.cis.ufl.edu.

Yes, we installed that poor excuse for a patch and immediately became unable to
flip between DOS and UNIX with /etc/suspend and unix restart 1 go.  We called
ACSC and they're going to call us back as soon as someone gets back from
vacation.  I more or less mentioned it just as a lead-in.

:
:Joe> Option #16 intrigues me.  Number of coprocessors [1]?  I tried and it will
:Joe> allow two as an answer.  Does this imply that a 6152 can handle two
:Joe> coprocessor boards?  If so, has it been done?  Any gory details available?
:Joe> I don't have the documentation available myself, but Steve looked thru a few
:Joe> guides and couldn't find anything about it.
:
:The Dec. '88 Release of AOS 4.3 supports 2 CPUs in and RT 6152.  I do not
:know if IBM every released any instructions although I vaguely remember
:seeing them drift by some where.  If memory serves, one also needs a
:modified version of the 6152 configuration diskette (the one with the
:diagnostics) so the bus addresses of the second CPU card can be set.  One
:CPU could be used to run the X server leaving the other for more useful
:computations.

Is there any other configuration possible?  I'm somewhat more interested in 
distributed computing applications, and doubling your processing power is
always nice.  :-)

:
:Joe> Anybody gots any comments?  ;-)
:
:Hope this helps.

It's a good start!   ;-)  Thanks.
:

... Joe

-------------------------------------------------------------------------------
Joe Greco - University of Wisconsin, Milwaukee - Department of Mathematics
jgreco@archimedes.math.uwm.edu		USnail: Joe Greco
Voice: 414/321-6184				9905 W. Montana Ave.
Data:  414/321-9287 (Happy Hacker's BBS) 	West Allis, WI  53227-3329
#include <witty_and_humorous_saying.h>
Disclaimer: I don't speak for the Math Department, the University, or myself.

In article <5535@uwm.edu>, jgreco@archimedes.math.uwm.edu (Joe Greco) writes:
|> In comp.sys.ibm.pc.rt article <F?.1.n91@cs.psu.edu>,
ehrlich@cs.psu.edu (Dan &) wrote:
|> :
|> :The Dec. '88 Release of AOS 4.3 supports 2 CPUs in and RT 6152.  I do not
|> :know if IBM every released any instructions although I vaguely remember
|> :seeing them drift by some where.  If memory serves, one also needs a
|> :modified version of the 6152 configuration diskette (the one with the
|> :diagnostics) so the bus addresses of the second CPU card can be set.  One
|> :CPU could be used to run the X server leaving the other for more useful
|> :computations.
|> Is there any other configuration possible?  I'm somewhat more interested in 
|> distributed computing applications, and doubling your processing power is
|> always nice.  :-)
|> :
|> :Joe> Anybody gots any comments?  ;-)
|> :
|> :Hope this helps.
|> It's a good start!   ;-)  Thanks.
|> :
|> ... Joe

Aha, somebody finally noticed that! I had intended to post this quite
a while back but as usual, until somebody brought it up I had forgotten
about it. I had sent out a beta-test of these instructions which was
probably what Dan had seen, but hadn't heard back anything so it just
slipped until now.

Please note that the multiple cpu stuff is completely UNSUPPORTED by 
IBM - it was a personal project that was sufficently far advanced to 
get code into the product but was much too late for the documentation
and testing required for a supported feature. This feature is not exactly
secret as it was demo'ed at the fall 1988 COMDEX as a technology demo
with the two Risc bus masters running BSD 4.3 on top of OS/2 (sigh).

There is also a paper that I'm going to present at the IBM internal Unix
conference next week, as it is not IBM CONFIDENTIAL I hope that I can
also post that here as well. 

In any case, if anybody goes attempt to get a multiple-cpu system
going please send me email with the results.

In any case here are some notes on how it is implemented followed by 
the instructions for how one builds a multi-cpu IBM 6152 system.
Enjoy! Again - this is NOT a suported feature - use at your own risk
etc. etc.

Multiple CPU Architecture for 6152

-       processors run independently of each other, each runs its
        own copy of IBM 4.3/6152.

-       primary cpu (cpu 0) owns real devices (lan, printer
        tape, asy, etc)

-       all cpu's share disks (hard, floppy, optical)
        but only 1 cpu writes to a given hard disk partition.

-       supports 1 or 2 additional processor cards, easiest
        case is 2 (total) cards each of which has its "own" disk.

-       access to "other" processor's disk is via read-only
        mount, or via NFS.

-       I/O support program (unix.exe) runs under DOS or OS/2
        which handles disk and most other I/O.

-       based on PS/2 model 60 (normal 6152 configuration with 
        additional processor cards). Also runs on model 80.

-       a software "microchannel" device implements a network 
        connection between cpu's. The primary cpu acts as a gateway
        to connect the secondary cpu's to other machines.

-       Unix drivers exist to allow other processor's memory to be
        accessed and the CPU's to be controlled.

-       minimal Unix kernel changes from latest ship kernel.

Performance

-       cpu bound jobs run with no appreciable degradation
        compared to conventional 6152's (each processor has 
        2, 4, or 8 meg of private memory). All processors do NOT
        have to have the same memory size.

-       I/O bound jobs compete for the same resources such as disk
        and are degraded, though total I/O thruput is higher. A
        model 80 helps as the 286 cpu becomes a bottleneck.

-       kernel compile that took 53 minutes with 1 cpu, took 
        30 minutes with 2 and 30 minutes with 3. It appeared to
        be disk bound with 3 cpu's.

-       sharing of work between processors was done at a high-level
        with a tool "mc" that one specifies as the C compiler to
        make (e.g.: make "CC=mc cc" )

-       my setup is to use X11 window manager and have a window
        for each secondary cpu.

-       many X benchmarks give almost 2x performance when the 
        benchmark and server run on different cpu's.

DOS implementation details

-       one copy of unix.exe runs, with various structures changed
        to have one-per-cpu. Implements a Hot-key (to switch the
        keyboard, screens, mouse, and speaker from one CPU to another).

-       halt/reboot requests are no-ops from any cpu but cpu 0.

-       code provided to allow secondary cpu's to be automatically started
        from primary cpu as part of normal boot sequence.

-       "main loop" looks for requests from both cpu's; generally services
        each in turn.

-       about 1 week's effort to get first version working; about 1 month's
        effort after that to fix bugs and add necessary features.

-       code is in shipable state.

-       runs on DOS 3.3 and has been run (once) on DOS 4.0

OS/2 implementation details

-       one instance of unix.exe runs per cpu; each runs in its own
        full-screen session.

-       uses standard OS/2 hot-key to switch between cpu's (and other OS/2
        sessions).

-       runs on OS/2 Version 1.1 (presentation manager) and 1.0
        but disk performance is much better with 1.1.

-       microchannel driver implemented using OS/2 shared memory segment.

-       disk performance is good, network performance and "microchannel
        driver" performance needs work (about 10x slower than DOS version).

-       needs additional work to be "proper" OS/2 program (totally event
        driven), currently uses polling for requests from Risc processor that 
        would best be event-driven threads. This would help performance
        and reduce the drag on background tasks.

Other

-       the second cpu is very handy for kernel develepment and performance
        measurements as one can be working on code on the main cpu and 
        running tests or debugging on the other cpu. I've found it nice
        to be able to recover from installing a kernel with a fatal bug
        from home without having someone on site.
----------------------------------------------------------------
Instructions on how to build a mutiple-cpu 6152:


-	assumes that you already have a 6152 with one cpu

-	obtain an aditional cpu (possibly by removing it from
	another 6152)

-	install the December release of 6152 system (or at least
	the kernel, boot, and unix.exe from December), you will
	also need the December /usr/bin/X11/Xibm as it knows how
	to save the screen on hot-key events.

-	install the new @8ff7.adf file onto the reference disk
	working copy (e.g. via doswrite -va @8ff7.adf):


------------------------------------------------------------

AdapterId 8ff7h

AdapterName  "RISC coprocessor card"

NumBytes 4

NamedItem Prompt "I/O port"
	Choice "01e0-01ef"
		pos[3]=00011110b
		pos[0]=00000001b
		pos[1]=00011110b
		io 01e0h-01eFh
		int 7
		arb 14
	Choice "01f0-01ff"
		pos[3]=00011111b
		pos[0]=00000001b
		pos[1]=00011100b
		io 01f0h-01fFh
		int 7
		arb 12
	Choice "200-20f"
		pos[3]=00100000b
		pos[0]=00000001b
		pos[1]=00011010b
		io 200h-20Fh
		int 7
		arb 10
	Choice "Disabled"
		pos[3]=11111111b
		pos[0]=00000000b
		pos[1]=00000000b
	Help 
"Default I/O address is 1e0. <Disabled>
 disables the adapter."
------------------------------------------------------------

-	install the additional processor card, and then use the
	reference diskette to autoconfigure the system. If the 
	two processors have different amounts of memory the first
	one (port 0x1e0) should have the larger amount of memory,
	as that is where one usually runs the X server.

-	the simplest installation will have two processors, each
	of which will have a disk drive for its own use (you will
	need a root and a swap for each processor, but /usr can 
	be shared, either via mounting it read-only, or via nfs).

	For simplicity I will assume that each disk has the normal
	root, swap, and /usr partitions.

-	create two new host names, e.g. if the original system was 'frodo'
	then create frodo-mc0, and frodo-mc1. frodo-mc0 will be the 
	gateway machine for cpu1 to the rest of the world. (You should
	use your local naming conventions if they are different from
	what we use).

-	the hd1 disk can be created by cloning the hd0 disk, e.g.
	use fdisk and minidisk to create the DOS/BIOS partition and
	the unix partitions respectively and then copy the unix
	partitions via the normal newfs/dump/restore mechanism.
	e.g.
		newfs -v hd1a
		mount /dev/hd1a /mnt
		cd /mnt
		dump 0f - / | restore rvf - 
		cd /
		umount /dev/hd1a

		newfs -v hd1g
		mount /dev/hd1g /mnt
		cd /mnt
		dump 0f - /usr | restore rvf - 
		cd /
		umount /dev/hd1g

-	change /etc/rc.config on hd1 to reflect the new hostname
	and network address, e.g. change network and hostname entries
	to:

	network='mc0'
	hostname='frodo-mc1'

-	on the hd0 disk, add the following lines to rc.config, so that
	we make frodo into a gateway (this may require allocating a new
	network number for 'frodo')

	network_2='mc0'
	hostname_2='frodo-mc0'
	net_flags_2="$net_flags"

-	now you can boot up the system. Note that when unix.exe starts
	it will tell you that you have 2 processors. The first processor
	should now be able to come up normally. Once it gets to the login
	state you can hot-key to the second processor (control-alt-esc),
	and boot it. It should come up on the second disk by default
	(e.g. boot hd(1,0)vmunix.) 

-	if everything has worked properly you can add a line to /etc/rc.config
	so that the second cpu is automatically started when the first is
	about to go multiuser. This is done by specifying:

	ipl_cpu=1

	in /etc/rc.config.

-	if one wants to reboot the second cpu, one can do so by first
	halting or rebooting it (e.g. /etc/halt or /etc/reboot), and
	then issing the following commands (on cpu 0):

		/etc/por 1
		/etc/load /boot
		/etc/ipl 1
		
	(note that you must put the 6152 version of boot into /boot
	rather than the RT version).

-	note that messages about the state of the second cpu are displayed
	on the console of the master cpu so that one can determine that 
	has halted or attempted to reboot.

-	note that if your configuration file doesn't have the line
	device mc0 at iocc0 csr 0xffffffff priority 13
	then it will need to be added in order to send packets between
	the two Risc cpu's.

------------------------------------------------------------
The above views are my own, not those of my employer.
Bill Webb (IBM AWD Palo Alto), (415) 855-4457.
UUCP: ...!uunet!ibmsupt!webb

In comp.sys.ibm.pc.rt article <1990Aug6.184720.24494@ibmpa>, uunet!ibmsupt!webb (Bill Webb) wrote:
:Aha, somebody finally noticed that! I had intended to post this quite
:a while back but as usual, until somebody brought it up I had forgotten
:about it. I had sent out a beta-test of these instructions which was
:probably what Dan had seen, but hadn't heard back anything so it just
:slipped until now.
:...

Thanks, neat!  Too bad we can't get some more coprocessor cards.

By the way, as far as I know Steve hasn't gotten an answer from ACSC yet on
why /etc/suspend won't work with the new ethernet patches.  Has anyone had a
problem with this?

... Joe

-------------------------------------------------------------------------------
Joe Greco - University of Wisconsin, Milwaukee - Department of Mathematics
jgreco@archimedes.math.uwm.edu		USnail: Joe Greco
Voice: 414/321-6184				9905 W. Montana Ave.
Data:  414/321-9287 (Happy Hacker's BBS) 	West Allis, WI  53227-3329
#include <witty_and_humorous_saying.h>
Disclaimer: I don't speak for the Math Department, the University, or myself.

In article <5600@uwm.edu>, jgreco@archimedes.math.uwm.edu (Joe Greco) writes:
|> ...
|> By the way, as far as I know Steve hasn't gotten an answer from ACSC yet on
|> why /etc/suspend won't work with the new ethernet patches.  Has anyone had a
|> problem with this?
|> 
|> ... Joe

I tried /etc/suspend on both token ring and ethernet machines and it
worked fine for me. I've sent a copy of the unix.exe that I'm using
to ACSC to see if it works for them as well. If so I expect they will 
forward a copy to you as well.

----------------------------------------------------------------
The above views are my own, not necessarily those of my employer.
Bill Webb (IBM AWD Palo Alto), (415) 855-4457.
UUCP: ...!uunet!ibmsupt!webb

In comp.sys.ibm.pc.rt article <1990Aug7.202533.18455@ibmpa>, webb@bass.paloalto.ibm.com (Bill Webb) wrote:
:I tried /etc/suspend on both token ring and ethernet machines and it
:worked fine for me. I've sent a copy of the unix.exe that I'm using
:to ACSC to see if it works for them as well. If so I expect they will 
:forward a copy to you as well.

They have; no luck.  They said it worked for them.  They were out to lunch
as I was leaving, but I believe Steve is going to try calling again later.

(sigh).

Now here's a question: We've rebuilt parts of the C library and /usr/include
on the RT we use to generate the ATR Kernels.  I was basically very careful
not to wipe out anything that seemed to have been added by IBM.  The point
was to bring up AOS a few steps closer to true 4.3 compatibility, and on
that respect I've been very successful.  Could these changes affect the
Kernel in a way that would cause unix.exe to reject a restart?

Perhaps more simply, I should ask: what the hell does unix.exe do to
determine whether or not the coprocessor is awaiting a restart?

I'm going to try building an old, un-Ethernet-patched ATR Kernel and see if
that works.  If not, perhaps it IS the C lib or the include files.
Suggestions?  (besides obvious permutations such as using the old C lib and
include files, which I'll also try)...

As a sidenote, when we restarted the new Kernels in the past, the 6152
replied "Fatal pc code error (whatever); coprocessor not waiting for
restart".  Your unix.exe simply states "Fatal ....; coprocessor not
running."

... Joe

-------------------------------------------------------------------------------
Joe Greco - University of Wisconsin, Milwaukee - Department of Mathematics
jgreco@archimedes.math.uwm.edu		USnail: Joe Greco
Voice: 414/321-6184				9905 W. Montana Ave.
Data:  414/321-9287 (Happy Hacker's BBS) 	West Allis, WI  53227-3329
#include <witty_and_humorous_saying.h>
Disclaimer: I don't speak for the Math Department, the University, or myself.

In article <5625@uwm.edu>, jgreco@archimedes.math.uwm.edu (Joe Greco) writes:
|>...
|> Now here's a question: We've rebuilt parts of the C library and /usr/include
|> on the RT we use to generate the ATR Kernels.  I was basically very careful
|> not to wipe out anything that seemed to have been added by IBM.  The point
|> was to bring up AOS a few steps closer to true 4.3 compatibility, and on
|> that respect I've been very successful.  Could these changes affect the
|> Kernel in a way that would cause unix.exe to reject a restart?
|> 
|> Perhaps more simply, I should ask: what the hell does unix.exe do to
|> determine whether or not the coprocessor is awaiting a restart?
|> ... Joe

The way that the suspend/restart code works is that it brings down each
of the devices by calling their suspend entry point. It then puts a 
magic number (RESTART_MAGIC) into low Romp processor memory and then sits 
there with interrupts disabled (except for the clock) waiting for the 
magic number to go to zero. All of this code is in the suspend() function
in /sys/ca/autoconf.c. The corresponding PC code is in the romprestart
function in /sys/pc_code/rbinit.c. 

From your description of the problem, it appears that the magic number
is OK (if it isn't you get the message "coprocessor not waiting for restart"),
but that the Risc processor isn't actually executing (the PC code checks to
see that the counter is being incremented by the Risc processor to tell
that it is still alive).

I can't see how changing the library code is likely to affect any of the 
above.

One thing that might affect the ethernet code is the use of the UB TSR
routine (nicpshh.exe) that was supposed to watch the UB driver ROM code to
see if it failed. If you are still running this code out of the
autoexec.bat file then you should delete it. The current driver does
not use the UB code in ROM and drives the UB card directly from the
Risc processor.

I'm hoping to send a kernel to ACSC today (if our internet connection
is working) so that they can see if that works. 

PS: I'm curious what you've changed to make "AOS a few steps closer to
true 4.3 compatibility" since it was based on BSD 4.3 to begin with, and
BSD 4.2 before that. If you mean 4.3 TAHOE then I can understand what
you are doing, but I thought we had 4.3 compatibility by being based on
4.3.

----------------------------------------------------------------
The above views are my own, not necessarily those of my employer.
Bill Webb (IBM AWD Palo Alto), (415) 855-4457.
UUCP: ...!uunet!ibmsupt!webb

In comp.sys.ibm.pc.rt article <1990Aug9.181954.21524@ibmpa>, webb@bass.paloalto.ibm.com (Bill Webb) wrote:
:
:In article <5625@uwm.edu>, jgreco@archimedes.math.uwm.edu (Joe Greco) writes:
:|> Perhaps more simply, I should ask: what the hell does unix.exe do to
:|> determine whether or not the coprocessor is awaiting a restart?
:|> ... Joe
:
:The way that the suspend/restart code works is that it brings down each
:of the devices by calling their suspend entry point. It then puts a 
:magic number (RESTART_MAGIC) into low Romp processor memory and then sits 
:there with interrupts disabled (except for the clock) waiting for the 
:magic number to go to zero. All of this code is in the suspend() function
:in /sys/ca/autoconf.c. The corresponding PC code is in the romprestart
:function in /sys/pc_code/rbinit.c. 

Okay, this is the kind of info I need!  ;-)  I'm glad that unix.exe doesn't
do anything insane, but in an attempt to locate the problem I think I'll
build an old (unpatched) Kernel on the RT with the new C lib and includes.
This should help  clarify whether or not these really *are* an issue.

:From your description of the problem, it appears that the magic number
:is OK (if it isn't you get the message "coprocessor not waiting for restart"),
:but that the Risc processor isn't actually executing (the PC code checks to
:see that the counter is being incremented by the Risc processor to tell
:that it is still alive).

Okay, now the Dec 88 release unix.exe complains that the coprocessor is not
waiting for restart.  Yours says not running.  Just to make sure you
understand that....

:I can't see how changing the library code is likely to affect any of the 
:above.

Neither can we.  I personally believe I've been careful and prudent.  The
only thing I can imagine is that occasionally I do a hand-compile and leave
out the -DLIBC_SCCS or something like that, to quickly incorporate something
into the C library (?to?? routines, see below)...

:One thing that might affect the ethernet code is the use of the UB TSR
:routine (nicpshh.exe) that was supposed to watch the UB driver ROM code to
:see if it failed. If you are still running this code out of the
:autoexec.bat file then you should delete it. The current driver does
:not use the UB code in ROM and drives the UB card directly from the
:Risc processor.

Absolutely not.  I'm booting unix.exe from the command line (no scripts,
etc).  I have tried all four permutations of:

unix go
unix irq +3 go  ( to boot unix)

and

unix restart 1 go
unix irq +3 restart 1 go ( to re-enter unix)

and a few other things that I did not document, in frustration  ;-)

:I'm hoping to send a kernel to ACSC today (if our internet connection
:is working) so that they can see if that works. 
:
:PS: I'm curious what you've changed to make "AOS a few steps closer to
:true 4.3 compatibility" since it was based on BSD 4.3 to begin with, and
:BSD 4.2 before that. If you mean 4.3 TAHOE then I can understand what
:you are doing, but I thought we had 4.3 compatibility by being based on
:4.3.

My apologies, I had been told that AOS was built around 4.2 with some
4.3isms.  I must admit I believed this; it bears more similarity to our
Ultrix and VAX BSD 4.2 systems than the 4.3/Tahoe system we have on campus.
The C library in AOS is missing some useful (and necessary) routines such as
strcasecmp.  I've been upgrading the networking utilities to the latest
Berkeley releases (available on uunet) and have found that several other C
library routines had to be added (strerror, I'm fairly sure, I don't recall
too many details).  It seems even Berkeley calls a few different things BSD
4.3.

One of my most vehement complaints about AOS are the routines htonl,
htons, ntohl, and ntohs.  These are macro defined in the include file
netinet/in.h (?).  The Berkeley networking software doesn't consistently
include this include file (though apparently it does include sys/types.h)
and as a result I get linker errors up the kazoo.  I finally got frustrated
and shot four "transparent" functions into the C library.

Don't get me wrong.  I think it's an excellent idea to put it in as a macro,
since it saves processor time and memory.  But that particular problem has
bit me several times even before the Berkeley networking software (and I
tell you, I get a kick out of the fact that Berkeley doesn't follow their
own specs.)

Problems like that just wreck my entire day.  I used to curse IBM until I
finally understood enough to realize that IBM really had done a very good
job and it was more often the application programmer's fault...

As for the rest, I don't have a 4.3 machine to compare to.  If I had Tahoe
source, I'd work on that some more.  As it is, I just add what I need as I
need (and find) it.  Actually I'm quite pleased at this point: I've been
porting sources intended for 4.3/Tahoe on the machine and I haven't had to
wrestle with them at all.

In case it doesn't show, I knew *no* C and only a very few UNIX commands
just two years ago.  Please forgive any shortcomings in my knowledge.  I'm
learning faster than I can.

... Joe

-------------------------------------------------------------------------------
Joe Greco - University of Wisconsin, Milwaukee - Department of Mathematics
jgreco@archimedes.math.uwm.edu		USnail: Joe Greco
Voice: 414/321-6184				9905 W. Montana Ave.
Data:  414/321-9287 (Happy Hacker's BBS) 	West Allis, WI  53227-3329
#include <witty_and_humorous_saying.h>
Disclaimer: I don't speak for the Math Department, the University, or myself.