Status Update
Comments
wa...@gmail.com <wa...@gmail.com> #2
FWIW, it's pretty easy to test this. I built the chromeos-6.1 kernel and put it on Kukui. When I picked CONFIG_ARM64_PSEUDO_NMI
and then added irqchip.gicv3_pseudo_nmi=1
to the kernel command line then the device didn't boot. When I added
pu...@google.com <pu...@google.com>
pu...@google.com <pu...@google.com> #3
I assume this thing doesn't have an ITS to do MSIs? because it also seems to throw the LPI configuration under the bus, which is... unfortunate...
wa...@gmail.com <wa...@gmail.com> #4
I assume this thing doesn't have an ITS to do MSIs?
It doesn't seem to. I get no hits from:
git grep arm,gic-v3-its -- arch/arm64/boot/dts/mediatek/
pu...@google.com <pu...@google.com> #5
At least missing from the list:
- GICR_CTLR
- GICR_ISPENDR0
- GICR_ISACTIVER0
- GICR_NSACR
Note that the restore order is crucial so that no data get lost (secure config first, then interrupt state). I haven't checked the actual implementation.
wa...@gmail.com <wa...@gmail.com> #6
At least missing from the list [...]
OK, thanks for the heads up. I will leave it to someone who knows this stuff better to say how urgent getting this fixed it. This problem would basically affect all Mediatek Chromebooks ever shipped. While we could certainly do a firmware update for them if this is a critical issue, if nothing else we'll need to support booting recovery images from the read-only firmware which will never have this fixed.
wa...@gmail.com <wa...@gmail.com> #7
[...] if nothing else we'll need to support booting recovery images from the read-only firmware which will never have this fixed.
This also brings up the topic of detecting this problem from the kernel. I brought this up in
It looks like the best way would be to use SMCC calls, so ideally we'd use ARM_SMCCC_ARCH_SOC_ID
to detect that we're on an affected Mediatek SoC and then define some Mediatek-specific "SiP" (Silicon Partner) call to detect the workaround. Unfortunately, older Mediatek boards (like 8183) don't implement the ARM_SMCCC_ARCH_SOC_ID
call. :( I guess we may have to detect those CPUs with something like of_machine_is_compatible()
and then call the Mediatek-specific SiP call. Does that sound reasonable? I'll see if I can code something up.
pu...@google.com <pu...@google.com> #8
pNMI really is a debug feature. Why should it be enabled by default?
We keep it off by default because it is known to show how broken firmware is, specially on the mobile side of things (this MTK stuff is a shining example of getting it spectacularly wrong).
I really wouldn't expect a recovery image to force pNMI on, if ever.
ni...@gmail.com <ni...@gmail.com> #9
pNMI really is a debug feature. Why should it be enabled by default?
We want it enabled by default because we want to be able to do in-the-field NMI-based backtraces when the hardlockup detector detects a lockup. That will enable us to act on a lot more kernel crash reports that today are opaque because we don't have the call stack of the most important CPU in the system: the one that is locked up.
If it's really just these priority registers that need saving / restoring then it doesn't seem like it would be that huge of a deal.
da...@gmail.com <da...@gmail.com> #10
FWIW: I managed to get ahold of the latest Mediatek Chromebook I was aware of (8186) and I confirmed that the problem still exists there.
ah...@gmail.com <ah...@gmail.com> #11
First of all, does this save/restore happen only during system suspend/resume, or also in other cases (e.g. cpuidle)? Remember that we don't need to support system suspend/resume for recovery mode.
Also, if the feature is only used to provide extra debugging output for hardlockups, is that really relevant to recovery mode in the field? I mean, hopefully we don't have any hardlockups in such a controlled environment to begin with? And if we do, does it make a difference for the practical user experience if this works right or not (i.e. does the kernel actually recover from this lockup or does it just print out more debugging information before dying)? Remember that we don't get any crash reports from recovery mode either, so the only difference this could make is if it prevents the recovery process from being successful when it otherwise would be.
If we really need to figure out a way to check the running firmware version from the kernel and apply hacky quirks based on that we can try to come up with something, but I'd rather avoid that if at all possible. (The most straight-forward would probably be to parse /firmware/chromeos/firmware-version in the device tree.)
da...@gmail.com <da...@gmail.com> #12
First of all, does this save/restore happen only during system suspend/resume, or also in other cases (e.g. cpuidle)? Remember that we don't need to support system suspend/resume for recovery mode.
cpuidle. We can't even boot a recovery image with this buig.
Also, if the feature is only used to provide extra debugging output for hardlockups, is that really relevant to recovery mode in the field?
We don't need this for recover images. We just need it not to crash. If we simply enabled psuedo-NMIs unconditionally then they would be enabled in recovery images and we'd crash. It's not trivial to disable these just for recovery images.
If we really need to figure out a way to check the running firmware version
I ran out of time today, but I at least posted a WIP (I didn't even try to compile it) at mediatek,gicr-save-quirk-fixed
property into the GIC node if they get a fix.
jo...@gmail.com <jo...@gmail.com> #13
OK, I've posted up a series for the kernel. If this lands then at least the kernel won't crash and it'll be up to the firmware to fix the problem and then patch the device tree.
Somehow something got confused (not sure what yet) and the cover letter and the last patch have the same message ID. :( It still seems like these can be found at:
th...@gmail.com <th...@gmail.com> #14
v2 posted:
NOTE that 8186 is no longer supported by my patch series because Corsola isn't upstream yet. :(
pi...@gmail.com <pi...@gmail.com> #16
Marc landed the code and bindings patch (thanks!). I'll plan to wait until I see the DT patches land, pick everything FROMGIT, and then check to see where mt8186-corsola status is since my patch series didn't include that (it's not upstream yet). Still hoping to hear some status update for the firmware fix.
Description
What
User experience
What type of Android issue is this?
Fingerprint Auth
What steps would let us observe this issue?
What did you expect to happen?
Double press power button should launch camera WITHOUT requiring fingerprint unlock
What actually happened?
Double pressing power button launched camera app but would attempt to scan finger print instead of allowing user to press shutter button (user missed the photo because of this)
What was the effect of this issue on your device usage, such as lost time or work?
Slight
Additional comments
I was hiking when this happened to me. It wasn't every time I launched the camera app from an off lock screen, but it did happen more than once on the current OTA update I'm running. I tried to replicate it just now but it worked as expected. I'm wondering if there was something to do with proximity sensing from coming out of my pocket, the double press timing on the power button, or something else, but it did make me miss the picture and it wouldn't let me take a picture until I got it to scan my fingerprint properly.
Tis my first time joining the beta team and first time running a bug report so please don't hesitate to reach out for clarification on anything.
When
Time and frequency
When did this happen?
Jun 5, 2024 2:58 PM GMT-06:00
How often has this happened?
Occasionally
Where
Component
Suggested component: <not visible> (1498455)
Build and device data
- Build Number: google/husky_beta/husky:VanillaIceCream/AP31.240426.023.B4/11882682:user/release-keys
(Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)
- SoC Revision: Zuma B1
Debugging information
Google Play services
com.google.android.gms
Version 242213039 (24.22.13 (190408-638740827))
System App (Updated)
Android System WebView
com.google.android.webview
Version 642214833 (125.0.6422.148)
System App (Updated)
Network operator: AT&T
SIM operator: AT&T
Filed by Android Beta Feedback. Version (Updated): 2.43-betterbug.external_20240522_RC03 (DOGFOOD)https://developer.android.com/preview/feedback#feedback-app .
To learn more about our feedback process, please visit