Page MenuHomeFreeBSD

[BHND] (fix-regression) reboot doesn't work: PMU watchdog must be triggered on shutdown
AbandonedPublic

Authored by mizhka on Jun 27 2016, 5:37 PM.
Tags
None
Referenced Files
F122224647: D6988.id.diff
Thu, Jul 3, 12:40 PM
Unknown Object (File)
Sun, Jun 29, 9:13 AM
Unknown Object (File)
Sat, Jun 21, 5:02 PM
Unknown Object (File)
Sun, Jun 8, 3:21 PM
Unknown Object (File)
Apr 22 2025, 6:57 AM
Unknown Object (File)
Mar 31 2025, 1:55 AM
Unknown Object (File)
Mar 12 2025, 12:12 AM
Unknown Object (File)
Mar 8 2025, 9:47 AM
Subscribers

Details

Reviewers
landonf
adrian
Summary

Hi,

The command "reboot" hangs on Asus RT-N53. It worked before, so fix is simple: watchdog must be triggered always on shutdown.

Test Plan

TC: run "reboot"
AR: hang
ER: success

Tested on BCM5358 (ASUS RT-N53)

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

mizhka retitled this revision from to [BHND] (fix-regression) reboot doesn't work: PMU watchdog must be triggered on shutdown.
mizhka updated this object.
mizhka edited the test plan for this revision. (Show Details)
mizhka added reviewers: landonf, adrian.
mizhka set the repository for this revision to rS FreeBSD src repository - subversion.

The command "reboot" hangs on Asus RT-N53. It worked before, so fix is simple: watchdog must be triggered always on shutdown.

This will break on non-PMU-equippped devices (e.g. WGT634U), and more recent Broadcom devices that map the PMU register block via a dedicated core instead of ChipCommon; if we can't use CFE, we have to look at the ChipCommon core revision + capability flags + device table.

TC: run "reboot"
AR: hang

If you break to debugger (sysctl debug.kdb.panic=1) and issue a 'reset' command, the same code path succeeds; any idea why CFE is failing here?

The command "reboot" hangs on Asus RT-N53. It worked before, so fix is simple: watchdog must be triggered always on shutdown.

This will break on non-PMU-equippped devices (e.g. WGT634U), and more recent Broadcom devices that map the PMU register block via a dedicated core instead of ChipCommon; if we can't use CFE, we have to look at the ChipCommon core revision + capability flags + device table.

Do you mean "throw exception" under "break"?

TC: run "reboot"
AR: hang

If you break to debugger (sysctl debug.kdb.panic=1) and issue a 'reset' command, the same code path succeeds; any idea why CFE is failing here?

Because CFE is unreliable thing :) CFE is generic word, too many builds, versions, hacks and so on. The less used CFE features, the less pain :)

I'm agree with switch-case table, but I'll check ddb reset path too.

With D7539 committed, is it safe to close this?