Remove All Ads from XDA

3.4 kernel bring-up

1,640 posts
Thanks Meter: 3,930
Post Reply Email Thread
31st July 2014, 10:36 AM |#31  
mrvek's Avatar
Senior Member
Thanks Meter: 462
@kabaldan : those reports about modem crashes you have mentioned are exclusively from CM users? The only I found are on CM bug tracker. Are you perhaps aware of other, possibly from KK official testers?
The Following User Says Thank You to mrvek For This Useful Post: [ View ] Gift mrvek Ad-Free
1st August 2014, 08:20 PM |#32  
Senior Member
Thanks Meter: 54
Hi guys. I apologize for the slightly off topic interruption but only someone who is into the kernel code would have a good chance at being able to answer my question.
I'm running my RAZR M on page plus and for that to work I need to be able to run the ics radio. Every jb version was able to use them just fine but the kk update broke that compatibility. My question is do you think it could be possible to patch the 3.4 kernel to work with the ics/jb radio? In my situation I can still use the kk bootloader do I'm thinking it might be somewhat simpler than your situation on the photon Q. Also since I'm making this post I might as well also thank you guys for working on this, really really appreciate it and even if my idea has no ground to stand I know your working on this could possibly bring a 3.4 kernel build to our jb bootloader as well. Thanks again and I won't interrupt again ☺
The Following User Says Thank You to thewraith420 For This Useful Post: [ View ] Gift thewraith420 Ad-Free
15th October 2014, 05:33 PM |#33  
mrvek's Avatar
Senior Member
Thanks Meter: 462

Just to point few more-less interesting findings.

1) modem watchdog bites in aiplane mode
2) modem watchdog bites without sim card present
3) modem crash log (/data/misc/ril/bp-dumps/modem.log) seems to be successfully written only when modem crashes on SMSM_RESET (which seems to be some bit set by modem). On watchdog bites 16Kb of nothing (0x0) is written
4) according to some reports of other qc baseband crashes the log_modem_sfr() sholud result in "SFR Init: wdog or kernel error suspected." (as seen in smem ramdump), but instead we get "modem subsystem failure reason: (unknown, smem_get_entry failed)."
5) ramdump_modem_{sw/fw}.bin is a lot of 0x0 - this and 4 might indicate some memory misconfiguration or similar issue

The most common "error" seen in smem ramdump is: "gfw_command_process.c
Invalid value passed to GFW in generic config command value passed %d, setting to %d", followed by some binary data which I have no clue how to intrepret. This string can significatly vary in count so it might not be fatal (dumping smem during normal operation and on 3.0.y might be interesting)

Stack dump is as below in vast majority of cases. Assuming it is correct, the issue is strongly related to idle states/suspend. On the other hand, according to some docs, modem disables its watchdog during certain power collapse periods (not clearly specified which).
The most reliable way I was able to find to trigger the modem crash is by toggling screen on/off several times (could be 2-3, might take more, but never fails).

Also, modem's tasks timeout is probably 60s for all tasks except one: "rxtx" (judging by modem crash log and assuming my interpretation of "Timeout" and "Count" table headers is correct. "Is_Blocked" always points to "xtm" and "tlm" tasks, whatever it may mean)
<3>[  138.293270,0] Watchdog bite received from modem software!
<4>[  138.293728,0] [<c00133bc>] (unwind_backtrace+0x0/0xe0) from [<c0057a3c>] (modem_wdog_bite_irq+0x20/0x58)
<4>[  138.294094,0] [<c0057a3c>] (modem_wdog_bite_irq+0x20/0x58) from [<c00d1f28>] (handle_irq_event_percpu+0x84/0x26c)
<4>[  138.294491,0] [<c00d1f28>] (handle_irq_event_percpu+0x84/0x26c) from [<c00d214c>] (handle_irq_event+0x3c/0x5c)
<4>[  138.294704,0] [<c00d214c>] (handle_irq_event+0x3c/0x5c) from [<c00d4c60>] (handle_fasteoi_irq+0xd8/0x124)
<4>[  138.295070,0] [<c00d4c60>] (handle_fasteoi_irq+0xd8/0x124) from [<c00d1834>] (generic_handle_irq+0x20/0x30)
<4>[  138.295467,0] [<c00d1834>] (generic_handle_irq+0x20/0x30) from [<c000e240>] (handle_IRQ+0x7c/0xc0)
<4>[  138.295833,0] [<c000e240>] (handle_IRQ+0x7c/0xc0) from [<c00085e8>] (gic_handle_irq+0x64/0xb4)
<4>[  138.296200,0] [<c00085e8>] (gic_handle_irq+0x64/0xb4) from [<c07fd7c0>] (__irq_svc+0x40/0x74)
<4>[  138.296413,0] Exception stack(0xc0e05f18 to 0xc0e05f60)
<4>[  138.296749,0] 5f00:                                                       00000000 00000018
<4>[  138.297085,0] 5f20: 00000004 00000000 c2de75c0 00000000 c2de75c0 c0e51178 00000000 511f04d0
<4>[  138.297298,0] 5f40: 00000000 00000000 00000000 c0e05f60 c0052704 c0058160 60000013 ffffffff
<4>[  138.297695,0] [<c07fd7c0>] (__irq_svc+0x40/0x74) from [<c0058160>] (msm_cpuidle_enter+0x54/0x58)
<4>[  138.298061,0] [<c0058160>] (msm_cpuidle_enter+0x54/0x58) from [<c0563404>] (cpuidle_enter+0x14/0x18)
<4>[  138.298428,0] [<c0563404>] (cpuidle_enter+0x14/0x18) from [<c05637d4>] (cpuidle_enter_state+0x14/0x6c)
<4>[  138.298794,0] [<c05637d4>] (cpuidle_enter_state+0x14/0x6c) from [<c056399c>] (cpuidle_idle_call+0x170/0x33c)
<4>[  138.299038,0] [<c056399c>] (cpuidle_idle_call+0x170/0x33c) from [<c000e7e0>] (cpu_idle+0x58/0xe8)
<4>[  138.299404,0] [<c000e7e0>] (cpu_idle+0x58/0xe8) from [<c07c8a14>] (rest_init+0x88/0xa0)
<4>[  138.299771,0] [<c07c8a14>] (rest_init+0x88/0xa0) from [<c0d00b4c>] (start_kernel+0x41c/0x480)
<3>[  138.300137,0] modem subsystem failure reason: (unknown, smem_get_entry failed).
<6>[  138.300350,0] subsys-restart: subsystem_restart_dev(): Restart sequence requested for modem, restart_level = 3.
How do you keep track of proprietary blobs and which are compatible? I remember that some blob (libaducal?) was from a samsung device (S3?) at some point. More importantly, how do you know which blobs need to be updated when kernel updates? Is that perhaps documented somewhere? Keeping track of git history is causing me a lot of problems with this so I'd appreciate any pointers to right direction.

Btw., why are OEMs and chipset manufacturers so rigid on their baseband, ril, etc. sources, documentation and datasheets? Solely because of "security through obsucrity"?
The Following 2 Users Say Thank You to mrvek For This Useful Post: [ View ] Gift mrvek Ad-Free
18th October 2014, 05:04 PM |#34  
mrvek's Avatar
Senior Member
Thanks Meter: 462
Just to correct the meaning of dog_state_table[] :

"Count" is time in seconds that the task has left to respond to watchdog task and bite occurs when it reaches 0 (src):
- timeout - the timeout value (currently in seconds) of the task
- count - amount of seconds left the task has to respond
- is_blocked - boolean that is set to 1/true when the task is not currently monitored by dog

This became awfully frustrating.
Good luck.
The Following User Says Thank You to mrvek For This Useful Post: [ View ] Gift mrvek Ad-Free
20th October 2014, 11:15 PM |#35  
kabaldan's Avatar
OP Recognized Developer
Flag Prague
Thanks Meter: 3,930
Donate to Me
@mrvek: I took a break from 3.4 kernel bring-up attempts for a while as I was overwhelmed by the tasks at work and also the demands from the usual family life .
But I'd like to get back to it.
I agree that there seems to be an issue revolving around the shared memory (SMEM).
I plan to investigate it some more.

Regarding the vendor blobs, there's no easy way to cope with it, but basically I chose to use the new blobs everywhere (to match the updated kernel space), unless the blobs relate to modem (qmi - qualcomm modem interface), which includes e.g. the gps related proprietaries.

The audio lib you mention is - we needed to switch the kernel to use ION instead of PMEM everywhere to stay on the track, so we also needed to find a compatible proprietary libacdbloader lib. Initially, mako (Nexus 4) lib was used, but it was not a good match (mako is using APQ8064, not MSM8960, so while close, not getting there in the end). So the issue was later fixed by using HTC One S (ville - htc s4 family) lib, which was the only available good matching ION using alternative at that time.
The Following 4 Users Say Thank You to kabaldan For This Useful Post: [ View ]
21st October 2014, 12:57 AM |#36  
mrvek's Avatar
Senior Member
Thanks Meter: 462
@kabaldan: thank you very much for the explanation

Btw., the previously mentioned "error" is not fatal as it happens in 3.0 on a running modem and can repeat a lot.
Invalid value passed to GFW in generic config command value passed 0, setting to 305
This one is generated by diag_mdlog binary which I noticed in stock JB xt897 release. Nifty little tool, hard to interpret output.
The Following 2 Users Say Thank You to mrvek For This Useful Post: [ View ] Gift mrvek Ad-Free
21st September 2016, 12:20 AM |#37  
Thanks Meter: 37
Are there any news regarding this?
Just as a silly idea: Is there a way to compare the status of the memory management unit between 3.0 and 3.4?
Or does a new bug in 3.4 sometimes corrupt something in the memory area of the modem (perhaps fixed in the meantime )?
Or could we compare the memory area using a 3.0 with a 3.4 kernel to see any corruption?
26th February 2017, 10:10 AM |#38  
Thanks Meter: 37
Ok, I'll spend 50€ for a successfull (and stable) effort to bring up the 3.4 (or any newer) kernel!
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes