Re: Hardware recommendations for compact 1U firewall

[Jack Peirce]

On 2016-12-15, Stuart Henderson  wrote:

> If you want to
cut down on weight+noise at the expense of more cost
> and a less powerful
cpu, maybe APU2 in a 1U case or something like
> supermicro SYS-5018A-FTN4.

I
can second this recommendation, it's what I use at home.

Re: requesting help working around boot failures with supermicro atom board

[Jack Peirce]

I have a great relationship with some SuperMicro engineers, if others can
provide part #'s and firmare/bios revs, I can bring this up with them.

From: owner-m...@openbsd.org
 on behalf of li...@wrant.com 
Sent:
Wednesday, October 21, 2015 8:50 PM
To: misc@openbsd.org
Subject: Re:
requesting help working around boot failures with supermicro atom board
Synopsis: if sensors show missing data then reset the BMC unit before
rebooting the system to prevent unable to boot long beep issue.

I found a
reliably reproducible workaround for this problem retaining
control continuity
without the need to trip the mains breaker.  This
entirely prevents the long
beep issue and allows the system to be used
in headless remote environments
without ensuring remote mains power
cycle capability and/or remote hands
intervention.

I have not had to disable the lm(4) sensor as advised
previously for
the workaround and reached the conclusion this problem is not
caused
by the driver itself in the first place, but by a buggy BMC firmware.
For this it is advisable to contact again the technical support at
Supermicro
and ask them for a reliable BMC firmware update which does
not manifest the
problem.

After running for a longer period (non specific or deterministic,
above
30min), the sensors start to display wrong (missing) values and can not
provide data points to the BMC firmware.  This is seen both in IPMI
direct and
networked access and in the web based management interface.
At this point, a
reboot would get the system unable to boot manifesting
the dreaded long beep.
Only a power cycle of mains (power supply
breaker or power distribution unit)
for a couple of seconds unblocks
the system and it is capable of successfully
booting up again.  This
however totally undermines the remote control
capabilities of the
system effectively turning it into a continuous source of
remote
management manual reboot requests via intervention events for mains
power cycle (stop and start).

The workaround for this is to reset the BMC
before attempting to reboot
the system, and it works over the network directly
over IPMI and also
via the web based BMC interface likewise.  This only
reboots the IPMI
controller (not the system) and its embedded firmware, then
after a
couple of minutes the sensors poll actual correct data and display it
properly.  At this point a system reboot issued succeeds as expected and
everything the system boots up and works properly, until some non
specific
longer time passes again (from 1h to days) and the BMC
controller gets stuck
again (with a certainty it gets stuck) for which
the indication is missing
sensors data and no reboot capability with
the long beep indication.

This is
NOT OS specific unless the driver polling the sensors causes
the sensors
sub-system in the embedded controller OS to crash, the only
factor affecting
it so far is found to be the time running the system
without mains power
cycle.  It is a flaw of the BMC firmware for which
the solution for sure is to
demand an updated firmware from Supermicro
without this fault.  It would help
if more people voice their concerns
over this so an updated BMC firmware is
issued from Supermicro technical
support and published on their web site.
Here is how it looks when the BMC is stuck:

$ ipmi-sensor
System Temp  |
no reading| ns
CPU Temp | no reading| ns
CPU FAN
| no reading| ns
SYS FAN  | no reading| ns
CPU Vcore
| no reading| ns
Vichcore | no reading| ns
+3.3VCC
| no reading| ns
VDIMM| no reading| ns
+5 V
| no reading| ns
+12 V| no reading| ns
+3.3VSB
| no reading| ns
VBAT | no reading| ns
Chassis
Intru| no reading| ns
PS Status| 0x00  | ok

$
ipmi-sensor-detail
System Temp  | na || na| na
| na| na| na| na| na
CPU Temp | na
|| na| na| na| na| na| na
| na
CPU FAN  | na || na| na| na
| na| na| na| na
SYS FAN  | na |
| na| na| na| na| na| na| na
CPU
Vcore| na || na| na| na| na
| na| na| na
Vichcore | na || na
| na| na| na| na| na| na
+3.3VCC
| na || na| na| na| na| na
| na| na
VDIMM| na || na| na
| na| na| na| na| na
+5 V | na
|| na| na| na| na| na| na
| na
+12 V| na || na| na| na
| na| na| na  

Re: Dell S300 controller

[Jack Peirce]

On Mon, May 04, 2015 at 08:22:28PM -0400, Steve Shockley wrote:
Does anyone know if the Dell PERC S300 controller will work under 
OpenBSD as a non-RAID SAS HBA?  It has an LSI SAS 1068e, but I didn't 
know if they did something to make it not work as an HBA.  Thanks.

I don't believe the controller will automatically export unconfigured
drives as single drive units. LSI makes 2 different versions of 
firmware for the unbranded controllers, IR mode for RAID and IT mode 
for HBA, but it's not possible/easy to flash them to the Dell branded 
controllers.

Create RAID0 single drive units on each disk and it should export.