OpenBSD Journal

Sparc64 boots SMP on Enterprise 3500 models.

Contributed by jj on from the Cpt.Marco-of-the-Enterprise dept.

After some hard work, mainly by Mark Kettenis, the sparc64 platform adds Enterprise 3500 to the list of supported machines when running SMP kernels. Now that SMP works better on sparc64, the success reports on some of the bigger systems are coming in. This is a taste of what OpenBSD 4.3 will bring to all sparc64 fans.

This dmesg came in from Marco Peereboom, for those of us that like them:
console is /central@1f,0/fhc@0,f8800000/zs@0,902000:a
Copyright (c) 1982, 1986, 1989, 1991, 1993
	The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2008 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 4.2-current (GENERIC.MP) #106: Wed Jan  9 16:01:39 MST 2008
    deraadt@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP
real mem = 4294967296 (4096MB)
avail mem = 4139417600 (3947MB)
mainbus0 at root: 5-slot Sun Enterprise E3500
cpu0 at mainbus0: SUNW,UltraSPARC-II (rev 10.0) @ 400 MHz
cpu0: physical 16K instruction (32 b/l), 16K data (32 b/l), 8192K external (64 b/l)
cpu1 at mainbus0: SUNW,UltraSPARC-II (rev 10.0) @ 400 MHz
cpu1: physical 16K instruction (32 b/l), 16K data (32 b/l), 8192K external (64 b/l)
cpu2 at mainbus0: SUNW,UltraSPARC-II (rev 10.0) @ 400 MHz
cpu2: physical 16K instruction (32 b/l), 16K data (32 b/l), 8192K external (64 b/l)
cpu3 at mainbus0: SUNW,UltraSPARC-II (rev 10.0) @ 400 MHz
cpu3: physical 16K instruction (32 b/l), 16K data (32 b/l), 8192K external (64 b/l)
central0 at mainbus0
fhc0 at central0 board 1: SUNW,501-2511
clock0 at fhc0: mk48t59
zs0 at fhc0 softpri 6
zstty0 at zs0 channel 0 (console i/o)
zstty1 at zs0 channel 1
zs1 at fhc0 softpri 6
zskbd0 at zs1 channel 0: no keyboard
zstty2 at zs1 channel 1: mouse
clkbrd0 at fhc0: 5 slots
fhc1 at mainbus0 board 7: SUNW,501-2557
ac at fhc1 class memory-controller not configured
simm-status at fhc1 not configured
environment at fhc1 not configured
sram at fhc1 not configured
flashprom at fhc1 not configured
fhc2 at mainbus0 board 9: SUNW,501-2557
ac at fhc2 class memory-controller not configured
simm-status at fhc2 not configured
environment at fhc2 not configured
sram at fhc2 not configured
flashprom at fhc2 not configured
sbus0 at mainbus0 addr 0xffda8000: clock = 25 MHz
sbus0: dvma map ff800000-ffffffff, iotdb 7cf4000-7cf6000, STC0 enabled
SUNW,socal at sbus0 class socal slot 13 offset 0x10000 vector 22 ipl 2 not configured
fhc3 at mainbus0 board 1: SUNW,501-2558
ac at fhc3 class memory-controller not configured
environment at fhc3 not configured
flashprom at fhc3 not configured
eeprom at fhc3 not configured
sbus-speed at fhc3 not configured
"counter-timer" at mainbus0 addr 0xffd8bc00 not configured
sbus1 at mainbus0 addr 0xffd80000: clock = 25 MHz
sbus1: dvma map ff800000-ffffffff, iotdb 7cf6000-7cf8000, STC0 enabled
hme0 at sbus1 slot 3 offset 0x8c00000 vector 4 ipl 6, address 08:00:20:cd:b4:6e
nsphy0 at hme0 phy 1: DP83840 10/100 PHY, rev. 1
esp0 at sbus1 slot 3 offset 0x8800000 vector 3 ipl 3: dma rev fas
esp0: FAS366/HME, 40MHz, SCSI ID 7
scsibus0 at esp0: 16 targets
sd0 at scsibus0 targ 0 lun 0:  SCSI2 0/direct fixed
sd0: 17366MB, 6962 cyl, 24 head, 212 sec, 512 bytes/sec, 35566479 sec total
cd0 at scsibus0 targ 6 lun 0:  SCSI2 5/cdrom removable
cgsix0 at sbus1 slot 0 offset 0x0 vector 5 ipl 5: SUNW,501-2253, 1152x900, rev 11
wsdisplay0 at cgsix0
wsdisplay0: screen 0 added (std, sun emulation)
"counter-timer" at mainbus0 addr 0xffd71c00 not configured
psycho0 at mainbus0 addr 0xffd6a000: SUNW,psycho, impl 0, version 4, ign 180
psycho0: bus range 0-0, PCI bus 0
psycho0: dvma map fe000000-ffffffff, iotdb 7d4a000-7d52000, STC0 enabled
pci0 at psycho0
"Sun PCIO EBus2" rev 0x01 at pci0 dev 1 function 0 not configured
hme1 at pci0 dev 1 function 1 "Sun HME" rev 0x01: ivec 0x1a1, address 08:00:20:cd:b4:6e
nsphy1 at hme1 phy 1: DP83840 10/100 PHY, rev. 1
psycho1 at mainbus0 addr 0xffd50000: SUNW,psycho, impl 0, version 4, ign 180
psycho1: bus range 128-128, PCI bus 128
psycho1: dvma map fe000000-ffffffff, iotdb 7d4a000-7d52000, STC0 enabled, STC1 enabled
pci1 at psycho1
fhc4 at mainbus0 board 3: SUNW,501-3023
ac at fhc4 class memory-controller not configured
environment at fhc4 not configured
flashprom at fhc4 not configured
eeprom at fhc4 not configured
sbus-speed at fhc4 not configured
"counter-timer" at mainbus0 addr 0xffd31c00 not configured
psycho2 at mainbus0 addr 0xffd2a000: SUNW,psycho, impl 0, version 4, ign 1c0
psycho2: bus range 0-0, PCI bus 0
psycho2: dvma map fe000000-ffffffff, iotdb 7d82000-7d8a000, STC0 enabled
pci2 at psycho2
isp0 at pci2 dev 3 function 0 "QLogic ISP1020" rev 0x05: ivec 0x1e0
isp0: invalid NVRAM header
scsibus1 at isp0: 16 targets
psycho3 at mainbus0 addr 0xffd10000: SUNW,psycho, impl 0, version 4, ign 1c0
psycho3: bus range 128-128, PCI bus 128
psycho3: dvma map fe000000-ffffffff, iotdb 7d82000-7d8a000, STC0 enabled, STC1 enabled
pci3 at psycho3
"counter-timer" at mainbus0 addr 0xffcffc00 not configured
"pcons" at mainbus0 not configured
softraid0 at root
bootpath: /sbus@3,0/SUNW,fas@3,8800000/sd@0,0
root on sd0a swap on sd0b dump on sd0b

(Comments are closed)


Comments
  1. By Anonymous Coward (LizardKing) chriswareham@chriswareham.demon.co.uk on http://www.chriswareham.net/

    We have a couple of E3500 machines at work that are currently switched off, since they were replaced by V440s a while ago. It'd be interesting to install OpenBSD on one of them and rerun our database benchmarks to see how it fares compared to Solaris 8. The database is MySQL (not my choice - that would have been PostgreSQL) so performace may be limited by MySQL depending on a good thread implementation. There again, Solaris 8 is a little bit long in the tooth now ...

    Comments
    1. By Brad (216.138.195.228) brad at comstyle dot com on

      > We have a couple of E3500 machines at work that are currently switched off, since they were replaced by V440s a while ago. It'd be interesting to install OpenBSD on one of them and rerun our database benchmarks to see how it fares compared to Solaris 8. The database is MySQL (not my choice - that would have been PostgreSQL) so performace may be limited by MySQL depending on a good thread implementation. There again, Solaris 8 is a little bit long in the tooth now ...

      Anything threaded will not gain from SMP at the moment as OpenBSD is still using a userland pthreads implementation. Running something not threaded would be a better performance test. Hopefully as more effort is put towards the MI bits of the SMP code in OpenBSD it will also mean eventually fixing the issues that currently prevent rthreads from working properly and then we'll have a kernel backed pthreads implementation.

      Comments
      1. By Chris (LizardKing) on http://www.chriswareham.net/

        > Anything threaded will not gain from SMP at the moment as OpenBSD is
        > still using a userland pthreads implementation. Running something not
        > threaded would be a better performance test. Hopefully as more effort is
        > put towards the MI bits of the SMP code in OpenBSD it will also mean
        > eventually fixing the issues that currently prevent rthreads from
        > working properly and then we'll have a kernel backed pthreads
        > implementation.

        This is what I suspected. The database schema from my benchmark could be
        easily ported to PostgreSQL, which would be a much better comparison than
        MySQL as it relies on forking processes rather than spawning threads per
        connection. Getting the test data into a different database may be a bit
        more work though, as the loaders are written in C and link directly to the
        MySQL client libraries

  2. By Damon McMahon (202.138.13.195) damon.mcmahon@gmail.com on

    This is great news, it may provide me with the necessary motivation to fire up my E450 :-)

    The article implies there are other sparc64 machines which boot SMP - is there a master list somewhere? I can't see any information on plus.html or sparc64.html?

    Comments
    1. By Johan M:son Lindman (jl) on

      > This is great news, it may provide me with the necessary motivation to fire up my E450 :-)
      >
      > The article implies there are other sparc64 machines which boot SMP - is there a master list somewhere? I can't see any information on plus.html or sparc64.html?


      The master list would be dmesg@openbsd.org, which is a dmesg database everyone should contribute to, but for many reasons it is held privately to the OpenBSD developers.

      So this article is really just a teaser to make you fire up your SMP-capable sparc64 machine and give it a try. When you do please submit a dmesg to dmesg@openbsd.org and if you so wish leave a dmesg here on undeadly or on misc@ as a courtesy to others in the community.

      Comments
      1. By Anonymous Coward (69.70.68.38) on

        > > This is great news, it may provide me with the necessary motivation to fire up my E450 :-)
        > >
        > > The article implies there are other sparc64 machines which boot SMP - is there a master list somewhere? I can't see any information on plus.html or sparc64.html?
        >
        >
        > The master list would be dmesg@openbsd.org, which is a dmesg database everyone should contribute to, but for many reasons it is held privately to the OpenBSD developers.
        >
        > So this article is really just a teaser to make you fire up your SMP-capable sparc64 machine and give it a try. When you do please submit a dmesg to dmesg@openbsd.org and if you so wish leave a dmesg here on undeadly or on misc@ as a courtesy to others in the community.

        Do they care to have i386 / amd64 (and i386 port on amd64) submitted too, or no need? If so, I have atleast a couple for newer and older, common & rare systems I can send if it's worth anything to them?

        Comments
        1. By Brad (216.138.195.228) brad at comstyle dot com on

          > Do they care to have i386 / amd64 (and i386 port on amd64) submitted too, or no need? If so, I have atleast a couple for newer and older, common & rare systems I can send if it's worth anything to them?

          dmesgs are always wanted for any systems OpenBSD is capable of running on no matter what architecture.

          Comments
          1. By Darrin Chandler (dwc) on http://www.stilyagin.com/darrin/

            > dmesgs are always wanted for any systems OpenBSD is capable of running on no matter what architecture.

            To add to that... it's also good to submit a dmesg from the same machine periodically. New things get supported, drivers change, etc. In the rare cases when there are regressions then having dmesg over time can help.

            Comments
            1. By Anonymous Coward (24.37.242.64) on

              > > dmesgs are always wanted for any systems OpenBSD is capable of running on no matter what architecture.
              >
              > To add to that... it's also good to submit a dmesg from the same machine periodically. New things get supported, drivers change, etc. In the rare cases when there are regressions then having dmesg over time can help.

              Cool! Sending a few now...

            2. By Anonymous Coward (216.84.37.163) on

              > > dmesgs are always wanted for any systems OpenBSD is capable of running on no matter what architecture.
              >
              > To add to that... it's also good to submit a dmesg from the same machine periodically. New things get supported, drivers change, etc. In the rare cases when there are regressions then having dmesg over time can help.

              And I will add, please turn off line wrap when mailing dmesgs. It's harder to scan for familiar or wanted things when the lines are wrapped.

    2. By Brad (216.138.195.228) brad at comstyle dot com on

      > This is great news, it may provide me with the necessary motivation to fire up my E450 :-)
      >
      > The article implies there are other sparc64 machines which boot SMP - is there a master list somewhere? I can't see any information on plus.html or sparc64.html?

      The idea is that any machine capable of MP should run. If it doesn't then report the issue.

    3. By Mark Kettenis (82.92.89.47) on

      > The article implies there are other sparc64 machines which boot SMP - is there a master list somewhere? I can't see any information on plus.html or sparc64.html?

      All machines listed as supported in sparc64.html should boot an SMP kernel. Of course it only makes sense on machines that actually have
      multiple CPUs.

      And even some of the machines listed as unsupported might work by now, in particular the Ultra 3, Ultra 25/45, Fire V445 and V490/V890. If people
      have access to these machines, it'd be great if they could try booting bsd.rd on them.

  3. By Anonymous Coward (128.171.90.200) on

    Cool

  4. By Anonymous Coward (85.178.114.44) on

    I wonder about the amount of RAM.
    Are the issues for "a littlebit more" RAM gone (fixed) or are these issues (like 8GB RAM or so) just related to x86/x64?

    4GB installed and nearly 4GB useable looks nice. :-)

    Comments
    1. By Brad (216.138.195.228) brad at comstyle dot com on

      > I wonder about the amount of RAM.
      > Are the issues for "a littlebit more" RAM gone (fixed) or are these issues (like 8GB RAM or so) just related to x86/x64?
      >
      > 4GB installed and nearly 4GB useable looks nice. :-)

      sparc64 is the only arch at the moment that can utilize greater than 4GB of memory.

      Comments
      1. By Miod Vallat (miod) on

        sparc64 is the only arch at the moment that can utilize greater than 4GB of memory.
        alpha and sgi theoretically can (but I don't know if such configurations have been tested).

        Comments
        1. By Brad (216.138.195.228) on

          > sparc64 is the only arch at the moment that can utilize greater than 4GB of memory.
          >
          > alpha and sgi theoretically can (but I don't know if such configurations have been tested).

          Theory and reality are two different things. I'll change my statement when it has been tested. :)

    2. By Bo Lind (62.242.34.166) bo.langgaard.lind@gmail.com on

      > I wonder about the amount of RAM.
      > Are the issues for "a littlebit more" RAM gone (fixed) or are these issues (like 8GB RAM or so) just related to x86/x64?
      >
      > 4GB installed and nearly 4GB useable looks nice. :-)

      I'm in the process of installing OpenBSD on a Sun Netra T4 with 8GB of RAM. There are other issues at the moment, but it appears it finds all of it.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]