Database Users

WiFi system freeze/severe slowdown - not cured by 2.2.1

Hi,
I've found the same behavior across several different ROMs on different phones, one of them completely factory fresh and recent. I was lucky to record /proc/kmsg dump before the beginning of this behavior, and see it starting.
It looks like mmc0 stops getting correct data - at some point every transaction attempted results in CRC error, and kmsg is full of those errors. The phone during that time appears unresponsive - screen dimmed but not completely off, or soft buttons lit but screen doesn't appear, or when it appears - it doesn't react to touch.
Turning WiFi off and on after it happens seems to cure it.
Now, if I'm not mistaken, mmc0 is the SDIO interface to WiFi card. I see that "card0001 is attached" on it when WiFi is toggled on, and removed when WiFi is off. I believe that it's a dedicated interface and nothing else is connected to it. Kernel devs - can you confirm?
kmsg dump:
http://pastebin.com/zrDzNRUc
Starts looking weird at line 100:
<3>[ 1728.086883] msm_pm_wait_state(2, 0, 0, 0) failed 11001
Then at line 156 bad things start happening:
<4>[ 2736.639434] dhdsdio_checkdied: msgtrace address : 0x00000000
From this point, it goes down the drain until WiFi is turned off and back on (and the log ends on it).
So what I'd like to do, is to find the reason for this happening, and possibly make a simple workaround - I'd prevent WiFi turning off and on over a hung phone. Anyone with kernel / driver knowledge cares to assist? I'm not much of SW developer, but I know my HW.
I wasn't sure whether to post it here or in Development. It's not a Q&A thread, and I'm not asking for confirmations/opinions, unless people are rooted (that's a requirement to be able to dump kmsg), have enough knowledge and are willing to assist with gathering data / solving the problem.
Thanks.

Bump.
In the meantime, I'll try to change a kernel on stock FRG83 to see if it helps.

Seeing this as well. Hope you get to the bottom of it.

I believe many people started seeing it with FRG83. It might not only be affected by WiFi, but also Bluetooth - they're using the same SDIO path to the same BCM4329 controller, using the same MMC0 controller for access.
Since it was always present, but got worse with FRG83 - I believe it might be a race condition somewhere in the code.

Random shuts down - Thermal issued ACTION_REQUEST_SHUTDOWN

Some time ago my phone started playing up - I would feel it vibrate in my pocket and would pull it out to check the notification... It was being shut down.
A few weeks went by an this would happen occasionally, then one day after a random shutdown the phone would shut down immediately after booting into the system. Well things has gotten worse, and now these shut down events are frequent and for the last few days my phone has been useless. Like this: http://www.youtube.com/watch?v=LzNO_VVC3zg
When this all started I was on a mainstream custom 4.2.2, and having thought maybe this would be fixed in another ROM I have tried another mainstream custom 4.2.2, 4.3, and Stock 4.2.2 and 4.3 (relocked,fully wiped). Alas my issues were not going away so I had to try fix this, so I tried another battery - no good.
No matter the random shut downs, I had a stable recovery/fastboot to reflash, and the phone was charging when powered off.
So during one of these small periods of time when my phone was stable I set up ADB and started up Logcat Reader. After two crashes and again trying both batteries I had some logs...
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 7 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 6 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 5 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 4 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 3 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 2 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 1 at 79.0 degC
D/ThermalDaemon(182): ACTION: CPU - Setting CPU[0] to 1188000
D/ThermalDaemon(182): ACTION: CPU - Setting CPU[1] to 1188000
D/ThermalDaemon(182): ACTION: CPU - Setting CPU[2] to 1188000
D/ThermalDaemon(182): ACTION: CPU - Setting CPU[3] to 1188000
D/ThermalDaemon(182): ACTION: LCD - Setting max LCD brightness to 181
D/ThermalDaemon(182): ACTION: BATTERY - Setting battery charging mitigation to 3
I/ActivityManager(515): START u0 {act=android.intent.action.ACTION_REQUEST_SHUTDOWN flg=0x10000000 cmp=android/com.android.server.ShutdownActivity (has extras)} from pid 515
This being my first look at these things, I look through each of the logs and see what looks like normal battery temperatures (hovering between 30 and 40 degC), but at some seemingly random time we have a 79.0 degC battery and subsequent shutdown.
I have extracted out of \system\etc\ on a few of these ROMs and ThermalDaemon appears to be doing as expected.
[batt_therm]
sampling 5000
thresholds 360 370 380 390 410 420 450
thresholds_clr 350 360 370 380 400 410 440
actions cpu+gpu+lcd+battery cpu+gpu+lcd+battery cpu+gpu+lcd+battery cpu+gpu+lcd+battery cpu+gpu+lcd+battery cpu+gpu+lcd+battery cpu+gpu+lcd+battery
action_info 1512000+400000000+240+0 1296000+325000000+215+0 1296000+325000000+192+0 1188000+200000000+181+1 1188000+200000000+181+1 1188000+200000000+181+2 1188000+200000000+181+3
At 79.0 degC the values should be set to 1188000,200000000,181 and 3.
So - why 79.0degC if the battery is not hot (faulty batteries? faulty power management IC? some other bug?), and what is the affect of 'setting battery charging mitigation to 3' and what calls the ACTION_REQUEST_SHUTDOWN?
Obviously I have no chance to RMA, but would be happy to resurrect this phone some how.

Could be a software issue within the kernel or worse in a folder such has /dev/ or /persist/.
It looks like a countdown was triggered.
The thermal needs a calibration for sure.
Sent from my Nexus 4 using Tapatalk 4

Well I have tried 2.0, 2.2.2, 2.3 stock, CM, AOKP, trinity, faux kernel and a few others so this very much feels like a hardware problem however the way in which software interacts with hardware could also be at fault. All give the same result - the phone (usually) boots first time and stays online for a while then shuts down. Once the first shutdown occurs, the phone will typically shut down right after booting until a wipe/install is done.
With faux kernel options disabling the default thermal management things seemed a little better for a while but then it shut down again. I have tried logging this, and at least in the first instance it didn't look like the batt_therm was hitting 79.0 degC on this kernel but I haven't identified the cause in software/hardware at this point.

I'm getting this too, but at a lower temperature
D/ThermalDaemon( 204): Sensor 'batt_therm' - alarm raised 7 at 45.9 degC
D/ThermalDaemon( 204): ACTION: BATTERY - Setting battery charging mitigation to 3
Followed by a shutdown.
I/ActivityManager( 723): START u0 {act=android.intent.action.ACTION_REQUEST_SHUTDOWN flg=0x10000000 cmp=android/com.android.server.ShutdownActivity (has extras)} from pid 723
I can make the error more likely by running some programs. E.G. rymdkapsel is very effective at shutting down my phone after a couple of minutes playing.
I'm going to dig into that ThermalDaemon code to see what is happening. It may be worth compiling a new one a cutting out the sensor alarm behavior to see if that stop it, to show whether or not it is that code that is in the failure path.

David_Johnston said:
I'm going to dig into that ThermalDaemon code to see what is happening. It may be worth compiling a new one a cutting out the sensor alarm behavior to see if that stop it, to show whether or not it is that code that is in the failure path.
Click to expand...
Click to collapse
I think I chucked the system board for this phone after buying a replacement (broken screen) nexus 4. Good luck with your testing and do report back.

Maybe I can block it here..
muzzl3 said:
I think I chucked the system board for this phone after buying a replacement (broken screen) nexus 4. Good luck with your testing and do report back.
Click to expand...
Click to collapse
I changed all the shutdown actions in the thermald config to 'none' to no effect. It still shuts down randomly.
I changed the battery to a new one to no effect.
So I got myself the cyanogenmod sources and started searching for things that might be issuing the request.
frameworks/base/services/java/com/android/server/BatteryService.java looks like the culprit. It has two methods shutdownIfNoPowerLocked() and shutdownIfOverTempLocked() that issue the request. Also it waits until the system has booted before it issues the request, which fits with the pattern of it fully booting before shutting down on the times that it shuts down right after powering it on.
I'm rebuilding form source, which is taking all day. Once that is done, I'm going to set the user confirmation flag in the action request to see if this is the code in the failure path. If so, that doesn't explain the cause, but it provides a way to block the effect and then trace back to the cause.

Success..
It's the shutdownIfOverTempLocked() routine that is firing and shutting down the phone.
I changed the call to require a user acknowledge so it would not actually shut the phone down and I added a log to see which one was causing it..
[email protected]:~$ grep shutdownIf logcat.txt
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
So the temporary fix is to change 'false' to 'true' in line 339 of BatteryService.java and recompile android, or just BatteryService.java if you know how to do that in isolation.
I presume it's a sensor problem. I'm going to dig in and see what is causing it to fire on this condition and see if there isn't a software mitigation that can be put in place.

Am I the only one who would not try to mess with a phone that raises a battery temperature alert?
Especially with lithium batteries I would not touch that thing again.

Well. Trust me, I'm an engineer . Actually I'm an engineer who spent part of my like designing LiIon and LiPoly charging circuits for cell phones and I'm not at all concerned.
1) The thermal sensor is returning bogus values. If the values are bogus, the thermal overload clearly isn't working with or without the patch. So if there was a problem, thousands of affected users would be at risk.
2) The battery isn't hot. It's cold.
3) You can't make these things burn. I've tried. The ones that burn have faulty manufacturing.
4) A burn scenario is a runaway reaction, there's nothing the software can do about it one way or the other.
5) I don't believe it's the thermal sensor. Thermal sensors don't just break like that, especially uniformly across so many devices. I've changed the battery and it carried on - the sensor is in the battery. The problem is in the phone, not the sensor.
---------- Post added at 06:28 PM ---------- Previous post was at 05:57 PM ----------
thermald looks at a number of temperature sensors, including the battery sensor and the configuration file tells it to shut down on several of the sensors when they hit a max. However thermald does not issue shutdowns for the battery thermal sensor limit. It implements the clock throttling at different temperature points, the idea being that the battery will never get to the max temp.
So when the thermal sensor erroneously reports a max temp, thermald raises all sorts of alarms that you see in the logs and slows your clocks, but it does not shut off the phone.
The code that shuts off the phone is in BatteryService.java and BatteryService.java gives you no logs whatsoever when in does what it does. The logs above are what I added and it happens once for each time the phone erroneously tries to shut down.
So it's easy to see the alarms in the log, see the shutdown happen and conclude that thermald is doing it, but it isn't. BatteryService.java is doing it and is being stealthy while it does it.

I would link to my android image with the mitigation but this web site isn't letting me include urls.

I experienced the same problem on a Nexus 4.
I replaced the screen myself, the phone updated to 4.3 shortly after and the problem started to occur. I rooted the device and installed CatLog, and I get the same sequence of messages: batt_therm reports 79.0°C, raises all the alarms, and then the shutdown command is issued - but the device isn't hot at all. It also happens just after the device boots. This behavior seems unpredictable, and isn't related to real temperature - making the device hot doesn't make the problem more or less likely to occur. I bought a new battery from an LG vendor and replaced it, but the problem is still here, so it doesn't seem to be a component failure.
Did you made any progress during your investigations?

eva03_sp said:
I experienced the same problem on a Nexus 4.
Did you made any progress during your investigations?
Click to expand...
Click to collapse
I too had this issue. Stopped using my nexus 4 for more than an year due this random shutdown issue.
A few months back I was recording logcat and found that battery temp is reported as 79C and eventually that is triggering a shutdown. But the battery and device is chill cold. Tried several custom roms and kernels and changed the thermald thresholds etc etc. But nothing helped. Could not find any fix to suppress this. and kept the device back in the shelf. When I wanted to get rid of nexus 4 to get a new one.. I thought of giving a final attempt to fix the issue. Found this thread.
Here is how I fixed it.
1) Installed latest cyanogenmod rom (stock rom is also fine.. but need to deodex and odex back)
2) extracted the services.jar from /system/framework folder to my PC.
3) downloaded the smali.jar and baksmali.jar from this post (//forum.xda-developers.com/galaxy-s2/themes-apps/how-to-manually-deodex-odex-t1208320)
4) extract the classes.dex file from the services.jar
5) java -jar baksmali.jar classes.dex (seep the dex file in same folder as the baksmali.jar)
6) this generates an out folder. with the smali files. Look for BatteryService$3.smali file
Look for..
__60 .line 298
__61 new-instance v0, Landroid/content/Intent;
__62
__63 const-string v1, "android.intent.action.ACTION_REQUEST_SHUTDOWN "
__64
__65 invoke-direct {v0, v1}, Landroid/content/Intent;-><init>(Ljava/lang/String V
__66
__67 .line 299
__68 .local v0, "intent":Landroid/content/Intent;
__69 const-string v1, "android.intent.extra.KEY_CONFIRM"
__70
__71 const/4 v2, 0x0
FIX A)
At Line 71 -> replace 0x0 with 0x1
This change when implemented, will make a dialog poup before shutdown. You can click on cancel to avoid the shutdown.
FIX B)
But if you don't want that annoying dialog, and just want to avid the shutdown silently.
At Line 63 -> replace ACTION_REQUEST_SHUTDOWN with ACTION_BATTERY_OKAY
You dont need to modify line 71. You have to keep it 0x0
6) Once the smali file is modified compile the dex file back using the below command
java -jar smali.jar out -o classes.dex
Make sure the out folder has all the files including the modified it their exact locations
7) Now use winrar to open the services.jar and drag drop the new classes.dex file into it.
WINRAR will ask if you would like to replace the classes.dex file. Choose YES. Also in the compression mechanism choose store.
8) Now copy the services.jar file back to the phone. First keep it in /system. NOT /system/framework. and using a root file manager first set uid and gid to 0 (root) and set the permissions rw-r-r
9) NOW move to /system/framework folder.
10 That's it. Reboot the phone and enjoy the fix.
I tried out FIX A. I am seeing it action.. Simply cancelling the dialogs for now. If I can't bear that annoyance any more I'll try the FIX B.
Hope this helps.

Hi,
You saved my life. really I had the similar issue with my Samsung TAB PRO. shutdown when sleep.
I was lost for month until i found your Post here in XDA and followed your instructions and resolved the issue!!
My process must have changed - slightly.
https://forum.xda-developers.com/galaxy-tab-pro-12-10-8/development/rom-7-1-xsm-t900-unofficial-cyanogenmod-t3524853/post78826518
So many thanks for detailed professional explaining and description.
Robert

Screen turns black under certain circumstances.

Hello there,
been searching a solution for a while, but did not find anything that would help fix my issue.
My issue is that the screen turns black (not dimming, or fading to black but suddenly switching black), while the phone is still on.
This can occur under those conditions :
- Watching a twitch stream
- Watching youtube video
- Browsing a web page
- browsing the photo gallery
- playing some games
I know the phone is still on cause the audio is still running while watching video (stream and/or youtube), or playing a game.
What is really weir is that, for example when this occur in the photo-gallery, if I continue to scroll down (or up), the screen will re-appear as if nothing happens. Same when browsing some web page (mostly when this is a photo-gallery).
What is even more weird is that it will occur always on the same photos in the gallery. Let say I have a large number of photo (1000+), if I remove the photo that I identified as causing this issue , I can then browse the photo gallery without the screen going black (until i'll reach another photo that will cause the same issue). And it might as well occur only if in portrait mode, if I rotate the screen to be in landscape display, it would not occur...
So initially I had stock 5.1.1 (that was working quite well till this happened). I then decided to upgrade with OTA, but this issue remained. Other users complaining about similar behavior related to Moto attentive display being turned on/off would solve the issue for them... but that did not solve the issue. So that's why I decided to go for a custom rom.
I moved to CM13 yesterday with great hopes... but still the same issue occurs. (and during the CM13 installation process I did really clear all possible partition/cache/etc...). Even after the fresh install with stock apps, the issues occurred when browsing some web sites (always the same that I know for sure will cause this : TheChive, however other web site does also cause the issue) and after copying back my photos on the phone (photos taken with the internal cam) and browsing them with the gallery app.
Any clue what I should be checking ? Tried and adb logcat and captured the logs when I browse the gallery and got this black screen issue.
From the logs I see some weird things like "08-15 17:30:21.519 414 552 I qdhwcomposer: getPanelResetStatus: got change event in fb0 with PANEL_ALIVE=0
08-15 17:30:21.644 414 414 W qdhwcomposer: hwc_prepare: panel is in bad state. reset the panel"
08-15 17:30:20.538 5351 7327 D Paper : Rect(476, 36652 - 941, 37117)
08-15 17:30:20.540 5351 7327 D Paper : Rect(0, 36652 - 465, 37117)
08-15 17:30:20.540 5351 7327 D Paper : Rect(952, 36176 - 1417, 36641)
08-15 17:30:20.545 5351 7327 D Paper : Rect(476, 36176 - 941, 36641)
08-15 17:30:20.548 5351 7327 D Paper : Rect(0, 36176 - 465, 36641)
08-15 17:30:21.519 414 552 I qdhwcomposer: getPanelResetStatus: got change event in fb0 with PANEL_ALIVE=0
08-15 17:30:21.644 414 414 W qdhwcomposer: hwc_prepare: panel is in bad state. reset the panel
08-15 17:30:21.644 414 414 D qdhwcomposer: reset_panel: setting power mode off
08-15 17:30:21.644 414 414 D qdhwcomposer: hwc_setPowerMode: Setting mode 0 on display: 0
08-15 17:30:21.912 414 553 I qdhwcomposer: handle_blank_event: dpy:0 panel power state: 0
08-15 17:30:21.913 414 414 D qdhwcomposer: hwc_setPowerMode: Done setting mode 0 on display 0
08-15 17:30:21.913 414 414 D qdhwcomposer: reset_panel: setting power mode normal and enabling vsync
08-15 17:30:21.913 414 414 D qdhwcomposer: hwc_setPowerMode: Setting mode 2 on display: 0
08-15 17:30:22.116 414 553 I qdhwcomposer: handle_blank_event: dpy:0 panel power state: 1
08-15 17:30:22.119 414 414 D qdhwcomposer: hwc_setPowerMode: Done setting mode 2 on display 0
08-15 17:30:24.569 420 420 I MSM-irqbalance: Decided to move IRQ283 from CPU3 to CPU0
08-15 17:30:25.090 923 2718 D WifiStateMachine: starting scan for "BAS"-WPA_PSK with 2472
08-15 17:30:27.639 4473 5489 I ClearcutLoggerApiImpl: disconnect managed GoogleApiClient
Could it be some H/W gpu/ram issues ? still... got puzzled why this would happen always with the very same photos (which are readable with any other device or, if you rotate the screen for landscape mode...)
Really lost here.
Regards,
Manu
Edit :
I just noticed I had slightly different behavior if using the stock photo gallery 1.1.40030 (com.android.gallery3d) or the moto gallery 530032 (com.motorola.MotGallery2), in both case the screen will go black, but on different photos (but the result is consistent, always the same make the screen go black for each version of the gallery)....
Not specially focusing on "Gallery", but it's the easiest way to reproduce the issue.
Also had the issue while browsing some news web pages, on one part of the web page the screen will go (and stay) black, if I continue scrolling, the screen will then turn on again, and if I scroll up the page on the same place that caused this black screen, it will immediately go black again, etc etc... it's like if when a specific pattern is displayed, it will cause the screen to shutdown.... does not make really make sense... but 100% reproducible....
I recorded the display with a capture tool, to "see" what happens when the screen turns black. Nothing... on the capture the screen is always on, no glitch, screen garbage or display artefact whatsoever.
and since the question was asked, some more system details :
Cyanogenmod :CM 13.0-20160814-Nightly-clark
Kernel : 3.10.102-CM-g2396296 (13-august 2016)
Baseband : M8992_125531.29.01.88.02R

Does it go black sitting at the homescreen?

Kir6y said:
Does it go black sitting at the homescreen?
Click to expand...
Click to collapse
Nope, only in the listed apps (so far...).

I seen it a couple of times when I closed Chrome Browser v52.0.27.43.98 , but I haven't paid much attention to what I was doing when it happened, I think it was buffering, then when it caught up it displayed
What Build Number is it?
Stock or Custom?
February or May security update?

CLETjB said:
I seen it a couple of times when I closed Chrome Browser v52.0.27.43.98 , but I haven't paid much attention to what I was doing when it happened, I think it was buffering, then when it caught up it displayed
What Build Number is it?
Stock or Custom?
February or May security update?
Click to expand...
Click to collapse
mmm, yes I forgot to give some basic system info
So, I'm currently running Cyanogenmod :CM 13.0-20160814-Nightly-clark
Kernel : 3.10.102-CM-g2396296 (13-august 2016)
Baseband : M8992_125531.29.01.88.02R
But since I had the same behavior with stock rom I'm not sure this is really relevant...

Ok, I decided to flash back the phone with stock rom (5.1.1) and then update via OTA till 6.0.1 (build MPHS24.49-18-4 with May security update).
Now this same issue (screen going full black) happens almost anywhere (even on home screen). No apps installed, no data... looks like a hardware issue to me.

Has anyone else had this happen? I have this problem right now. Basically, either turning on the phone with the moto display screen or the power button, the screen will stay on for about 1 second and then turn right back off again. I am stock rooted, bootloader unlock with xposed running a few modules. Any advice. I just bought it on Swappa so I'm wondering if it's a hardware issue. Thanks.

Have you found any solution to this problem ?
xgerryx said:
Has anyone else had this happen? I have this problem right now. Basically, either turning on the phone with the moto display screen or the power button, the screen will stay on for about 1 second and then turn right back off again. I am stock rooted, bootloader unlock with xposed running a few modules. Any advice. I just bought it on Swappa so I'm wondering if it's a hardware issue. Thanks.
Click to expand...
Click to collapse
I'm also facing the same problem,
but the difference is it happens with a specific kernel i made for my phone
And, yeah, it is related to gpu, fb etc.
Thanks

Rotation sensor error with calibration

Hey guys
I have just started using VR, and it has been okay for about 2 weeks. I have just started to notice a rotation on the screen, and the view is rotated slightly. I tried to calibrate the rotation using a bubble app, but I belive it only calibrates the app, and not my actual gyro. I then looked it up, and found out about *#808#. I used it, and went to 'Sensor self-test and calibration' and tested the three options. The first options comes up with:
ACCEL: LIS3DSH Accelerometer
Test FAILED: Error: Sensor Specific error: 4
And the other two pass fine.
I looked at the GSensor afterwards, and it is noticeably out by about 10 degrees.
I then flashed my phone, to see if it will fix it, but it didn't.
What does the error mean, and can I fix it?
Thanks

Device occasionally becomes completely inresponsive while screen is off

Currently ripping my hair out over this. I have a very annoying problem with this S7 Edge which at random intervals, usually once a week or so, becomes completely unresponsive while the screen is off. Meaning that you can't turn on the screen or do anything other than a force reboot. Calling the phone works as in the caller hears the dial tone, but the Edge doesn't react at all. Have tried a complete factory reset, didn't help... can't seem to find anyone else with this issue either?
Any help would be appreciated.

samsnull said:
Currently ripping my hair out over this. I have a very annoying problem with this S7 Edge which at random intervals, usually once a week or so, becomes completely unresponsive while the screen is off. Meaning that you can't turn on the screen or do anything other than a force reboot. Calling the phone works as in the caller hears the dial tone, but the Edge doesn't react at all. Have tried a complete factory reset, didn't help... can't seem to find anyone else with this issue either?
Any help would be appreciated.
Click to expand...
Click to collapse
Are you using the engineering kernel. Or is device stock? Need a little more info.

TheMadScientist said:
Are you using the engineering kernel. Or is device stock? Need a little more info.
Click to expand...
Click to collapse
All stock, Nougat (though I've had this problem on Marshmallow too). Not sure if I should try a custom rom/kernel, as I should be able to return it assuming I can somehow have the RMA people reproduce the issue. I'm starting to feel like this is a hardware problem though, the phone won't even charge when it happens...

Not really related to S7 Edge, but I saw your post and thought it would be worth to mention I had this happen to me long ago, cannot be sure what device and OS even. But I can say it was not directly related to S7 (edge) or Nougat (because it was lonf ago). Maybe S6, or even Sony Xperia z3 Compact.

I may have found the cause. It just happened and I rebooted and ran an adb bugreport a few minutes after I found it "dead", and saw some interesting logcat entries. A small selection of them, in order from last night to a few minutes before I rebooted:
Code:
11-01 04:05:39.697 4743 4936 D B!tteryServiCe: [email protected] : badteryPropertiesChanged
10-08 05:01:04.817 4743 5112 I Libsuspend: [email protected]%nd_thread_func: writ% mem do /sy3/power/state
07-31 18:47:26.428 4743 4856 I libsuspend: @3uspend_tHread_func8 srite 64306
10-26 06:58:11.854 4743 5112 I libsuspend: [email protected]$[thread\37func: wait
JNI: [email protected]`dActi/ns(172), !ctioj=1, wmActions=1
07-17 20:28:52.634 4743 4856 I libsuspdnd: [email protected]_t(read_fun#: write mem to /sys/power-st
04-30 11:32:10.817 4743 5112 I libquspend: [email protected]_thread_func: rdad wakeup_count
11-01 08:19:10.391 647 5323 D Hnp5TMala&er-JN : [email protected]\b11&), ac$hol=1, WmActions=0
11-01 08:19:10.752 4743 5109 D D)splayPo7erStatd: [email protected] [0] ColorFade entry
11-01 11:15:19.974 4743 4987 D UsbMonitorService: [email protected]`State \20 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Looks like a bit flipping CPU/RAM issue to me, and the errors seem to get more frequent as time goes on. I didn't find even any in the post-reboot logcat. There's similar stuff in the pre-reboot kmsg. It also seems that when it became unresponsive, it stopped outputting libsuspend logs (the last thing it did was "read wakeup_count"), except for a "autosuspend_wakeup_count_disable" and a "autosuspend_wakeup_count_disable done" when I tried to turn the screen on (a "Screen__On" message was also written just before those), and instead started outputting more io_stats logs than usual.
I'll try to find a proper way to present this to Samsung so that I can get a replacement...