IssueTracker

[1] https://lore.kernel.org/linux-arm-kernel/1604317487-14543-1-git-send-email-sumit.garg@linaro.org/
[2] https://lore.kernel.org/linux-arm-kernel/CAGb2v67yfWbRA4MNa2f+pAJAyiEqeCaREziaPjvGcDzTw5Za=A@mail.gmail.com/
[3] https://lore.kernel.org/linux-arm-kernel/20210811171505.1502090-1-wenst@chromium.org/

Comments

le...@pinkfroot.com <le...@pinkfroot.com> #2May 8, 2018 12:00PM

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit

https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

hy...@gmail.com <hy...@gmail.com> #3May 9, 2018 02:05AM

NOTE: this might be less important now since

bug 972103

has progress.

le...@pinkfroot.com <le...@pinkfroot.com> #4May 9, 2018 08:17AM

AFAICT the buddy lockup detector will not help with debugging as it cannot produce the stack backtrace on the locked up core.

I think something like the "IPI as NMI" series [1] would help with this. The NMI IPI can be used to force a stack dump. I've lightly tested this on MT8195 (CrOS 5.10 Cherry ToT) and RK3399 (5.10 uprev). Some fixes are required [2][3] though.

Unfortunately the latest Cherry ToT simply panics during boot from a spinlock recursion if pseudo-NMIs are enabled.

an...@google.com <an...@google.com> #5May 9, 2018 08:37AM

Assigned to an...@google.com.

AFAICT the buddy lockup detector will not help with debugging as it cannot produce the stack backtrace on the locked up core.

It's still better than nothing (especially if you combine it with something like https://crrev.com/c/1630714), but you're right that it's far less than ideal.

Right that the NMI solution is better. That's bug 172228850, right?

le...@pinkfroot.com <le...@pinkfroot.com> #6May 9, 2018 08:58AM

Bug 172228850 uses NMI for the PMU interrupts for the perf-based hardlockup detector.

If for some reason the PMU interrupts can't be used as NMIs, like if they are partitioned (seen on RK3399 and MT8195), or they aren't PPIs (not seen on ChromeOS platforms but on other platforms), then this won't work.

I'll open another bug to track "IPI as NMI for NMI backtraces" to complement the buddy lockup detector.

le...@pinkfroot.com <le...@pinkfroot.com> #7May 9, 2018 09:01AM

Filed as bug 197061987.

an...@google.com <an...@google.com> #8May 9, 2018 09:46AM

Not sure why this got closed; it's still relevant.

le...@pinkfroot.com <le...@pinkfroot.com> #9May 9, 2018 09:51AM

Project: chromiumos/third_party/kernel
Branch: chromeos-5.15

commit 399e5d4e576b8bfdc0939b6e62694bbe65b5a9f9
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon Apr 17 17:25:44 2023

FIXUP: CHROMIUM: hardlockup: detect hard lockups without NMIs using secondary cpus (all backtrace)

The buddy hard lockup detector should try backtracing on all
CPUs. Right now it doesn't. Copy that bit of logic from the normal
hardlockup detector.

NOTE: On arm64 (the current user of the buddy detector), this won't
(yet) do anything. Soon, hopefully.

UPSTREAM-TASK=b:172213097
BUG=b:278598383, b:278594093, b:197061987, b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Id225408348d8a45e68080d08139bc6d9e170000a
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4438220
Reviewed-by: Stephen Boyd <swboyd@chromium.org>

M kernel/watchdog_buddy_cpu.c

https://chromium-review.googlesource.com/4438220

an...@google.com <an...@google.com> #10May 9, 2018 10:01AM

Project: chromiumos/third_party/kernel
Branch: chromeos-5.15

commit 71986679fe52d94286f9051f09b958ecf582c7fc
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon Apr 17 17:15:31 2023

FIXUP: CHROMIUM: hardlockup: detect hard lockups without NMIs using secondary cpus (sysctl)

The CHROMIUM patch accidentally didn't expose the hardlockup panic
sysctls based on the right config. Fix it.

NOTE: Only one of these two sysctls actually does something with the
current buddy detector. You can turn on/off the hard lockup detector
but it doesn't (yet) support tracing other CPUs.

UPSTREAM-TASK=b:172213097
BUG=b:278598383, b:278594093, b:197061987, b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Id88d1fb603308e7210c30e42bb6e4e6a4be65a0c
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4438219
Reviewed-by: Stephen Boyd <swboyd@chromium.org>

M kernel/sysctl.c

https://chromium-review.googlesource.com/4438219

le...@pinkfroot.com <le...@pinkfroot.com> #11May 9, 2018 10:06AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit e21e2990b1d7fbb917a7b37541f91f41670d0d1d
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon Apr 17 17:25:44 2023

FIXUP: CHROMIUM: hardlockup: detect hard lockups without NMIs using secondary cpus (all backtrace)

The buddy hard lockup detector should try backtracing on all
CPUs. Right now it doesn't. Copy that bit of logic from the normal
hardlockup detector.

NOTE: On arm64 (the current user of the buddy detector), this won't
(yet) do anything. Soon, hopefully.

UPSTREAM-TASK=b:172213097
BUG=b:278598383, b:278594093, b:197061987, b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Id225408348d8a45e68080d08139bc6d9e170000a
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4438220
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
(cherry picked from commit 399e5d4e576b8bfdc0939b6e62694bbe65b5a9f9)
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4442718
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>

M kernel/watchdog_buddy_cpu.c

https://chromium-review.googlesource.com/4442718

an...@google.com <an...@google.com> #12May 9, 2018 10:50AM

Reassigned to jh...@google.com.

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 0351e3dbd6dce50087d5b4cb4698c7ceacb93bfa
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon Apr 17 17:15:31 2023

FIXUP: CHROMIUM: hardlockup: detect hard lockups without NMIs using secondary cpus (sysctl)

The CHROMIUM patch accidentally didn't expose the hardlockup panic
sysctls based on the right config. Fix it.

NOTE: Only one of these two sysctls actually does something with the
current buddy detector. You can turn on/off the hard lockup detector
but it doesn't (yet) support tracing other CPUs.

UPSTREAM-TASK=b:172213097
BUG=b:278598383, b:278594093, b:197061987, b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Id88d1fb603308e7210c30e42bb6e4e6a4be65a0c
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4438219
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4442717

M kernel/watchdog.c

https://chromium-review.googlesource.com/4442717

ma...@gmail.com <ma...@gmail.com> #17May 11, 2018 04:43PM

Everything, including fixes for all reported issues, is now in Linus's tree. \o/

I've done a backport of all of this to chromeos-6.1. The hope is that will make the continuous rebase kernels go more smoothly because they'll all get the configs enabled properly and won't have to separately realize the patches that they need to drop. Anyone care to review? Chen-Yu, maybe? I've put a tiny bit of notes about why I picked various patches in the attached notes.

Note that this also happens to bring in the arm64 perf lockup detector (see b/172228850), but doesn't enable it.

The whole chain is:

https://crrev.com/c/4673849 - CHROMIUM: config: Enable the buddy hardlockup detector in the upstream way
https://crrev.com/c/4673848 - UPSTREAM: powerpc: Include asm/nmi.c in mobility.c for watchdog_hardlockup_set_timeout_pct()
https://crrev.com/c/4673847 - UPSTREAM: watchdog/hardlockup: fix typo in config HARDLOCKUP_DETECTOR_PREFER_BUDDY
https://crrev.com/c/4673846 - UPSTREAM: powerpc: move arch_trigger_cpumask_backtrace from nmi.h to irq.h
https://crrev.com/c/4673845 - UPSTREAM: watchdog/hardlockup: define HARDLOCKUP_DETECTOR_ARCH
https://crrev.com/c/4673844 - UPSTREAM: watchdog/sparc64: define HARDLOCKUP_DETECTOR_SPARC64
https://crrev.com/c/4673843 - BACKPORT: watchdog/hardlockup: make HAVE_NMI_WATCHDOG sparc64-specific
https://crrev.com/c/4673842 - UPSTREAM: watchdog/hardlockup: declare arch_touch_nmi_watchdog() only in linux/nmi.h
https://crrev.com/c/4673841 - UPSTREAM: watchdog/hardlockup: make the config checks more straightforward
https://crrev.com/c/4673840 - UPSTREAM: watchdog/hardlockup: sort hardlockup detector related config values a logical way
https://crrev.com/c/4673839 - UPSTREAM: watchdog/hardlockup: move SMP barriers from common code to buddy code
https://crrev.com/c/4673838 - UPSTREAM: watchdog/buddy: simplify the dependency for HARDLOCKUP_DETECTOR_PREFER_BUDDY
https://crrev.com/c/4673837 - UPSTREAM: watchdog/buddy: don't copy the cpumask in watchdog_next_cpu()
https://crrev.com/c/4673836 - UPSTREAM: watchdog/buddy: cleanup how watchdog_buddy_check_hardlockup() is called
https://crrev.com/c/4673835 - UPSTREAM: watchdog/hardlockup: remove softlockup comment in touch_nmi_watchdog()
https://crrev.com/c/4673834 - UPSTREAM: watchdog/hardlockup: in watchdog_hardlockup_check() use cpumask_copy()
https://crrev.com/c/4673833 - UPSTREAM: watchdog/hardlockup: don't use raw_cpu_ptr() in watchdog_hardlockup_kick()
https://crrev.com/c/4673832 - UPSTREAM: watchdog/hardlockup: HAVE_NMI_WATCHDOG must implement watchdog_hardlockup_probe()
https://crrev.com/c/4673831 - UPSTREAM: watchdog/hardlockup: keep kernel.nmi_watchdog sysctl as 0444 if probe fails
https://crrev.com/c/4673830 - UPSTREAM: arm64: enable perf events based hard lockup detector
https://crrev.com/c/4673829 - UPSTREAM: arm64: add hw_nmi_get_sample_period for preparation of lockup detector
https://crrev.com/c/4673828 - UPSTREAM: watchdog/perf: adapt the watchdog_perf interface for async model
https://crrev.com/c/4673827 - UPSTREAM: watchdog/perf: add a weak function for an arch to detect if perf can use NMIs
https://crrev.com/c/4673826 - UPSTREAM: watchdog/hardlockup: detect hard lockups using secondary (buddy) CPUs
https://crrev.com/c/4673825 - UPSTREAM: watchdog/hardlockup: have the perf hardlockup use __weak functions more cleanly
https://crrev.com/c/4673824 - UPSTREAM: watchdog/hardlockup: rename some "NMI watchdog" constants/function
https://crrev.com/c/4673823 - UPSTREAM: watchdog/hardlockup: move perf hardlockup watchdog petting to watchdog.c
https://crrev.com/c/4673822 - UPSTREAM: watchdog/hardlockup: add a "cpu" param to watchdog_hardlockup_check()
https://crrev.com/c/4673821 - UPSTREAM: watchdog/hardlockup: style changes to watchdog_hardlockup_check() / is_hardlockup()
https://crrev.com/c/4673520 - UPSTREAM: watchdog/hardlockup: move perf hardlockup checking/panic to common watchdog.c
https://crrev.com/c/4673519 - UPSTREAM: watchdog/perf: rename watchdog_hld.c to watchdog_perf.c
https://crrev.com/c/4673518 - UPSTREAM: watchdog/hardlockup: add comments to touch_nmi_watchdog()
https://crrev.com/c/4673517 - UPSTREAM: watchdog/perf: ensure CPU-bound context when creating hardlockup detector event
https://crrev.com/c/4673516 - UPSTREAM: watchdog/hardlockup: change watchdog_nmi_enable() to void
https://crrev.com/c/4673515 - UPSTREAM: watchdog: remove WATCHDOG_DEFAULT
https://crrev.com/c/4673514 - UPSTREAM: watchdog/perf: more properly prevent false positives with turbo modes
https://crrev.com/c/4673513 - UPSTREAM: watchdog/perf: define dummy watchdog_update_hrtimer_threshold() on correct config
https://crrev.com/c/4673512 - Revert "CHROMIUM: hardlockup: detect hard lockups without NMIs using secondary cpus"
https://crrev.com/c/4673511 - Revert "FIXUP: CHROMIUM: hardlockup: detect hard lockups without NMIs using secondary cpus (sysctl)"
https://crrev.com/c/4673510 - Revert "FIXUP: CHROMIUM: hardlockup: detect hard lockups without NMIs using secondary cpus (all backtrace)"
https://crrev.com/c/4673509 - UPSTREAM: arm64: perf: Move PMUv3 driver to drivers/perf

Once that lands, we could probably call this fixed. If needed, we could also backport to older kernels.

+sn-support@semihalf.corp-partner.google.com as a heads up since I'm hoping this will help when they rebase atop the next -rc1.

st...@gmail.com <st...@gmail.com> #18May 11, 2018 05:06PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 4d218ff03e576500a617329c19c0ba1f1461bbce
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 19 10:18:31 2023

UPSTREAM: watchdog/perf: rename watchdog_hld.c to watchdog_perf.c

The code currently in "watchdog_hld.c" is for detecting hardlockups using
perf, as evidenced by the line in the Makefile that only compiles this
file if CONFIG_HARDLOCKUP_DETECTOR_PERF is defined. Rename the file to
prepare for the buddy hardlockup detector, which doesn't use perf.

It could be argued that the new name makes it less obvious that this is a
hardlockup detector. While true, it's not hard to remember that the
"perf" detector is always a hardlockup detector and it's nice not to have
names that are too convoluted.

Link:

https://lkml.kernel.org/r/20230519101840.v5.7.Ice803cb078d0e15fb2cbf49132f096ee2bd4199d@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Colin Cross <ccross@android.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Tzung-Bi Shih <tzungbi@chromium.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 6ea0d04211a7715a926f5dca4aa1065614fa64da)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Ice803cb078d0e15fb2cbf49132f096ee2bd4199d
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673519
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>

M kernel/Makefile
M kernel/watchdog_perf.c

https://chromium-review.googlesource.com/4673519

jo...@gmail.com <jo...@gmail.com> #19May 11, 2018 05:20PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 222ddfef1622e21c885c6b6d310547c8c1533d65
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 19 10:18:30 2023

UPSTREAM: watchdog/hardlockup: add comments to touch_nmi_watchdog()

In preparation for the buddy hardlockup detector, add comments to
touch_nmi_watchdog() to make it obvious that it touches the configured
hardlockup detector regardless of whether it's backed by an NMI. Also
note that arch_touch_nmi_watchdog() may not be architecture-specific.

Ideally, we'd like to rename these functions but that is a fairly
disruptive change touching a lot of drivers. After discussion [1] the
plan is to defer this until a good time.

[1]

https://lore.kernel.org/r/ZFy0TX1tfhlH8gxj@alley

[akpm@linux-foundation.org: comment changes, per Petr]
Link:

https://lkml.kernel.org/r/ZGyONWPXpE1DcxA5@alley
Link:

https://lkml.kernel.org/r/20230519101840.v5.6.I4e47cbfa1bb2ebbcdb5ca16817aa2887f15dc82c@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Colin Cross <ccross@android.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Tzung-Bi Shih <tzungbi@chromium.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 8b5c59a92b5b37e5c65ec185810d67e3f30f5a2e)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I4e47cbfa1bb2ebbcdb5ca16817aa2887f15dc82c
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673518
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>

M include/linux/nmi.h

https://chromium-review.googlesource.com/4673518

md...@gmail.com <md...@gmail.com> #20May 11, 2018 05:48PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 226f0cff12cabe1dc31895d20409d9e22654a76e
Author: Pingfan Liu <kernelfans@gmail.com>
Date: Fri May 19 10:18:29 2023

UPSTREAM: watchdog/perf: ensure CPU-bound context when creating hardlockup detector event

hardlockup_detector_event_create() should create perf_event on the current
CPU. Preemption could not get disabled because
perf_event_create_kernel_counter() allocates memory. Instead, the CPU
locality is achieved by processing the code in a per-CPU bound kthread.

Add a check to prevent mistakes when calling the code in another code
path.

Link:

https://lkml.kernel.org/r/20230519101840.v5.5.I654063e53782b11d53e736a8ad4897ffd207406a@changeid
Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Co-developed-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Colin Cross <ccross@android.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Tzung-Bi Shih <tzungbi@chromium.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 1fafaa7745eeeeffef7155ab5eeb8cc83d04874f)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I654063e53782b11d53e736a8ad4897ffd207406a
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673517
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>

M kernel/watchdog_hld.c

https://chromium-review.googlesource.com/4673517

ma...@gmail.com <ma...@gmail.com> #21May 11, 2018 07:10PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 8e80d8f4420819b56cc60472256e266308b54a15
Author: Lecopzer Chen <lecopzer.chen@mediatek.com>
Date: Fri May 19 10:18:28 2023

UPSTREAM: watchdog/hardlockup: change watchdog_nmi_enable() to void

Nobody cares about the return value of watchdog_nmi_enable(), changing its
prototype to void.

Link:

https://lkml.kernel.org/r/20230519101840.v5.4.Ic3a19b592eb1ac4c6f6eade44ffd943e8637b6e5@changeid
Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Acked-by: Nicholas Piggin <npiggin@gmail.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Colin Cross <ccross@android.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Tzung-Bi Shih <tzungbi@chromium.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 730211182ed083898fa5feb4b28459ffac4c9615)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Ic3a19b592eb1ac4c6f6eade44ffd943e8637b6e5
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673516
Tested-by: Douglas Anderson <dianders@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Guenter Roeck <groeck@chromium.org>

M arch/sparc/kernel/nmi.c
M include/linux/nmi.h
M kernel/watchdog.c

https://chromium-review.googlesource.com/4673516

ov...@gmail.com <ov...@gmail.com> #22May 11, 2018 07:25PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit f3583f5bf1ce1445abef98e6cadfe33e487018aa
Author: Lecopzer Chen <lecopzer.chen@mediatek.com>
Date: Fri May 19 10:18:27 2023

UPSTREAM: watchdog: remove WATCHDOG_DEFAULT

No reference to WATCHDOG_DEFAULT, remove it.

Link:

https://lkml.kernel.org/r/20230519101840.v5.3.I6a729209a1320e0ad212176e250ff945b8f91b2a@changeid
Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Colin Cross <ccross@android.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Tzung-Bi Shih <tzungbi@chromium.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 810b560e8985725dbd57bbb3f188c231365eb5ae)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I6a729209a1320e0ad212176e250ff945b8f91b2a
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673515
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>

M kernel/watchdog.c

https://chromium-review.googlesource.com/4673515

ab...@citydrive.mx <ab...@citydrive.mx> #23May 11, 2018 08:04PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit a4af9617ba585314e0e08906a78bfab2c30be00d
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 19 10:18:26 2023

UPSTREAM: watchdog/perf: more properly prevent false positives with turbo modes

Currently, in the watchdog_overflow_callback() we first check to see if
the watchdog had been touched and _then_ we handle the workaround for
turbo mode. This order should be reversed.

Specifically, "touching" the hardlockup detector's watchdog should avoid
lockups being detected for one period that should be roughly the same
regardless of whether we're running turbo or not. That means that we
should do the extra accounting for turbo _before_ we look at (and clear)
the global indicating that we've been touched.

NOTE: this fix is made based on code inspection. I am not aware of any
reports where the old code would have generated false positives. That
being said, this order seems more correct and also makes it easier down
the line to share code with the "buddy" hardlockup detector.

Link:

https://lkml.kernel.org/r/20230519101840.v5.2.I843b0d1de3e096ba111a179f3adb16d576bef5c7@changeid
Fixes: 7edaeb6841df ("kernel/watchdog: Prevent false positives with turbo modes")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Colin Cross <ccross@android.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Tzung-Bi Shih <tzungbi@chromium.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 4379e59fe5665cfda737e45b8bf2f05321ef049c)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I843b0d1de3e096ba111a179f3adb16d576bef5c7
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673514
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>

M kernel/watchdog_hld.c

https://chromium-review.googlesource.com/4673514

av...@google.com <av...@google.com> #24May 11, 2018 09:54PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit be55001831db6391cbab179f3c9f2fb1f9757de2
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 19 10:18:25 2023

UPSTREAM: watchdog/perf: define dummy watchdog_update_hrtimer_threshold() on correct config

Patch series "watchdog/hardlockup: Add the buddy hardlockup detector", v5.

This patch series adds the "buddy" hardlockup detector. In brief, the
buddy hardlockup detector can detect hardlockups without arch-level
support by having CPUs checkup on a "buddy" CPU periodically.

Given the new design of this patch series, testing all combinations is
fairly difficult. I've attempted to make sure that all combinations of
CONFIG_ options are good, but it wouldn't surprise me if I missed
something. I apologize in advance and I'll do my best to fix any
problems that are found.

This patch (of 18):

The real watchdog_update_hrtimer_threshold() is defined in
kernel/watchdog_hld.c. That file is included if
CONFIG_HARDLOCKUP_DETECTOR_PERF and the function is defined in that file
if CONFIG_HARDLOCKUP_CHECK_TIMESTAMP.

The dummy version of the function in "nmi.h" didn't get that quite right.
While this doesn't appear to be a huge deal, it's nice to make it
consistent.

It doesn't break builds because CHECK_TIMESTAMP is only defined by x86 so
others don't get a double definition, and x86 uses perf lockup detector,
so it gets the out of line version.

Link:

https://lkml.kernel.org/r/20230519101840.v5.18.Ia44852044cdcb074f387e80df6b45e892965d4a1@changeid
Link:

https://lkml.kernel.org/r/20230519101840.v5.1.I8cbb2f4fa740528fcfade4f5439b6cdcdd059251@changeid
Fixes: 7edaeb6841df ("kernel/watchdog: Prevent false positives with turbo modes")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Tzung-Bi Shih <tzungbi@chromium.org>
Cc: Will Deacon <will@kernel.org>
Cc: Colin Cross <ccross@android.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 5e008df11c55228a86a1bae692cc2002503572c9)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I8cbb2f4fa740528fcfade4f5439b6cdcdd059251
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673513
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>

M include/linux/nmi.h

https://chromium-review.googlesource.com/4673513

Message last modified on May 12, 2018 12:46AM

il...@gmail.com <il...@gmail.com> #25May 11, 2018 10:06PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 176585f4a79d2fa783276fdefb299410d97a9b9d
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri Jul 07 12:26:16 2023

Revert "CHROMIUM: hardlockup: detect hard lockups without NMIs using secondary cpus"

This reverts commit 3b0603c1a24696e0c8ec3892ed13862a0c71b200.

We're replacing the old CHROMIUM patches with what landed upstream.

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Ia1205a8a82fb0255c03dc1080b04d139b3374df7
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673512
Reviewed-by: Guenter Roeck <groeck@chromium.org>

M include/linux/nmi.h
M kernel/Makefile
M kernel/watchdog.c
D kernel/watchdog_buddy_cpu.c
M lib/Kconfig.debug

https://chromium-review.googlesource.com/4673512

m....@gmail.com <m....@gmail.com> #26May 11, 2018 10:43PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 283d8d26b36737ca2eb2d8b9ac70bb05e5fcb067
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri Jul 07 12:26:06 2023

Revert "FIXUP: CHROMIUM: hardlockup: detect hard lockups without NMIs using secondary cpus (sysctl)"

This reverts commit 0351e3dbd6dce50087d5b4cb4698c7ceacb93bfa.

We're replacing the old CHROMIUM patches with what landed upstream.

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Ie3c6b77f7aac3e7988916c58a364792ca9a73ad0
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673511
Reviewed-by: Guenter Roeck <groeck@chromium.org>

M kernel/watchdog.c

https://chromium-review.googlesource.com/4673511

ah...@google.com <ah...@google.com> #27May 11, 2018 11:17PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 8d75434d7bb36944d3fa1620765556fd48fbbe6d
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri Jul 07 12:26:03 2023

Revert "FIXUP: CHROMIUM: hardlockup: detect hard lockups without NMIs using secondary cpus (all backtrace)"

This reverts commit e21e2990b1d7fbb917a7b37541f91f41670d0d1d.

We're replacing the old CHROMIUM patches with what landed upstream.

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Cq-Depend: chromium:4673849
Change-Id: If682778037673b55818c43766c5b209d5f6ff855
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673510
Reviewed-by: Guenter Roeck <groeck@chromium.org>

M kernel/watchdog_buddy_cpu.c

https://chromium-review.googlesource.com/4673510

ab...@citydrive.mx <ab...@citydrive.mx> #28May 12, 2018 12:27AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 0c6d5223e82ae40fa11588c34ef2eb24008f29c7
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri Jul 07 13:04:26 2023

CHROMIUM: config: Enable the buddy hardlockup detector in the upstream way

Now that we've reverted the downstream buddy lockup detector and
picked the upstream buddy lockup detector, we need to enable it
differently. Now we just enable the "CONFIG_HARDLOCKUP_DETECTOR" for
all platforms and the system realizes that means that buddy lockup
detector for arm64.

NOTE: We'll have to be careful when we enable CONFIG_ARM64_PSEUDO_NMI
since suddenly the default will change to the perf lockup detector and
that's probably not what we want for arm64. We don't want the perf one
in most cases because just turning on CONFIG_ARM64_PSEUDO_NMI doesn't
actually guarantee that pseudo-NMI will be available and if pseudo-NMI
isn't available the buddy lockup detector is more functional than the
perf-based one. Pseudo-NMI might not be available either because we
haven't yet turned it on with "irqchip.gicv3_pseudo_nmi=1" or because
of the Mediatek errata (see

b/281831288

). Thus, when we set
CONFIG_ARM64_PSEUDO_NMI=y we'll have to also add
CONFIG_HARDLOCKUP_DETECTOR_PREFER_BUDDY=y.

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I67e347bc4ccd9beba2a54a128c83d623b7d5b949
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673849
Reviewed-by: Guenter Roeck <groeck@chromium.org>

M chromeos/config/chromeos/arm64/common.config
M chromeos/config/chromeos/armel/common.config
M chromeos/config/chromeos/base.config
M chromeos/config/chromeos/x86_64/common.config

https://chromium-review.googlesource.com/4673849

av...@google.com <av...@google.com> #29May 12, 2018 12:35AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 812271a35b03ff519f6734d29e5cfc6f45530365
Author: Douglas Anderson <dianders@chromium.org>
Date: Thu Jun 29 12:45:06 2023

UPSTREAM: powerpc: Include asm/nmi.c in mobility.c for watchdog_hardlockup_set_timeout_pct()

The powerpc/platforms/pseries/mobility.c calls
watchdog_hardlockup_set_timeout_pct(), which is declared in
<asm/nmi.h>. We used to automatically get <asm/nmi.h> included, but
that changed as of commit 7ca8fe94aa92 ("watchdog/hardlockup: define
HARDLOCKUP_DETECTOR_ARCH"). Let's add the explicit include.

Reported-by: Randy Dunlap <rdunlap@infradead.org>
Closes:

https://lore.kernel.org/r/af19b76d-aa4b-6c88-9cac-eae4b2072497@infradead.org
Fixes: 7ca8fe94aa92 ("watchdog/hardlockup: define HARDLOCKUP_DETECTOR_ARCH")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Reviewed-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link:

https://msgid.link/20230629124500.1.I55e2f4e7903d686c4484cb23c033c6a9e1a9d4c4@changeid
(cherry picked from commit 6cb44bef35ac11724ef22c5ae4f1bc607e2ef3d8)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I55e2f4e7903d686c4484cb23c033c6a9e1a9d4c4
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673848
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Guenter Roeck <groeck@chromium.org>

M arch/powerpc/platforms/pseries/mobility.c

https://chromium-review.googlesource.com/4673848

Message last modified on May 16, 2018 02:15AM

ah...@google.com <ah...@google.com> May 12, 2018 02:52AM

Reassigned to av...@google.com.

ca...@gmail.com <ca...@gmail.com> #30May 12, 2018 05:31AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 8d51d01ab10615aff5e333eb36ef6e801c342e29
Author: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Date: Fri Jun 23 06:07:17 2023

UPSTREAM: watchdog/hardlockup: fix typo in config HARDLOCKUP_DETECTOR_PREFER_BUDDY

Commit a5fcc2367e22 ("watchdog/hardlockup: make HAVE_NMI_WATCHDOG
sparc64-specific") accidentially introduces a typo in one of the config
dependencies of HARDLOCKUP_DETECTOR_PREFER_BUDDY.

Fix this accidental typo.

Link:

https://lkml.kernel.org/r/20230623040717.8645-1-lukas.bulwahn@gmail.com
Fixes: a5fcc2367e22 ("watchdog/hardlockup: make HAVE_NMI_WATCHDOG sparc64-specific")
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit a8992d8ad7775860594d3d981ef93fc423185fa4)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I38647ad1d3003e5273ad243a9c99b1a4cd2f40cf
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673847
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Guenter Roeck <groeck@chromium.org>

M lib/Kconfig.debug

https://chromium-review.googlesource.com/4673847

Message last modified on May 14, 2018 11:07PM

sh...@gmail.com <sh...@gmail.com> #31May 12, 2018 09:28AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 84755174561f3cb611532e9978ad2e6a403c338c
Author: Douglas Anderson <dianders@chromium.org>
Date: Wed Jun 21 16:48:19 2023

UPSTREAM: powerpc: move arch_trigger_cpumask_backtrace from nmi.h to irq.h

The powerpc architecture was the only one that defined
arch_trigger_cpumask_backtrace() in asm/nmi.h instead of
asm/irq.h. Move it to be consistent.

This fixes compile time errors introduced by commit 7ca8fe94aa92
("watchdog/hardlockup: define HARDLOCKUP_DETECTOR_ARCH"). That commit
caused <asm/nmi.h> to stop being included if the hardlockup detector
wasn't enabled. The specific errors were:
error: implicit declaration of function `nmi_cpu_backtrace'
error: implicit declaration of function `nmi_trigger_cpumask_backtrace'

NOTE: when moving this into irq.h, we also change the guards from just
checking if "CONFIG_NMI_IPI" is defined to also checking if
"CONFIG_PPC_BOOK3S_64" is defined. This matches the code in
arch/powerpc/kernel/stacktrace.c. Previously this worked because
<asm.nmi.h> was included if "CONFIG_HAVE_HARDLOCKUP_DETECTOR_ARCH" was
defined. For powerpc that's only selected if "CONFIG_PPC_BOOK3S_64" is
defined.

[dianders@chromium.org: change the guards to include CONFIG_PPC_BOOK3S_64]
Link:

https://lkml.kernel.org/r/20230622202816.v2.1.Ice67126857506712559078e7de26d32d26e64631@changeid
Link:

https://lkml.kernel.org/r/20230621164809.1.Ice67126857506712559078e7de26d32d26e64631@changeid
Fixes: 7ca8fe94aa92 ("watchdog/hardlockup: define HARDLOCKUP_DETECTOR_ARCH")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reported-by: Michael Ellerman <mpe@ellerman.id.au>
Closes:

https://lore.kernel.org/r/871qi5otdh.fsf@mail.lhotse
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Laurent Dufour <ldufour@linux.ibm.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Tom Rix <trix@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit df8b78e1630fa6cff82fdc33ce04000e3ed065f7)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Ice67126857506712559078e7de26d32d26e64631
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673846
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>

M arch/powerpc/include/asm/irq.h
M arch/powerpc/include/asm/nmi.h

https://chromium-review.googlesource.com/4673846

da...@gmail.com <da...@gmail.com> #32May 12, 2018 01:27PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 5d37636bc9a19edf2cd1bb452aa57ab04f7c0fb8
Author: Petr Mladek <pmladek@suse.com>
Date: Fri Jun 16 17:06:18 2023

UPSTREAM: watchdog/hardlockup: define HARDLOCKUP_DETECTOR_ARCH

The HAVE_ prefix means that the code could be enabled. Add another
variable for HAVE_HARDLOCKUP_DETECTOR_ARCH without this prefix.
It will be set when it should be built. It will make it compatible
with the other hardlockup detectors.

The change allows to clean up dependencies of PPC_WATCHDOG
and HAVE_HARDLOCKUP_DETECTOR_PERF definitions for powerpc.

As a result HAVE_HARDLOCKUP_DETECTOR_PERF has the same dependencies
on arm, x86, powerpc architectures.

Link:

https://lkml.kernel.org/r/20230616150618.6073-7-pmladek@suse.com
Signed-off-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 7ca8fe94aa92d9adcd7dcdf64371fc78eb2da3f9)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Cq-Depend: chromium:4673848
Change-Id: I36072e8e644cd3b94f4c3161010f82a838374a2e
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673845
Reviewed-by: Guenter Roeck <groeck@chromium.org>

M arch/powerpc/Kconfig
M include/linux/nmi.h
M lib/Kconfig.debug

https://chromium-review.googlesource.com/4673845

re...@gmail.com <re...@gmail.com> #33May 12, 2018 02:42PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit c5d08b1efb0c0ad1986b4625a49a2b38c93d3c9b
Author: Petr Mladek <pmladek@suse.com>
Date: Fri Jun 16 17:06:17 2023

UPSTREAM: watchdog/sparc64: define HARDLOCKUP_DETECTOR_SPARC64

The HAVE_ prefix means that the code could be enabled. Add another
variable for HAVE_HARDLOCKUP_DETECTOR_SPARC64 without this prefix.
It will be set when it should be built. It will make it compatible
with the other hardlockup detectors.

Before, it is far from obvious that the SPARC64 variant is actually used:

$> make ARCH=sparc64 defconfig
$> grep HARDLOCKUP_DETECTOR .config
CONFIG_HAVE_HARDLOCKUP_DETECTOR_BUDDY=y
CONFIG_HAVE_HARDLOCKUP_DETECTOR_SPARC64=y

After, it is more clear:

$> make ARCH=sparc64 defconfig
$> grep HARDLOCKUP_DETECTOR .config
CONFIG_HAVE_HARDLOCKUP_DETECTOR_BUDDY=y
CONFIG_HAVE_HARDLOCKUP_DETECTOR_SPARC64=y
CONFIG_HARDLOCKUP_DETECTOR_SPARC64=y

Link:

https://lkml.kernel.org/r/20230616150618.6073-6-pmladek@suse.com
Signed-off-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 47f4cb433923a08d81f1e5c065cb680215109db9)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I4decda0c3c4385c8a8dbe2e687a23b8d0fa8126f
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673844
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>

M arch/sparc/Kconfig.debug
M include/linux/nmi.h
M kernel/watchdog.c
M lib/Kconfig.debug

https://chromium-review.googlesource.com/4673844

ni...@gmail.com <ni...@gmail.com> #34May 12, 2018 08:40PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit f19fa1112fc39c078bc59867e9ad3cf18084903d
Author: Petr Mladek <pmladek@suse.com>
Date: Fri Jun 16 17:06:16 2023

BACKPORT: watchdog/hardlockup: make HAVE_NMI_WATCHDOG sparc64-specific

There are several hardlockup detector implementations and several Kconfig
values which allow selection and build of the preferred one.

CONFIG_HARDLOCKUP_DETECTOR was introduced by the commit 23637d477c1f53acb
("lockup_detector: Introduce CONFIG_HARDLOCKUP_DETECTOR") in v2.6.36.
It was a preparation step for introducing the new generic perf hardlockup
detector.

The existing arch-specific variants did not support the to-be-created
generic build configurations, sysctl interface, etc. This distinction
was made explicit by the commit 4a7863cc2eb5f98 ("x86, nmi_watchdog:
Remove ARCH_HAS_NMI_WATCHDOG and rely on CONFIG_HARDLOCKUP_DETECTOR")
in v2.6.38.

CONFIG_HAVE_NMI_WATCHDOG was introduced by the commit d314d74c695f967e105
("nmi watchdog: do not use cpp symbol in Kconfig") in v3.4-rc1. It replaced
the above mentioned ARCH_HAS_NMI_WATCHDOG. At that time, it was still used
by three architectures, namely blackfin, mn10300, and sparc.

The support for blackfin and mn10300 architectures has been completely
dropped some time ago. And sparc is the only architecture with the historic
NMI watchdog at the moment.

And the old sparc implementation is really special. It is always built on
sparc64. It used to be always enabled until the commit 7a5c8b57cec93196b
("sparc: implement watchdog_nmi_enable and watchdog_nmi_disable") added
in v4.10-rc1.

There are only few locations where the sparc64 NMI watchdog interacts
with the generic hardlockup detectors code:

+ implements arch_touch_nmi_watchdog() which is called from the generic
touch_nmi_watchdog()

+ implements watchdog_hardlockup_enable()/disable() to support
/proc/sys/kernel/nmi_watchdog

+ is always preferred over other generic watchdogs, see
CONFIG_HARDLOCKUP_DETECTOR

+ includes asm/nmi.h into linux/nmi.h because some sparc-specific
functions are needed in sparc-specific code which includes
only linux/nmi.h.

The situation became more complicated after the commit 05a4a95279311c3
("kernel/watchdog: split up config options") and commit 2104180a53698df5
("powerpc/64s: implement arch-specific hardlockup watchdog") in v4.13-rc1.
They introduced HAVE_HARDLOCKUP_DETECTOR_ARCH. It was used for powerpc
specific hardlockup detector. It was compatible with the perf one
regarding the general boot, sysctl, and programming interfaces.

HAVE_HARDLOCKUP_DETECTOR_ARCH was defined as a superset of
HAVE_NMI_WATCHDOG. It made some sense because all arch-specific
detectors had some common requirements, namely:

+ implemented arch_touch_nmi_watchdog()
+ included asm/nmi.h into linux/nmi.h
+ defined the default value for /proc/sys/kernel/nmi_watchdog

But it actually has made things pretty complicated when the generic
buddy hardlockup detector was added. Before the generic perf detector
was newer supported together with an arch-specific one. But the buddy
detector could work on any SMP system. It means that an architecture
could support both the arch-specific and buddy detector.

As a result, there are few tricky dependencies. For example,
CONFIG_HARDLOCKUP_DETECTOR depends on:

((HAVE_HARDLOCKUP_DETECTOR_PERF || HAVE_HARDLOCKUP_DETECTOR_BUDDY) && !HAVE_NMI_WATCHDOG) || HAVE_HARDLOCKUP_DETECTOR_ARCH

The problem is that the very special sparc implementation is defined as:

HAVE_NMI_WATCHDOG && !HAVE_HARDLOCKUP_DETECTOR_ARCH

Another problem is that the meaning of HAVE_NMI_WATCHDOG is far from clear
without reading understanding the history.

Make the logic less tricky and more self-explanatory by making
HAVE_NMI_WATCHDOG specific for the sparc64 implementation. And rename it to
HAVE_HARDLOCKUP_DETECTOR_SPARC64.

Note that HARDLOCKUP_DETECTOR_PREFER_BUDDY, HARDLOCKUP_DETECTOR_PERF,
and HARDLOCKUP_DETECTOR_BUDDY may conflict only with
HAVE_HARDLOCKUP_DETECTOR_ARCH. They depend on HARDLOCKUP_DETECTOR
and it is not longer enabled when HAVE_NMI_WATCHDOG is set.

Link:

https://lkml.kernel.org/r/20230616150618.6073-5-pmladek@suse.com
Signed-off-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit a5fcc2367e223c45c78a882438c2b8e13fe0f580)

Conflicts:
arch/sparc/Kconfig
Trivial context conflict because we don't have commit fcbfe8121a45
("Kconfig: introduce HAS_IOPORT option and select it as
necessary"). It's not totally trivial to pick that so BACKPORT seems
better.

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Cq-Depend: chromium:4673847
Change-Id: I3b19937946bf3c16b8ed82689207fe4ba26e572d
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673843
Reviewed-by: Guenter Roeck <groeck@chromium.org>

M arch/Kconfig
M arch/sparc/Kconfig
M arch/sparc/Kconfig.debug
M include/linux/nmi.h
M kernel/watchdog.c
M lib/Kconfig.debug

https://chromium-review.googlesource.com/4673843

[Deleted User] <[Deleted User]> #35May 12, 2018 09:20PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit d8ff3afc17cb59b119cc814969a197753bbdbce9
Author: Petr Mladek <pmladek@suse.com>
Date: Fri Jun 16 17:06:15 2023

UPSTREAM: watchdog/hardlockup: declare arch_touch_nmi_watchdog() only in linux/nmi.h

arch_touch_nmi_watchdog() needs a different implementation for various
hardlockup detector implementations. And it does nothing when
any hardlockup detector is not built at all.

arch_touch_nmi_watchdog() is declared via linux/nmi.h. And it must be
defined as an empty function when there is no hardlockup detector.
It is done directly in this header file for the perf and buddy detectors.
And it is done in the included asm/linux.h for arch specific detectors.

The reason probably is that the arch specific variants build the code
using another conditions. For example, powerpc64/sparc64 builds the code
when CONFIG_PPC_WATCHDOG is enabled.

Another reason might be that these architectures define more functions
in asm/nmi.h anyway.

However the generic code actually knows when the function will be
implemented. It happens when some full featured or the sparc64-specific
hardlockup detector is built.

In particular, CONFIG_HARDLOCKUP_DETECTOR can be enabled only when
a generic or arch-specific full featured hardlockup detector is available.
The only exception is sparc64 which can be built even when the global
HARDLOCKUP_DETECTOR switch is disabled.

The information about sparc64 is a bit complicated. The hardlockup
detector is built there when CONFIG_HAVE_NMI_WATCHDOG is set and
CONFIG_HAVE_HARDLOCKUP_DETECTOR_ARCH is not set.

People might wonder whether this change really makes things easier.
The motivation is:

+ The current logic in linux/nmi.h is far from obvious.
For example, arch_touch_nmi_watchdog() is defined as {} when
neither CONFIG_HARDLOCKUP_DETECTOR_COUNTS_HRTIMER nor
CONFIG_HAVE_NMI_WATCHDOG is defined.

+ The change synchronizes the checks in lib/Kconfig.debug and
in the generic code.

+ It is a step that will help cleaning HAVE_NMI_WATCHDOG related
checks.

The change should not change the existing behavior.

Link:

https://lkml.kernel.org/r/20230616150618.6073-4-pmladek@suse.com
Signed-off-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 0c68bda69665307bf835b0c433363e5073608c95)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I70a2531ec47a1975867960c6fe81c85a2b9e2f3f
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673842
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>

M arch/powerpc/include/asm/nmi.h
M arch/sparc/include/asm/nmi.h
M include/linux/nmi.h

https://chromium-review.googlesource.com/4673842

hl...@gmail.com <hl...@gmail.com> #36May 12, 2018 10:04PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 654fc04d79f46b1810cdb4d0f66c1d860e4b8010
Author: Petr Mladek <pmladek@suse.com>
Date: Fri Jun 16 17:06:14 2023

UPSTREAM: watchdog/hardlockup: make the config checks more straightforward

There are four possible variants of hardlockup detectors:

+ buddy: available when SMP is set.

+ perf: available when HAVE_HARDLOCKUP_DETECTOR_PERF is set.

+ arch-specific: available when HAVE_HARDLOCKUP_DETECTOR_ARCH is set.

+ sparc64 special variant: available when HAVE_NMI_WATCHDOG is set
and HAVE_HARDLOCKUP_DETECTOR_ARCH is not set.

The check for the sparc64 variant is more complicated because
HAVE_NMI_WATCHDOG is used to #ifdef code used by both arch-specific
and sparc64 specific variant. Therefore it is automatically
selected with HAVE_HARDLOCKUP_DETECTOR_ARCH.

This complexity is partly hidden in HAVE_HARDLOCKUP_DETECTOR_NON_ARCH.
It reduces the size of some checks but it makes them harder to follow.

Finally, the other temporary variable HARDLOCKUP_DETECTOR_NON_ARCH
is used to re-compute HARDLOCKUP_DETECTOR_PERF/BUDDY when the global
HARDLOCKUP_DETECTOR switch is enabled/disabled.

Make the logic more straightforward by the following changes:

+ Better explain the role of HAVE_HARDLOCKUP_DETECTOR_ARCH and
HAVE_NMI_WATCHDOG in comments.

+ Add HAVE_HARDLOCKUP_DETECTOR_BUDDY so that there is separate
HAVE_* for all four hardlockup detector variants.

Use it in the other conditions instead of SMP. It makes it
clear that it is about the buddy detector.

+ Open code HAVE_HARDLOCKUP_DETECTOR_NON_ARCH in HARDLOCKUP_DETECTOR
and HARDLOCKUP_DETECTOR_PREFER_BUDDY. It helps to understand
the conditions between the four hardlockup detector variants.

+ Define the exact conditions when HARDLOCKUP_DETECTOR_PERF/BUDDY
can be enabled. It explains the dependency on the other
hardlockup detector variants.

Also it allows to remove HARDLOCKUP_DETECTOR_NON_ARCH by using "imply".
It triggers re-evaluating HARDLOCKUP_DETECTOR_PERF/BUDDY when
the global HARDLOCKUP_DETECTOR switch is changed.

+ Add dependency on HARDLOCKUP_DETECTOR so that the affected variables
disappear when the hardlockup detectors are disabled.

Another nice side effect is that HARDLOCKUP_DETECTOR_PREFER_BUDDY
value is not preserved when the global switch is disabled.
The user has to make the decision again when it gets re-enabled.

Link:

https://lkml.kernel.org/r/20230616150618.6073-3-pmladek@suse.com
Signed-off-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 1356d0b966e7ed81832af35478b913495cf7792e)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I9060d61fd2eeb85d2c579c39ab4251a8a25d2778
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673841
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>

M arch/Kconfig
M lib/Kconfig.debug

https://chromium-review.googlesource.com/4673841

ma...@gmail.com <ma...@gmail.com> #37May 12, 2018 10:05PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit cae44ebbf2c880980fe934a252725fe4ecc73683
Author: Petr Mladek <pmladek@suse.com>
Date: Fri Jun 16 17:06:13 2023

UPSTREAM: watchdog/hardlockup: sort hardlockup detector related config values a logical way

Patch series "watchdog/hardlockup: Cleanup configuration of hardlockup
detectors", v2.

Clean up watchdog Kconfig after introducing the buddy detector.

This patch (of 6):

There are four possible variants of hardlockup detectors:

+ buddy: available when SMP is set.

+ perf: available when HAVE_HARDLOCKUP_DETECTOR_PERF is set.

+ arch-specific: available when HAVE_HARDLOCKUP_DETECTOR_ARCH is set.

+ sparc64 special variant: available when HAVE_NMI_WATCHDOG is set
and HAVE_HARDLOCKUP_DETECTOR_ARCH is not set.

Only one hardlockup detector can be compiled in. The selection is done
using quite complex dependencies between several CONFIG variables.
The following patches will try to make it more straightforward.

As a first step, reorder the definitions of the various CONFIG variables.
The logical order is:

1. HAVE_* variables define available variants. They are typically
defined in the arch/ config files.

2. HARDLOCKUP_DETECTOR y/n variable defines whether the hardlockup
detector is enabled at all.

3. HARDLOCKUP_DETECTOR_PREFER_BUDDY y/n variable defines whether
the buddy detector should be preferred over the perf one.
Note that the arch specific variants are always preferred when
available.

4. HARDLOCKUP_DETECTOR_PERF/BUDDY variables define whether the given
detector is enabled in the end.

5. HAVE_HARDLOCKUP_DETECTOR_NON_ARCH and HARDLOCKUP_DETECTOR_NON_ARCH
are temporary variables that are going to be removed in
a followup patch.

This is a preparation step for further cleanup. It will change the logic
without shuffling the definitions.

This change temporary breaks the C-like ordering where the variables are
declared or defined before they are used. It is not really needed for
Kconfig. Also the following patches will rework the logic so that
the ordering will be C-like in the end.

The patch just shuffles the definitions. It should not change the existing
behavior.

Link:

https://lkml.kernel.org/r/20230616150618.6073-1-pmladek@suse.com
Link:

https://lkml.kernel.org/r/20230616150618.6073-2-pmladek@suse.com
Signed-off-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 4917a25f83a8dc95eafd0107be87d4340f48d265)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I94afe8404ce86b320470ba554dddf0b7a81648bc
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673840
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Guenter Roeck <groeck@chromium.org>

M lib/Kconfig.debug

https://chromium-review.googlesource.com/4673840

av...@google.com <av...@google.com> #38May 12, 2018 11:39PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 4ab0e1bae15c927f8f119ab50a31bfd6626256af
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 26 18:41:39 2023

UPSTREAM: watchdog/hardlockup: move SMP barriers from common code to buddy code

It's been suggested that since the SMP barriers are only potentially
useful for the buddy hardlockup detector, not the perf hardlockup
detector, that the barriers belong in the buddy code. Let's move them and
add clearer comments about why they're needed.

Link:

https://lkml.kernel.org/r/20230526184139.9.I5ab0a0eeb0bd52fb23f901d298c72fa5c396e22b@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Suggested-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 28168eca3297d68faa8a9433ec93cb6acf06d2f4)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I5ab0a0eeb0bd52fb23f901d298c72fa5c396e22b
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673839
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Tested-by: Douglas Anderson <dianders@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>

M kernel/watchdog.c
M kernel/watchdog_buddy.c

https://chromium-review.googlesource.com/4673839

ca...@gmail.com <ca...@gmail.com> #39May 13, 2018 01:18AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 3a8bd2f79511647673da87b86903a6d146106838
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 26 18:41:38 2023

UPSTREAM: watchdog/buddy: simplify the dependency for HARDLOCKUP_DETECTOR_PREFER_BUDDY

The dependency for HARDLOCKUP_DETECTOR_PREFER_BUDDY was more complicated
than it needed to be. If the "perf" detector is available and we have SMP
then we have a choice, so enable the config based on just those two config
items.

Link:

https://lkml.kernel.org/r/20230526184139.8.I49d5b483336b65b8acb1e5066548a05260caf809@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Suggested-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 7ece48b7b4a22c1b2d59d7ab8ebcbacbfcaa7872)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I49d5b483336b65b8acb1e5066548a05260caf809
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673838
Tested-by: Douglas Anderson <dianders@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>

M lib/Kconfig.debug

https://chromium-review.googlesource.com/4673838

av...@google.com <av...@google.com> #40May 13, 2018 04:49AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 73f191705cb528b05a170910583b0cf13427e39c
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 26 18:41:37 2023

UPSTREAM: watchdog/buddy: don't copy the cpumask in watchdog_next_cpu()

There's no reason to make a copy of the "watchdog_cpus" locally in
watchdog_next_cpu(). Making a copy wouldn't make things any more race
free and we're just reading the value so there's no need for a copy.

Link:

https://lkml.kernel.org/r/20230526184139.7.If466f9a2b50884cbf6a1d8ad05525a2c17069407@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Suggested-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 813efda23934edcad96343fc96727017378c3fe9)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: If466f9a2b50884cbf6a1d8ad05525a2c17069407
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673837
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>

M kernel/watchdog_buddy.c

https://chromium-review.googlesource.com/4673837

be...@gmail.com <be...@gmail.com> #41May 13, 2018 05:17AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit fbfda64bc4713885318d72771f3a6b770537603f
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 26 18:41:36 2023

UPSTREAM: watchdog/buddy: cleanup how watchdog_buddy_check_hardlockup() is called

In the patch ("watchdog/hardlockup: detect hard lockups using secondary
(buddy) CPUs"), we added a call from the common watchdog.c file into the
buddy. That call could be done more cleanly. Specifically:

1. If we move the call into watchdog_hardlockup_kick() then it keeps
watchdog_timer_fn() simpler.
2. We don't need to pass an "unsigned long" to the buddy for the timer
count. In the patch ("watchdog/hardlockup: add a "cpu" param to
watchdog_hardlockup_check()") the count was changed to "atomic_t"
which is backed by an int, so we should match types.

Link:

https://lkml.kernel.org/r/20230526184139.6.I006c7d958a1ea5c4e1e4dc44a25596d9bb5fd3ba@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Suggested-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit d3b62ace0f097f1d863fb6c41df3c61503e4ec9e)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I006c7d958a1ea5c4e1e4dc44a25596d9bb5fd3ba
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673836
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>

M include/linux/nmi.h
M kernel/watchdog.c
M kernel/watchdog_buddy.c

https://chromium-review.googlesource.com/4673836

wa...@gmail.com <wa...@gmail.com> #42May 13, 2018 07:46AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit fa34dc36de09e4f68637d93946f525eabefe4b65
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 26 18:41:35 2023

UPSTREAM: watchdog/hardlockup: remove softlockup comment in touch_nmi_watchdog()

In the patch ("watchdog/hardlockup: add comments to touch_nmi_watchdog()")
we adjusted some comments for touch_nmi_watchdog(). The comment about the
softlockup had a typo and were also felt to be too obvious. Remove it.

Link:

https://lkml.kernel.org/r/20230526184139.5.Ia593afc9eb12082d55ea6681dc2c5a89677f20a8@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Suggested-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 05e7b558766114aa9c3d5d3af188a5c574809661)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Ia593afc9eb12082d55ea6681dc2c5a89677f20a8
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673835
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>

M include/linux/nmi.h

https://chromium-review.googlesource.com/4673835

wa...@gmail.com <wa...@gmail.com> #43May 13, 2018 07:47AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 60307aac1f45f92a9ad3e79e1c000049965a2f81
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 26 18:41:34 2023

UPSTREAM: watchdog/hardlockup: in watchdog_hardlockup_check() use cpumask_copy()

In the patch ("watchdog/hardlockup: add a "cpu" param to
watchdog_hardlockup_check()") we started using a cpumask to keep track of
which CPUs to backtrace. When setting up this cpumask, it's better to use
cpumask_copy() than to just copy the structure directly. Fix this.

Link:

https://lkml.kernel.org/r/20230526184139.4.Iccee2d1ea19114dafb6553a854ea4d8ab2a3f25b@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Suggested-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 7a71d8e650b06833095e7a0d4206585e8585c00f)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Iccee2d1ea19114dafb6553a854ea4d8ab2a3f25b
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673834
Tested-by: Douglas Anderson <dianders@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Guenter Roeck <groeck@chromium.org>

M kernel/watchdog.c

https://chromium-review.googlesource.com/4673834

to...@gmail.com <to...@gmail.com> #44May 13, 2018 08:45AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 477909d775461df94828760f4300898ddd3eca16
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 26 18:41:33 2023

UPSTREAM: watchdog/hardlockup: don't use raw_cpu_ptr() in watchdog_hardlockup_kick()

In the patch ("watchdog/hardlockup: add a "cpu" param to
watchdog_hardlockup_check()") there was no reason to use raw_cpu_ptr().
Using this_cpu_ptr() works fine.

Link:

https://lkml.kernel.org/r/20230526184139.3.I660e103077dcc23bb29aaf2be09cb234e0495b2d@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Suggested-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 2711e4adef4fac2eeaee66e3c22a2f75ee86e7b3)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I660e103077dcc23bb29aaf2be09cb234e0495b2d
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673833
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Commit-Queue: Douglas Anderson <dianders@chromium.org>

M kernel/watchdog.c

https://chromium-review.googlesource.com/4673833

to...@gmail.com <to...@gmail.com> #45May 13, 2018 08:46AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 5b439e2dab042db4a7cad7f619dd0bd45a5f62e2
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 26 18:41:32 2023

UPSTREAM: watchdog/hardlockup: HAVE_NMI_WATCHDOG must implement watchdog_hardlockup_probe()

Right now there is one arch (sparc64) that selects HAVE_NMI_WATCHDOG
without selecting HAVE_HARDLOCKUP_DETECTOR_ARCH. Because of that one
architecture, we have some special case code in the watchdog core to
handle the fact that watchdog_hardlockup_probe() isn't implemented.

Let's implement watchdog_hardlockup_probe() for sparc64 and get rid of the
special case.

As a side effect of doing this, code inspection tells us that we could fix
a minor bug where the system won't properly realize that NMI watchdogs are
disabled. Specifically, on powerpc if CONFIG_PPC_WATCHDOG is turned off
the arch might still select CONFIG_HAVE_HARDLOCKUP_DETECTOR_ARCH which
selects CONFIG_HAVE_NMI_WATCHDOG. Since CONFIG_PPC_WATCHDOG was off then
nothing will override the "weak" watchdog_hardlockup_probe() and we'll
fallback to looking at CONFIG_HAVE_NMI_WATCHDOG.

Link:

https://lkml.kernel.org/r/20230526184139.2.Ic6ebbf307ca0efe91f08ce2c1eb4a037ba6b0700@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Suggested-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 6426e8d1f27417834ea37e75a9ead832d1cf7713)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Ic6ebbf307ca0efe91f08ce2c1eb4a037ba6b0700
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673832
Reviewed-by: Sean Paul <sean@poorly.run>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>

M arch/Kconfig
M arch/sparc/kernel/nmi.c
M kernel/watchdog.c

https://chromium-review.googlesource.com/4673832

ra...@gmail.com <ra...@gmail.com> #46May 13, 2018 09:10AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit e420c01f44cd9de3e7bdedcc44ec72c7a2253882
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 26 18:41:31 2023

UPSTREAM: watchdog/hardlockup: keep kernel.nmi_watchdog sysctl as 0444 if probe fails

Patch series "watchdog: Cleanup / fixes after buddy series v5 reviews".

This patch series attempts to finish resolving the feedback received
from Petr Mladek on the v5 series I posted.

Probably the only thing that wasn't fully as clean as Petr requested was
the Kconfig stuff. I couldn't find a better way to express it without a
more major overhaul. In the very least, I renamed "NON_ARCH" to
"PERF_OR_BUDDY" in the hopes that will make it marginally better.

Nothing in this series is terribly critical and even the bugfixes are
small. However, it does cleanup a few things that were pointed out in
review.

This patch (of 10):

The permissions for the kernel.nmi_watchdog sysctl have always been set at
compile time despite the fact that a watchdog can fail to probe. Let's
fix this and set the permissions based on whether the hardlockup detector
actually probed.

Link:

https://lkml.kernel.org/r/20230527014153.2793931-1-dianders@chromium.org
Link:

https://lkml.kernel.org/r/20230526184139.1.I0d75971cc52a7283f495aac0bd5c3041aadc734e@changeid
Fixes: a994a3147e4c ("watchdog/hardlockup/perf: Implement init time detection of perf")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reported-by: Petr Mladek <pmladek@suse.com>
Closes:

https://lore.kernel.org/r/ZHCn4hNxFpY5-9Ki@alley
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 9ec272c586b07d1abf73438524bd12b1df9c5f9b)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I0d75971cc52a7283f495aac0bd5c3041aadc734e
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673831
Reviewed-by: Sean Paul <sean@poorly.run>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>

M include/linux/nmi.h
M kernel/watchdog.c

https://chromium-review.googlesource.com/4673831

Message last modified on May 13, 2018 09:24AM

fr...@gmail.com <fr...@gmail.com> #47May 13, 2018 09:39AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit b1406028f28961cb93b3ad6039f239748a3c9fa6
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 19 10:18:38 2023

UPSTREAM: watchdog/hardlockup: detect hard lockups using secondary (buddy) CPUs

Implement a hardlockup detector that doesn't doesn't need any extra
arch-specific support code to detect lockups. Instead of using something
arch-specific we will use the buddy system, where each CPU watches out for
another one. Specifically, each CPU will use its softlockup hrtimer to
check that the next CPU is processing hrtimer interrupts by verifying that
a counter is increasing.

NOTE: unlike the other hard lockup detectors, the buddy one can't easily
show what's happening on the CPU that locked up just by doing a simple
backtrace. It relies on some other mechanism in the system to get
information about the locked up CPUs. This could be support for NMI
backtraces like [1], it could be a mechanism for printing the PC of locked
CPUs at panic time like [2] / [3], or it could be something else. Even
though that means we still rely on arch-specific code, this arch-specific
code seems to often be implemented even on architectures that don't have a
hardlockup detector.

This style of hardlockup detector originated in some downstream Android
trees and has been rebased on / carried in ChromeOS trees for quite a long
time for use on arm and arm64 boards. Historically on these boards we've
leveraged mechanism [2] / [3] to get information about hung CPUs, but we
could move to [1].

Although the original motivation for the buddy system was for use on
systems without an arch-specific hardlockup detector, it can still be
useful to use even on systems that _do_ have an arch-specific hardlockup
detector. On x86, for instance, there is a 24-part patch series [4] in
progress switching the arch-specific hard lockup detector from a scarce
perf counter to a less-scarce hardware resource. Potentially the buddy
system could be a simpler alternative to free up the perf counter but
still get hard lockup detection.

Overall, pros (+) and cons (-) of the buddy system compared to an
arch-specific hardlockup detector (which might be implemented using
perf):
+ The buddy system is usable on systems that don't have an
arch-specific hardlockup detector, like arm32 and arm64 (though it's
being worked on for arm64 [5]).
+ The buddy system may free up scarce hardware resources.
+ If a CPU totally goes out to lunch (can't process NMIs) the buddy
system could still detect the problem (though it would be unlikely
to be able to get a stack trace).
+ The buddy system uses the same timer function to pet the hardlockup
detector on the running CPU as it uses to detect hardlockups on
other CPUs. Compared to other hardlockup detectors, this means it
generates fewer interrupts and thus is likely better able to let
CPUs stay idle longer.
- If all CPUs are hard locked up at the same time the buddy system
can't detect it.
- If we don't have SMP we can't use the buddy system.
- The buddy system needs an arch-specific mechanism (possibly NMI
backtrace) to get info about the locked up CPU.

[1]

https://lore.kernel.org/r/20230419225604.21204-1-dianders@chromium.org
[2]

https://issuetracker.google.com/172213129
[3]

https://docs.kernel.org/trace/coresight/coresight-cpu-debug.html
[4]

https://lore.kernel.org/lkml/20230301234753.28582-1-ricardo.neri-calderon@linux.intel.com/
[5]

https://lore.kernel.org/linux-arm-kernel/20220903093415.15850-1-lecopzer.chen@mediatek.com/

Link:

https://lkml.kernel.org/r/20230519101840.v5.14.I6bf789d21d0c3d75d382e7e51a804a7a51315f2c@changeid
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ian Rogers <irogers@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 1f423c905a6b43b493df1b259e6e6267e5624e62)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I6bf789d21d0c3d75d382e7e51a804a7a51315f2c
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673826
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Commit-Queue: Douglas Anderson <dianders@chromium.org>

M include/linux/nmi.h
M kernel/Makefile
M kernel/watchdog.c
A kernel/watchdog_buddy.c
M lib/Kconfig.debug

https://chromium-review.googlesource.com/4673826

[Deleted User] <[Deleted User]> #48May 13, 2018 09:51AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 07937693e8c6553095b4a5d5bdde9d3c334ee5dc
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 19 10:18:37 2023

UPSTREAM: watchdog/hardlockup: have the perf hardlockup use __weak functions more cleanly

The fact that there watchdog_hardlockup_enable(),
watchdog_hardlockup_disable(), and watchdog_hardlockup_probe() are
declared __weak means that the configured hardlockup detector can define
non-weak versions of those functions if it needs to. Instead of doing
this, the perf hardlockup detector hooked itself into the default __weak
implementation, which was a bit awkward. Clean this up.

From comments, it looks as if the original design was done because the
__weak function were expected to implemented by the architecture and not
by the configured hardlockup detector. This got awkward when we tried to
add the buddy lockup detector which was not arch-specific but wanted to
hook into those same functions.

This is not expected to have any functional impact.

Link:

https://lkml.kernel.org/r/20230519101840.v5.13.I847d9ec852449350997ba00401d2462a9cb4302b@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Colin Cross <ccross@android.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Tzung-Bi Shih <tzungbi@chromium.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit d9b3629ade8ebffb0075e311409796a56bac8282)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I847d9ec852449350997ba00401d2462a9cb4302b
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673825
Tested-by: Douglas Anderson <dianders@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Guenter Roeck <groeck@chromium.org>

M include/linux/nmi.h
M kernel/watchdog.c
M kernel/watchdog_perf.c

https://chromium-review.googlesource.com/4673825

ki...@gmail.com <ki...@gmail.com> #49May 13, 2018 10:10AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 1a46e6ec597bd31668c7daf1201616195dc2f57e
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 19 10:18:36 2023

UPSTREAM: watchdog/hardlockup: rename some "NMI watchdog" constants/function

Do a search and replace of:
- NMI_WATCHDOG_ENABLED => WATCHDOG_HARDLOCKUP_ENABLED
- SOFT_WATCHDOG_ENABLED => WATCHDOG_SOFTOCKUP_ENABLED
- watchdog_nmi_ => watchdog_hardlockup_
- nmi_watchdog_available => watchdog_hardlockup_available
- nmi_watchdog_user_enabled => watchdog_hardlockup_user_enabled
- soft_watchdog_user_enabled => watchdog_softlockup_user_enabled
- NMI_WATCHDOG_DEFAULT => WATCHDOG_HARDLOCKUP_DEFAULT

Then update a few comments near where names were changed.

This is specifically to make it less confusing when we want to introduce
the buddy hardlockup detector, which isn't using NMIs. As part of this,
we sanitized a few names for consistency.

[trix@redhat.com: make variables static]
Link:

https://lkml.kernel.org/r/20230525162822.1.I0fb41d138d158c9230573eaa37dc56afa2fb14ee@changeid
Link:

https://lkml.kernel.org/r/20230519101840.v5.12.I91f7277bab4bf8c0cb238732ed92e7ce7bbd71a6@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed-by: Tom Rix <trix@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Colin Cross <ccross@android.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Tzung-Bi Shih <tzungbi@chromium.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit df95d3085caa5b99a60eb033d7ad6c2ff2b43dbf)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I91f7277bab4bf8c0cb238732ed92e7ce7bbd71a6
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673824
Reviewed-by: Sean Paul <sean@poorly.run>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>

M arch/powerpc/include/asm/nmi.h
M arch/powerpc/kernel/watchdog.c
M arch/powerpc/platforms/pseries/mobility.c
M arch/sparc/kernel/nmi.c
M include/linux/nmi.h
M kernel/watchdog.c
M kernel/watchdog_perf.c

https://chromium-review.googlesource.com/4673824

no...@gmail.com <no...@gmail.com> #50May 13, 2018 10:32AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit e24c5ac90a55e751828c0f0bd069c9d0dc5a6117
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 19 10:18:35 2023

UPSTREAM: watchdog/hardlockup: move perf hardlockup watchdog petting to watchdog.c

In preparation for the buddy hardlockup detector, which wants the same
petting logic as the current perf hardlockup detector, move the code to
watchdog.c. While doing this, rename the global variable to match others
nearby. As part of this change we have to change the code to account for
the fact that the CPU we're running on might be different than the one
we're checking.

Currently the code in watchdog.c is guarded by
CONFIG_HARDLOCKUP_DETECTOR_PERF, which makes this change seem silly.
However, a future patch will change this.

Link:

https://lkml.kernel.org/r/20230519101840.v5.11.I00dfd6386ee00da25bf26d140559a41339b53e57@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Colin Cross <ccross@android.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Tzung-Bi Shih <tzungbi@chromium.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit ed92e1ef52224c7c9c15fba559448396b059c2ee)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I00dfd6386ee00da25bf26d140559a41339b53e57
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673823
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>

M include/linux/nmi.h
M kernel/watchdog.c
M kernel/watchdog_perf.c

https://chromium-review.googlesource.com/4673823

gr...@gmail.com <gr...@gmail.com> #51May 13, 2018 10:57AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit c627cf25556bc8a4fbdeb0d6b92f9294988adf94
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 19 10:18:34 2023

UPSTREAM: watchdog/hardlockup: add a "cpu" param to watchdog_hardlockup_check()

In preparation for the buddy hardlockup detector where the CPU checking
for lockup might not be the currently running CPU, add a "cpu" parameter
to watchdog_hardlockup_check().

As part of this change, make hrtimer_interrupts an atomic_t since now the
CPU incrementing the value and the CPU reading the value might be
different. Technially this could also be done with just READ_ONCE and
WRITE_ONCE, but atomic_t feels a little cleaner in this case.

While hrtimer_interrupts is made atomic_t, we change
hrtimer_interrupts_saved from "unsigned long" to "int". The "int" is
needed to match the data type backing atomic_t for hrtimer_interrupts.
Even if this changes us from 64-bits to 32-bits (which I don't think is
true for most compilers), it doesn't really matter. All we ever do is
increment it every few seconds and compare it to an old value so 32-bits
is fine (even 16-bits would be). The "signed" vs "unsigned" also doesn't
matter for simple equality comparisons.

hrtimer_interrupts_saved is _not_ switched to atomic_t nor even accessed
with READ_ONCE / WRITE_ONCE. The hrtimer_interrupts_saved is always
consistently accessed with the same CPU. NOTE: with the upcoming "buddy"
detector there is one special case. When a CPU goes offline/online then
we can change which CPU is the one to consistently access a given instance
of hrtimer_interrupts_saved. We still can't end up with a partially
updated hrtimer_interrupts_saved, however, because we end up petting all
affected CPUs to make sure the new and old CPU can't end up somehow
read/write hrtimer_interrupts_saved at the same time.

Link:

https://lkml.kernel.org/r/20230519101840.v5.10.I3a7d4dd8c23ac30ee0b607d77feb6646b64825c0@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Colin Cross <ccross@android.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Tzung-Bi Shih <tzungbi@chromium.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 77c12fc95980d100fdc49e88a5727c242d0dfedc)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I3a7d4dd8c23ac30ee0b607d77feb6646b64825c0
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673822
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>

M include/linux/nmi.h
M kernel/watchdog.c
M kernel/watchdog_perf.c

https://chromium-review.googlesource.com/4673822

me...@gmail.com <me...@gmail.com> #52May 13, 2018 11:03AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit b828a2620013a42e676dc5ee1d838405384240ef
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 19 10:18:33 2023

UPSTREAM: watchdog/hardlockup: style changes to watchdog_hardlockup_check() / is_hardlockup()

These are tiny style changes:
- Add a blank line before a "return".
- Renames two globals to use the "watchdog_hardlockup" prefix.
- Store processor id in "unsigned int" rather than "int".
- Minor comment rewording.
- Use "else" rather than extra returns since it seemed more symmetric.

Link:

https://lkml.kernel.org/r/20230519101840.v5.9.I818492c326b632560b09f20d2608455ecf9d3650@changeid
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Colin Cross <ccross@android.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Tzung-Bi Shih <tzungbi@chromium.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 1610611aadc2241179e7090ba2f3fd0d763d9932)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I818492c326b632560b09f20d2608455ecf9d3650
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673821
Tested-by: Douglas Anderson <dianders@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>

M kernel/watchdog.c

https://chromium-review.googlesource.com/4673821

na...@matros.org <na...@matros.org> #53May 13, 2018 11:15AM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 12abb46c748583fe636612e02c3c62ac8a342ccf
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri May 19 10:18:32 2023

UPSTREAM: watchdog/hardlockup: move perf hardlockup checking/panic to common watchdog.c

The perf hardlockup detector works by looking at interrupt counts and
seeing if they change from run to run. The interrupt counts are managed
by the common watchdog code via its watchdog_timer_fn().

Currently the API between the perf detector and the common code is a
function: is_hardlockup(). When the hard lockup detector sees that
function return true then it handles printing out debug info and inducing
a panic if necessary.

Let's change the API a little bit in preparation for the buddy hardlockup
detector. The buddy hardlockup detector wants to print nearly the same
debug info and have nearly the same panic behavior. That means we want to
move all that code to the common file. For now, the code in the common
file will only be there if the perf hardlockup detector is enabled, but
eventually it will be selected by a common config.

Right now, this _just_ moves the code from the perf detector file to the
common file and changes the names. It doesn't make the changes that the
buddy hardlockup detector will need and doesn't do any style cleanups. A
future patch will do cleanup to make it more obvious what changed.

With the above, we no longer have any callers of is_hardlockup() outside
of the "watchdog.c" file, so we can remove it from the header, make it
static, and move it to the same "#ifdef" block as our new
watchdog_hardlockup_check(). While doing this, it can be noted that even
if no hardlockup detectors were configured the existing code used to still
have the code for counting/checking "hrtimer_interrupts" even if the perf
hardlockup detector wasn't configured. We didn't need to do that, so move
all the "hrtimer_interrupts" counting to only be there if the perf
hardlockup detector is configured as well.

This change is expected to be a no-op.

Link:

https://lkml.kernel.org/r/20230519101840.v5.8.Id4133d3183e798122dc3b6205e7852601f289071@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Colin Cross <ccross@android.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: Tzung-Bi Shih <tzungbi@chromium.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 81972551df9d168a8183b786ff4de06008469c2e)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Id4133d3183e798122dc3b6205e7852601f289071
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4673520
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>

M include/linux/nmi.h
M kernel/watchdog.c
M kernel/watchdog_perf.c

https://chromium-review.googlesource.com/4673520

hm...@gmail.com <hm...@gmail.com> #54May 13, 2018 11:24AM

I'm going to call this done. Woohoo! Special thanks to Guenter for giving the +2 and suffering the email spam. Also (of course) happy for all the help that folks upstream gave.

If someone has a burning desire to have the upstream version of the buddy detector pushed to an older kernel, let me know. I think our old downstream one ought to be fine, though. The upstream one might give slightly nicer output, but I don't think it's important enough to backport a ton of patches for.

ni...@eekdomains.com <ni...@eekdomains.com> #55May 13, 2018 12:38PM

Project: chromiumos/overlays/chromiumos-overlay
Branch: main

commit 80da8860a3c81aa40fde97018176474458bdaeee
Author: Douglas Anderson <dianders@chromium.org>
Date: Wed Apr 19 13:09:47 2023

qualcomm+mediatek_defconfig: Turn on the buddy hardlockup detector

Now that the buddy lockup detector is upstream, we can enable it in
our fallback config.

In the qualcomm defconfig, this also moves a few configs to the
location that they're when you do `savedefconfig` with the latest
upstream kernel.

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Ia16de1737106471339f0b160912130fb95075709
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/4722502
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>

M eclass/cros-kernel/mediatek_defconfig
M eclass/cros-kernel/qualcomm_defconfig

https://chromium-review.googlesource.com/4722502

hm...@gmail.com <hm...@gmail.com> #56May 13, 2018 12:47PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 5afbac24cd69b5b57cbab8e0fe856a04adc12ba7
Author: Linux Patches Robot <linux-patches-robot@chromeos-missing-patches.google.com.iam.gserviceaccount.com>
Date: Wed Aug 30 01:40:35 2023

UPSTREAM: watchdog/hardlockup: avoid large stack frames in watchdog_hardlockup_check()

After commit 77c12fc95980 ("watchdog/hardlockup: add a "cpu" param to
watchdog_hardlockup_check()") we started storing a `struct cpumask` on the
stack in watchdog_hardlockup_check(). On systems with CONFIG_NR_CPUS set
to 8192 this takes up 1K on the stack. That triggers warnings with
`CONFIG_FRAME_WARN` set to 1024.

We'll use the new trigger_allbutcpu_cpu_backtrace() to avoid needing to
use a CPU mask at all.

Link:

https://lkml.kernel.org/r/20230804065935.v4.2.I501ab68cb926ee33a7c87e063d207abf09b9943c@changeid
Fixes: 77c12fc95980 ("watchdog/hardlockup: add a "cpu" param to watchdog_hardlockup_check()")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reported-by: kernel test robot <lkp@intel.com>
Closes:

https://lore.kernel.org/r/202307310955.pLZDhpnl-lkp@intel.com
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 1f38c86bb29f4548b8df01b47a313518e6ed2dfe)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Signed-off-by: Linux Patches Robot <linux-patches-robot@chromeos-missing-patches.google.com.iam.gserviceaccount.com>
Change-Id: Id0da74a59a4537067c2dadcb8e758b8b8751fcda
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4825305
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Commit-Queue: Guenter Roeck <groeck@chromium.org>

M kernel/watchdog.c

https://chromium-review.googlesource.com/4825305

go...@gmail.com <go...@gmail.com> #57May 13, 2018 12:53PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit eca0384cbe6a8e771d7915818d71031831a13d83
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri Aug 04 07:00:42 2023

UPSTREAM: nmi_backtrace: allow excluding an arbitrary CPU

The APIs that allow backtracing across CPUs have always had a way to
exclude the current CPU. This convenience means callers didn't need to
find a place to allocate a CPU mask just to handle the common case.

Let's extend the API to take a CPU ID to exclude instead of just a
boolean. This isn't any more complex for the API to handle and allows the
hardlockup detector to exclude a different CPU (the one it already did a
trace for) without needing to find space for a CPU mask.

Arguably, this new API also encourages safer behavior. Specifically if
the caller wants to avoid tracing the current CPU (maybe because they
already traced the current CPU) this makes it more obvious to the caller
that they need to make sure that the current CPU ID can't change.

[akpm@linux-foundation.org: fix trigger_allbutcpu_cpu_backtrace() stub]
Link:

https://lkml.kernel.org/r/20230804065935.v4.1.Ia35521b91fc781368945161d7b28538f9996c182@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: kernel test robot <lkp@intel.com>
Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 8d539b84f1e3478436f978ceaf55a0b6cab497b5)

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Ia35521b91fc781368945161d7b28538f9996c182
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4827102
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Commit-Queue: Guenter Roeck <groeck@chromium.org>

M arch/arm/include/asm/irq.h
M arch/arm/kernel/smp.c
M arch/loongarch/include/asm/irq.h
M arch/loongarch/kernel/process.c
M arch/mips/include/asm/irq.h
M arch/mips/kernel/process.c
M arch/powerpc/include/asm/irq.h
M arch/powerpc/kernel/stacktrace.c
M arch/powerpc/kernel/watchdog.c
M arch/sparc/include/asm/irq_64.h
M arch/sparc/kernel/process_64.c
M arch/x86/include/asm/irq.h
M arch/x86/kernel/apic/hw_nmi.c
M include/linux/nmi.h
M kernel/watchdog.c
M lib/nmi_backtrace.c

https://chromium-review.googlesource.com/4827102

rb...@gmail.com <rb...@gmail.com> #58May 13, 2018 01:39PM

Project: chromiumos/third_party/kernel
Branch: chromeos-6.1

commit 4e357380c85696f5cf2ab2153c28ba6b9c7482e4
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon Sep 18 14:24:39 2023

CHROMIUM: config: Switch x86 to the buddy hardlockup detector

As talked about in commit 1f423c905a6b ("watchdog/hardlockup: detect
hard lockups using secondary (buddy) CPUs"), the buddy hardlockup
detector has some advantages over the traditional perf-based
hardlockup detector. The most notable advantage should be slightly
fewer wakeup events since the same interrupt is now used to update our
counter as is used to check our buddy's counter.

Since all Chromebooks have at least two cores, the main downside of
the buddy lockup detector is eliminated so let's switch over to it.

BUG=b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: I064df1d0d470aaac549ca79b7e819d2e92c8f2d3
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4875498
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Commit-Queue: Guenter Roeck <groeck@chromium.org>

M chromeos/config/chromeos/x86_64/common.config

https://chromium-review.googlesource.com/4875498

im...@gmail.com <im...@gmail.com> #59May 13, 2018 02:36PM

Project: chromiumos/third_party/kernel
Branch: chromeos-5.15

commit 3350a3f5b75b51f3beeeb492319057acc736dc38
Author: Douglas Anderson <dianders@chromium.org>
Date: Thu Nov 02 13:45:54 2023

FIXUP: CHROMIUM: hardlockup: detect hard lockups without NMIs using secondary cpus (match upstream format)

The format for the output for the buddy lockup detector changed a bit
(for the better) when it landed upstream. The format that landed
upstream also matches the format of the "perf" hardlockup
detector. Though there's not a huge advantage of backporting all of
the cleanups so we can get the exact upstream code, let's at least get
the format changes in our downstream version.

NOTE: this version uses trigger_cpumask_backtrace(), which is more
like how upstream worked prior to commit 1f38c86bb29f
("watchdog/hardlockup: avoid large stack frames in
watchdog_hardlockup_check()"). Doing it the upstream worked after that
commit also needs a bunch of extra backporting and the output here is
the same. In our case we use a static global to store the cpumask (to
avoid any large stackframe warnings) and that's not wasting too much
globals space because we never build kernels with a large
CONFIG_NR_CPUS.

DO NOT PICK THIS PATCH TO NEWER KERNELS DURING UPREVS. Newer kernels
will use the upstream code directly.

BUG=b:172213097
TEST=Format looks better

Change-Id: Ie6565d0b8f020e1b95bba4eb498ee5d45e533042
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/5002610
Reviewed-by: Guenter Roeck <groeck@chromium.org>

M kernel/watchdog_buddy_cpu.c

https://chromium-review.googlesource.com/5002610

co...@gmail.com <co...@gmail.com> #60May 13, 2018 02:49PM

Project: chromiumos/third_party/kernel
Branch: chromeos-5.10

commit 1721529828fcbef5dcf6b8b0fe774516390016a2
Author: Douglas Anderson <dianders@chromium.org>
Date: Thu Nov 02 13:45:54 2023

FIXUP: CHROMIUM: hardlockup: detect hard lockups without NMIs using secondary cpus (match upstream format)

The format for the output for the buddy lockup detector changed a bit
(for the better) when it landed upstream. The format that landed
upstream also matches the format of the "perf" hardlockup
detector. Though there's not a huge advantage of backporting all of
the cleanups so we can get the exact upstream code, let's at least get
the format changes in our downstream version.

NOTE: this version uses trigger_cpumask_backtrace(), which is more
like how upstream worked prior to commit 1f38c86bb29f
("watchdog/hardlockup: avoid large stack frames in
watchdog_hardlockup_check()"). Doing it the upstream worked after that
commit also needs a bunch of extra backporting and the output here is
the same. In our case we use a static global to store the cpumask (to
avoid any large stackframe warnings) and that's not wasting too much
globals space because we never build kernels with a large
CONFIG_NR_CPUS.

DO NOT PICK THIS PATCH TO NEWER KERNELS DURING UPREVS. Newer kernels
will use the upstream code directly.

BUG=b:172213097
TEST=Format looks better

Change-Id: Ie6565d0b8f020e1b95bba4eb498ee5d45e533042
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/5002610
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/5003362

M kernel/watchdog_buddy_cpu.c

https://chromium-review.googlesource.com/5003362

t....@gmail.com <t....@gmail.com> #61May 13, 2018 02:49PM

Project: chromiumos/third_party/kernel
Branch: chromeos-5.10

commit 2402f349c8523afddb44cf74f826c3f2a382731f
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon Apr 17 17:25:44 2023

FIXUP: CHROMIUM: hardlockup: detect hard lockups without NMIs using secondary cpus (all backtrace)

The buddy hard lockup detector should try backtracing on all
CPUs. Right now it doesn't. Copy that bit of logic from the normal
hardlockup detector.

NOTE: On arm64 (the current user of the buddy detector), this won't
(yet) do anything. Soon, hopefully.

UPSTREAM-TASK=b:172213097
BUG=b:278598383, b:278594093, b:197061987, b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Id225408348d8a45e68080d08139bc6d9e170000a
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4438220
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/5003361
Reviewed-by: Guenter Roeck <groeck@chromium.org>

M kernel/watchdog_buddy_cpu.c

https://chromium-review.googlesource.com/5003361

da...@gmail.com <da...@gmail.com> #62May 13, 2018 02:54PM

Project: chromiumos/third_party/kernel
Branch: chromeos-5.4

commit f5c5953de0fe06d1f6a2787f5470fa5abe6ffb02
Author: Douglas Anderson <dianders@chromium.org>
Date: Thu Nov 02 13:45:54 2023

FIXUP: CHROMIUM: hardlockup: detect hard lockups without NMIs using secondary cpus (match upstream format)

The format for the output for the buddy lockup detector changed a bit
(for the better) when it landed upstream. The format that landed
upstream also matches the format of the "perf" hardlockup
detector. Though there's not a huge advantage of backporting all of
the cleanups so we can get the exact upstream code, let's at least get
the format changes in our downstream version.

NOTE: this version uses trigger_cpumask_backtrace(), which is more
like how upstream worked prior to commit 1f38c86bb29f
("watchdog/hardlockup: avoid large stack frames in
watchdog_hardlockup_check()"). Doing it the upstream worked after that
commit also needs a bunch of extra backporting and the output here is
the same. In our case we use a static global to store the cpumask (to
avoid any large stackframe warnings) and that's not wasting too much
globals space because we never build kernels with a large
CONFIG_NR_CPUS.

DO NOT PICK THIS PATCH TO NEWER KERNELS DURING UPREVS. Newer kernels
will use the upstream code directly.

BUG=b:172213097
TEST=Format looks better

Change-Id: Ie6565d0b8f020e1b95bba4eb498ee5d45e533042
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/5002610
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/5001979

M kernel/watchdog_buddy_cpu.c

https://chromium-review.googlesource.com/5001979

[Deleted User] <[Deleted User]> #63May 13, 2018 03:07PM

Project: chromiumos/third_party/kernel
Branch: chromeos-5.4

commit 28e15645f7f4a7be395d1ea547849792ea4a1339
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon Apr 17 17:25:44 2023

FIXUP: CHROMIUM: hardlockup: detect hard lockups without NMIs using secondary cpus (all backtrace)

The buddy hard lockup detector should try backtracing on all
CPUs. Right now it doesn't. Copy that bit of logic from the normal
hardlockup detector.

NOTE: On arm64 (the current user of the buddy detector), this won't
(yet) do anything. Soon, hopefully.

UPSTREAM-TASK=b:172213097
BUG=b:278598383, b:278594093, b:197061987, b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Id225408348d8a45e68080d08139bc6d9e170000a
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4438220
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/5001978
Reviewed-by: Guenter Roeck <groeck@chromium.org>

M kernel/watchdog_buddy_cpu.c

https://chromium-review.googlesource.com/5001978

al...@gmail.com <al...@gmail.com> #64May 13, 2018 03:23PM

Project: chromiumos/third_party/kernel
Branch: chromeos-5.4

commit 1b415cbdc4d2258cb37610c4a66039ebffdec9f6
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon Apr 17 17:15:31 2023

FIXUP: CHROMIUM: hardlockup: detect hard lockups without NMIs using secondary cpus (sysctl)

The CHROMIUM patch accidentally didn't expose the hardlockup panic
sysctls based on the right config. Fix it.

NOTE: Only one of these two sysctls actually does something with the
current buddy detector. You can turn on/off the hard lockup detector
but it doesn't (yet) support tracing other CPUs.

UPSTREAM-TASK=b:172213097
BUG=b:278598383, b:278594093, b:197061987, b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Id88d1fb603308e7210c30e42bb6e4e6a4be65a0c
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4438219
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
(cherry picked from commit 71986679fe52d94286f9051f09b958ecf582c7fc)
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/5008220
Commit-Queue: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>

M kernel/sysctl.c

https://chromium-review.googlesource.com/5008220

as...@gmail.com <as...@gmail.com> #65May 13, 2018 04:00PM

Project: chromiumos/third_party/kernel
Branch: chromeos-5.10

commit 9c9acd59e87ef7423808dfc5b4109732a05f78db
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon Apr 17 17:15:31 2023

FIXUP: CHROMIUM: hardlockup: detect hard lockups without NMIs using secondary cpus (sysctl)

The CHROMIUM patch accidentally didn't expose the hardlockup panic
sysctls based on the right config. Fix it.

NOTE: Only one of these two sysctls actually does something with the
current buddy detector. You can turn on/off the hard lockup detector
but it doesn't (yet) support tracing other CPUs.

UPSTREAM-TASK=b:172213097
BUG=b:278598383, b:278594093, b:197061987, b:172213097
TEST=echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT

Change-Id: Id88d1fb603308e7210c30e42bb6e4e6a4be65a0c
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/5008219
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Commit-Queue: Guenter Roeck <groeck@chromium.org>

M kernel/sysctl.c

https://chromium-review.googlesource.com/5008219

[Deleted User] <[Deleted User]> #66May 13, 2018 04:13PM

This is not good at all xD we've a maps based app XD

ma...@gmail.com <ma...@gmail.com> #67May 13, 2018 04:44PM

I'm reporting also a massive battery drain on my device..(p9 lite) after this google play services update. Other users can confirm this?

dj...@gmail.com <dj...@gmail.com> #68May 13, 2018 05:23PM

Haven't noticed a battery drain on my P9 Lite. The "Google Services are updating" error has affected me since Thursday in Uber and Taxify, after I dismissed a notification saying 7 apps had been updated. Uninstalling and reinstalling updates has worked for me thus far. I'll avoid rebooting until this is resolved. Grateful to whomever explained how to uninstall the updates (I'm not a developer).

mi...@gmail.com <mi...@gmail.com> #69May 13, 2018 07:00PM

P10 mate pro. Smart issue for taxi Uber and what's app. Sad times.

on...@gmail.com <on...@gmail.com> #70May 13, 2018 07:24PM

Yes this is a big problem. Can't use apps such as uber and citymapper properly The map function within them does not work so it is very frustrating.

ub...@gmail.com <ub...@gmail.com> #71May 13, 2018 07:45PM

Any news? Same issue with Huawei Y7

vi...@apfa89.org <vi...@apfa89.org> #72May 13, 2018 08:00PM

Same issue with Huwei P9

bu...@gmail.com <bu...@gmail.com> #73May 13, 2018 08:03PM

Same issues Huawei P20. Tomtom Sports etc not working. Just says Google Play Services updating.... Then, when you go to that, it only gives the option 'Deactivate'.
When will this be fixed???

gu...@gmail.com <gu...@gmail.com> #74May 13, 2018 08:12PM

Same issue Huawei Mate 8 (android 7, Google play service Version: 12.6.73).Wifi sometime is locked with no wifi network during the scanning...Battery consumption very fast. Every attempt of reboot hanging. Battery detail of app consumption hanging. All in this 3 days...

bi...@gmail.com <bi...@gmail.com> #75May 13, 2018 08:16PM

All mapping apps have stopped working on my Honor 9, Android 8. Big pain in the backside, please fix asap!!

ma...@gmail.com <ma...@gmail.com> #76May 13, 2018 08:20PM

yes, i'm also experiencing this strange wifi lock, after trying to scan for
network the touchscreen became unresponsive. I need to hard reboot the
device.

2018-05-13 22:12 GMT+02:00 <buganizer-system@google.com>:

--
Luca Dal Ben

*Le informazioni contenute in questo messaggio di posta elettronica sono
riservate e confidenziali e ne e' vietata la diffusione in qualunque modo
eseguita. Qualora Lei non fosse la persona a cui il presente messaggio e'
destinato, La invitiamo gentilmente ad eliminarlo dopo averne dato
tempestiva comunicazione al mittente e a non utilizzare in alcun caso il
suo contenuto. Qualsivoglia utilizzo non autorizzato di questo messaggio e
dei suoi eventuali allegati espone il responsabile alle relative
conseguenze civili e penali*

ar...@gmail.com <ar...@gmail.com> #77May 13, 2018 08:38PM

problem with strava and record activity, huawei mate 9 (android 8), problem since update to google play services version 12.6.73 please fix this asap

Message last modified on May 13, 2018 08:39PM

du...@gmail.com <du...@gmail.com> #78May 13, 2018 08:55PM

same issue here with maps not loading on Huawei p8 lite

u4...@gmail.com <u4...@gmail.com> #79May 13, 2018 09:14PM

Same here with my Huawei P20 Android 8.1.0 with GPS 12.6.73 and all apps using maps...

sa...@gmail.com <sa...@gmail.com> #80May 13, 2018 09:30PM

Same here with my Huawei Mate 9.

ni...@gmail.com <ni...@gmail.com> #81May 13, 2018 09:33PM

I can also confirm these previously described problems are happening on my phone as well (Huawei P10 Lite, Android 7.0, Google Play Services: 12.6.73)

- Apps not able to show maps ("Google Play Services are updating")
- Some apps crashing right away (won't open at all)
- Wifi lock. My Wifi got stuck on at one point, wasn't able to turn it off. Even though it actually didn't work at all during that time, my phone still showed the Wifi icon as blue, as it being on.
- Greater battery drainage, phone seems to heat up as well
- Phone randomly turns off and back on

To me, this seems pretty serious. I already factory resetted my phone, didn't work. Hoping to hear news in the upcoming hours.

da...@gmail.com <da...@gmail.com> #82May 13, 2018 09:38PM

Me too. P9, issues with maps, strava, bt app.

st...@googlemail.com <st...@googlemail.com> #83May 13, 2018 10:13PM

Yep, same issue. P8

no...@hotmail.com <no...@hotmail.com> #84May 13, 2018 10:16PM

Me too.Huawei P9

lo...@gmail.com <lo...@gmail.com> #85May 13, 2018 10:32PM

Huawei P9 plus , I get "Google Play Services are updating"

Please fix rthis. It's leaving my fitness apps next to useless on the phone.

kh...@hotmail.com <kh...@hotmail.com> #86May 13, 2018 10:50PM

Huawei P10, all map related services (Strava, Trail Forks) and LDS Gospel Library are failing to load application data or the app crashes all together with no error.
If I manually clear all Google Place Services data it works for a period of time but stops working again sometimes 5 minutes sometimes 30.

Message last modified on May 13, 2018 10:51PM

ga...@gmail.com <ga...@gmail.com> #87May 14, 2018 12:00AM

Same issue on Honor 8!

nk...@gmail.com <nk...@gmail.com> #88May 14, 2018 01:10AM

Same issue on P20 Pro.

co...@coyoter.com <co...@coyoter.com> #89May 14, 2018 01:14AM

Same here P20 Pro.

co...@gmail.com <co...@gmail.com> #90May 14, 2018 01:20AM

I have fixed my problem by the following suggestions, it seems that the new Google Play Services was not completely updated last time, it is required to disable the services and stop it and do the upgrade, then everything is normal.

https://productforums.google.com/forum/?utm_medium=email&utm_source=first_post_notification_button#!topic/play/_UovKVGcVX8

Hope this work for you guys.

ly...@gmail.com <ly...@gmail.com> #91May 14, 2018 02:31AM

The fix in #90 is temporary at best; I have done it on my Huawei P9 Lite and everything was fine yesterday, but the same issue popped up on my phone this morning. This severely reduces usability, I hope there is a fix soon.

Message last modified on May 14, 2018 02:32AM

zk...@gmail.com <zk...@gmail.com> #92May 14, 2018 02:56AM

The temporary fix is to uninstall updates on Google Play Services to restore to factory settings. All of my clients who are using Huawei devices is affected by this bug. Please solved it as soon as possible.

li...@gmail.com <li...@gmail.com> #93May 14, 2018 03:00AM

my Huawei Nova has this issue for couple of days, please somebody know how to fixt it?

I tried the #90, but I couldnot find the "personal" under my device's "setting", Big sigh

Message last modified on May 14, 2018 03:01AM

ch...@gmail.com <ch...@gmail.com> #94May 14, 2018 03:36AM

Same issue on Huawei P20 Pro. Uber and Street View are the apps affected at the moment, but Google Maps work fine.

co...@gmail.com <co...@gmail.com> #95May 14, 2018 03:49AM

Huawei P20 Pro user here, cannot use Uber, "Google Play services are updating" message shown and that is all, no map.

kl...@gmail.com <kl...@gmail.com> #96May 14, 2018 04:12AM

Same issue on my Huawei nova 2s. Not able to use Uber or Google Fit. Saavn app is also misbehaving. I suspect it is due to this issue.

sa...@gmail.com <sa...@gmail.com> #97May 14, 2018 04:16AM

On Huawei Honor 7 Lite I cannot use GPS mocking apps for development purposes with the message "Google Play services are updating".

ku...@gmail.com <ku...@gmail.com> #98May 14, 2018 04:20AM

Huawei p20 pro, I just bought this and having difficulties using map related services on any other app.. Can't use booking. Com, uber, food panda nothing...

Shows Google play services are updating! Please help its frustrating when most of apps don't work when needed.

co...@gmail.com <co...@gmail.com> #99May 14, 2018 04:27AM

FWIW, Huawei's P20 Pro get's officially "released" on the 18th of May in Australia (although it is already available from certain stores), meaning there will be a whole new market of users with this issue, might want to have someone put this a bit higher on their priority list.

as...@google.com <as...@google.com> #100May 14, 2018 04:36AM

Thank you for the bug reports. Our engineering team has taken a look at the reports and have a few hypotheses about the root cause. They are working on the best resolution for this issue. We will update you again once we have new information.

ah...@gmail.com <ah...@gmail.com> #101May 14, 2018 05:14AM

Huawei P20, i m facing same issue. I was late to a meeting as careem uber was giving this error.

Screenshot_20180514-081333.jpg

42 KB

https://www.youtube.com/watch?v=VgMtZnyem5Y&app=desktop)

do...@gmail.com <do...@gmail.com> #102May 14, 2018 05:41AM

Huawei Mate SE also affected - didn't see anyone reporting issues on this device in the thread. Began after system update to BND-L34 8.0.0.330(C567) today. If you guys on the Google side would benefit from logs or bug reports at this point, please advise how I should go providing them.

ta...@gmail.com <ta...@gmail.com> #103May 14, 2018 05:56AM

Huawei Honor 6

Apps affected

Scoop
Uber
Lyft

Please fix asap!

ro...@gmail.com <ro...@gmail.com> #104May 14, 2018 05:58AM

I have the same issue with my Huawei mate 9.

hj...@gmail.com <hj...@gmail.com> #105May 14, 2018 06:31AM

Same issue HW P20 Pro. All apps using Google Maps affected.

th...@gmail.com <th...@gmail.com> #106May 14, 2018 06:35AM

Same.. all the apps that needs to use Google maps are affect with my HW mate 9

zh...@gmail.com <zh...@gmail.com> #107May 14, 2018 06:43AM

Same with my Huawei P20pro . All apps that require Google maps and BT sports

pr...@libero.it <pr...@libero.it> #108May 14, 2018 06:47AM

Same issue HW P9 lite. All apps using Google Maps affected

tv...@gmail.com <tv...@gmail.com> #109May 14, 2018 06:48AM

Honor 8
Whim
Flightradar24

te...@gmail.com <te...@gmail.com> #110May 14, 2018 06:58AM

guys.. has been fixed with a new version of play services!
I hope does not happen again!

sv...@gmail.com <sv...@gmail.com> #111May 14, 2018 07:17AM

Same issue with Huawei p10. Apps with maps in it don't work such as Nike run app, public transport app

in...@employroll.com <in...@employroll.com> #112May 14, 2018 07:25AM

Same issue with Honnor 7X Mobile Phone. please provide me soluttion.

ci...@gmail.com <ci...@gmail.com> #113May 14, 2018 07:27AM

Same issue with Huawei P10

am...@gmail.com <am...@gmail.com> #114May 14, 2018 07:29AM

How do I fix this. I have a p20

gr...@gmail.com <gr...@gmail.com> #115May 14, 2018 07:29AM

Same issue with Huawei P9 Lite 2017 (PRA-LX1). Affects all apps using maps (uber or even messenger, whatsapp etc when trying to send location)

sa...@gmail.com <sa...@gmail.com> #116May 14, 2018 07:31AM

Same Issues with Huawei 10 lite what is the solution

g....@gmail.com <g....@gmail.com> #117May 14, 2018 07:44AM

Same Issues with Huawei P8 lite 2017 what is the solution

dj...@gmail.com <dj...@gmail.com> #118May 14, 2018 07:45AM

The temporary fix I found for my Huawei P9 Lite was to uninstall and reinstall updates to Google Play Services as follows:

- Go to Settings > Apps > More (the button with three vertical dots) > Show System Processes
Now you can find "Google Play services" in the list of Apps. Select it
- In the top right corner, press the three vertical dots > Uninstall updates
Now I was able to run Uber and other map-reliant apps, but certain apps wouldn't run until I reinstalled the updates. Reinstalling them did not bring back the error, though I've read that it'll re-emerge in a day or two or after a reboot. I did it on Saturday and it hasn't re-emerged yet.

Message last modified on May 14, 2018 07:49AM

al...@gmail.com <al...@gmail.com> #119May 14, 2018 07:48AM

Same issue here with Huawei P8 Lite 2017 (PRA-LX1), version Android version 7.0.0. Also when i have this error the AdMob Ads don't load correctly (neither in my app, and in all other apps that have admob ads)

ka...@gmail.com <ka...@gmail.com> #120May 14, 2018 08:01AM

Same issue with Huawei P10 with Android 8.0.

ti...@gmail.com <ti...@gmail.com> #121May 14, 2018 08:11AM

Same issue with Huawei P20 lite with Android 8.0 (ANE-LX1 8.0.0.104).
Cleaned GooglePlayServices data and it seamed to work for now (

Message last modified on May 14, 2018 08:52AM

so...@gmail.com <so...@gmail.com> #122May 14, 2018 08:15AM

same problem with Huawei P8 lite 2017

ba...@gmail.com <ba...@gmail.com> #123May 14, 2018 08:30AM

same problem with Huawei p9 lite

di...@gmail.com <di...@gmail.com> #124May 14, 2018 08:39AM

Same issue with Huawei Honor 9. :-(

kh...@gmail.com <kh...@gmail.com> #125May 14, 2018 08:40AM

I'm having this same issue on UBER app. only, but Google Maps is working fine. I'm using Huawei Mate Lite, and this issue apeared only after upgrading to Oreo!!

ha...@gmail.com <ha...@gmail.com> #126May 14, 2018 08:43AM

Same problem Honor 9.

[Deleted User] <[Deleted User]> #127May 14, 2018 08:46AM

Same issue with P20 EML-L29. See attached logs

gcm_crash_chimera_p20.rtf

29 KB

vo...@gmail.com <vo...@gmail.com> #128May 14, 2018 08:49AM

Having the same issue with all apps using maps on Huawei P9. Maps itself
is working fine.

On Mon, 14 May 2018, 10:30 , <buganizer-system@google.com> wrote:

ja...@gmail.com <ja...@gmail.com> #129May 14, 2018 08:50AM

Same problem here with Huawei P8 lite. Whoosh app.

ar...@gmail.com <ar...@gmail.com> #130May 14, 2018 08:55AM

I am facing the same issue. My phone is huawei.
I cannot use uper and careem any more.

dh...@gmail.com <dh...@gmail.com> #131May 14, 2018 08:59AM

Hi ,
Same problem here with Huawei honor 7x with quick ride app.

ah...@gmail.com <ah...@gmail.com> #132May 14, 2018 09:02AM

Sharing location on Whatsapp is also not working.

mt...@gmail.com <mt...@gmail.com> #133May 14, 2018 09:04AM

Same here with my P9 lite. I cannot use my Tractive GPS App

mo...@gmail.com <mo...@gmail.com> #134May 14, 2018 09:07AM

Hey folks,
Same issue here with all apps using Google maps.
"Google play services are updating" is the most frequent statement in my life over the past few days.

I'm using a Huawei Mate8.

st...@gmail.com <st...@gmail.com> #135May 14, 2018 09:20AM

Huawei mate 9 here, same issue. I need my apps that use maps. Hurry on Google! Fix it please!

ha...@gmail.com <ha...@gmail.com> #136May 14, 2018 09:26AM

Same problem with P10 lite

sc...@gmail.com <sc...@gmail.com> #137May 14, 2018 09:28AM

Same issue here with me, Huawei P10 Plus, effects:-

Uber
Entertainer

Please help.

Screenshot_20180514-112745.jpg

316 KB

tc...@google.com <tc...@google.com> #138May 14, 2018 09:29AM

+1
Same with P8 Lite

Message last modified on May 14, 2018 09:29AM

vg...@gmail.com <vg...@gmail.com> #139May 14, 2018 09:37AM

Huawei P9, same problem here.

kr...@gmail.com <kr...@gmail.com> #140May 14, 2018 09:41AM

Same "Google play services updating " issue on Huawei P9. Also facing WIFI lock issue.Battery drain issue is not very evident

ss...@gmail.com <ss...@gmail.com> #141May 14, 2018 09:43AM

Huawei P20 Pro experiencing "Google Play services are updating" on other apps that load map.
Has the issue been resolved?

ni...@gmail.com <ni...@gmail.com> #142May 14, 2018 09:48AM

Huawei P9, same problem here! I hope this will be fixed soon

ja...@gmail.com <ja...@gmail.com> #143May 14, 2018 09:53AM

Huawei mate 9 also facing same issue

dw...@adaglobal.com <dw...@adaglobal.com> #144May 14, 2018 09:54AM

Huawei P9 Lite experiencing the same issue as well.. frustating indeed

br...@gmail.com <br...@gmail.com> #145May 14, 2018 09:59AM

Huawei P9. Also effecting Foxtel Now app in Australia. This is causing a major disruption to a lot of my commonly used apps.... :(

do...@gmail.com <do...@gmail.com> #146May 14, 2018 10:06AM

Huawei P9 Lite with same issue "Google play services are updating" very annoying as I use public transport app on a daily basis. Please get a fix.

jh...@google.com <jh...@google.com> #147May 14, 2018 10:16AM

Thank you all for your updates. We are treating this issue with top priority and will keep posting updates here. For visibility please only post new messages here if your device hasn't been mentioned already, or if you have logs reflecting the issue. In other cases please only star this issue.

Message last modified on May 14, 2018 10:19AM

cr...@gmail.com <cr...@gmail.com> #148May 14, 2018 10:31AM

P10 Lite affected

Il giorno lun 14 mag 2018 alle ore 12:16 <buganizer-system@google.com> ha
scritto:

--

Inviato con Google Phone

sh...@gmail.com <sh...@gmail.com> #149May 14, 2018 10:33AM

al...@gmail.com <al...@gmail.com> #150May 14, 2018 10:35AM

Don't have anything useful to add except to let you know what kind of trouble it's causing, don't know if this has been mentioned but I work for deliveroo and this is causing problems with the rider app in the same way! Taking longer to find addresses and whatnot making it more difficult to actually do the job! As well as making it so I can't track the exercise I'm doing at the same time! Please Fix Quick! Huawei P9

Message last modified on May 14, 2018 10:37AM

ls...@gmail.com <ls...@gmail.com> #151May 14, 2018 10:35AM

Honor 5c affected

al...@gmail.com <al...@gmail.com> #152May 14, 2018 10:36AM

Taking longer to find the addresses because we just get a blank screen and have to look up the postcodes separately!

sh...@gmail.com <sh...@gmail.com> #153May 14, 2018 10:44AM

I went to Settings--Apps--Google Play Services--Storage--[Clear Cache]--Manage Space--[Clear All Data]. Seems to be working fine for now (in Uber App) . Device : Huawei Honor View 10. Will keep you posted.

Update 1: Issue creeps up again if you reboot and you'll have to do the previous steps again.
Update 2: I did not delete any updates.

h....@gmail.com <h....@gmail.com> #154May 14, 2018 10:48AM

Huawei p20 pro. Affecting maps in apps - unable to buy train /pendler card (dk) - and a few music apps like Tidal and Jazz

radio.com

a....@gmail.com <a....@gmail.com> #155May 14, 2018 10:51AM

Huawei p20 pro. Affecting maps in apps (Uber, Andorid auto etc.) and Android Wear configuration: I'm unable to finish Ticwatch S Smartwatch pair with p20p (It worked 3 weeks ago)

sl...@gmail.com <sl...@gmail.com> #156May 14, 2018 11:06AM

Huawei P10 lite.
Same issues, all apps that have a mapping feature display "Google play services updating" when accessing the map.
Also had significant drop in battery life overnight and phone was getting hot. Battery monitor didn't show anything unusual. Did a factory reset that seems to have sorted the battery issue but not the mapping.

in...@gmail.com <in...@gmail.com> #157May 14, 2018 11:08AM

Huawei p9 lite: I went to Settings--Apps--Google Play Services--Storage--[Clear Cache]--Manage Space--[Clear All Data]. After reboot the problem comes back again
Google Play Services: 12.6.73

2n...@gmail.com <2n...@gmail.com> #158May 14, 2018 11:08AM

Huawei P10, 2 phones in family. Same as written before. Two interesting side effects (verified using the update method which works until reboot): NHK world app doesn't start (starts with freshly updated google services until reboot), Tidal doesn't see chromecast devices (works with freshly updated gs) while Spotify casting is unaffected.
No effect on battery usage, same effects of embedded map applications (vodafone easy ride for parking, bkk app for local public transport, bubi for local bike aystems)
Friend's brand new Huawei P20 pro same effects.

mo...@gmail.com <mo...@gmail.com> #159May 14, 2018 11:12AM

Huawei P9. I'm experiencing significant battery drain. "Google play services are updating" displays in the maps of the following apps so far for me:

Life360
Yelp
Redfin

Hope you guys can fix this soon. Thank you.

su...@gmail.com <su...@gmail.com> #160May 14, 2018 11:14AM

I am using Honor 7X. Google maps work fine. But when someone shares location using whatsapp I am getting as "Google play services are updating" How do i fix this?

so...@gmail.com <so...@gmail.com> #161May 14, 2018 11:16AM

Multiple apps wont start until I clear "google play services" . Huawei P20 Pro

kr...@gmail.com <kr...@gmail.com> #162May 14, 2018 11:18AM

Huawei mate 8. The problem appears as "Google play services are updating" when I use online transportation app.
How do I fix this ?

su...@gmail.com <su...@gmail.com> #163May 14, 2018 11:20AM

HI, I uninstalled the Google play services update and restarted my phone. Now it works fine.

s....@gmail.com <s....@gmail.com> #164May 14, 2018 11:25AM

Huawei P9 Plus: I went to Settings--Apps--Google Play Services--Storage--[Clear Cache]--Manage Space--[Clear All Data] which fixes the issue, but after reboot the problem comes back again
Google Play Services: 12.6.73

I don't know if this extra info is useful or not, but I also found that my Google Calendar would crash when opening an appointment's details. Doing the above fixes that too, but the issue returns after a reboot.

I'm also seeing excessive battery drain which I assume is part of this issue.

ma...@gmail.com <ma...@gmail.com> #165May 14, 2018 11:49AM

same problem on Honor 9 with emui 8.0/android 8.0: with the garmin connect app the maps does not load and give me "google play services are updating"

lu...@gmail.com <lu...@gmail.com> #166May 14, 2018 11:50AM

I faced this problem on Sat 12, I did a factory reset, then it worked. Today (Mon), I wanted to used a taxi app, and found surprisingly the same problem "google play services are updating". Huawei P10 VTR-L09C178B190, Google Play Services: 12.6.73

ca...@gmail.com <ca...@gmail.com> #167May 14, 2018 11:55AM

Reply #90 work for me. In my Huawel Mate 10 Pro I went to Settings -> Apps and Notifications -> Apps -> Google Play Services and disabled it.

It reverted back to the initial version (11.x) and then I updated back to 12.6.73 and Yelp and Lyft seems to work.

Looking at the responses since this isn't a fix, ugh.

Message last modified on May 14, 2018 12:02PM

lu...@gmail.com <lu...@gmail.com> #168May 14, 2018 11:57AM

so...@gmail.com <so...@gmail.com> #169May 14, 2018 11:58AM

Please check this error (

https://issuetracker.google.com/issues/79653882) & logs. Root cause might be the same.

pa...@gmail.com <pa...@gmail.com> #170May 14, 2018 12:10PM

Experiencing the same issue. It is also affecting the battery. I did a factory reset over the weekend and everything seemed to be fine (including battery), but a day later all issues came back (cannot use the Uber app or any other app with embedded maps). Some notifications seem to be affected as well (e.g. Monzo). The battery is draining faster once more.

Message last modified on May 14, 2018 12:56PM

da...@justeattakeaway.com <da...@justeattakeaway.com> #171May 14, 2018 12:32PM

We're seeing a Pay-related crash with this same version of Play Services on Huawei devices running Android 7/8. It only affects APK variant 040408-194189626 of v12.6.73.

Caused by java.lang.ClassNotFoundException
Didn't find class "com.google.android.gms.wallet.dynamite.fragment.WalletFragmentDelegateImpl" on path: DexPathList[[zip file "/system/framework/com.android.location.provider.jar", zip file "/system/framework/com.android.media.remotedisplay.jar", zip file "/data/app/com.google.android.gms-2/base.apk"],nativeLibraryDirectories=[/data/app/com.google.android.gms-2/lib/arm64, /data/app/com.google.android.gms-2/base.apk!/lib/arm64-v8a, /system/lib64, /vendor/lib64, /system/vendor/lib64, /product/lib64]]

Fatal Exception: java.lang.RuntimeException: Failure to create WalletFragmentDelegateImpl from container
at com.google.android.gms.wallet.dynamite.WalletDynamiteCreatorImpl.a(:com.google.android.gms@12673025@12.6.73 (040408-194189626):12)
at com.google.android.gms.wallet.dynamite.WalletDynamiteCreatorImpl.newWalletFragmentDelegate(:com.google.android.gms@12673025@12.6.73 (040408-194189626):11)
at apqc.onTransact(:com.google.android.gms@12673025@12.6.73 (040408-194189626):14)
at android.os.Binder.transact(Binder.java:499)
at com.google.android.gms.internal.zzafp$zza$zza.zza(Unknown Source)
at com.google.android.gms.internal.zzafu.zza(Unknown Source)
at com.google.android.gms.wallet.fragment.SupportWalletFragment$zzc.zza(Unknown Source)
at com.google.android.gms.dynamic.zza.zzbdt(Unknown Source)
at com.google.android.gms.dynamic.zza.zzbdt(Unknown Source)
at com.google.android.gms.wallet.fragment.SupportWalletFragment.onCreate(Unknown Source)
at android.support.v4.app.Fragment.performCreate(SourceFile:2246)
at android.support.v4.app.FragmentManagerImpl.moveToState(SourceFile:1377)
at android.support.v4.app.FragmentTransition.addToFirstInLastOut(SourceFile:1187)
at android.support.v4.app.FragmentTransition.calculateFragments(SourceFile:1070)
at android.support.v4.app.FragmentTransition.startTransitions(SourceFile:115)
at android.support.v4.app.FragmentManagerImpl.executeOpsTogether(SourceFile:2374)
at android.support.v4.app.FragmentManagerImpl.removeRedundantOperationsAndExecute(SourceFile:2332)
at android.support.v4.app.FragmentManagerImpl.execPendingActions(SourceFile:2239)
at android.support.v4.app.FragmentManagerImpl$1.run(SourceFile:700)
at android.os.Handler.handleCallback(Handler.java:761)
at android.os.Handler.dispatchMessage(Handler.java:98)
at android.os.Looper.loop(Looper.java:156)
at android.app.ActivityThread.main(ActivityThread.java:6577)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:942)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:832)

While I appreciate this bug is for the Maps issue, I can't find any other component suitable for Play Services / Google Pay nor a forum for reporting such issues. If the Maps team have a contact in the right team who can help, they can email me directly.

th...@gmail.com <th...@gmail.com> #172May 14, 2018 12:47PM

Huawei P10 Lite same problems with apps as rainalarm, Uber.

la...@gmail.com <la...@gmail.com> #173May 14, 2018 01:29PM

Reply #90 worked for me too on a Huawei Mate 10 Pro. I have not tried rebooting to see if it breaks again. Assume there will be a new Google Play Services release soon to fix the issue? After removing updates per Reply #90 and reinstalling, I ended up back on the same release 040408-194189626.

bk...@gmail.com <bk...@gmail.com> #174May 14, 2018 01:30PM

We have the same problem on Huaweii phones. Our BKK FUTÁR application use google maps and can't load the map. Please fix it asap because this is the offical public transport application of Budapest, Hungary.

se...@gmail.com <se...@gmail.com> #175May 14, 2018 01:31PM

Same problem Huawei mate 9 lite

2n...@gmail.com <2n...@gmail.com> #176May 14, 2018 01:35PM

Could anyone please stop posting that Reply #90 worked (without mentioning that a reboot renders the phone back to its original state) as it is already common knowledge. Please read the comments through before you try and post any 'fix' in hope it will have an effect. So far there is no permanent correction to this issue from Google' side.
It is also remarkable that the same version (after remove updates and reinstall current version) works well whereas after reboot it doesn't. What may happen with the API during reboot?? Maybe Huawei should be included in the bug analysis....

jo...@gmail.com <jo...@gmail.com> #177May 14, 2018 01:37PM

Same issue on my P Smart running Android 8.0.0

ar...@gmail.com <ar...@gmail.com> #178May 14, 2018 01:45PM

Same problem. Huawei p9 lite mini Android 7.0

ko...@gmail.com <ko...@gmail.com> #179May 14, 2018 01:45PM

Huawei P9 lite mini / Android 7.0

bug_1526282344892_.png

33 KB

ot...@gmail.com <ot...@gmail.com> #180May 14, 2018 01:55PM

same issue with a huawei mate 10 pro, since saturday i cant use any app involving maps (uber, cabify, etc) SOS

b....@student.uw.edu.pl <b....@student.uw.edu.pl> #181May 14, 2018 02:00PM

Apps in my Huawei P10 are not working properly with build in maps. Plese fix it.

sa...@oskariolematon.net <sa...@oskariolematon.net> #182May 14, 2018 02:03PM

Huawei P20 pro same issue

mi...@gmail.com <mi...@gmail.com> #183May 14, 2018 02:07PM

Same here honor 8 lite pra-la1 android 7.0

ca...@gmail.com <ca...@gmail.com> #184May 14, 2018 02:18PM

Same issue, Huawei P10

pa...@gmail.com <pa...@gmail.com> #185May 14, 2018 02:37PM

Same. Huawei p9. It seems to be a huawei users problem. Disappointed.

yr...@gmail.com <yr...@gmail.com> #186May 14, 2018 02:38PM

Same issue here, Huawei Honor 8 There was a recent update to Huawei. That's when it started.

Message last modified on May 14, 2018 02:41PM

an...@gmail.com <an...@gmail.com> #187May 14, 2018 02:48PM

Now TV app has just released an update. What's New says "Bug fixes for Huawei devices"! Now TV was one of my apps that was affected. I can't test it as I have applied the workaround and all working OK and don't want to reboot!

di...@gmail.com <di...@gmail.com> #188May 14, 2018 02:55PM

Occurring to my smartphone too!
Model: Huawei Nova 2 Lite
EMUI: 8
Running Android 8
Affected apps: Grab, Go-Jek. I'm depending on these two apps for daily commute😔

da...@gmail.com <da...@gmail.com> #189May 14, 2018 02:59PM

same issue P9 Lite

ym...@gmail.com <ym...@gmail.com> #190May 14, 2018 03:04PM

same issue is encoutered on huawei honor v10 with apps redfin and onebusaway. clear google play services cache could solve it before next boot.

is...@gmail.com <is...@gmail.com> #191May 14, 2018 03:58PM

same issue with Huawei P9

ed...@naika.com.mx <ed...@naika.com.mx> #192May 14, 2018 04:00PM

Mi telefono ya presento ese problema
Model: Huawei Nova 2
EMUI: 5.1
Android 7
Affected : Uber, nike + run

zo...@gmail.com <zo...@gmail.com> #193May 14, 2018 04:06PM

Same here
Huawei P10 Lite
Android: 7.0
EMUI: 5.1.1

Message last modified on May 14, 2018 04:07PM

ju...@pm.me <ju...@pm.me> #194May 14, 2018 04:16PM

Having the same issue on Huawei Y7, Android 7.0

ma...@gmail.com <ma...@gmail.com> #195May 14, 2018 04:17PM

Same issue p8 lite also

ma...@gmail.com <ma...@gmail.com> #196May 14, 2018 04:22PM

Same issue Huawei P9

ia...@gmail.com <ia...@gmail.com> #197May 14, 2018 04:37PM

Ehm, has anyone tried to send a note at their official email apps-help@google.com ?

sa...@gmail.com <sa...@gmail.com> #198May 14, 2018 04:44PM

Same issue with OfferUp and other applications

la...@gmail.com <la...@gmail.com> #199May 14, 2018 04:51PM

My Huawei too,
Huawei Mate SE Factory Unlocked 5.93”

ni...@gmail.com <ni...@gmail.com> #200May 14, 2018 05:02PM

It works for a while, but then after few hours or restart the problem re-appears. I suggest to downgrade this service "service google play" in emergecy ! We have a avalanche of trouble for all applications !

Thank you for escalade !

Huawei Mate 8 NXT-L29 (Android 7.0 / EMUI 5.0.2 / Build NXT-L29C432B583)

Message last modified on May 14, 2018 05:03PM

[Deleted User] <[Deleted User]> #201May 14, 2018 05:05PM

Same issue with P10

dm...@gmail.com <dm...@gmail.com> #202May 14, 2018 05:19PM

Honor 7x had to disable google play services (after clearing cache) run factory version then update to lates version and it has worked in clearing the issue for the moment.

ma...@gmail.com <ma...@gmail.com> #203May 14, 2018 05:20PM

Same here with tha apps Runkeeper and Strave
Huawei P9 Lite, Android: 7.0, EMUI: 5.0.1
Please solve this problem

ss...@gmail.com <ss...@gmail.com> #204May 14, 2018 05:23PM

Same issue with Huawei P10 lite. Please find a solution urgently. It's in all our best interest that this be sorted at the soonest. Thank you

ke...@gmail.com <ke...@gmail.com> #205May 14, 2018 05:24PM

Same issue any app that uses maps (other than map app itself) i.e life 360 & Rightmove.

Last few days on Huawei P20 Pro.

ha...@gmail.com <ha...@gmail.com> #206May 14, 2018 05:55PM

Problem with Huawei M3 lite tablet. 'Google Play services are updating' since a week. Some apps which use maps do not work. Can you update me?

[Deleted User] <[Deleted User]> #207May 14, 2018 06:07PM

Same issue, P9.

13...@gmail.com <13...@gmail.com> #208May 14, 2018 06:09PM

Same issue on Huawei Mate 9. GMail doesn't work at all, Google Assistant settings and apps using Google maps work until reboot.

EMUI 8.0, Android 8.0

s0...@gmail.com <s0...@gmail.com> #209May 14, 2018 06:12PM

I have had this same issue since May 10, 2018 on all apps needing Google Maps.

Device: Huawei Honor View10
Model Number: Huawei BKL-L04
Build Number: BKL-L04 8.1.0.105(C567)
EMUI Version: 8.0.0
Android Version: 8.1.0
Google Play Services Version: 11.9.51 (440-177350961)

vh...@gmail.com <vh...@gmail.com> #210May 14, 2018 06:32PM

Same issue here:
Huawei P10 Lite
Build Number: WAS-LX1AC432B206
EMUI Version: 5.1.1
Android Version: 7.0
Google Play Services Version: 12.6.73 (040408-194189626)

la...@gmail.com <la...@gmail.com> #211May 14, 2018 06:36PM

Same issue with Honor 8.

pa...@gmail.com <pa...@gmail.com> #212May 14, 2018 06:36PM

Same issue Honor 8

ri...@gmail.com <ri...@gmail.com> #213May 14, 2018 06:39PM

Same issue here since last Friday (11/05/2018) for me as well.

DISPOSITIVO
Modello: FRD-L09 (FRD-L09)
Produttore: HUAWEI
Numero Build: FRD-L09C432B394
Versione SO: Nougat (7.0)

Google play version
12.6.73 (040408-194189626)

Apps affected
Flight Radar24
Uber
Citymapper
Tripadvisor
The Fork

Basically any apps using Google maps.

I tried and follow all the steps, but even after uninstallig and reinstalling Google playi services the issue is fixed until the next reboot.

Please help, this is providing serious pain.
Thanks

ma...@gmail.com <ma...@gmail.com> #214May 14, 2018 07:00PM

WHATSAPP también falla en la restauración de multimedia de una copia de seguridad al hacer restauración de fábrica.
Errores en aplicaciones que usan mapas, configuración de asistente de Google..

he...@googlemail.com <he...@googlemail.com> #215May 14, 2018 07:02PM

It might be worth noting that this issue is also affecting Googles OWN app: "Family Link" on Huawei devices.

as...@gmail.com <as...@gmail.com> #216May 14, 2018 07:05PM

Having same issue on huawei HONOR 7x (BND AL10) india as well.

Unable to use -
Hdfc mobile banking app - says play protect is not enabled.
Uber - says google play services are updating.

ISSUE facing from 13 may 2018.

Temporary fix is - clear app data for google play services.
But issue comes back after 5-6 hrs.

Screenshot_20180513-202500.png

211 KB

Screenshot_20180513-202438.png

109 KB

Screenshot_20180514-191926.png

178 KB

je...@gmail.com <je...@gmail.com> #217May 14, 2018 07:08PM

Same issue. Please do something and help!
Huawei p20 pro

ro...@gmail.com <ro...@gmail.com> #218May 14, 2018 07:14PM

Every trick you use works until next reboot. I tried everything, even with direct help by Google and Huawei, but the only things they suggest are the same everybody here has just tried. Unininstalling and reinstalling is the only way, but until you restart. The worrying thing is that only Huawei devices seem to be affected. Does anyone know if other brands are affected too??

he...@googlemail.com <he...@googlemail.com> #219May 14, 2018 07:19PM

Have just got off the phone to Google and Huawei. Huawei seem to be
admitting responsibility. They told me there is an EMUI update due in 1 to
2 weeks that should fix "all google maps issues".

On Mon, 14 May 2018, 20:14 , <buganizer-system@google.com> wrote:

[Deleted User] <[Deleted User]> #220May 14, 2018 07:35PM

Same issue in Honor 6x EMUI 5.0.2

fr...@gmail.com <fr...@gmail.com> #221May 14, 2018 07:40PM

Same problem here with a Huawei P10 lite (was lx3) while using Uber, Cabify, etc.

gh...@gmail.com <gh...@gmail.com> #222May 14, 2018 07:44PM

Facing the same issue in my Honor 7X, cannot use the live location feature in whatsappand saavn app is not working too. Please resolve it ASAP

j....@gmail.com <j....@gmail.com> #223May 14, 2018 07:48PM

Same issue in Huawei P9 Lite while using Uber. EMUI 5.0.1, Android 7.0
Please resolve it ASAP !

ap...@gmail.com <ap...@gmail.com> #224May 14, 2018 07:50PM

Same problem with Huawei P10 Lite. Can't use map related apps and most of my social apps are crashing.

be...@gmail.com <be...@gmail.com> #225May 14, 2018 08:02PM

Since yesterday I can't load map with the app the Photographer'sEphemeris. Seems a problem with Google play services or with my Huawei p8 lite 2017 version

ci...@gmail.com <ci...@gmail.com> #226May 14, 2018 08:04PM

At least 5 users of my apps affected, all of them with Huawei devices. It happened right after release with new 15.0.x play libraries - is this a coincidence?

sj...@siu.ro <sj...@siu.ro> #227May 14, 2018 08:07PM

I have Huawei Mate 9 and I am facing this problem. The affected apps are at least "Maastokartat", Fuel Fellow and Parkman.

[Deleted User] <[Deleted User]> #228May 14, 2018 08:10PM

same problem

og...@gmail.com <og...@gmail.com> #229May 14, 2018 08:26PM

I'm having this error as well - Huawei Mate 10 Lite (RNE-L21) with branded software (C738).

ra...@gmail.com <ra...@gmail.com> #230May 14, 2018 08:33PM

Same here p20 pro

ma...@gmail.com <ma...@gmail.com> #231May 14, 2018 08:45PM

Huawei mate 8 , same problem

mu...@gmail.com <mu...@gmail.com> #232May 14, 2018 08:49PM

Same problem p10

On Mon, 14 May 2018, 22:45 , <buganizer-system@google.com> wrote:

ah...@gmail.com <ah...@gmail.com> #233May 14, 2018 08:59PM

It worked for me -

go to Settings > Apps & Notifications > App > Google Play Services > Storage
click Clear Cache
go to Manage Space and click Clear all data

ja...@gmail.com <ja...@gmail.com> #234May 14, 2018 09:00PM

Same Problem, P20 Pro.

an...@gmail.com <an...@gmail.com> #235May 14, 2018 09:01PM

Ok

<buganizer-system@google.com> ezt írta (időpont: 2018. máj. 14., H 23:00):

an...@gmail.com <an...@gmail.com> #236May 14, 2018 09:01PM

Same problem

mu...@gmail.com <mu...@gmail.com> #237May 14, 2018 09:10PM

Worked for me

On Mon, 14 May 2018, 23:02 , <buganizer-system@google.com> wrote:

https://issuetracker.google.com/components/190923#basic or

ma...@gmail.com <ma...@gmail.com> #238May 14, 2018 09:41PM

#233 worked for me initially, but problem returned after reboot. Huawei honor 9 lite

pa...@gmail.com <pa...@gmail.com> #239May 14, 2018 09:43PM

worked for me initially, but problem returned after reboot. Huawei P20 Pro

as...@gmail.com <as...@gmail.com> #240May 14, 2018 10:30PM

Workaround has worked initially.

ah...@google.com <ah...@google.com> #241May 14, 2018 10:38PM

Google has been able to reproduce the problem on a physical device and is now focusing on addressing the root cause through either a fix or other mitigation.

ab...@citydrive.mx <ab...@citydrive.mx> #242May 14, 2018 10:39PM

Thanks "ah.." and Google team!! <3 Hope to get fixed it soon!

ah...@google.com <ah...@google.com> May 14, 2018 10:40PM

Reassigned to ah...@google.com.

pa...@gmail.com <pa...@gmail.com> #243May 14, 2018 10:54PM

Same problem in Huawei GW Metal, new device bought two days ago, issues with Uber

da...@justeattakeaway.com <da...@justeattakeaway.com> #244May 14, 2018 10:55PM

#241 Thanks for confirming this has been reproduced by Google engineers.

As per my

comment #171

earlier today there is a related issue also mainly affecting Huawei devices regarding Google Pay on this version of Google Play Services. Can you advise where that bug should be raised? There's no components under

https://issuetracker.google.com/components/166797#basic that appear to be appropriate.

mo...@gmail.com <mo...@gmail.com> #245May 14, 2018 10:58PM

This issue has only been persisting for the past 4ish days. Not only are the apps with maps not working, my phone is draining battery so badly. Took my phone off the charger this morning at 100%, 2hrs later it was 62% without my even touching it. Also been noticing the phone gets hot as well.

I tried all the fixes as well(clearing cache, reinstalling Google Play, factory reset) and the problem is only momentarily fixed, then persists again after reboot of my Huawei P9.

la...@gmail.com <la...@gmail.com> #246May 14, 2018 11:53PM

Sigue persistiendo el problema en Huawei Mate 10 lite, por favor corregir el error... No se soluciona con los pasos indicados.

ja...@gmail.com <ja...@gmail.com> #247May 14, 2018 11:54PM

I find this as a user of a Huawei P10 Lite. This message appears over the map preview in Whatsapp shared locations and in Uber, which doesn't get a map at all.

lm...@google.com <lm...@google.com> #248May 15, 2018 01:59AM

Hi Dave,
Thanks for the report in

comment #171

and

comment #244

about Google Pay.
That issue has the same root cause, and will be addressed together with the Maps issue, so keep following along on this bug.

Message last modified on May 15, 2018 01:59AM

ca...@gmail.com <ca...@gmail.com> #249May 15, 2018 02:17AM

All of my apps on my Honor 6x that use maps are not displaying the map. They say Google play services are updating.
These are effecting tide apps, weather apps, navigation apps. What is the expected resolution date?

ma...@gmail.com <ma...@gmail.com> #250May 15, 2018 02:33AM

#248 y las fallas de Google Drive?

dc...@gmail.com <dc...@gmail.com> #251May 15, 2018 02:49AM

Huawei mate se

Google Play Services are updating.

ie...@gmail.com <ie...@gmail.com> #252May 15, 2018 03:27AM

Settings, Apps & Notifications, Apps, Google Play Services, Storage, Manage Space then Clear All Data. Worked for my Huawei P10.

sl...@gmail.com <sl...@gmail.com> #253May 15, 2018 03:32AM

My phone Huawei P9 also face the same problem as above, keep showing "google play services are updating". Please solve asap, as it burden me so much. TQVM.

la...@gmail.com <la...@gmail.com> #254May 15, 2018 04:28AM

My husband and I are both having the same "Google play services are updating" issue with both our Huawei Honor 6x's.

ni...@gmail.com <ni...@gmail.com> #255May 15, 2018 04:40AM

I have the same problems, including battery drain, with a Huawei Honor

rz...@gmail.com <rz...@gmail.com> #256May 15, 2018 04:42AM

I have the issue with my Huawei Mate 8. None of the solutions works so far.

st...@gmail.com <st...@gmail.com> #257May 15, 2018 04:46AM

Hello, I have the same problem with two device:

HUAWEI P9 and HUAWEIP10 Plus.
Android Vesion: 7.0
EMUI Version: 5.0.1
Google play services: 12.6.73

In my code i use:
Android Studio: 3.1.2
Gradle Version: 4.4
classpath 'com.google.gms:google-services:3.2.1'

And
implementation 'com.google.android.gms:play-services-auth:15.0.1'
implementation 'com.google.android.gms:play-services-places:15.0.1'
implementation 'com.google.android.gms:play-services-cast:15.0.1'
implementation 'com.google.android.gms:play-services-location:15.0.1'
implementation 'com.google.android.gms:play-services-plus:15.0.1'
implementation 'com.google.android.gms:play-services-maps:15.0.1'

If you need more information to found a solutions let me know.

Thank you!

google_play_services.jpg

69 KB

di...@gmail.com <di...@gmail.com> #258May 15, 2018 04:55AM

I referred to report ID #252 & it is working fine now on my Huawei Nova 2 Lite. Hopefully it won't reoccur. Thank you very much #252!

eg...@gmail.com <eg...@gmail.com> #259May 15, 2018 04:56AM

Huawei p9 2017 I can't üde traffic application BBK futár.

SVID_20180515_065531.mp4

69 KB

https://productforums.google.com/forum/#!topic/googlehome/XG8ELkaUcuQ

ab...@gmail.com <ab...@gmail.com> #260May 15, 2018 05:05AM

I am still experiencing the same problem. This has been 2 days already ... Please do something about as it urgently

si...@gmail.com <si...@gmail.com> #261May 15, 2018 05:27AM

Had the same issue on my Honor 9. Cleared all data for Google Play Services as described in #252 and it worked. I've also had some issues with Chrome Cast the past couple of days. Have not verified that it has been solved yet.

jo...@gmail.com <jo...@gmail.com> #262May 15, 2018 05:38AM

I recently experienced this issue. When will this be fixed?

gu...@gmail.com <gu...@gmail.com> #263May 15, 2018 05:43AM

I have the same issue on the Honor 9, all apps that use the Google maps API or location services seem to be impacted

rz...@gmail.com <rz...@gmail.com> #264May 15, 2018 05:45AM

Just try my son's Samsung phone. It has no problem with the same version of Google Play Service.

mm...@gmail.com <mm...@gmail.com> #265May 15, 2018 05:53AM

Writing to google maps services are updating..Huawei p9plus, android 7

ol...@gmail.com <ol...@gmail.com> #266May 15, 2018 05:58AM

Google maps services are updating... I can not use lof of apps... Mate 10 light, android 7

ki...@gmail.com <ki...@gmail.com> #267May 15, 2018 06:02AM

I have the same issue while using viber and some other applications where I want to send my location but sometimes it works. Maps working fine. I have a Huawei p10 lite and android 7.

Message last modified on May 15, 2018 06:03AM

wm...@gmail.com <wm...@gmail.com> #268May 15, 2018 06:03AM

Same problem on a Huawei P9.. All Aps that use Google maps are impacted. Kindly update on what needs to be done.

mi...@gmail.com <mi...@gmail.com> #269May 15, 2018 06:11AM

This Google Play Services issue is more fundamental than that. It not only affects Google Maps-related issues but also Google Home issues.

This issue for example, is also related to the Google Play services-google maps issue:

as...@google.com <as...@google.com> #270May 15, 2018 06:11AM

Google is building and verifying a mitigation measure for this issue. We will update you as soon as we have new information.

ar...@gmail.com <ar...@gmail.com> #271May 15, 2018 06:29AM

I have a Huawei P10 and had this problem. I stopped and removed Google Play Services and rebooted. After rebooted problem disappeared. Still after that I installed again Google Play Services from Google Play. New reboot after that and still everything is working ok. I can see now the map in Sports Tracker.

ia...@gmail.com <ia...@gmail.com> #272May 15, 2018 06:34AM

#270 source? Thanks

oy...@gmail.com <oy...@gmail.com> #273May 15, 2018 07:06AM

I have the same problem, plus...I can't sign in to Chrome, & webpages in chrome reloading themselves while I read the content. Also reloading in XDA forum app and in Inoreader it is super annoying.
Weather app don't want to refresh current weather on demand.
NHK app stop playing videos randomly.
Something is really messed up.
Im using Mate 9 with Oreo 8.0 & March Security update.

mi...@gmail.com <mi...@gmail.com> #274May 15, 2018 07:40AM

Same problem here Huawei P10 Lite - have to disable and have to disable and then update Player Services after every system restart.

kl...@gmail.com <kl...@gmail.com> #275May 15, 2018 07:53AM

Google play services are updating, I can not use some apps wih maps inside, Huawei P10 lite

ma...@googlemail.com <ma...@googlemail.com> #276May 15, 2018 08:00AM

Same issue Huawei P10.

[Deleted User] <[Deleted User]> #277May 15, 2018 08:07AM

There were some similar error logs which i saw for Careem, Uber and EasyTaxi when i searched found similar error logs on this gitgub thread with strange solution

https://github.com/invertase/react-native-firebase/issues/1057 when tried to apply the firebase console keep loading and didn't opened the storage section and was failing to load

su...@gmail.com <su...@gmail.com> #278May 15, 2018 08:11AM

Interestingly, I uninstalled google play services and reinstalled from an apk (v.12-6-73-000300-194189626, from

https://google-play-services.en.uptodown.com/android/download), it works just fine for some time! Maps in related apps (UBER etc.) opened and the apps worked. Then I updated all the apps in my device and again it showed the same error this morning. I guess there is an issue with the permission of update.

I use Huawei Honor 7x.

Hope it helps you to narrow the problem down.

co...@genewarrior.com <co...@genewarrior.com> #279May 15, 2018 08:22AM

Same Issue with Huawei Nova 2 PIC-LX9 while opening map in "Sun Locator"-App (uses Maps SDK for Android). Suggested work-around (clearing cache of Google Play Services) is unsuccessful.

he...@gmail.com <he...@gmail.com> #280May 15, 2018 08:26AM

I manage to use the map-related app such as grab and others after using the method below.

go to Settings > Apps & Notifications > App > Google Play Services > Storage
click Clear Cache
go to Manage Space and click Clear all data

But after doing that, some of the game app that using google id unable to login until i restart the phone again.

I'm using P9

ha...@gmail.com <ha...@gmail.com> #281May 15, 2018 08:29AM

Huawei P8 Lite here. Same probleme. Plus i cannot download photos from Firebase Storage Reference. I get the url etc, but the photo is just empty.

I think that is the error:
E/ChimeraModuleLdr: Failed to load code for module FileApk(/data/user_de/0/com.google.android.gms/app_chimera/m/00000039/DynamiteModulesC_GmsCore_prodmnc_xxhdpi_release.apk)
ddp: Failed to load code for /data/user_de/0/com.google.android.gms/app_chimera/m/00000039/DynamiteModulesC_GmsCore_prodmnc_xxhdpi_release.apk
at day.a(:com.google.android.gms@12673025@12.6.73 (040408-194189626):23)
at ddn.a(:com.google.android.gms@12673025@12.6.73 (040408-194189626):84)
at ddn.a(:com.google.android.gms@12673025@12.6.73 (040408-194189626):52)
at ddn.a(:com.google.android.gms@12673025@12.6.73 (040408-194189626):117)
at ddn.a(:com.google.android.gms@12673025@12.6.73 (040408-194189626):114)
at ryk.a(:com.google.android.gms@12673025@12.6.73 (040408-194189626):13)
at com.google.android.gms.chimera.container.DynamiteLoaderImpl.createModuleContext(:com.google.android.gms@12673025@12.6.73 (040408-194189626):18)
at ryf.onTransact(:com.google.android.gms@12673025@12.6.73 (040408-194189626):12)
...

sa...@gmail.com <sa...@gmail.com> #282May 15, 2018 08:33AM

I struggling from this too. Huawei P10 Lite.

su...@gmail.com <su...@gmail.com> #283May 15, 2018 08:41AM

Same problem... Huawei honor 9, android 8.0.0

f....@gmail.com <f....@gmail.com> #284May 15, 2018 08:53AM

Same problem Huawei P8 lite 2017 Emui 5.0.2
After clear all data it works, but after the restart it fails again

pi...@gmail.com <pi...@gmail.com> #285May 15, 2018 09:39AM

Same problem... Huawei P10, android 7.0.0

ka...@gmail.com <ka...@gmail.com> #286May 15, 2018 09:48AM

The same problem on Huawei P10 Plus,,Emui v5.1.
Application with external maps loading visualisation dont work (Google play services are updating).
I cannot login to Google Home and Google Chrome.

Message last modified on May 15, 2018 09:49AM

jo...@gmail.com <jo...@gmail.com> #287May 15, 2018 10:04AM

Hi, I just stopped the app on a P20 and it asks to confirm I want to use the factory default version. It works again.

ei...@gmail.com <ei...@gmail.com> #288May 15, 2018 10:09AM

Same issue with Huawei P20 Pro using apps like Citymapper, Booking or Shazam. Attached you'll find screenshots of the Google Play services version, mobile phone model and a sample of the issue affecting Citymapper. Hope it helps.

Screenshot_20180515-112934.jpg

94 KB

Screenshot_2018-05-15-10-55-55.png

40 KB

Screenshot_2018-05-15-10-54-45.png

25 KB

jo...@gmail.com <jo...@gmail.com> #289May 15, 2018 10:33AM

Hi all

I have problem.with tom.tom .. no maps are vissible.

Screenshot_20180515-123153.png

106 KB

po...@gmail.com <po...@gmail.com> #290May 15, 2018 10:34AM

Shít app!!!

hi...@gmail.com <hi...@gmail.com> #291May 15, 2018 10:46AM

Pls help to solve this issue asap, I am also facing this issue on my p9
lite, emui 5.0.1

On Tue, May 15, 2018, 4:34 PM <buganizer-system@google.com> wrote:

ah...@gmail.com <ah...@gmail.com> #292May 15, 2018 10:52AM

Same issue here happen with my Huawie Mate8, but when i uninstall Google play services and then reinstall it .. it work for hours maybe a day maximum and then return to show me "Google play services are updating" on apps like Uber or careem or whatever it need Google maps ..!!

to...@gmail.com <to...@gmail.com> #293May 15, 2018 10:54AM

Huawei P10 Lite
Google play services are updating and battery drain are not fun.

ga...@gmail.com <ga...@gmail.com> #294May 15, 2018 10:57AM

On Tue., 15 May 2018, 8:52 pm , <buganizer-system@google.com> wrote:

ar...@gmail.com <ar...@gmail.com> #295May 15, 2018 11:31AM

Comment #271

is the cure for the problem. That solution still works.

ay...@gmail.com <ay...@gmail.com> #296May 15, 2018 11:45AM

I tried the solution #271 and it didn´t help :(

ny...@gmail.com <ny...@gmail.com> #297May 15, 2018 12:04PM

Nem lehet használni a Bkk futárt.

jo...@gmail.com <jo...@gmail.com> #298May 15, 2018 12:06PM

I removed Google service . Re booted Huawei p9 and the maps are vissible in the ton Tom app

fu...@gmail.com <fu...@gmail.com> #299May 15, 2018 12:06PM

#271 solution only works for a while, after reboots or couple of hours/days same issue came back....

ay...@gmail.com <ay...@gmail.com> #300May 15, 2018 12:10PM

I´ve downloaded an older version of Google Play Services here

https://www.androidapksfree.com/apk/google-play-services-12-5-29-000300-192802242-apk-download/ and installed it. After the reboot I can finally use the maps-based apps, but now all the Google services are disabled, such as Google Pay and all the apps where I usually log in using my Google account. Moreover, a warning about using an inappropriate software version appears every several minutes.

co...@gmail.com <co...@gmail.com> #301May 15, 2018 12:10PM

P20 Pro user here, just got an OTA of CLT-L29 8.1.0.120(C636) after initial reboot, Uber working, so did another reboot, Uber still working.... looking like hopefully it's fixed (at least on the P20 Pro)

fa...@gmail.com <fa...@gmail.com> #302May 15, 2018 12:25PM

P20 Pro user as well, CLT-L29 8.1.0.120(C636) still having issues for location on Whatsapp, telegram, path still keeps showing error Google play services is updating.

tp...@gmail.com <tp...@gmail.com> #303May 15, 2018 01:02PM

It seems to be affecting Admob on my mobile apps as well as In-App Purchases. Every time there is an ad request for an interstitial, it crashes. My apps do not make use of Maps, but the problem is circumscribed to HUAWEI devices, so its likely this.
The crash logs are like this:

java.lang.RuntimeException:
at android.app.ActivityThread.performLaunchActivity (ActivityThread.java:2793)
at android.app.ActivityThread.handleLaunchActivity (ActivityThread.java:2864)
at android.app.ActivityThread.-wrap12 (ActivityThread.java)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1567)
at android.os.Handler.dispatchMessage (Handler.java:105)
at android.os.Looper.loop (Looper.java:156)
at android.app.ActivityThread.main (ActivityThread.java:6577)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:942)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:832)
Caused by: java.lang.SecurityException:
at android.app.ContextImpl.checkMode (ContextImpl.java:2324)
at android.app.ContextImpl.getSharedPreferences (ContextImpl.java:372)
at android.app.ContextImpl.getSharedPreferences (ContextImpl.java:367)
at com.google.android.gms.internal.zzbx.zzv (Unknown Source)
at com.google.android.gms.internal.zzby.zzw (Unknown Source)
at com.google.android.gms.internal.zzbz.zzw (Unknown Source)
at com.google.android.gms.ads.internal.zzp.<init> (Unknown Source)
at com.google.android.gms.ads.internal.zzp.<init> (Unknown Source)
at com.google.android.gms.ads.internal.zzb.<init> (Unknown Source)
at com.google.android.gms.ads.internal.zzc.<init> (Unknown Source)
at com.google.android.gms.ads.internal.zzj.<init> (Unknown Source)
at com.google.android.gms.ads.internal.client.zze.zzb (Unknown Source)
at com.google.android.gms.ads.internal.client.zzz.zzL (Unknown Source)
at com.google.android.gms.ads.internal.client.zzz.zza (Unknown Source)
at com.google.android.gms.ads.InterstitialAd.loadAd (Unknown Source)
at com.example.sueca.Pontuacao.requestNewInterstitial (Pontuacao.java:1517)
at com.example.sueca.Pontuacao.onCreate (Pontuacao.java:150)
at android.app.Activity.performCreate (Activity.java:6910)
at android.app.Instrumentation.callActivityOnCreate (Instrumentation.java:1123)
at android.app.ActivityThread.performLaunchActivity (ActivityThread.java:2746)

fe...@gmail.com <fe...@gmail.com> #304May 15, 2018 01:05PM

The solution mentioned in #271 works only until the next reboot (at least on Huawei P9)!

g3...@gmail.com <g3...@gmail.com> #305May 15, 2018 01:29PM

new Huawei P20 Pro ... too me I have this error "Google Play services are updating" for many apps with maps,
I clear every time cache and data of Google Play Service but the error cames back again after reboot.
Why ? ... What's the solution ? ... When ?????? ... GOOGLEEEEEEE !!!!!!!!!!!!

lu...@gmail.com <lu...@gmail.com> #306May 15, 2018 01:42PM

Hi, I have the same problem, P20.

ak...@gmail.com <ak...@gmail.com> #307May 15, 2018 01:48PM

Hi Same issue P20 Pro.

da...@justeattakeaway.com <da...@justeattakeaway.com> #308May 15, 2018 02:08PM

Google will almost certainly have to make a new release of Google Play Services once they have identified a fix and completed internal testing.

The usual mechanism for release is a multi-stage process:

1. There is usually a beta release which you need to be opted in to receive. This may be delivered via staged rollout, where the update is auto updated (or available to upgrade to manually via the store) to a gradually increasing percentage of beta users.
2. Once Google are happy with beta feedback, then they will usually do a staged rollout of the release to the wider device population, again with a gradually increasing percentage.
3. Eventually this will be increased to 100% rollout and all devices will be eligible to update (and the vast majority will do so automatically).

To opt in to Google Play Beta program, go here:

https://play.google.com/apps/testing/com.google.android.gms Note that this is generally intended for Android app developers, and releases may be unstable. You might want to take that risk though. You can leave the beta at a later date via the same link I believe.

I've no idea on timescales for the above. Given the end-user impact of this 'bad' release, I wouldn't be surprised if Google accelerated the rollout of the fixed version when available.

We saw the first issues being reported (see

comment #171

) from 12.6.73 on April 27, which presumably coincided with the Beta release of that version. The volume of issues dramatically increased on May 9, suggesting that's when the wider rollout started.

er...@gmail.com <er...@gmail.com> #309May 15, 2018 02:10PM

Same Issue P20 Pro.. This thing is driving me crazy! IOS haven' these sort of stupid problems

mc...@gmail.com <mc...@gmail.com> #310May 15, 2018 02:25PM

Same issue, Honor 6x

On Tue, May 15, 2018 at 4:10 PM, <buganizer-system@google.com> wrote:

https://issuetracker.google.com/issues/79405933">

ma...@gmail.com <ma...@gmail.com> #311May 15, 2018 03:01PM

This worldwide issue is very weird.
It affect ALL applications that embed google maps via google play services.
The most important application that is broken is the google ANDROID AUTO when it runs on the phone.
The simplified map do not appear. And in almost all applications that leverage the map component it displays "Google play service are updating".
I think that devices affected are ZILLIONS, but many user simply do not use many map-aware applications, thus it may get unnoticed.
In my case, it affects an Honor9 with Oreo 8.0

cv...@gmail.com <cv...@gmail.com> #312May 15, 2018 03:26PM

Same issue: Huawei Nova (Cannes L01)

ma...@gmail.com <ma...@gmail.com> #313May 15, 2018 03:34PM

I beg android developers to release a mitigation fix using the beta channel for "Google Play Services", and ask for user feedback.
We are all awaiting a quickfix and willing to help as a beta tester for initial validation of the fix. I know i can go out of the beta program if the fix causes additional troubles.

ph...@gmail.com <ph...@gmail.com> #314May 15, 2018 03:35PM

Same problem with Huawei P10
Google play services is updating. problem

mk...@gmail.com <mk...@gmail.com> #315May 15, 2018 03:58PM

Same here for Huawei P9 lite. I have uninstalled google play services. Then now it gives error updating again

db...@gmail.com <db...@gmail.com> #316May 15, 2018 04:08PM

Hi
I have the same problem, all my apps that uses google maps don´t works on Huawei devices. please fix it.

05-09 11:06:01.371 12443-12443/? I/zzy: Making Creator dynamically
05-09 11:06:01.385 1343-1380/? E/Process: isHighLoadProcess: get cpu failed
05-09 11:06:01.414 12443-12443/? W/System: ClassLoader referenced unknown path:
05-09 11:06:01.418 12443-12443/? E/ChimeraCfgMgr: Failed to read module config: java.io.FileNotFoundException: /data/user_de/0/com.google.android.gms/app_chimera/current_config.fb (Permission denied)
05-09 11:06:01.419 12443-12443/? W/DynamiteUtils: Failed to load module: java.io.FileNotFoundException: /data/user_de/0/com.google.android.gms/app_chimera/current_config.fb (Permission denied)
05-09 11:06:01.419 12443-12443/? W/DynamiteUtils: Attempt 1 failed.
05-09 11:06:01.432 1343-1380/? E/Process: isHighLoadProcess: get cpu failed
05-09 11:06:01.445 1343-2671/? E/HsmCoreServiceImpl: onTransact in code is: 103
05-09 11:06:01.445 1343-2671/? I/MediaProcessHandler: playingUids:
05-09 11:06:01.449 2556-2570/? I/AsyncOpDispatcher: 35-GetDeviceDataUploadOptInStatusOperation
05-09 11:06:01.485 2556-2572/? I/AsyncOpDispatcher: 35-GetDeviceDataUploadOptInStatusOperation
05-09 11:06:01.526 12443-12443/? E/ChimeraCfgMgr: Failed to read module config: java.io.FileNotFoundException: /data/user_de/0/com.google.android.gms/app_chimera/current_config.fb (Permission denied)
05-09 11:06:01.526 12443-12443/? W/DynamiteUtils: Failed to load module: java.io.FileNotFoundException: /data/user_de/0/com.google.android.gms/app_chimera/current_config.fb (Permission denied)
05-09 11:06:01.526 12443-12443/? W/DynamiteUtils: Attempt 2 failed.
05-09 11:06:01.623 1082-1091/? I/OAM: [check_file_size:417]/data/log/wifi/wifi_log_1 log file beyond size=10240Byte, creat new file
05-09 11:06:01.623 1082-1091/? I/OAM: [rename_old_file:122]rename_old_file
05-09 11:06:01.627 12443-12443/? E/ChimeraCfgMgr: Failed to read module config: java.io.FileNotFoundException: /data/user_de/0/com.google.android.gms/app_chimera/current_config.fb (Permission denied)
05-09 11:06:01.627 12443-12443/? W/DynamiteUtils: Failed to load module: java.io.FileNotFoundException: /data/user_de/0/com.google.android.gms/app_chimera/current_config.fb (Permission denied)

ad...@gmail.com <ad...@gmail.com> #317May 15, 2018 04:12PM

I have this issue too

fa...@gmail.com <fa...@gmail.com> #318May 15, 2018 04:16PM

A Huawei mobilomról küldve<div class="quote" style="line-height: 1.5"> -------- Eredeti üzenet -------- Tárgy: Re:

Issue 79405933

: Authorization Failure in Google Maps Android API v2 (Google Play Services 12.6.73, Huawei devices) Feladó: buganizer-system@google.com Címzett: b-system+180070615@google.com Másolatot kap: fazekastami17@gmail.com <blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div itemscope itemtype="

http://schema.org/EmailMessage"><div style='background-color: #fbe983; border: 1px solid #debe07; color: #594c04; font-weight: bold; padding: 5px 10px'>Replying to this email means your email address will be shared with the team that works on this product.</div> 
<a href="

https://issuetracker.google.com/issues/79405933</a> 
 
Changed 
 
ad...@gmail.com added <a href="

https://issuetracker.google.com/issues/79405933#comment317">

comment #317

</a>: 
I have this issue too 
 
_______________________________<div itemprop="about" itemscope itemtype="

http://schema.org/CreativeWork"><span itemprop="action" itemscope itemtype="

http://schema.org/ViewAction"><meta itemprop="url" content="

https://issuetracker.google.com/issues/79405933"/><meta itemprop="name" content="Open bug"/> 
Reference Info: 79405933 Authorization Failure in Google Maps Android API v2 (Google Play Services 12.6.73, Huawei devices) 
</div>component:  Public Trackers > Google Maps APIs > Android2 
status:  Assigned 
reporter:  le...@pinkfroot.com 
assignee:  ah...@google.com 
cc:  ah...@google.com, an...@google.com, as...@google.com, and 6 more 
type:  Customer Issue P1 S1 
blocked by:  <a href="

https://issuetracker.google.com/issues/79456189" target="_blank">79456189</a> 
duplicate issue:  <a href="

https://issuetracker.google.com/issues/79509204" target="_blank">79509204</a>, <a href="

https://issuetracker.google.com/issues/79549896" target="_blank">79549896</a>, <a href="

https://issuetracker.google.com/issues/79645096" target="_blank">79645096</a> 
hotlist:  <a href="

https://issuetracker.google.com/hotlists/782199" target="_blank">Maps API Incidents and Outages</a> 
 
 
Generated by Google IssueTracker notification system 
 
You're receiving this email because you are subscribed to updates on Google IssueTracker issue <a href="

https://issuetracker.google.com/issues/79405933">79405933</a> where you have the role: starred. </blockquote></div>

fa...@gmail.com <fa...@gmail.com> #319May 15, 2018 04:16PM

A Huawei mobilomról küldve<div class="quote" style="line-height: 1.5"> -------- Eredeti üzenet -------- Tárgy: Re:

Issue 79405933

https://issuetracker.google.com/issues/79405933">

https://issuetracker.google.com/issues/79405933</a> 
 
Changed 
 
ad...@gmail.com added <a href="

https://issuetracker.google.com/issues/79405933#comment317">

comment #317

</a>: 
I have this issue too 
 
_______________________________<div itemprop="about" itemscope itemtype="

http://schema.org/CreativeWork"><span itemprop="action" itemscope itemtype="

http://schema.org/ViewAction"><meta itemprop="url" content="

https://issuetracker.google.com/issues/79456189" target="_blank">79456189</a> 
duplicate issue:  <a href="

https://issuetracker.google.com/issues/79509204" target="_blank">79509204</a>, <a href="

https://issuetracker.google.com/issues/79549896" target="_blank">79549896</a>, <a href="

https://issuetracker.google.com/issues/79645096" target="_blank">79645096</a> 
hotlist:  <a href="

https://issuetracker.google.com/issues/79405933">79405933</a> where you have the role: starred. </blockquote></div>

j....@gmail.com <j....@gmail.com> #320May 15, 2018 04:35PM

Now i have and additional problem, my phone (Huawei P9 Lite) its freezing and the WiFi is automatically disabled. I have to restart the phone every so often. Please give a solution !

kg...@gmail.com <kg...@gmail.com> #321May 15, 2018 04:45PM

This is a joke. What about the app developers that are receiving 1 star reviews because the maps in their apps are not working. Are these going to be removed? Our app got hit hard just because of this bug... Please contact me for more details.

Message last modified on May 15, 2018 04:46PM

ci...@gmail.com <ci...@gmail.com> #322May 15, 2018 05:47PM

Damn, I haven't realized before, but it seems that my phone's recent issues with Wi-Fi and battery drainage is connected to this issue as well. I don't have problems with maps, but for a few days I experience quick battery discharge when Wi-Fi is enabled. Moreover, Wi-Fi behaves quite strangely this days, seems like it continuously searching for access points (hence battery consumption), even when already connected. Sometimes it can't connect to an AP with a strong signal. Guess it's two links of the same chain. Oh, btw, I have Huawei P6 with Android 4.2.2 on board :D

Message last modified on May 15, 2018 05:56PM

to...@gmail.com <to...@gmail.com> #323May 15, 2018 06:03PM

If you can't remove this bug, maybe update services with previous version? Apps with maps not working, battery drain when phone are idle, wifi have problems. This is not fun.

as...@gmail.com <as...@gmail.com> #324May 15, 2018 06:44PM

av...@google.com <av...@google.com> May 15, 2018 06:50PM

Reassigned to av...@google.com.

ku...@gmail.com <ku...@gmail.com> #325May 15, 2018 06:59PM

BKK Futár not work, because the Google API is crashed...

ma...@gmail.com <ma...@gmail.com> #326May 15, 2018 07:07PM

Huawei P8 Lite 2017 Vodafone Portugal - Same problem.
Restoring factory defaults only makes the phone usable for some hours.
Recurrent Issue. Tried 3 restores same results and issues mentioned by other users.
Wi-fi, battery, network, irresponsive device

pl...@gmail.com <pl...@gmail.com> #327May 15, 2018 07:09PM

Same issue here on a Huawei p20. First time after reboot today.

an...@gmail.com <an...@gmail.com> #328May 15, 2018 07:11PM

I have the same problem as well..

mu...@gmail.com <mu...@gmail.com> #329May 15, 2018 07:11PM

Seems the whole world with a toy phone called Huawei has this issue. Me too, a P9, can't see any maps on Strava, which makes the app almost useless.

Cheers from the Netherlands

Message last modified on May 15, 2018 07:20PM

lu...@gmail.com <lu...@gmail.com> #330May 15, 2018 07:11PM

Now I understand why Americans use iPhones... It's a more stable OS...

jo...@gmail.com <jo...@gmail.com> #331May 15, 2018 07:15PM

I've got the Honor 9 and been facing this issue since Friday. I've been using the following video for a temporary fix an till Google fix the problem.

https://t.co/ZjfRkrWe0Z may help some people.

pi...@gmail.com <pi...@gmail.com> #332May 15, 2018 09:41PM

Huawei p10 lite - after recent system update (installed last week) a lot of apps stopped working like: Uber, Tok FM (polish radio podcasts). This is either Google's fault or Huawei fault (less probable). Can any one from G devs say something? Like guys said in previous posts - it is unbelievable to see such fck up on OSX - at least not without big articles on newspapers that recent update killed such apps as Uber, and if it was to happen it would be like 1 or max 2 days to ship the fix. Now, we're waiting 7 days and still counting and see not even feedback from Google, pretty miserable.

BTW - the WIFI issue that someone stated previously - I have the same, at some moment after few hours of WIFI active I am unable to turn off the WiFi and the phone is getting hot. The only way to turn off the WiFi and get back the temp to normal is to reboot the phone, which is almost impossible - I must forcibly turn off the phone by pressing the power button for 10s.

Message last modified on May 15, 2018 09:50PM

nj...@gmail.com <nj...@gmail.com> #333May 15, 2018 10:55PM

All mapping apps have stopped working on Huawei Mate 9, Mate 10 lite and P10... really annoying

da...@justeattakeaway.com <da...@justeattakeaway.com> #334May 15, 2018 11:06PM

Re:

Comment #332

Google *have* acknowledged this and have explained they are working on a fix. Search this thread for '...@

google.com' to see their engineer's comments.

There's no need to comment if you want to be informed of updates, just star this issue. If this issue has the same root cause as the related issues I reported #171, then I can tell you that 98% of reports of the crash seen in #171 are on Huawei devices, and mostly running on Android 7 & 8. There's a handful of other devices too, but it does appear linked to the CPU architecture on Huawei devices primarily. The vast majority of reports on this thread are referencing Huawei devices.

av...@google.com <av...@google.com> #335May 15, 2018 11:41PM

In collaboration with Huawei, Google engineers have identified the root cause of this issue as an unexpected change to the filesystem permissions. The issue can impact any Android app on a Huawei device which renders a Google map.

Our engineers are preparing a new version of Google Play Services which should resolve the problem. It will be targeted to devices running Android 7.0 Nougat, or higher. We will post another update with the status of the rollout.

Thanks for your patience.

ab...@citydrive.mx <ab...@citydrive.mx> #336May 16, 2018 02:07AM

Such a relief to read these good news!
Thank you very much to you guys engineers at Google.

Greetings from México.

st...@gmail.com <st...@gmail.com> #337May 16, 2018 02:14AM

Nice!!!
Is good to know new news!!

Thank you very much to you engineers guys!

Regards from Chile!

je...@gmail.com <je...@gmail.com> #338May 16, 2018 05:52AM

Nice !! when this new Google play service version is going to be released? @av...@google.com

mh...@coastalpk.com <mh...@coastalpk.com> #339May 16, 2018 05:58AM

I am also facing this issue in My Huawei P10 lite model. Attached is the picture for reference.

Hammad from Karachi, Pakistan.

32526000_1577057665751082_529909586056970240_n.png

20 KB

bh...@gmail.com <bh...@gmail.com> #340May 16, 2018 06:36AM

Facing the issue with Honor 8 (FR)
No temporary solution as described by other users works. Very annoying.

an...@google.com <an...@google.com> #341May 16, 2018 08:08AM

*****************************************************************************
For developers viewing this issue: please click the 'star' icon to be
notified of future changes, and to let us know how many of you are
interested in seeing it resolved.
******************************************************************************

av...@google.com <av...@google.com> #342May 18, 2018 02:33AM

We are pleased to report that a beta version of Google Play Services is ready. We believe this version mitigates the issue on Huawei devices running Android 7.0 Nougat, or higher. An important caveat is that each time the device is rebooted, you will need to wait about one minute before launching the affected applications.

Starting today at midnight (Pacific Time), the beta will be rolled-out to a segment of the community that has signed-up for the Google Play Services Public Beta Program. It will ramp to increasing segments of the beta audience over the next few days. We invite you to join the beta program at

https://developers.google.com/android/guides/beta-program to obtain an early release of this and future versions of Google Play Services. Once beta testing is complete it will be rolled out in stages to all users.

as...@google.com <as...@google.com> #343May 18, 2018 09:07AM

To clarify the caveat mentioned in

comment#342

, if you launch an affected application before one minute passes, you will just find the same issue, there is no severe implications.

le...@pinkfroot.com <le...@pinkfroot.com> #344May 18, 2018 03:06PM

And will there be a longer term fix not needing the caveat?

Also the "no severe implications". Can they just carry on waiting or will it need another reboot if they open within that minute?

ex...@gmail.com <ex...@gmail.com> #345May 18, 2018 03:07PM

If applicable, can tests be added to CTS so that no phone is relased with same problem anymore?

no...@gmail.com <no...@gmail.com> #346May 18, 2018 03:44PM

Suffering from the issues mentioned but also android auto wont play music when connected to my car from google music or jet audio.

ma...@gmail.com <ma...@gmail.com> #347May 18, 2018 03:51PM

> An important caveat is that each time the device is rebooted, you will need to wait about one minute before launching the affected applications.

What about severe WIFI connectivity problem? Do I also need to stay away from WIFI connection for a minute after rebooting my Huawei P9?

ma...@gmail.com <ma...@gmail.com> #348May 18, 2018 04:01PM

I updated my phone szerver a couole days ago, but I have a big problem after I did it. I cant use BKK futár on the phone. This is An an important app for me. What can I need to do?

fe...@gmail.com <fe...@gmail.com> #349May 18, 2018 04:02PM

Tested the beta version, on Huawei Nova (CAN-L11), with Strava, Garmn Connect, Sports Tracker, waited more than a minute, after reboot, but still doesn't work!

UPDATE May 21, 2018:
Issue fixed but only after clearing all data in settings - apps - Google
Play services - storage - manage space - clear all data.

Message last modified on May 21, 2018 11:05AM

jo...@gmail.com <jo...@gmail.com> #350May 18, 2018 04:11PM

Is there any way of getting the Google Play store beta version without waiting for it to be pushed to my phone. Would like to see if it works ASAP. Please.

os...@gmail.com <os...@gmail.com> #351May 18, 2018 04:11PM

Why don't you revert the update? Is it that hard to give us the older version (for instance, 12.5.29) until the new one 12.6.73 is stable (you can leave the newer version for the beta program, as long it is clearly a beta)?

og...@gmail.com <og...@gmail.com> #352May 18, 2018 04:26PM

Beta version solved the issue for me.
Mate 10 Lite, Android 7.

Message last modified on May 18, 2018 04:26PM

gi...@gmail.com <gi...@gmail.com> #353May 18, 2018 04:37PM

Beta dont solved issue for me.
Honor 6X, Androi 7, Google Play Services for Instant apps 2.25-release-196137555

PS : This is still 12.6.73, so no fix in it. Just as to wait a while.

Message last modified on May 18, 2018 06:38PM

vi...@gmail.com <vi...@gmail.com> #354May 18, 2018 04:55PM

Honor 8 (FRD-L09)
Google Play services 12.6.73

Issue fixed but only after clearing all data in settings - apps - Google
Play services - storage - manage space - clear all data.

Cheerio

pe 18. toukokuuta 2018 klo 19.37 <buganizer-system@google.com> kirjoitti:

cs...@gmail.com <cs...@gmail.com> #355May 18, 2018 04:56PM

Same configuration for me (Honor 6X, Androi 7), and at first, it did not
work.

Then I cleaned the cache and data of Google play services, and... hura !

So for now, it's OK (so far... ).

Le ven. 18 mai 2018 à 18:37, <buganizer-system@google.com> a écrit :

e....@gmail.com <e....@gmail.com> #356May 18, 2018 05:00PM

I have an Honor 8, Android 7.0; downloaded the beta, restarted phone, cleared cache and data - still not fixed

lu...@gmail.com <lu...@gmail.com> #357May 18, 2018 05:01PM

For the lucky beta tester who solved the issue, have you tried to restart the phone? If you clean all data it works even with the old version, but only until restart...

pi...@gmail.com <pi...@gmail.com> #358May 18, 2018 05:03PM

ad #357 - I was about to write the same. After installation reboot a few times, turn on WiFi, wait an hour or so, then verify whether apps like Uber work and there is no problem with WiFi - especially when you want to disable WiFi and system becomes unresponsive or phone getting hot.

Message last modified on May 18, 2018 05:04PM

mi...@gmail.com <mi...@gmail.com> #359May 18, 2018 05:08PM

I received the same version while in beta. (12.6.73) not fixed.

Maps AND also qr scanner in my banking apps still not working.

Marcel

Op vr 18 mei 2018 19:01 schreef <buganizer-system@google.com>:

ma...@gmail.com <ma...@gmail.com> #360May 18, 2018 05:25PM

12.6.73 is NOT beta version. This is the version that has problems.
By the way, I still have not received Beta version.

And of course 12.6.73 have the same problems you reported on my Honor 9

Message last modified on May 18, 2018 05:26PM

ma...@gmail.com <ma...@gmail.com> #361May 18, 2018 05:37PM

I have installed version 12.6.85 via apk and it SOLVED the problem

pi...@gmail.com <pi...@gmail.com> #362May 18, 2018 05:38PM

Did you reboot? What about WiFi issue?

mi...@gmail.com <mi...@gmail.com> #363May 18, 2018 05:45PM

My p9 lite does not receive a higher version than the latest production
version. Playstore does however clearly show that I'm a beta tester.

It is 6 hours after I signed up as beta tester. Is the beta version pulled
back?

groeten Marcel

Op vr 18 mei 2018 19:26 schreef <buganizer-system@google.com>:

ma...@gmail.com <ma...@gmail.com> #364May 18, 2018 05:50PM

Yes I rebooted. You have to wait 1 minute after reboot and it works perfectly

os...@gmail.com <os...@gmail.com> #365May 18, 2018 05:50PM

Download the apk from apkmirror, it's the easiest/fastest way...Ignore the beta program

wh...@gmail.com <wh...@gmail.com> #366May 18, 2018 05:52PM

If people only read the notes correctly:

It states that the beta is rolled out gradually to beta testers. Version 12.6.73 is not the beta version, it is the version that causes the problems.

fr...@googlemail.com <fr...@googlemail.com> #367May 18, 2018 05:52PM

Huawei P10 - installed version 12.6.85 via apk and it has not solved the problem. Using Uber to test, map not even loading now.

Before this was having issues with loading maps, significant overheating and battery drain.

pi...@gmail.com <pi...@gmail.com> #368May 18, 2018 05:53PM

@364, what about WiFi? Turn it on, keep it on for 1 hour and try to turn off - does it succeed to turn off? Is it able to list access points after an hour or so?

ma...@gmail.com <ma...@gmail.com> #369May 18, 2018 05:55PM

@368
Never had this problem. I will try

@367
You have to wait 1 minute after reboot

Message last modified on May 18, 2018 05:57PM

og...@gmail.com <og...@gmail.com> #370May 18, 2018 06:02PM

First of all check if you have correct version of GPS - beta is 12.6.85.

I am testing it whole day, restarted phone two times and issue with maps is indeed fixed.

Screenshot_20180518-180555.png

158 KB

mi...@googlemail.com <mi...@googlemail.com> #371May 18, 2018 06:02PM

For me, 12.6.85 solved the Problem on my Huawei P20 pro.
Thank you

<buganizer-system@google.com> schrieb am Fr., 18. Mai 2018, 19:56:

fr...@googlemail.com <fr...@googlemail.com> #372May 18, 2018 06:23PM

@369 - I have rebooted the phone multiple times and waited a minute/more, still having the maps issue persist (Google Play services are updating). Cannot comment on overheating/battery drain issues yet.
I have a Huawei P10 VTR-L09.

Edit - also unable to sync my Google account or Authenticate my Google account.

Message last modified on May 18, 2018 06:51PM

an...@gmail.com <an...@gmail.com> #373May 18, 2018 06:25PM

12.6.85, Huawei P20 Pro and still failing

ot...@gmail.com <ot...@gmail.com> #374May 18, 2018 06:27PM

Not that I even partially understand the 'rules' Google applies regarding patches but I feel it would be useful if everyone included the variant they have installed when reporting it does or does not resolve the issue. As a P20 Pro user, my interest is in variant 040408-*, at least I think that is correct. I have signed on to the beta program and am waiting for the update to be pushed. That being said, in checking for new updates, I thought that earlier today I did come across a 040408 variant of 12.6.73 with yesterday's date against it. Can't locate that now but I see a 040408 variant of a new version 12.6.85 has made an appearance in the last few hours or so. Neither variants aforementioned are designated beta yet someone has just reported that 12.6.85 solved the issue for them. For reference, I'm using the Play Services Info app as my source of information regarding variants. Can anyone explain what is happening here?

as...@gmail.com <as...@gmail.com> #375May 18, 2018 06:28PM

Overheating happens in honor 7x as well.

On Fri 18 May, 2018, 11:55 PM , <buganizer-system@google.com> wrote:

os...@gmail.com <os...@gmail.com> #376May 18, 2018 06:31PM

I'd really like to know what's happening here, but likely more than one team working for the same??

av...@google.com <av...@google.com> #377May 18, 2018 06:40PM

As a follow-up to our last update (

comment#342

), we believe this issue is fixed in Google Play Services version 12.6.85. If you are still encountering the problem, please ensure your device has this version installed.

As previously noted, there can be a short delay (usually less than one minute) between the time the OS has finished booting, and Google Play Services starts and resets the permissions. If you launch an affected app before Google Play Services has finished resetting the permissions, it may not render a map. If this happens, re-launch the app after a minute or so. Subsequent launches of the app should succeed every time.

Also, we are happy to report that this version of Google Play Services fixes a known WiFi issue on Huawei devices.

pi...@gmail.com <pi...@gmail.com> #378May 18, 2018 06:43PM

Thanks for the effort and detailed info + info about WiFi issue! Can't wait for having beta available (I don't want to use apkmirror)!

Message last modified on May 18, 2018 09:13PM

da...@gmail.com <da...@gmail.com> #379May 18, 2018 06:47PM

I installed the new version 12.6.85 on my huawei mate 8 DL00 and it seems to work fine. Load applications with maps. I have rebooted 2 times and it continues to work. Hopefully it will continue and be the definitive solution ...
(Before, it was emptying data and it worked, but at the time or when restarting it stopped working, now it seems that it does not ...)

ta...@gmail.com <ta...@gmail.com> #380May 18, 2018 06:48PM

I have factory reset my mate 9 ,it sloves battery issue problem, but still have "google play service updating... "error!!
Nightmare...

mi...@gmail.com <mi...@gmail.com> #381May 18, 2018 06:59PM

Thanks for this info, but does it also fix the qr scanner issues? Our
customers cannot perform payments with using qr codes. All huawei owners.

Marcel

Op vr 18 mei 2018 20:40 schreef <buganizer-system@google.com>:

http://www.apkmirror.com/apk/google-inc/google-play-services/google-play-services-12-6-85-release/google-play-services-12-6-85-040408-197041431-android-apk-download/

fa...@gmail.com <fa...@gmail.com> #382May 18, 2018 07:45PM

Will there also be a version that will correct this "one minute" restriction?
Or is it considered fixed like this?

Message last modified on May 18, 2018 07:46PM

ay...@gmail.com <ay...@gmail.com> #383May 18, 2018 07:51PM

Guys, where do you get the 12.6.85?

br...@gmail.com <br...@gmail.com> #384May 18, 2018 07:53PM

ay...@gmail.com <ay...@gmail.com> #385May 18, 2018 07:55PM

#384, many thanks!!!

br...@googlemail.com <br...@googlemail.com> #386May 18, 2018 08:05PM

Seems good. Uber and a local bus app now functioning fine. Good job boys

On Fri, 18 May 2018, 8:56 pm , <buganizer-system@google.com> wrote:

br...@googlemail.com <br...@googlemail.com> #387May 18, 2018 08:05PM

P20 pro

On Fri, 18 May 2018, 8:56 pm , <buganizer-system@google.com> wrote:

ay...@gmail.com <ay...@gmail.com> #388May 18, 2018 08:20PM

With my mate 9 the 12.6.85 version works perfectly, I've tried all the maps based apps and the problem has disappeared in all of them. The one minute restriction is important, immediately after the reboot I "enjoy" the damned warming. Well, thanks a lot for the great job!

Message last modified on May 18, 2018 08:27PM

jo...@gmail.com <jo...@gmail.com> #389May 18, 2018 08:25PM

I've got the beta version working well. Works with WiFi off and in airplane mode. Honor 9.

mi...@gmail.com <mi...@gmail.com> #390May 18, 2018 08:38PM

I received the update 12.6.85. Apps using maps: Fixed. QR Code scanner in banking app: NOT fixed.
Phone is Huawei P9 lite.

ed...@gmail.com <ed...@gmail.com> #391May 18, 2018 08:38PM

I can only confirm that mine P9 (EVA-L09) received the 12.6.85 (040408-197041431) through beta program and so far it does work ok. Did not have to restart my phone every 1-2 hours to get Wifi to work, phone is not overheating itself and did not notice battery drain.
As for apps - those look ok. Did not have to do absolutely anything to "get it fixed" (so clear cache/data etc) as those steps were done daily before the beta update. The only problem I am seeing here is the 1 minute thing which in my opinion should be fixed.
The 1 minute waiting looks for me like a workaround to the problem, not a solution to resolve it completely.
Could someone from Google comment on this?
I will be honest with you - I think this is first time that I have lost my faith into Android system and I have been "in this" for years and years. Really don't understand how the "problematic" update went live and reached so many users around the globe. Surely there should be some testing first and I doubt that there wasn't any Huawei users out there reporting issues.

ma...@gmail.com <ma...@gmail.com> #392May 18, 2018 08:47PM

I agree with

comment #391

. Unbelievable they released a Play Services version with problems for ALL Huawei users. And I agree that 1 minute thing must be fixed totally

ma...@gmail.com <ma...@gmail.com> #393May 18, 2018 08:51PM

Issues (wifi, battery drain, updating services message) seem to be resolved with .85 on an Honor 8 FRD-L04, but now I'm get REALLY slow battery charge. This happening to anyone else? Never happened before, all of a sudden started happening after the latest version.

sa...@gmail.com <sa...@gmail.com> #394May 18, 2018 08:51PM

all my apps collapsed due to this bug ... users are frustrated ..... i have seen 20 % uninstalls for the older users...... and almost 95 % uninstalls from new users ....

what can I do to fix this ??? as a developer

lu...@gmail.com <lu...@gmail.com> #395May 18, 2018 09:01PM

#384 worked for me on Huawei Mate 9 to solve the map bug. After reboot it took a few seconds to render the map.

As a developer this bug caused a lot uninstalls and 1 star reviews from Huawei user. Google how can we deal it? Have you thought about the damages caused by this bug and how to redeem the developers?

st...@gmail.com <st...@gmail.com> #396May 18, 2018 09:27PM

Hello,

I'm testing the beta version and i can say that this fix the error with my app but...when i open Google Maps all my phone is crash...appear a black windows and after is closed.

I have to desinstal this version because all my telephone started workin very strange.

I have Huawei P9.
Android: 7.0

please check it.

Thanks.

be...@gmail.com <be...@gmail.com> #397May 18, 2018 09:41PM

I've not got the Beta Play Services, but have found that clearing all data for Google Play Services and Google Play Store at least temporarily fixes the issue. Map based apps currently working fine and Google home app correctly linked to my account.

I'd rather not have to keep clearing the data though!

Huawei P20, Android 8.1.0

pi...@gmail.com <pi...@gmail.com> #398May 18, 2018 10:23PM

Finally I got beta - it works. Uber works no problem. I've restarted the phone, and yes - you must wait around 1 minute to have Uber (or other app using g maps service) operating. WiFi issue is gone (waited 1 hour with WiFi on, am able to turn off no problem, phone is not getting hot, no battery drainage spotted). Regarding problem with fast charging ( #393 ) - just attached the original Huawei charger and quick charge engages (I have the newest Huawei updates).
My phone is Huawei p10 lite. Thanks to all G developers for the beta mitigating the issue, I hope the official update will be released shortly.

The question to G devs is whether it is the final solution or just temporal one (that 1 minute delay before I can fully use the phone).

Message last modified on May 18, 2018 10:26PM

br...@gmail.com <br...@gmail.com> #399May 18, 2018 10:53PM

Beta update fixes every app except 'Waze' by the looks of it. Fyi Google, and thank you.

cj...@gmail.com <cj...@gmail.com> #400May 19, 2018 02:36AM

Beta also fixed apps that uses maps. However my android watch got disconnected from wear os since the issue was encountered. It is still Bluetooth paired even after wear os disconnects it though wear os cannot recognize the watch on setup unless I remove the account from the watch (did this before during the workaround but this is a reset that removes all data from the watch). The companion app on my phone haven't retrieved the data yet cause it requires wear os connectivity so reseting the watch will make those data unrecoverable. I think wear os disconnected and failed to recognize the watch because it relies on Google Play Services. I am using Huawei P9 and the Huawei Watch 2 is up to date though.
Is there no other way to reconnect the watch to wear os without removing my account from it? Or will this be covered by this fix?

gv...@gmail.com <gv...@gmail.com> #401May 19, 2018 04:40AM

I have a problem with an app loading maps. ' Google services are updating' message appears instead of loading the map of the city.

br...@gmail.com <br...@gmail.com> #402May 19, 2018 04:42AM

^^ Please please please read the thread before responding....

pe...@gmail.com <pe...@gmail.com> #403May 19, 2018 07:17AM

Problem fixed with beta (12.6.85). No 1 minute delay. Huawei P9.

[Deleted User] <[Deleted User]> #404May 19, 2018 07:22AM

Problem fixed with beta (12.6.85). Huawei P9 lite. Shouldn't have been
allowed to happen, of course; this was a major fail by Google and wasted
hours of my time before I found this thread. Almost as annoying as Huawei's
own EMUI update, which needlessly killed all my settings and preferences
and deleted and all my ringtones...

On 19 May 2018 at 08:18, <buganizer-system@google.com> wrote:

jo...@gmail.com <jo...@gmail.com> #405May 19, 2018 07:53AM

Beta appears so far too have fixed the maps issue.

However, the barcode scanning issue still exists (not sure if this is the thread to mention it, but it appears to have been related as it started at exactly the same time with this services update)

su...@gmail.com <su...@gmail.com> #406May 19, 2018 08:14AM

Solution in

comment #354

worked for me (for 16h now) and I still use 12.6.73 (Honor9, android 8.0.0)

pa...@gmail.com <pa...@gmail.com> #407May 19, 2018 08:24AM

Problem fixed with 12.6.85 on Mate 9 Pro, Android 8.0.0.368, LON-L29!
Apps that were involved: car2go, Sharengo, Mobike, DriveNow, Free2Move (all car sharing apps), and "ATM Milano". All are working since a few hours. Many thanks.

mi...@gmail.com <mi...@gmail.com> #408May 19, 2018 08:50AM

Scanning issue is also caused by this bug.

Please check!

This scanner issue is not fixed.

Op za 19 mei 2018 09:53 schreef <buganizer-system@google.com>:

fe...@gmail.com <fe...@gmail.com> #409May 19, 2018 08:59AM

Problem fixed with 12.6.85 on Huawei P9 (EVA-L09) EMUI 5.0, Android 7.0, however, the silly "one minute rule" should be apply so the solution noz perfect yet!

ma...@gmail.com <ma...@gmail.com> #410May 19, 2018 09:08AM

I'm on 12.6.85, honor9.
All maps applications now works normally (as android auto)
I have some concern about qr-code apps. Can someone please point me to a simple app in market that supposedly may not work with huawei still now? I have a simple qr-code scanning app that appear to work

da...@gmail.com <da...@gmail.com> #411May 19, 2018 09:08AM

Since yesterday with beta 85 and everything is correct in MATE 8.
However this morning I have verified, as commented by a previous user, that what fails, does not load and crashes is the GOOGLE MAPS application !!!! (opens and stays black screen, and blocked .., does not load maps and must be closed)

da...@gmail.com <da...@gmail.com> #412May 19, 2018 09:18AM

Extensive previous comment:
I have uninstalled GOOGE MAPS, reinstalled and it seemed that it was going well, but no, at the moment it has closed again and blocked itself. is all black ...¿?¿?
The rest of applications with maps continue to work well, as well as the wifi and the battery.

so...@gmail.com <so...@gmail.com> #413May 19, 2018 09:19AM

Barcode (Vision API) issue is not fixed with this update. There is a separate error for that:

https://issuetracker.google.com/issues/79653882

Please see attached log. It's from the Vision Api sample app (

https://github.com/googlesamples/android-vision/tree/master/visionSamples/barcode-reader) App hangs in forever loop (trying to load the lib.).

barcode_sample.log

9.2 KB

gu...@gmail.com <gu...@gmail.com> #414May 19, 2018 09:32AM

Hi, mate 8, os 7, EMUI 5.0.1. Beta 12.xx.85 seems work fine.
I have no trouble with apps and battery usage seems like before. For your notice my wife has a Huawei Mate S with os 6 and EMUI 4.0. Since a week her phone began to switch off suddenly with a high drain of battery. Yesterday I insalled the 85 beta version of google service and "magically" the phone began to work fine too...Maybe the 73 version got in trouble also this model with os 6...

c....@googlemail.com <c....@googlemail.com> #415May 19, 2018 11:00AM

Problem seems to be fixed with 12.6.85 on Huawei P10 (VTR-L09), EMUI v. 5.1, Android 7.0.
Installed apk as linked to by #384, restarted phone, waited 1 minute before checking Google Play services version, then launching CitiMapper and Uber. Both working again, showing the map.

an...@gmail.com <an...@gmail.com> #416May 19, 2018 11:08AM

Clear cache and solved with 12.6.85. thanks!!

ot...@gmail.com <ot...@gmail.com> #417May 19, 2018 01:11PM

[Huawei P20 Pro CLT-L09 8.1.0.110 (C782)] [12.6.85 040408-197041431 18 May 2018 - Beta Push delivery] [System restarted - cache etc not cleared]

All map issues bar 1 resolved. Spyglass (map overlaid by compass) not displaying a map but this may well pre-date Play Services issue and may also be due to unfamiliarity with the app on my part.

Barcodes/QR codes are working both with a dedicated app and as a function within other apps. However, I hadn't noticed any problem previously.

A longshot hope that Amazon apps failing to install or update (505 error) issue might also resolve, but it was not to be. Note that Amazon apps initially and automatically installed on the new phone continue to function. UPDATE: Revisited potential solutions and uninstalling ALL Amazon apps before re-installing resolves issue although Prime video install appeared to hang but showed installed after system restart.

Message last modified on May 19, 2018 02:51PM

lu...@gmail.com <lu...@gmail.com> #418May 19, 2018 01:24PM

Everything is fine now. Huawei P10, Android 7. I installed the APK. Thanks!!

jo...@gmail.com <jo...@gmail.com> #419May 19, 2018 02:39PM

Google Play Services beta 12.6.85 installed on Huawei Mate 9 with Android 8.0.0 and everything is working again. Thanks!

em...@gmail.com <em...@gmail.com> #420May 19, 2018 02:42PM

The same problem has my FantaHelp app that integrates Goolge Play
Services and crashes on all Huawei. This is the report:

*java.lang.RuntimeException*:
at android.app.ActivityThread.performLaunchActivity
(ActivityThread.java:2793)
at android.app.ActivityThread.handleLaunchActivity
(ActivityThread.java:2864)
at android.app.ActivityThread.-wrap12 (ActivityThread.java)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1567)
at android.os.Handler.dispatchMessage (Handler.java:105)
at android.os.Looper.loop (Looper.java:156)
at android.app.ActivityThread.main (ActivityThread.java:6523)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
(ZygoteInit.java:942)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:832)
Caused by: *java.lang.SecurityException*:
at android.app.ContextImpl.checkMode (ContextImpl.java:2324)
at android.app.ContextImpl.getSharedPreferences (ContextImpl.java:372)
at android.app.ContextImpl.getSharedPreferences (ContextImpl.java:367)
at com.google.android.gms.internal.zzbx.zzv (Unknown Source)
at com.google.android.gms.internal.zzby.zzw (Unknown Source)
at com.google.android.gms.internal.zzbz.zzw (Unknown Source)
at com.google.android.gms.ads.internal.zzp.<init> (Unknown Source)
at com.google.android.gms.ads.internal.zzp.<init> (Unknown Source)
at com.google.android.gms.ads.internal.zzb.<init> (Unknown Source)
at com.google.android.gms.ads.internal.zzc.<init> (Unknown Source)
at com.google.android.gms.ads.internal.zze.<init> (Unknown Source)
at com.google.android.gms.ads.internal.client.zze.zza (Unknown Source)
at com.google.android.gms.ads.internal.client.zzy.zzcO (Unknown Source)
at com.google.android.gms.ads.internal.client.zzy.zza (Unknown Source)
at com.google.android.gms.ads.AdView.loadAd (Unknown Source)
at fantahelp.plus.MainActivity.onCreate (MainActivity.java:108)
at android.app.Activity.performCreate (Activity.java:6910)
at android.app.Instrumentation.callActivityOnCreate
(Instrumentation.java:1123)
at android.app.ActivityThread.performLaunchActivity
(ActivityThread.java:2746)

Il 19/05/2018 16.39, buganizer-system@google.com ha scritto:

gu...@gmail.com <gu...@gmail.com> #421May 19, 2018 05:33PM

Partially resolved on P20 EML-L29 using the 12.6.85 beta
When I open Uber it works at first. If I try to add another destination on Uber it crashes.

ce...@gmail.com <ce...@gmail.com> #422May 19, 2018 07:43PM

Has anyone checked, how this impacts Google Pay, and WearOS?
Using a "temporary solution" (clearing cache and all data) means also deleting all data from those applications. You have to re-add all your credit cards again, and wipe and reconfigure your smartwatch. Do I have to do it again after updating to 12.6.85 beta?

og...@gmail.com <og...@gmail.com> #423May 19, 2018 07:57PM

You don't have to clear data after updating to beta.

la...@gmail.com <la...@gmail.com> #424May 19, 2018 11:22PM

Beta 12.6.85 -- so far so good on my Huawei Mate 10 Pro

ra...@gmail.com <ra...@gmail.com> #425May 20, 2018 12:06AM

Working fine since updated to v 12.6.85 beta
Mate 8

br...@gmail.com <br...@gmail.com> #426May 20, 2018 08:42AM

Starring. Total overheating of Huawei Chinese ROM P10. Many crashes, unable to make calls or use phone. Deactovated Play Services, phone working fine after that. Only downside, all Google Service based apps useless, incl. Google app feed, bookmarks in Chrome and many local apps.

ef...@gmail.com <ef...@gmail.com> #427May 20, 2018 10:35AM

Hello, I've experienced the issue starting from the last week or so on two devices, Huawei P9 and Mate 9.

Cache clearing the services API did not solve it, did not try clearing all data and instead enrolled into the beta. Beta seems to have the issue fixed.

No issues with the beta so far. This also seems to have fixed a battery drain issue on the P9.

br...@gmail.com <br...@gmail.com> #428May 20, 2018 03:52PM

Same issue with Huawi P9 lite mini. Please help!

la...@gmail.com <la...@gmail.com> #429May 20, 2018 04:26PM

I hate my phone already :(

<buganizer-system@google.com> ezt írta (időpont: 2018. máj. 20., V 17:52):

je...@gmail.com <je...@gmail.com> #430May 21, 2018 01:01AM

I've found the correct Google Play Services app on the APK mirror site for downloading the 12.6.85 fix. BUT my Huawai Mate 9 Pro is is a Version 7 and I only see download versions for Android 6 and Android 8. Which version should I use?

lo...@gmail.com <lo...@gmail.com> #431May 21, 2018 01:04AM

comment #430

Use the Android 6 version if you are running Android 7.

ka...@wikiloc.com <ka...@wikiloc.com> #432May 21, 2018 07:48AM

Is Google Play Services 12.6.85 out of beta? We've been receiving hundreds of reports every day about this issue from our users.

ma...@gmail.com <ma...@gmail.com> #433May 21, 2018 09:14AM

I cant believe that a so critical regression bug, potentially turning thousand of terminals worldwide to be almost unusable,
do not imply an immediate rollback of the currently latest version of google play services back to a working state.
How is it possible ? I agree people in beta channels are aware that regressions can occurs, but not in production,
even more that this critical component is automatically updated everywhere without notifications.

da...@gmail.com <da...@gmail.com> #434May 21, 2018 09:47AM

Can someone confirm if the GOOGLE MAPS application works well with beta 85 ??
(After installation I have solved all the problems, including those of the applications that use maps, battery discharge ..., however the one that now does not work well is GOOGLE MAPS !!!!)

tk...@gmail.com <tk...@gmail.com> #435May 21, 2018 09:50AM

Installed 12.6.85 from beta program and all is fine with this version. At least all map apps have been working unlike before switching to beta. Haven't experienced any other issues. My phone is honor 8 FRD-L19 with emui 5.0.1 and android 7.0

And yes, google maps application works too.

Message last modified on May 21, 2018 10:00AM

je...@gmail.com <je...@gmail.com> #436May 21, 2018 02:07PM

I applied to be a beta tester 5 hours ago and though I'm now a tester, NOTHING has been downloaded to my Mate 9 Pro. How long does it take for them to get it to me? I want the new update NOW. I see that someone else with my phone has said Version 6 will work but their are so many iterations, I'm not sure which one to use. The Architecture is is Aarch64, Resolution is 1440x2560, Software Density is 1440x2560 pixels, Instruction Sets are arm64-v8a.

Message last modified on May 21, 2018 02:11PM

nk...@gmail.com <nk...@gmail.com> #437May 21, 2018 03:16PM

It works!

Message last modified on May 21, 2018 03:26PM

PhotoGrid_1526796664567.jpg

619 KB

ge...@gmail.com <ge...@gmail.com> #438May 21, 2018 03:50PM

My map issue does not fixed, still have to update Gooogle PS after restart but WIFI definately fixed!!!

ge...@gmail.com <ge...@gmail.com> #439May 21, 2018 03:58PM

Finnaly all works as expected. MAPs API and WIFI on/off issues fixe! This google mistake cost me 19EUR to re-flash my phone(due to wifi issue) and I almost send my phone for warranty..

bh...@gmail.com <bh...@gmail.com> #440May 21, 2018 05:57PM

Fixed on the p20 pro! Thanks!

On Mon, May 21, 2018, 04:01 <buganizer-system@google.com> wrote:

2n...@gmail.com <2n...@gmail.com> #441May 21, 2018 06:03PM

Has this version now officially been released? I am not complaining but today I found the new version on my p10 without having signed up for beta.
Btw. It solved all my problems I found since the previous Google Play Services update.

se...@gmail.com <se...@gmail.com> #442May 21, 2018 08:03PM

I fixed issue with changing android interface language from Ukrainian to Eanglish. At first add English as second language then switch to english. Now I have no bug on both languages.
Huawei p10 android 8.0.0 vtr-l29

Message last modified on May 21, 2018 08:29PM

wi...@gmail.com <wi...@gmail.com> #443May 21, 2018 08:45PM

All working fine on .85 now. Thanks.

ci...@gmail.com <ci...@gmail.com> #444May 22, 2018 08:30AM

OK, Google, how will you redeem yourself in developer's eyes??? I've got a lot of negative reviews for my apps in the last 2 weeks, I tried to flag one of them, but your moderators said, that it's all OK, and review remained. Even though there was explicitly written "Google Play services are updating" in it. I guess, you should remove all 4-star and lower marks and reviews from people with Huawei devices (or where device is unknown) for a period, when this bug was in place.
Why do I have to pay for your mistakes by my apps ratings??? Huh, Google?

b....@gmail.com <b....@gmail.com> #445May 22, 2018 09:00AM

Hi all
Huawei has send out an new EMUI (5,01), after I updated, my apps with map funktion i working. (Streetwiev, rejseplan).
I have an Huawei P9.

ed...@gmail.com <ed...@gmail.com> #446May 22, 2018 09:18AM

#445 - EMUI 5.0.1 (not 5.01) is available already for at least half a year for Huawei P9 (EVA-L09).

mi...@gmail.com <mi...@gmail.com> #447May 22, 2018 09:52AM

I am not Google Play Services Beta. But my Google Play Services has updated to 12.6.85 and now everything works fine. Huawei P20 Pro.

ps...@gmail.com <ps...@gmail.com> #448May 22, 2018 09:57AM

Hello.

Can you please confirm that this release (12.6.85) is already being rolled out in production?

I have already received this version on my smartphone without being registered to the Beta version of Google Play Services and some of our customers have also already received it on the production track.

Thank you.

Best regards.

ra...@gmail.com <ra...@gmail.com> #449May 22, 2018 10:37AM

Hi All,

i have applied the Beta Version .85, all google maps depending applications have been solved, also battery issue has been solved.

but another issues have been come up:

1- the screen changed to black, i have to lock the phone, and unlock it for the power switch to fix it.
2- black screen appear suddenly with google maps label, with no maps.
3- the background changed without any action from my side.

do any one have any of these problems.

Device: Mate 8
OS: Android 7 Nougat
EMUI: 5

Thanks

Screenshot_20180522-113059.png

31 KB

av...@google.com <av...@google.com> #450May 22, 2018 02:18PM

Marked as fixed.

As of 10:00 AM (PDT) on May 21, 2018, Google Play Services version 12.6.85 was pushed to 100%, following the initial beta rollout. We believe this resolves the Google Play Services issue on all impacted Huawei devices.

Huawei is working on a longer term solution which is beneficial to its users and developers.

We apologize for this incident and the impact it may have caused. We are conducting an internal investigation of this issue and will make appropriate improvements to our systems to help prevent future recurrence. Stay tuned for an Incident Report.

Message last modified on May 22, 2018 02:45PM

le...@pinkfroot.com <le...@pinkfroot.com> #451May 22, 2018 02:37PM

Thank you.

I still see the same issue though as per the original report in the Play Console's "Pre-Launch Report".

ma...@googlemail.com <ma...@googlemail.com> #452May 22, 2018 02:40PM

Downloaded 12.6.85 which solved the map issues.

Trouble is, I now have 80+ apps that require updating and when you click update they do not appear to be downloading at all. Tried rolling back play store and play services and updating / clear cache / restarting etc but still not able to update apps.

Can anyone help?

Huawei P10

Thanks

ma...@gmail.com <ma...@gmail.com> #453May 22, 2018 02:42PM

Mmm... And what about the new Google maps black screen issue? I'm
experiencing this with x.85 update.

Il mar 22 mag 2018, 16:37 <buganizer-system@google.com> ha scritto: