Reserve recovery,quiescent and reboot,quiescent to known reboot
reasons.
Test: none
Bug: 120624642
Change-Id: I78c52f6db447c9d3980a3f2007471bc7aa60e25f
libbase GetProperty collects the properties properly, which also
allow for content greater than 128 bytes in length.
Replace internal GetProperty and SetProperty helpers with libbase
version.
Test: unit tests
Bug: 121161069
Bug: 124114707
Change-Id: Ic0829955705ebaa19d747bb3f6942f4b9786316a
If ro.boot.boottime is malformed or truncated, it will crash
bootstat operations.
Test: compile
Bug: 121161069
Bug: 124114707
Change-Id: Ie2edcffb6d54a8e0c7f2e9a89ae4b29cce246d75
bootstat updates boot reason upon boot_complete, however users of the
updated properties e.g. getLastShutdownReason from PowerManager could
be called before boot_complete. This introduces a inconsistency and
racing for those APIs.
In this CL, we change boot reason to be updated at the same time when
zygote starts where persist properties have been loaded already. Also
the initialization of bootloader's boot reason is pulled into post-fs
where all kernel command line arguments have been parsed in init already.
Bug: 122696730
Bug: 119509425
Test: trigger thermal shutdown and see warnings
Test: verify boot reason properties updated correctly post boot
Change-Id: Ia393b98ea072bc0ae6e4110d111393b34be0ee5d
Signed-off-by: Wei Wang <wvw@google.com>
smpl anywhere in boot loader reason string will match and convert to
reboot,powerloss when propagated to system boot reason.
Test: compile
Bug: 63736262
Change-Id: I156bfefd05d2bab480408cf6bb1dc4c61c8983f9
uvlo anywhere in boot loader reason string will match and convert to
reboot,undervoltage when propagated to system boot reason.
Test: compile
Bug: 63736262
Change-Id: I14b0b7e8185aa4fb519efdb6cb1306718e9de69c
Selected visually obvious non-compliant boot reasons to allow
for future re-use of a later formerly duplicated entry.
Test: compile
Bug: 112157996
Change-Id: I3c6b449d36f9e4b745214dd7840b1dc1258bf483
Retain the last four reboot reasons from latest to oldest, adding a
detail of UTC epoch time for each. Beef up boot_reason_test.sh to
deal with multi-line content.
Test: boot_reason_test.sh
Bug: 110925971
Change-Id: Ie2600434b95a885693f005a363ee38d9eba18ee7
We need to make progress both on adding the real interface for battery
level and cleaning up logging. This stands in the way of both.
Bug: http://b/77725702
Test: builds
Change-Id: Ia457e497606c2c7965d6895baebb26eef17857c9
Merged-In: Ia457e497606c2c7965d6895baebb26eef17857c9
To ensure a surprise reboot does not take the last boot reason on
face value especially if coming from more than one boot sessions ago.
We shift and clear the value from persist.sys.boot.reason to
sys.boot.reason.last and establish a correct last reboot reason in
the canonical sys.boot.reason property.
This effectively deprecates persist.sys.boot.reason as an API. They
should have been using sys.boot.reason instead for a correctly
determined reasoning.
Test: boot_reason_test.sh
Bug: 86671991
Merged-In: If85750704445088fd62978679ab3a30744c46abb
Change-Id: If85750704445088fd62978679ab3a30744c46abb
This change removes the CAP_SYSLOG file based capability from bootstat,
since the intention is that it should not be accessing the logs in the
long term. In order to avoid bitrot, the fallback code that depends on
CAP_SYSLOG has also been removed.
Bug: 62845925
Test: system/core/bootstat/boot_reason_test.sh
Change-Id: I899be44ef3ac1c4d81072f801d55c928ae09bb15
(partial cherry pick from commit fe3e762b6d)
Adding the boot sequence reported atom in ag/3518079 caused the duration
of bootstat to increase, as seen in b/72864061. I isolated the cause
down to calling BootReasonStrToReason. However, this function also gets
called in ReportBootReason, so I created another function that does the
parsing and sets the system boot reason property, and made
RecordBootReason and statsd logging get that property.
Bug: 72864061
Test: rebooted phone, verified boot events were received in adb shell
logcat -b stats and verified adb shell bootstat -p printed correct
values. Ran timing tests as well on walleye with 20 boots: before this
change, the average was ~150-160ms. After, it was ~80ms.
Change-Id: I92dbc9880328835647be7d9d50c7861b42f27bdb
Merged-In: I92dbc9880328835647be7d9d50c7861b42f27bdb
Received some clarity as to some of the boot reasons.
List of boot reasons and new translations to Canonical boot reason:
- "power_key" -> "cold,powerkey" (existing)
- "usb" -> "cold,charger" (existing)
- "rtc" -> "cold,rtc" (existing)
- "wdt" -> "reboot" (changed)
- "wdt_by_pass_pwk" -> "warm" (changed)
- "tool_by_pass_pwd" -> "reboot,tool" (changed)
- "2sec_reboot" -> "cold,rtc,2sec" (changed)
- "unknown" -> "reboot,unknown" (existing)
- "kernel_panic" (existing)
- "reboot" (existing)
- "watchdog" (existing)
Add the new string to enums for the new Boot Reason.
Test: boot_reason_test.sh (on affected device)
Bug: 74595769
Bug: 63736262
Change-Id: Iecedc3b1f7c47f26d0c77b1f316f745c6d2c1256
Some devices report the following canonical boot reason for all
shutdown operations:
reboot,kernel_power_off_charging__reboot_system
because shutdown switches to a charging kernel, and reboots into the
system when the user presses the power button. Thus last kernel
messages arrives as:
<0>.(0)[53:pmic_thread]reboot: Restarting system with command \
'kernel power off charging reboot system'
-> "shutdown" (w/o last boot reason)
-> "shutdown,<subreason>" (w/last boot reason)
The reboot reason from that charging instance propagates as a
fortified boot reason blocking interpretation of the last boot reason
that manages shutdown canonical boot reason determination. The fix
is to change reboot,kernel_power_off_charging__reboot_system to
shutdown, so that it is viewed as a blunt reason that can be
overridden by last boot reason.
We added the above boot reason to kBootReasonMap because the Bit
Error Handler can use it to reconstruct if there is any damage to
the last kernel messages content. The sad thing is that the enum
will never propagate as we are filtering it out and reporting
"shutdown" instead. Of course, we are now covered for a can not
happen.
Test: boot_reason_test.sh
Bug: 74595769
Bug: 63736262
Change-Id: I28987f0871af7d967cc4bbbffed43bd42349acdd
Found a kernel modem driver report:
Kernel panic - not syncing: subsys-restart: Resetting the SoC - modem crashed.
Which translates to the canonical boot reason, a wordy:
kernel_panic,subsys-restart:_resetting_the_soc_-_modem_crashed.
Shortening and ber matching the string, plus others that are possible,
to be more succinct, so added kernel_panic,{modem|adsp|dsps|wcnss}.
Test: build
Bug: 80553005
Change-Id: I969e1da896cd15b82e2fe11ceb77a5f54dfcfbc8
This test fails on most devices, gives us a report of devices that
do not propagate the boot reason via the bootloader. This should
become a bootloader required test.
Test: boot_reason_test.sh optional_rescueparty
Change-Id: Ibdc7b23b025e5d89d659ff08083b2e071343923c
Report kernel_panic,sysrq,livelock,<state> reboot reason via last
dmesg (pstore console). Add ro.llk.killtest property, which will
allow reliable ABA platforms to drop kill test and go directly
to kernel panic. This should also allow some manual unit testing
of the canonical boot reason report.
New canonical boot reasons from llkd are:
- kernel_panic,sysrq,livelock,alarm llkd itself locked up (Hail Mary)
- kernel_panic,sysrq,livelock,driver uninterrruptible D state
- kernel_panic,sysrq,livelock,zombie uninterrruptible Z state
Manual test assumptions:
- llkd is built by the platform and landed on system partition
- unit test is built and landed in /data/nativetest (could
land in /data/nativetest64, adjust test correspondingly)
- llkd not enabled, ro.llk.enable and ro.llk.killtest
are not set by platform allowing test to adjust all the
configuration properties and start llkd.
- or, llkd is enabled, ro.llk.enable is true, and killtest is
disabled, ro.llk.killtest is false, setup by the platform.
This breaks the go/apct generic operations of the unit test
for llk.zombie and llk.driver as kernel panic results
requiring manual intervention otherwise. If test moves to
go/apct, then we will be forced to bypass these tests under
this condition (but allow them to run if ro.llk.killtest
is "off" so specific testing above/below can be run).
for i in driver zombie; do
adb shell su root setprop ro.llk.killtest off
adb shell /data/nativetest/llkd_unit_test/llkd_unit_test --gtest_filter=llkd.${i}
adb wait-for-device
adb shell su root setprop ro.llk.killtest off
sleep 60
adb shell getprop sys.boot.reason
adb shell /data/nativetest/llkd_unit_test/llkd_unit_test --gtest_filter=llkd.${i}
done
Test: llkd_unit_test (see test assumptions)
Bug: 33808187
Bug: 72838192
Change-Id: I2b24875376ddfdbc282ba3da5c5b3567de85dbc0
This change allows bootstat to read the ro.boot.boottime_offset
property, which is set on devices where Android runs in a container.
This is because the CLOCK_BOOTTIME clock is not reset when (from
Android's perspective) the device restarts, since the host OS does not
restart itself.
Bug: 77273909
Test: CtsBootStatsTestCases
Change-Id: Ifb792864394be0b4686cc9d555c0afced856f4b4
Merged-In: Ifb792864394be0b4686cc9d555c0afced856f4b4
This change allows bootstat to read the ro.boot.boottime_offset
property, which is set on devices where Android runs in a container.
This is because the CLOCK_BOOTTIME clock is not reset when (from
Android's perspective) the device restarts, since the host OS does not
restart itself.
Bug: 77273909
Test: CtsBootStatsTestCases
Change-Id: Ifb792864394be0b4686cc9d555c0afced856f4b4
Provide some easy kernel panic subreasons mined from last kmesg,
generates a canonical boot reason (system boot reason) that
may aid triage.
Notably report kernel_panic,hung if [khungtaskd] triggers on
a livelock condition, forms a signals on the dashboards.
Helper function getSubreason modified to optionally enable checking
for a single quote resulting in a refactoring to ease maintenance of
the termination detection in the face of single bit errors heuristics.
Test: boot_reason_test.sh
Bug: 63736262
Bug: 33808187
Change-Id: I7fdd1e57e7a26095738175074306f0d2d59b1d69
Allow for a daemon to write to last kmsg to propagate a detailed
subreason to kernel_panic,sysrq actions. A minor refactor moves
common code into a helper function getSubreason for retrieval and
bit error correction operations.
A sysrq crash generally produces a kernel-provided message:
SysRq : Trigger a crash
which is used to generate a canonical boot reason kernel_panic,sysrq.
A user daemon could write to /dev/kmsg just prior to the sysrq with
SysRq : Trigger a crash : '<subreason>'
to change the canonical boot reason to kernel_panic,sysrq,<subreason>.
Administration added pending kBootReasonMap entries present in TRON.
Test: manual echo into /dev/kmsg and /proc/sysrq-trigger and check
Test: boot_reason_test.sh
Bug: 33808187
Bug: 63736262
Change-Id: Ibf5432737e5a3449ebe40a8c6cf2d3e912ed6bbc
Hopefully the quick property test is first, setting the stage for
ignoring future failures. This solves a problem with multiple
test failures directly attributed to a CTS compliance issue
with the bootloader's boot reason. One test fails, the remainder
get a pass on this one issue.
Test: boot_reason_test.sh
Bug: 63736262
Change-Id: Id56946b6f2f3a33d65bd1830543838f153290759
For aliasReasons allow one to optionally suppress needle for output
member using a <bang> (!) character prefix.
Test: boot_reason_test.sh
Bug: 63736262
Bug: 74595769
Change-Id: If35518c08cf909c6c78a16275e9d8dfd0ff839a9
For all known cases, if usb is present in the bootloader reason,
then it is actually reporting a cold,charger canonical boot reason.
This signifies that the device was powered down, and was woken
up by the charger being connected.
For all known cases, if rtc is present in the bootloader reason,
then it is actually reporting a cold,rtc canonical boot reason.
This signifies that the device was powered down, and was woken
up by the rtc clock.
Test: boot_reason_test.sh
Bug: 74595769
Bug: 63736262
Change-Id: I04bede0b7ccaa1b859943f7def93521a8f7b25c6
