freebsd stable - Apr 2018 - FreeBSD 10.4 kernel breaks on i7-7700 / PRIME H270M-PLUS

I'm trying to do the usual src code upgrade from FreeBSD 10.3 to 10.4, 
as I've done many times before with earlier version bumps.

However, for some reason the 10.4 kernel seems to break my system, 
either with the 10.3 or 10.4 userland.

The main issue seems to be some sort of deadlock. For example, on the 
console, following boot (which seems fairly normal) I can login to the 
console as root, but when I try to use commands like su or sudo to 
switch to another user, that command hangs and at that point CTRL-C is 
useless: I have to switch to another tty. Trying to login via ssh over 
the network also fails but neither case gives me any obvious clues in 
logs. If I switch back to a 10.3 kernel sanity is restored.

Not sure if it's related, but on boot I see these new errors that 
weren't present on 10.3:
> [1] ACPI Error: Mutex [0x0] is not acquired, cannot release
(20160527/utmutex-386)
> [1] ACPI Error: Could not release AML Interpreter mutex
(20160527/exutils-147)
> [1] ACPI Error: Mutex [0x0] is not acquired, cannot release
(20160527/utmutex-386)
> [1] ACPI Error: Could not release AML Interpreter mutex
(20160527/exutils-147
I've dumped the  kernel boot log here:

	http://www.knigma.org/scratch/010418.10.4.txt

I'm struggling to pin down the cause, so I'm hoping this mail might jog 
a memory or provide a pointer please?

Motherboard is a PRIME H270M-PLUS with the latest BIOS.

Thanks!!
-- 
Mark Knight

02.04.2018 5:00, Mark Knight wrote:
> I'm trying to do the usual src code upgrade from FreeBSD 10.3 to 10.4,
as I've done many times before with earlier version bumps.
> 
> However, for some reason the 10.4 kernel seems to break my system, either
with the 10.3 or 10.4 userland.
> 
> The main issue seems to be some sort of deadlock.
> For example, on the console, following boot (which seems fairly normal)
> I can login to the console as root, but when I try to use commands like
> su or sudo to switch to another user, that command hangs and at that point
CTRL-C is useless:
> I have to switch to another tty.
What does it show if you press "CTRL-T" to see a status of
"hung" process?

Does it help if you comment out the line mentioning /dev/console in the
/etc/syslog.conf
and apply the change with killall -1 syslogd ?