APIC Warning L1 data cache less than

[Visseroth]

I have a A1SRi-2758F machine running 2.4.2 and just updated to p1 and on startup for the upgrade received a error that does not come up consistently. Meaning if you reboot the system enough it will proceed and boot normally. I only know this because I assumed the error had something to do with the APIC settings in the CMOS but nothing seemed to help the error go away, so I was hoping someone could give me some insite as to what the error means.

Error being... WARNING: L1 data cache covers less APIC IDs than a core

Now I have a few of these boards. The only difference being that this board is newer and is running version 2.0 of SuperMicro's BIOS where as my other machines are running version 1.1a

System Specs...
BIOS    Vendor: American Megatrends Inc.
Version: 2.0
Release Date: Mon Jul 24 2017

Version    2.4.2-RELEASE-p1 (amd64)
built on Tue Dec 12 13:45:26 CST 2017
FreeBSD 11.1-RELEASE-p6

CPU Type    Intel(R) Atom(TM) CPU C2758 @ 2.40GHz
8 CPUs: 1 package(s) x 8 core(s)
AES-NI CPU Crypto: Yes (active)

16GB of RAM

Dual 1TB 2.5 Inch Seagate ST1000LX015 in mirror zfs

RAM Disk enabled 512/4096

Anyone have any thoughts as to what this error is so I can make it go away?

[Visseroth]

No one?

Mind you, that is where the kernel stops. I assume that was the cause of the stop.

[robi]

I ran into this yesterday. Updated to 2.4.2p1 a day after it was released. This rig with Supermicro A1SRi-2758F was up and running for 3 years now, and hanged with this same error.
Reboot - stops in the same place again.
Entered BIOS, disabled APIC at the CPU options, booted fine. Thought this fixed it, but box crashed again after about 30 mins. Pulled power, let it rest a while, boot again, crash again after about 30 mins...
This ain't a joke anymore - me thinking - especially these days when all computer shops are closed...

I gues I was hit by Intel's C2000 fault somehow. Found this thread, which inspired me to check for a BIOS update.

Noticed that BIOS on the board was at v1.1a, on Supermicro's websithe there's v2 available. Downloaded, updated, reset BIOS to factory defaults, booted up again - all fine in the last 24 hours (knock-knock).

The thing is that I have a client running 3 rigs with this very same board, one with bios v1, two with bios v1.1a, and they work just fine with latest pfSense. I think we're sitting on a timed bomb here. Hope they will make it through until I get there physically and update BIOS in place...

[Visseroth]

Your reply made me think I was the one that made the reply as I am in the exact same situation.
I would try the BIOS update on the machine with the problem, funny thing is it's already running version 2. My other machines running 1.1a don't seem to have a problem so far.

[robi]

Well re-writing the flash using the same firmware and restoring BIOS to factory defaults (including IPMI settings) couldn't harm...

[Visseroth]

True.
I'll give it a shot as soon as I have a chance.
Thanks for the reply. I'll post back as soon as I know more.

[robi]

Well if this happens again with the same board, I'll have to switch hardware, can't afford downtime these days.

[robi]

Knock-knock - working fine since then.

[Visseroth]

Nice! I haven't had a chance to do anything with this one as of yet. I will report back when I know more.

[Visseroth]

Reset the CMOS today to factory defaults. Set what I wanted set and restarted the system. Same result. Fortunately I have another one of these on hand so I'm going to swap this active system out so I can bench it and do some testing. Also shot SuperMicro a email about the issue. Maybe there's a unknown bug? I'm not sure, sure would be nice to know what is going on though.

[Visseroth]

So was going to swap the firewall out today so I could bench it and test and figure out what was going on and as soon as I fired up the temp firewall, exact same model and case but version 1.1a BIOS, it did the same thing. So I suspected it was likely being caused by something plugged in and since the only thing plugged in was the Tripplite battery backup, I unplugged it, restarted it a few times and it never hung with the error until I plugged the UPS back in.
So, in short the kernel is handing on the UPS during boot.

Should I report this as a bug? It has to be a FreeBSD kernel bug.
I plan to work around it by changing the UPS from USB to serial.

The only other issue I was running into was "AutoConfigBackup service started" would seemingly hang forever. Not always, but periodically.