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
F112042867: D6988.diff
Wed, Mar 12, 12:12 AM
Unknown Object (File)
Sat, Mar 8, 9:47 AM
Unknown Object (File)
Sat, Mar 1, 1:35 AM
Unknown Object (File)
Fri, Feb 28, 6:04 PM
Unknown Object (File)
Fri, Feb 21, 3:52 PM
Unknown Object (File)
Thu, Feb 13, 8:23 PM
Unknown Object (File)
Jan 11 2025, 3:31 AM
Unknown Object (File)
Nov 19 2024, 5:45 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?