Watchdog timeout APU2

stephenw10

The device I have is actually an APU1, what we (confusingly) sold as the APU2 and APU4 at the time when those models didn't exist!

When you you see shown from: kenv -q smbios.system.product

The APU1 is no longer detected because that value has changed in newer BIOS versions. Though the APU2 should be.

Steve

stephenw10

Hmm, it appears there's no way to enable the hardware watchdog in the APU1 in Coreboot so I'm unable to test it there.

Misterb

@stephenw10 I have an APU2 running pfSense and the kenv -q smbios.system.product command returns 'apu2', but isn't the point moot as the "has_hw_watchdog" function doesn't support APU[n]?

stephenw10

Right but it's not hard to enable it if the watchdog hardware is actually detected when you load the driver.

I can do that here for an APU1 with a simple patch but since there seems to be no way to enable the watchdog in Coreboot I have no way to test it.

Steve

pki79

@stephenw10 i am willing to test it, have APU2 on bench now.

stephenw10

First run at the command line: kldload amdsbwd

Make sure the system logs show the watchdog device present.

If it is then run: echo 'amdsbwd_load="YES"' >> /boot/loader.conf.local
That will ensure it is loaded at boot every time.
To check that, reboot and then run: kldstat
You should see amdsbwd listed as loaded.

Steve

pki79

@stephenw10 said in Watchdog timeout APU2:

First run at the command line: kldload amdsbwd

:kldload amdsbwd
kldload: can't load amdsbwd: No such file or directory

Do i need some additional packages?

Misterb

@pki79 said in Watchdog timeout APU2:

kldload amdsbwd

kldload amdsbwd

worked on my APU2 and kldstat shows the driver as loaded.

Steve, I'm guessing that the has_hw_watchdog() function you mention above is something run at boot time by pfSense to determine whether or not to load the (in the APU2 case) amdsbwd driver and that forcing it to be loaded with the
echo 'amdsbwd_load="YES"' >> /boot/loader.conf.local
command together with enabling the watchdog in the BIOS will make things work as expected?

stephenw10

It also requires the watchdogd process to be started at boot to 'pat' the watchdog via the driver and prevent it triggering. The code does that if it's enabled in the config but of course you can't enable it unless there's a recognised device present. If you want to test it though you can just start it using a shellcmd or just run it at the command line.

Also it turns out that although there's no way to enable the watchdog in the APU1 from Coreboot you can still use it by enabling it from pfSense. I was just testing it wrong!
If you 'kill -9' the watchdogd process it will exit without disabling the watchdog and the firewall will reboot when the timer expires:

Sep 8 01:01:20 	kernel 		amdsbwd0: Previous Reset was caused by Watchdog

So on the APU2 if the driver is loaded you can run: watchdogd -t 64
That enables the watchdog with a 64s timeout. If you then kill that process it exits and disables the watchdog so the firewall should not reset. If you kill -9 that process it should reset in ~60s.

If you enable the watchdog in coreboot I recommend at least 180s to allow the system to boot and start the watchdogd process. If you're testing it manually I'd go with something a lot longer than that!

If that looks to be working as expected on the APU2 it should be trivial to enable it in Plus.

Steve

left4pook

This works for me! Thank you. APU2C4 is running v4.17.0.3 Coreboot with the bios watchdog timer set to 300, amdsbwd loaded, and watchdogd -t 128. Kill -9 watchdogd process does indeed cause the system to reboot once the timer expires. Otherwise, the system stays up.