[LG V20 Guides, News, & Discussion] emdroidle:
There are distinctly suspicious bits in there, such as:

I'd give pretty good odds you would have seen a camera glitch at that moment. Certainly tells me you do a lot more with your phone than I do if the lowmemorykiller is activating so often. Aside from that point though not too much looks particularly suspicious. This though does give us the data point that perhaps using programs which use lots of memory is could be part of what is causing problems.

Don't pay too much attention to lessons you've learned from Windows. Filenames are simply random strings. By convention certain names tend to be certain types of data, but some names are pretty generic. Filenames ending with "txt" are near-universally text files, but filenames ending with ".bin", ".img" or ".image" could be nearly anything. For LG phones/tools generally ".bin" and ".img" are pretty equivalent.

Thanks for the `dmesg` files, though nothing jumped out at me as suspicious.

I wouldn't bet on it. The relationship between the device-tree files and the actual hardware appears to be a two-way street. Often they effect hardware by telling software to program the hardware differently (tell the modem to place its registers at a different address). I've been left wondering how programmable an awful lot of the MSM8996 hardware is; I suspect quite a bit of it is genuine FPGAs which can be nearly entirely reprogrammed at run-time by software.

You might note my kernel source lacks that patch, yet the modem works perfectly. I've ended up with a distinctly mixed opinion of rashed. rashed has a lot of commits which call LG "stupid", yet have almost no description of what they do. rashed started committing an alternative Bluetooth stack, but later found it didn't work. Yet because rashed did it in their primary branch rather than a testing branch, drivers/bluetooth/broadcom is trashed in LineageOS's main branch, doesn't work for AOSP, LineageOS or stock.

I'd been thinking along the same lines, try to find a fixing patch in their tree. Looks like you've had better luck than I. Ultimately I'm guessing I'll need to climb towards the top of their source tree, but that is going to be a distinct task due to the above. :(

In other news I've been working on trying to update system and modem from KDZ file. This is an early test program which mostly tries to implement the task of testing whether a given KDZ file is plausible for updating a given device. Only report (-r) and test (-t) modes work at this point. Report mode simply tells you about the chunks in the KDZ file and whether they exactly match the phone or not.

Test mode simply answers the question of whether it thinks the KDZ can be applied. If it gives the message "KDZ appears applicable to this device", the KDZ appears to be applicable, you should get this message for KDZ files which are later than the one installed on your device. The message "KDZ appears applicable to this device and matches original" is supposed to only appear if the KDZ file is the one which your phone was on when you started DirtySanta.

"KDZ does not appear applicable to this device" should appear if the KDZ is a mismatch. Ideally this will appear if you point it at a H910, H918, US996 or other V20 variant KDZ. Alas I'm fearful of how precisely I've managed to target the matching process. There are lots of spots on the V20 that vary between firmwares and I'm not too optimistic I've managed to target things precisely enough. :(

Writing isn't yet implemented, so this should be safe. Note, this was designed for running inside TWRP, though it may well work at a root shell.

MD5: 7fbd83694d4746a56d6b83e3f05108dd

SHA160: 0a6bb18ff63ea1485f3523d9c29a399adea6ba46

SHA512: 1615ca00051dfd031026c33cd9b822e36ce3a0d96015aaca2e762aeb3c0ef18cf1d0eb0f91d0cdfde7521d8d4701c0d3338bf734eb988aeba94a3cc10590f74a