With the ongoing work on the log shaker, it would be very useful to be able to access /proc/last_kmsg :)

Do you know what we should be doing to get /proc/last_kmsg ?

/proc/last_kmsg is created by kernel/drivers/staging/android/ram_console.c But not sure how to enable it so far :(

I know this. Can we get T2M to make it work? The ram_console driver is enabled, but we may lack the persistent_ram one, and both looks like they need to be declared in the device tree to get loaded properly. But this needs some memory space defined to be used, etc. So I don't have time to investigate much more.

The smoketest blocker bug 1122119 took a huge amount of time to get diagnosed because of the lack of kernel logs. Having this feature would really help QA to save some time. Bhavana, can we ask T2M to look into this?

Hi Wesly, Could you please help to find t2m to support this task? maybe they can provide a quick solution before next solution. Thank you.

First I would like to understand more about the need, sounds like we want to enable kernel log (/proc/last_kmsg), or? And we would like to enable it in pvt build or based image? (maybe both?) Since we expect v18D is the last Flame KK base image release and is moving focus to L, is this a must have/hard blocker for anything? Maybe we can put such request to the on-going L-porting and release, doing by t2M now? Or a local/test build image w/ this change will be sufficient?

Given there are several issues that manifests by kernel panic on the current base image, I don't see a strong reason this should not be fixed on KK image. Having it only on pvtbuild and in the sources we have on github would be fine for me, we may not need a new official base image from T2M: kernel is free from blob, so we can still easily redistribute it.

(In reply to Wesly Huang from comment #6) > First I would like to understand more about the need, sounds like we want to > And we would like to enable it in pvt build or based image? (maybe both?) PVT builds are enough for now I think. > Since we expect v18D is the last Flame KK base image release and is moving > focus to L, is this a must have/hard blocker for anything? As the regression seen in bug 1122119 will re-land in the foreseeable future, this would be a really nice to have in the current release.

I think one possible way is to have a quick patch from t2m to enable it, then we can have it in our pvt build.

Wesly, the latest comments clarify what we need, please note this is a critical requirement for QA ....WE lost a lot of time debugging this across QA/dev resources in the world, had to reset devices every single day due to the white screen issue...so hoping you can help here. Once we have the patch viral or releng should be able to help.

sorry for late, sick leave and biz trip for past 3 days, already asked T2M's support (patch for enabling /proc/last_kmsg) for this and will call them again later for follow up.

Per T2M's feedback this will need further support from QCT to have it enabled. @Youlong: as discussed would you put more detail in here? Thank you.

hi all - for this issue, it'll add ram console driver in kernel, and we've apply a case for this problem, 01899981. if qcom feedback i will update status. tks.

Bug 1130035 has the symptoms of a kernel panic. Probably a different cause from bug 1122119.

Any news on this topic?

patch qcom provided for last_kmsg

Cool :)

Just one question: is this really for Flame? I see that the patch changes the msm8974 device tree description, but the Flame uses a msm8210 SoC and the DTB is 8610.

I can get last_kmsg after the second boot after flashing \o/ And it seems to be properly populated!

So we have last_kmsg working properly, except when I trigger the crash :(. When I reboot my device after the white screen, persistent_ram do not find previous memory: > [ 0.066411] persistent_ram: no valid data in buffer (sig = 0x00000000)

Clearing the NI while the issue in comment 20 gets addressed. Out of curiosity :gerard-majax, against which crash did you test in comment 20? Bug 1130035, bug 1122119, or another?

I'm getting the same issue as described in comment 20 :(

Comment on attachment 8561242 [details] Kernel PR You didn't write this patch. :) The patch comes with a proper commit message and author information that we should use.

(In reply to Michael Wu [:mwu] from comment #23) > Comment on attachment 8561242 [details] > Kernel PR > > You didn't write this patch. :) > > The patch comes with a proper commit message and author information that we > should use. The patch was for msm8974, I changed and did a little cleanup for 8210/8610 :)