• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

Question Occasionally crash to "waiting to flash full ramdump"

Search This thread

vinotux

Member
Apr 3, 2021
26
20
Hi, sorry if this question was asked before by another user but my phone occasionally crashes to the waiting to flash full ramdump (or something of that sort) out of nowhere. After crashing, I could just force shut down the device using the volume keys and boot up normally again.

This only happens once or twice a week - my phone is unlocked and is sporting the latest kirasakura kernel.

Do you guys have any ideas on how to fix it?

Thanks in advance :)
 

MarekPietrzak

Member
Apr 13, 2021
10
2
Hello, I had same issue, it is caused by custom kernel, on .176 firmware both kernels listed on XDA are quite unstable. Just restore stock kernel by using payload dumper on firmware file and flashing boot.img, dtbo.img and vendor_boot.img using fastboot.
To keep root, patch boot.img with magisk before flashing.
 
Last edited:
  • Like
Reactions: vinotux

JazonX

Senior Member
Dec 16, 2009
1,898
757
Xiaomi Mi 11 Ultra
Hi, sorry if this question was asked before by another user but my phone occasionally crashes to the waiting to flash full ramdump (or something of that sort) out of nowhere. After crashing, I could just force shut down the device using the volume keys and boot up normally again.

This only happens once or twice a week - my phone is unlocked and is sporting the latest kirasakura kernel.

Do you guys have any ideas on how to fix it?

Thanks in advance :)

Did you flash the DLKM module?
 
Hello, I had same issue, it is caused by custom kernel, on .176 firmware both kernels listed on XDA are quite unstable. Just restore stock kernel by using payload dumper on firmware file and flashing boot.img, dtbo.img and vendor_boot.img using fastboot.
To keep root, patch boot.img with magisk before flashing.

You probably shouldn't be starting rumors like that, especially without any legitimate proof. The reports are few and far between, but also addressed promptly. Neither of the kernels is "quite unstable" and the issue has happened on stock.
 

MarekPietrzak

Member
Apr 13, 2021
10
2
You probably shouldn't be starting rumors like that, especially without any legitimate proof. The reports are few and far between, but also addressed promptly. Neither of the kernels is "quite unstable" and the issue has happened on stock.
I don't intend to insult anyone, I just shared my personal experience, on previous firmware version both kernels worked fine and stable, but on .176 I had constant crashes with "waiting for flashing full ramdump" message. When I restored stock kernel, this issue no longer persisted. I will for sure try again custom kernel, but in two weeks or longer, as ROG phone 5 is my primary device and I need to stay in contact. I will try to reproduce this issue and grab logs. Now I can share my observation, that those crashes occurred when device was idle, and usually on charger.
 
  • Like
Reactions: vinotux
Thanks for your response, do I need to? I flashed using FKM and not TWRP

You honestly shouldn't need it at all anymore. I believe AnyKernel took the lead and fixed the issue, but it was only TWRP that needed it.

I don't intend to insult anyone, I just shared my personal experience, on previous firmware version both kernels worked fine and stable, but on .176 I had constant crashes with "waiting for flashing full ramdump" message.

No worries. I was only making sure it was clear this was a recent issue and not an ongoing problem. Kirisakura spans a lot of devices and got the reports much later, so a slight delay in the fix should be expected.
 
Last edited:

vinotux

Member
Apr 3, 2021
26
20
You honestly shouldn't need it at all anymore. I believe AnyKernel took the lead and fixed the issue, but it was only TWRP that needed it.



No worries. I was only making sure it was clear this was a recent issue and not an ongoing problem. Kirisakura spans a lot of devices and got the reports much later, so a slight delay in the fix should be expected.
Great, I'll just reevaluate when the new update rolls out, thank you 😁.
 
Great, I'll just reevaluate when the new update rolls out, thank you 😁.

Make sure to perform a backup of anything important, even if you are staying with stock. It appears the issue may go beyond something as simple as installing a custom kernel, assuming the issues reported on both are related.

Finding the common denominator, as they say, might find the root cause, but that is a pretty big task. It would also require more than one report and I only have the one.
 

vinotux

Member
Apr 3, 2021
26
20
Make sure to perform a backup of anything important, even if you are staying with stock. It appears the issue may go beyond something as simple as installing a custom kernel, assuming the issues reported on both are related.

Finding the common denominator, as they say, might find the root cause, but that is a pretty big task. It would also require more than one report and I only have the one.
Actually I flashed your kernel and it's been smooth sailing since then. I'm a little too busy to diagnose the root cause of the problem 😅.
 
Actually I flashed your kernel and it's been smooth sailing since then. I'm a little too busy to diagnose the root cause of the problem 😅.

Fair enough. It shouldn't be on you to do it anyway. With any luck, i'll have debugging sorted out before the end of the weekend with proper instructions to avoid all the guesswork.

 
An error happens, the kernel logs the issue, the device reboots. This is how things are supposed to work. When disabling debugging, an error happens and the device reboots. The logging step is skipped, but life continues.

The problem is when debugging is partially disabled, but still attempting to write. This is basically why there is a "waiting for ramdump" message. It is waiting for the logging to complete to proceed to the next step.


This commit set the stage for a future break, which happened in the .176 update when printk_buffer_rebase replaced get_last_shutdown_log.
 
Last edited:

vinotux

Member
Apr 3, 2021
26
20
Hi, just a quick update.

I had been experiencing major issues and the waiting to flash full ramdump debacle had gotten extremely frightening. The phone wouldn't recognize the IMEI of the device, wifi wouldn't work, etc. The error happened multiple times a day. I took it to ASUS and they basically told me to f off due to my phone being unlocked.

As a last resort, I flashed the .151 RAW firmware and I swear all of the problems vanished. If I was a betting man, I'd say that the .176 update caused all of the problems since I've used the device for a week now without any problems thus far.

Major thanks to @twistedumbrella and others for replying to this thread.
 
  • Like
Reactions: twistedumbrella

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    Hello, I had same issue, it is caused by custom kernel, on .176 firmware both kernels listed on XDA are quite unstable. Just restore stock kernel by using payload dumper on firmware file and flashing boot.img, dtbo.img and vendor_boot.img using fastboot.
    To keep root, patch boot.img with magisk before flashing.

    You probably shouldn't be starting rumors like that, especially without any legitimate proof. The reports are few and far between, but also addressed promptly. Neither of the kernels is "quite unstable" and the issue has happened on stock.
    2
    Hi, sorry if this question was asked before by another user but my phone occasionally crashes to the waiting to flash full ramdump (or something of that sort) out of nowhere. After crashing, I could just force shut down the device using the volume keys and boot up normally again.

    This only happens once or twice a week - my phone is unlocked and is sporting the latest kirasakura kernel.

    Do you guys have any ideas on how to fix it?

    Thanks in advance :)

    Did you flash the DLKM module?
    1
    Hello, I had same issue, it is caused by custom kernel, on .176 firmware both kernels listed on XDA are quite unstable. Just restore stock kernel by using payload dumper on firmware file and flashing boot.img, dtbo.img and vendor_boot.img using fastboot.
    To keep root, patch boot.img with magisk before flashing.
    1
    You probably shouldn't be starting rumors like that, especially without any legitimate proof. The reports are few and far between, but also addressed promptly. Neither of the kernels is "quite unstable" and the issue has happened on stock.
    I don't intend to insult anyone, I just shared my personal experience, on previous firmware version both kernels worked fine and stable, but on .176 I had constant crashes with "waiting for flashing full ramdump" message. When I restored stock kernel, this issue no longer persisted. I will for sure try again custom kernel, but in two weeks or longer, as ROG phone 5 is my primary device and I need to stay in contact. I will try to reproduce this issue and grab logs. Now I can share my observation, that those crashes occurred when device was idle, and usually on charger.
    1
    Hi, just a quick update.

    I had been experiencing major issues and the waiting to flash full ramdump debacle had gotten extremely frightening. The phone wouldn't recognize the IMEI of the device, wifi wouldn't work, etc. The error happened multiple times a day. I took it to ASUS and they basically told me to f off due to my phone being unlocked.

    As a last resort, I flashed the .151 RAW firmware and I swear all of the problems vanished. If I was a betting man, I'd say that the .176 update caused all of the problems since I've used the device for a week now without any problems thus far.

    Major thanks to @twistedumbrella and others for replying to this thread.