-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear Mark,
first of all, thank you very much for your explainations, the diff
and, indeed, the ultra swift reply!
That helps us a lot already.
A snapshot with a higher value of max CPUs out of the box, of course,
would be the proverbial icing on the cake.
Probably a strange question but I hazard it anyways - should we
monitor the snapshot directory the /pub/OpenBSD/snapshots folder or is
there a quicker way to find out what your fellow developers think?
Again, many thanks for your help and best wishes,
Stefan
- --------------------------------
Dr.-Ing. Stefan Kiltz
Otto-von-Guericke University of Magdeburg
ITI Research Group on
Multimedia and Security
Universitaetsplatz 2
39106 Magdeburg
Germany
Tel: +49-391-67-52838
Fax: +49-391-67-18110
eMail: ki...@iti.cs.uni-magdeburg.de
On 13 Jun 2022, at 17:20, Mark Kettenis wrote:
From: kiltz <ki...@iti.cs.uni-magdeburg.de>
Date: Mon, 13 Jun 2022 14:46:39 +0200
Hi Stefan,
Dear kind people at OpenBSD.org,
we want to run OpenBSD as a firewall system on a Gigabyte R152_P30
with the following specifications:
Ampere Altra Q80-33 processor (80 Cores, 3,3 GHz)
512 GB RAM (3200 MHz ECC-reg.)
2 x 480 GB SSD SATA 6 Gb/s 2,5''
Dual-Port 1 GbE (RJ-45)
IPMI 2.0 Baseboard Management Controller (BMC)
1 x PCIe4.0 x16 (FHHL)
1 x PCIe3.0 x16 OCP2.0 (belegt)
1 x USB 3.0 (front), 3 x USB 3.0 (rear), 1 x VGA (rear)
We tried both:
- official stable 7.1 (/pub/OpenBSD/7.1/arm64) and
- snapshot from 6th of June 2022 (/pub/OpenBSD/snapshots/arm64)
The repeatable result is a working install in single CPU/Core
installation mode, cpu panic after first reboot with mp kernel. We
use
the serial to LAN console provided by the IMPI/BMC card.
Attached you will find screenshots from:
- the last 49 columns of the reboot into mp kernel
(Screenshot_boot_after_install_Gigabyte_R152_P30 at 2022-06-13
13-51-00.png),
- the ddb trace output (Screenshot ddb_trace_2022-06-13
14-02-11.png),
- the ddb ps output (Screenshot ddb_ps_at 2022-06-13 14-03-25.png),
- the ddb show panic output (Screenshot ddb_show_panic_at 2022-06-13
14-04-28.png)
- the ddb show registers output (Screenshot ddb_show_registers_at
2022-06-13 14-06-34.png)
Due to the nature of the early boot panic, the kernel output is not
accessible to us.
Interestingly, FreeBSD only supports them in their current release,
the stable fails with a similar panic. They seem to have found a fix
of sorts. But we very much prefer OpenBSD for the firewalling role of
aforementioned system.
Of course we support your effort so if you need more info from us
regarding the circumstances, we will happily try and supply the
required information.
The immediate problem is that OpenBSD currently supports a maximum of
32 CPUs. That limit is a bit arbitrary, so the diff below bumps it to
128. You could try building a GENERIC.MP kernel with this diff after
booting the GENERIC (bsd.sp) single-processor kernel. I'll see what
my fellow developers think abut bumping MAXCPUS. Depending on the
outcome of that a snapshot with this change may be available in a few
days.
I'm not sure how well OpenBSD/arm64 scales to 80 CPUs. Probably not
very well but I guess there is only one way to find out...
Cheers,
Mark
Index: arch/arm64/include/cpu.h
===================================================================
RCS file: /cvs/src/sys/arch/arm64/include/cpu.h,v
retrieving revision 1.25
diff -u -p -r1.25 cpu.h
--- arch/arm64/include/cpu.h 23 Mar 2022 23:36:35 -0000 1.25
+++ arch/arm64/include/cpu.h 13 Jun 2022 15:09:32 -0000
@@ -184,7 +184,7 @@ extern struct cpu_info *cpu_info_list;
#define CPU_INFO_FOREACH(cii, ci) for (cii = 0, ci = cpu_info_list; \
ci != NULL; ci = ci->ci_next)
#define CPU_INFO_UNIT(ci) ((ci)->ci_dev ? (ci)->ci_dev->dv_unit : 0)
-#define MAXCPUS 32
+#define MAXCPUS 128
extern struct cpu_info *cpu_info[MAXCPUS];
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
iEYEARECAAYFAmKnYesACgkQuLKZPfaiT0iDDgCfXC6QIWGHzkMyWxPKHCaTkYwR
AXUAnjLiJX1RyuqrMejk4AT2s5X99fmi
=pRhT
-----END PGP SIGNATURE-----
