Progress of Linux on VAX

[Maciej W. Rozycki]

Hi Jan,

> It's been a long time, since the last e-mail was posted to this mailing 
> list, so I have a few questions to ask.

 I'll be happy to answer any, although I'll appreciate patience.  I've got 
lots of issues to address recently, the most involving being PSU failures.  
It appears that the units from early 1990s have now reached the age at 
which capacitor failures have become a plague.  Chemicon SXF parts are 
apparently especially notorious for their electrolyte leaks and they were 
unfortunately used by DEC in their several PSU models.  They need to be 
replaced ASAP, before further damage ensues.  Replacement PSUs have become 
scarce, making PSU repair the only way to move forward, and schematics are 
unavailable making it a tough challenge for someone with no previous PSU 
repair experience.

> I am wondering about any recent progress of the Linux port on VAX, is 
> there still any code being written by J.B.G. or Maciej, maybe others who 
> got involved ?

 The port has stalled although I still have intent to continue with it.  
Unfortunately I have recently discovered my 4000/90 I used for the port 
has silently died while in storage and does not want to start.  I'm in the 
process of dealing with it; hopefully the outcome will be good.

 Either way my intent is to move forward sometime, possibly by importing 
the old patches into current upstream Linux kernel sources.  On the 
userland side we have patches for GCC 4.1.2, glibc 2.4 and GDB 6.8.  
Binutils work out of the box.

> Have you considered sharing the code on Github or similar git providers 
> (it would make it easier for other people to maybe start with the 
> contribution) ?

 That might be a good idea, thanks, for the new kernel tree.

> What is the status of the code currently written, does it boot any VAX 
> machines (which ?) up to a shell prompt ?

 Before it died my 4000/90 netbooted over its onboard Ethernet interface, 
and then mounted NFS root and continued userland booting over a PMAD-A 
TURBOchannel Ethernet option card.  It used to reach a Bash prompt with 
some software running started by init(8), most notably the NTP daemon.  I 
suppose more user software would work merely if I got to compiling it.

 The reason for the complicated Ethernet setup was the SGEC driver (which 
is there among VAX patches) does not work with the /90 for some reason.  
I'm told the SGEC is really an early version of the PCI Tulip chip, except 
with a different host bus interface.  So I suppose rather than trying to 
fix up whatever code we have in the SGEC driver we should really wire the 
Tulip driver instead, just like we have the TGA and DEFPA PCI drivers 
wired for SFB+ and DEFTA TURBOchannel options respectively now.

 With userland we have a few issues, the most obvious one piece of core 
software being outdated.  Before moving forward I have planned to address 
a couple of issues which have hindered my progress:

1. `ldconfig' crashes with a stack overflow requiring DSO symlinks to be 
   created manually.

2. Likewise native GDB crashes with a stack overflow making debugging the 
   former issue a bit more complicated.  A little bit only though as
   `gdbserver' actually works with cross-GDB attached remotely.  There was 
   some issue with DWARF record interpretation though IIRC.

3. Native GCC crashes with a stack overflow again, possibly the same issue
   as the two former.

Now the stack overflow was a real one, being netbooted my machine had no 
swap, but it had 128MB of RAM and consequently roughly as much VM space, 
and that indeed got exhausted.  So it clearly was an obvious bug 
somewhere, perhaps miscompilation even.  Which is why I wanted to address 
it before moving forward, so that I knew it wasn't carried forward by 
chance.  NB the kernel itself seemed solid, it was only userland 
suffering.

 Now with the bug hopefully fixed sometime my plan was to move forward 
with glibc first, and that requires a TLS ABI for NPTL support.  Version 
2.4 is really the last one that (with a hack) along with GCC 4.1.x can be 
persuaded to run with LinuxThreads.

 With a TLS ABI in place we will be able to submit a VAX glibc port 
upstream; with the current glibc consensus-based maintenance model we 
might be able to succeed with that, although we might not be able to 
persuade people to accept non-IEEE-754 hard float support.

 Updates to GCC can then follow, and should be easier as the VAX backend 
has been to some extent maintained upstream for the NetBSD project.  
Wiring an existing backend to another OS is pretty straightforward, and I 
have made patches for all language bindings available as at GCC 4.1, 
including Java and Ada.

 Again an issue is non-IEEE-754 hard float, which is supported by GCC, but 
is not really compatible with Java.  I have made some efforts to simulate 
IEEE 754 hard float with VAX hard float for finite numeric floating-point 
data as the two formats can be converted between each other quite easily.  
This conversion has to happen at the boundary between Java bytecode and 
native compiled code only.  I haven't verified the results as obviously 
I'd need to go much further with native userland than I did before I was 
faced with the problems mentioned above.  The changes let me cross-compile 
Classpath successfully though.

 Changes to GDB should be easy to port, they're self-contained and not 
really extensive.  They mostly comprise Linux-specific ptrace(2) bindings 
and native support as vax-tdep.c is there in place already.

 Anything else should really be a matter of compiling.

> Does anything else work after a completed bootup ?

 See the VAX/Linux binary RPM packages and corresponding sources at my 
site: <ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/>.  Linux 
kernel patches are unfortunately offline after the reinstallation of 
git.kernel.org following a break-in a few years ago.  I did post all my 
updates I believe though at one point to our list and they should be 
available in the archives.

 I do hope to get back to our effort once I'm done with my current 
hardware mess and then some DECstation updates with the MIPS port which I 
have meant to be doing (SCSI driver).  Realistically not before next year 
I'm afraid though.

 If you have any further questions or comments, then please shout.  I've 
cc-ed JBG in case he's anything to add.  He's been busy recently and I 
wouldn't be surprised if he'd missed your posting altogether just as 
almost have I.

  Maciej