[Q] SurfaceFlinger causing kernel panics? - HTC Droid DNA

I apologize because I just posted a thread very similar to this one recently, but I felt this warranted a new thread because I have a lead on the cause of the problem. I've been having random reboots on various AOSP ROMs (stock, crpalmer, and torrented's kernel, makes no difference) for the past few months, and I think I found the cause of it but I have no idea what to do about it. My phone has been fine for 2 or 3 days but I just got 2 random reboots in a row and I was finally able to take a last_kmsg of it and I found this:
Code:
Kernel panic - not syncing: SurfaceFlinger PC:fput+0x24/0x32c LR:ion_import_dma_buf+0x210/0x238
[ 480.493575] c0 251 [MDM][COMM] mdm_panic_prep: setting AP2MDM_ERRFATAL high for a non graceful reset
[ 480.894338] c0 251 set_restart_reason: set restart reason = 776655aa
[ 480.894368] c0 251 set_restart_msg: set restart msg = `KP: SurfaceFlinger PC:fput+0x24/0x32c LR:ion_import_dma_buf+0x210/0x238'
Can one of the anyone, particularly a kernel dev, possibly shed some light on what I can do to fix this? Again, I'm getting these reboots no matter what kernel I'm using. I'm not sure if it's the same cause every time but this is something. I'm going to run it on stock again for awhile and see if I get different messages. Thank you.

Contact crpalmer in the original development forum.

Related

[Q] How to fix Streak5 'ARM9 has crashed' reboot problem?

Hi!
I am currently working on a CM 7.2 port for the Dell Streak 5, which I want to share soon (I can't post this in the dev forum because I don't have enough posts written just yet). Currently I am trying to find a fix or a workaround for the following problem:
Sometimes, the Streak immediately reboots and shows the Dell logo. It just shows the following kernel logs (also written to LogCat):
Code:
07-03 19:13:09.348 W/PrintK ( 83): ARM9 has CRASHED
07-03 19:13:09.348 W/PrintK ( 83): smd_diag, smem: DIAG ''
07-03 19:13:09.348 W/PrintK ( 83): ARM9 has CRASHED
07-03 19:13:09.348 W/PrintK ( 83): smd_diag, smem: DIAG ''
07-03 19:13:09.348 W/PrintK ( 83): ARM9 has CRASHED
07-03 19:13:09.348 W/PrintK ( 83): smd_diag, smem: DIAG ''
07-03 19:13:09.348 W/PrintK ( 83): ARM9 has CRASHED
07-03 19:13:09.348 W/PrintK ( 83): smd_diag, smem: DIAG ''
07-03 19:13:10.430 W/PrintK ( 83): ARM9 has CRASHED
07-03 19:13:10.430 W/PrintK ( 83): smd_diag, smem: DIAG ''
07-03 19:13:10.430 W/PrintK ( 83): ARM9 has CRASHED
07-0
When I searched the kernel source, it seems that the following lines in arch/arm/mach-msm/smd.c are responsible for this log output (ommitting the parts that are not compiled):
Code:
#if defined (CONFIG_QSD_ARM9_CRASH_FUNCTION)
void smd_diag(void)
{
char *x;
x = smem_find(ID_DIAG_ERR_MSG, SZ_DIAG_ERR_MSG);
if (x != 0)
{
SMD_CRASH_LOG( "%s, smem: DIAG '%s'\n", __func__, x);
queue_work(crash_work_queue, &smd_crash_worker);
}
}
#else /* CONFIG_QSD_ARM9_CRASH_FUNCTION */
/* ommitted (not compiled) */
#endif /* CONFIG_QSD_ARM9_CRASH_FUNCTION */
static void handle_modem_crash(void)
{
SMD_CRASH_LOG( "ARM9 has CRASHED\n");
smd_diag();
/* hard reboot if possible FIXME
if (msm_reset_hook)
msm_reset_hook();
*/
/* in this case the modem or watchdog should reboot us */
#ifndef CONFIG_QSD_ARM9_CRASH_FUNCTION /* return imediately for kernel to do something */
for (;;)
#endif /* CONFIG_QSD_ARM9_CRASH_FUNCTION */
;
}
It seems that the modem is crashing and forces the device to reboot. The severe problem is that sometimes the device ends up rebooting again and again, suddenly stuck in the Dell logo - so maybe the reboot performed by the modem is not correct. But in the optimal case the device should just reset the modem, and not reboot the entire device.
As the radio drivers are only available in binary form (of course) and the device already is EOL, I really need help to find a good workaround. Does anybody have a solution to this problem?
I discovered that there is a kernel driver available in arch/arm/mach-msm/reset_modem.c that sounds interesting. It should be able to reset the modem by writing the appropriate command to a kernel device, and which is compiled as a kernel module in the default Dell Streak kernel config. Has anybody tried this out yet?
Thanks in advance & regards
Marc
PS: I am using the Phoenix kernel by the DSC Team, added with some patches by _n0p_.
Hi Marc!
How severe this problem is?
Hi _n0p_!
It's very severe to me - I have a couple of these devices here, and it's really critical if they turn off during operation (and some of them don't even come back up again afterwards).
It would be better if the radio was reset on failure - I can afford that the devices do not have a radio connection for a couple of seconds. Or at least this is what I hope.
There's a "System Type -> Reset Modem Driver" module option in kernel.
May sound dumb, but maybe it needs it?
_n0p_ said:
There's a "System Type -> Reset Modem Driver" module option in kernel.
May sound dumb, but maybe it needs it?
Click to expand...
Click to collapse
I recompiled the kernel with this module built-in, but from what I read from the source code it's just providing a device /dev/reset_modem to enable users to reset the modem from userspace (as root). However, this will not be possible entirely if the kernel itself is rebooting already, leaving no chance to any userspace commands. I believe this has to be fixed in the kernel itself. Right now I am looking at the method smsm_reset_modem in the file smd.c which sounds quite interesting. Maybe I can deactivate the code for rebooting the device there and instead run code to reset the modem. Interestingly, setting CONFIG_QSD_ARM9_CRASH_FUNCTION to 'n' in the config leads to kernel compilation errors - so the Streak was never intented to resolve modem problems the better way...
By the way, a few minutes ago I was able to log a modem restart during the reboot loop with LogCat:
pastebin.com/9U3XPxdK (yay, I can not post links yet :/ )
This looks really ugly - but it could help during debugging the problem. It would be much nicer to know what actually forces the modem to restart... (is it possible to get the stack trace during runtime, maybe by using a special macro?)
cant you check on the build based on the cm7.2 that already at the dev section? if it is not all, at least some of it would help...
deysmacro said:
cant you check on the build based on the cm7.2 that already at the dev section? if it is not all, at least some of it would help...
Click to expand...
Click to collapse
I don't know exactly what triggers the problem - maybe the devices run fine for a long time, but crash when using GPS + network in some odd way, or when the network type switched from 2G to 3G or back - I really can't tell.
As for CM 7.2, I had to build from the sources (both Kernel and CM) in order to do fixes to the ROM etc. Maybe I could try out the CM 7.2 build, but even if the problem would (not) exist there, too, I would be back to the start.
At least yesterday I tried out the reset_modem kernel module and tried all commands I could find in the source on the device /dev/reset_modem - it just crashed the modem and the device all the time, instead of one command which was effectively doing nothing. So back to the start... :-(
man... that does sucks... well... i wish you all the best nonetheless... :good:
Where's an interesting module param:
msm_smd_debug_mask
--
Also, according to:
Code:
#define MODEM_CRASH_NOTIFY_USER
extern void qi2ccapkybd_set_led(unsigned int light);
#define MODEM_CRASH_NOTIFY_USER_0 do {qi2ccapkybd_set_led(0x0);} while(0)
#define MODEM_CRASH_NOTIFY_USER_1 do {qi2ccapkybd_set_led(0xFFFFFF);} while(0)
It should blink leds on going to reboot.
--
Marc, thank you! While looking at SMD i found the code that blinks leds on AMSS mismatch (finally!)
_n0p_ said:
Marc, thank you! While looking at SMD i found the code that blinks leds on AMSS mismatch (finally!)
Click to expand...
Click to collapse
wow...! a discovery... ! :victory:
This actually leads me to think that we now free of "Blinking LEDs problem" and maybe, just maybe changing AMSS (BB) might help with modem reset problem.
I'm currently using 366 (manics told that it has good voice quality).
_n0p_ said:
This actually leads me to think that we now free of "Blinking LEDs problem" and maybe, just maybe changing AMSS (BB) might help with modem reset problem.
I'm currently using 366 (manics told that it has good voice quality).
Click to expand...
Click to collapse
last time i downgraded from rom based on 407 to 366 and although the blinking led happens.. but phone continue to work like normal... :laugh:
and yeah... 366 does have a good voice quality... and not mention excellent cell tower reception... it is proven since i have been in the building where reception is pretty much poor.. but with 366... somehow it almost always full...
but since nobody make a custom ROM based on 366, i had to sadly use other ROM...
As it's a bit offtopic, let's continue here:
http://forum.xda-developers.com/showpost.php?p=28318630&postcount=4374
Hey _n0p_!
Yeah, that seems to be the code that leads to blinking LED sensor keys on wrong AMSS!
As for the AMSS/DSP1 partitions, I currently use the newest from the original Streak 407 firmware, which I flashed via 'fastboot flash amss amss.mbn' and 'fastboot flash dsp1 dsp1.mbn'. Maybe that leads to the problems.
So you would recommend downgrading to amss 366? Although it does not match the kernel version and Android version? Isn't this a bad idea in general?
And for the DSP1, which version do you recommend - also from 366? Or the complete 366 update.pkg?
I am currently testing the image I flashed after initially flashing the 407 package the correct way - maybe this fixes the problems. Otherwise I will try 366.
By the way: Is there a good overview available what all the other files do, e.g. fsbl.mbn, osbl.mbn, dbl.mbn and appsboot.mbn?
From what I know, DT.img is the bootloader, amss the baseband software and dsp1 the DSP software for audio. And I know it's dangerous to flash the files individually, as I was able to completely brick a device by just flashing one of these special partitions...
Well, i'm using 366 right now. Too early to tell a conclusion, but it seems like default audio output is lower then in 4062 BB.
So far no glitches.
And i'm using only AMSS.
--
AFAIK DT.mbn is firmware updater, but I might be wrong.
Also DSP also works for video processing as well.
--
Almost forgot: it seems simple to disable bb error reboot.
Maybe it's worth giving a test?
_n0p_ said:
Almost forgot: it seems simple to disable bb error reboot.
Maybe it's worth giving a test?
Click to expand...
Click to collapse
Do you mean disabling CONFIG_QSD_ARM9_CRASH_FUNCTION in the kernel config? I did this, recompiled (had to fix a small include error after that, too) and tried it out - so far it crashed again after some time of usage.
BTW, how did you disable the AMSS version check? I guess you disabled the option CONFIG_QSD_OEM_RPC_VERSION_CHECK - but it's good to know.
I thought of simply trimming that rpc probe proc.
And you are right, that's the conf value plus needs ifdefing undeclared version check (in this case), variable.
Marc, it seems like
#if 0
//#ifdef CONFIG_BUILDTYPE_SHIP
SMD_CRASH_LOG( "%s: restart system\n", __func__);
queue_delayed_work(restart_work_queue, &smd_crash_restart_worker,
MODEM_CRASH_RESTART_TIMEOUT);
#endif /* CONFIG_BUILDTYPE_SHIP */
would reboot device only if modem in reset state and camera button is pressed.
Hey n0p!
_n0p_ said:
Marc, it seems like
#if 0
//#ifdef CONFIG_BUILDTYPE_SHIP
SMD_CRASH_LOG( "%s: restart system\n", __func__);
queue_delayed_work(restart_work_queue, &smd_crash_restart_worker,
MODEM_CRASH_RESTART_TIMEOUT);
#endif /* CONFIG_BUILDTYPE_SHIP */
would reboot device only if modem in reset state and camera button is pressed.
Click to expand...
Click to collapse
I tried your code, as well as some other fixes. It always led to a kernel loop and the modem didn't come back, so in the end I just included a solution to detect the problem and continue to reboot the device.
From what I learned in the last few weeks, it seems the complete ARM processor goes down with the modem. In the end, it seems to be a hardware problem, because I noticed the following facts:
Even if I completely re-flash a device that shows an error, it still occurs - especially when the network is used.
Some devices do not show this problem and can run for a long time. Other devices that had this problem always continue to have this problem. Even after re-flashing and even using different amss/dsp1 versions and on the original software.
What's more: I also had the problem on a new device that never had a custom ROM on it. Yeah, using the original firmware.
So in the end everyone should be better off to throw away his device if this problem occurs.

[Q][SGH-T959V] Aries port Sleep of Death (SoD)

While porting SGH-T959V to the aries kernel, we've ran into a rather nasty SoD.
Without further ado, here is what I see on the usb-uart:
Code:
[ 168.243223] (hpd_status = 0)++
[ 171.568772] wm8994_set_mic_bias: HWREV=13, on=0
[ 171.581786] PM: Syncing filesystems ... done.
[ 171.591614] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 171.614047] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[ 171.633556] Suspending console(s) (use no_console_suspend to debug)
Then the device never comes back from suspend. The power button, nor any other button on the phone will wake the phone.
This issue does not happen if:
usb is plugged in
a device that holds a wakelock, such as sdhc/mmc, is active. So: logging to sdcard
So the only way for me to debug the issue is over usb-uart or internal uart (which I'm still working on trying to solder correctly).
My first assumption is that a gpio pin is set incorrectly, but I've spent the last 3 months tinkering around with gpio settings and got no where.
I've also tried enabling power management (both platform specific and generic) debugging, and followed the basic pm debugging documentation in the kernel.
I get zero information about which device is either failing to suspend or any evidence as to where I should look.
At first we suspected the ril (samsung-modemctl), but after I checked out a commit before that code was committed and disabled rild in our init.aries.rc, I was able to reproduce the issue. So that rules out ril/samsung-modemctl.
I'm was also thinking it might have been one of the gpio interrupt pins, and I went through each pin and tried changing settings with no change.
Any help would be most appreciated, as I'm at a loss to where I should go next.
I am more then happy to test any theories and provide verbose results.
Here is the full log to boot:
http://pastebin.com/ymxU7qTM
Here is what happens when I turn off the screen:
Code:
[ 32.282978] request_suspend_state: sleep (0->3) at 31638909909 (2012-11-13 08:09:37.690081300 UTC)
[ 32.325302] (hpd_status = 0)++
[ 32.558317] PM: Syncing filesystems ... done.
[ 32.571488] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 32.590714] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[ 32.610223] Suspending console(s) (use no_console_suspend to debug)
Is any of the core files open source?? Like who made it? My friend told me he saw a protection on the core files
Sent from my SGH-T959V using xda app-developers app
xtrem88 said:
Is any of the core files open source?? Like who made it? My friend told me he saw a protection on the core files
Sent from my SGH-T959V using xda app-developers app
Click to expand...
Click to collapse
Everything is up on github.
Sync cm9 like normal:
Code:
mkdir android
cd android
repo init -u https://github.com/CyanogenMod/android.git -b ics
Add the local_manifest.xml:
Code:
cd .repo
wget http://bhundven.github.com/CM9/local_manifest.xml
cd ..
Sync the repo:
Code:
repo sync -j<# of repos to sync in parallel>
What do you mean by:
xtrem88 said:
he saw a protection on the core files
Click to expand...
Click to collapse
according to him its " The Pieces of Codes That Is Responsible For Pinging the Device's rtc and Boot Loader Has A Unique SLL Pinging ID On It.... and Since It locked For A Specific Type Of Hardware; The Only thing To Do Is To Dissemble The ROM And Re program It......"
this might be far fetched but im always about finding a small way around, but is there anyways we could make a loop so when the screen is off we can keep the sdhc/mmc active or make the phone think usb is plugged in?
dsexton702 said:
this might be far fetched but im always about finding a small way around, but is there anyways we could make a loop so when the screen is off we can keep the sdhc/mmc active or make the phone think usb is plugged in?
Click to expand...
Click to collapse
I downloaded the whole kernel from bhundven's git, I am trying to see the kernel
debugging parameters, but I don't know where to look exactly, what I wanted
to see if "no_console_suspend" is set to 1. I don't know if we can boot the kernel
with this parameter from the terminal :/
more specifically:
Kernel panic during suspend
Debugging suspend/resume issues can be difficult if the kernel panics during suspend, especially late in the suspend because console messages are disabled. One can stop console messages from being suspended by using the kernel parameter no_console_suspend:
no_console_suspend=1
This will force the console not to suspend. Boot with this option, chvt 1 (to console #1), and suspend using pm-suspend
Click to expand...
Click to collapse
Some valuable information about kernel debugging found here:
https://wiki.ubuntu.com/Kernel/KernelDebuggingTricks
Although it is for ubuntu kernel, but android is quite similar I think.
It could be Heisenbug that bryan mentioned before as a side effect of printk causing a slow down and
race condition issue.
but probably bryan already did that.. I don't really know, just throwing ideas here and there.. Sorry for reviving the thread btw
Rebel_X said:
I downloaded the whole kernel from bhundven's git, I am trying to see the kernel
debugging parameters, but I don't know where to look exactly, what I wanted
to see if "no_console_suspend" is set to 1. I don't know if we can boot the kernel
with this parameter from the terminal :/
more specifically:
Some valuable information about kernel debugging found here:
https://wiki.ubuntu.com/Kernel/KernelDebuggingTricks
Although it is for ubuntu kernel, but android is quite similar I think.
It could be Heisenbug that bryan mentioned before as a side effect of printk causing a slow down and
race condition issue.
but probably bryan already did that.. I don't really know, just throwing ideas here and there.. Sorry for reviving the thread btw
Click to expand...
Click to collapse
No way, any help I can get on this the better it will be for the sgs4g users.
I'm not at a place where I can review the link or do anything, but I will check it out.
'no_console_suspend' also stops the SoD.
Sent from my SAMSUNG-SGH-I717 using Tapatalk 2

Instant crash when governor set to msm-dcvs

I just got my GSIV today and rooted it using the stickied root method. I have installed setcpu. The rom crashes the second I set the governor to MSM-DCVS. Any ideas?
PelPix said:
I just got my GSIV today and rooted it using the stickied root method. I have installed setcpu. The rom crashes the second I set the governor to MSM-DCVS. Any ideas?
Click to expand...
Click to collapse
My S4 GT-i9505 crash too...
PelPix said:
I just got my GSIV today and rooted it using the stickied root method. I have installed setcpu. The rom crashes the second I set the governor to MSM-DCVS. Any ideas?
Click to expand...
Click to collapse
Same here.... i searched and really have not found an answer.
Stacktrace from enabling msm-dcvs
Here's the relevant stack trace from the kernel panic when enabling the msm-dcvs governor.
Code:
[ 2811.452880] MSM_DCVS: msm_dcvs_freq_sink_start: msm_dcvs_freq_sink_start invalid dcvs_core_id = 0 returning -EINVAL
[ 2811.462585] ------------[ cut here ]------------
[ 2811.466979] kernel BUG at /opt/jenkins/android/workspace/android/jellybean/kernel/samsung/jf/drivers/cpufreq/cpufreq_gov_msm.c:206!
[ 2811.478790] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[ 2811.484557] Modules linked in: dhd vpnclient
[ 2811.488799] CPU: 0 Not tainted (3.4.0-cyanogenmod-gfbaa5c7 #1)
I've done a little cursory exploring and noticed that the CPU_OFFSET parameter starts at 1 on this kernel module, but it is being told to enable this governor on core 0, hence the message above. Not sure at the moment if it's the module's fault, or just some misconfiguration from settings activity when enabling this module.
I plan to look into this in a bit more depth sometime in the next few weeks(hopefully).
Follow up to stepheno's message
stephenopdx said:
Here's the relevant stack trace from the kernel panic when enabling the msm-dcvs governor.
Code:
[ 2811.452880] MSM_DCVS: msm_dcvs_freq_sink_start: msm_dcvs_freq_sink_start invalid dcvs_core_id = 0 returning -EINVAL
[ 2811.462585] ------------[ cut here ]------------
[ 2811.466979] kernel BUG at /opt/jenkins/android/workspace/android/jellybean/kernel/samsung/jf/drivers/cpufreq/cpufreq_gov_msm.c:206!
[ 2811.478790] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[ 2811.484557] Modules linked in: dhd vpnclient
[ 2811.488799] CPU: 0 Not tainted (3.4.0-cyanogenmod-gfbaa5c7 #1)
I've done a little cursory exploring and noticed that the CPU_OFFSET parameter starts at 1 on this kernel module, but it is being told to enable this governor on core 0, hence the message above. Not sure at the moment if it's the module's fault, or just some misconfiguration from settings activity when enabling this module.
I plan to look into this in a bit more depth sometime in the next few weeks(hopefully).
Click to expand...
Click to collapse
Hi, stephenopdx and I are working together on this issue in our free time. As a follow up, we've found that the call to msm_dcvs_scm_init is returning a non-zero value (specifically 4). This function is calling the command DCVD_CMD_INIT (command ID 5) in the SCM_SVC_DCVS service. The continues down to an ARM instruction call to move the processor into "secure mode" (aka TrustZone). I'd like to emphasize at this point that both stephenopdx are complete noobs when it comes to kernel development.
We are wondering:
1) Why, if the scm_call to DCVS_CMD_INIT fails, does the kernel continue on its merry way?
2) What does that return code of 4 mean?
3) What preconditions are necessary to initialize DCVS?
4) Is there a place where we can find reference materials (things like return codes and their meanings) for the Qualcomm MSM 8960 SoC? Googling for return code 4 was fairly futile.
5) Is there some sort of kernel debugger so that we can stop using terrible pr_err messages?
We can also produce stack traces or kernel panic logs (heavily augmented with demented pr_err messages to help us figure out what's going on) if anyone is interested.
Thanks!

[DEV] LegacyXperia development discussion - DEVS ONLY

Hi, since I closed my DEV threads there is no place for discussing development related things.
I've opened this thread so we can discuss any development related stuff (kernel etc).
Please keep the thread clean. I will report any non-low-level development posts.
ION kernel status
Kernel boots, lcd backlight is on but no image is shown.
I only get a display full of noise for half a second, after the following error occurs:
Code:
[ 8.994812] ------------[ cut here ]------------
[ 8.995025] WARNING: at /home/mike/android/cm10.1/kernel/semc/msm7x30/kernel/mutex.c:198 __mutex_lock_slowpath+0x70/0x27c()
[ 8.995483] Modules linked in:
[ 8.995758] [<c001428c>] (unwind_backtrace+0x0/0x11c) from [<c008a6f0>] (warn_slowpath_common+0x4c/0x64)
[ 8.996154] [<c008a6f0>] (warn_slowpath_common+0x4c/0x64) from [<c008a720>] (warn_slowpath_null+0x18/0x1c)
[ 8.996582] [<c008a720>] (warn_slowpath_null+0x18/0x1c) from [<c061b524>] (__mutex_lock_slowpath+0x70/0x27c)
[ 8.998138] [<c061b524>] (__mutex_lock_slowpath+0x70/0x27c) from [<c061b73c>] (mutex_lock+0xc/0x24)
[ 9.007171] [<c061b73c>] (mutex_lock+0xc/0x24) from [<c02988dc>] (mddi_host_timer_service+0x374/0x430)
[ 9.016448] [<c02988dc>] (mddi_host_timer_service+0x374/0x430) from [<c00949dc>] (run_timer_softirq+0x18c/0x260)
[ 9.026519] [<c00949dc>] (run_timer_softirq+0x18c/0x260) from [<c008fa1c>] (__do_softirq+0x74/0x120)
[ 9.035705] [<c008fa1c>] (__do_softirq+0x74/0x120) from [<c008fe8c>] (irq_exit+0x44/0xa8)
[ 9.043884] [<c008fe8c>] (irq_exit+0x44/0xa8) from [<c000f08c>] (handle_IRQ+0x68/0x8c)
[ 9.051788] [<c000f08c>] (handle_IRQ+0x68/0x8c) from [<c00084e4>] (vic_handle_irq+0x28/0x30)
[ 9.060119] [<c00084e4>] (vic_handle_irq+0x28/0x30) from [<c000dd80>] (__irq_svc+0x40/0x70)
[ 9.068511] Exception stack(0xc0879f58 to 0xc0879fa0)
[ 9.073547] 9f40: ffffffff 000000b0
[ 9.081634] 9f60: 00000001 00000000 c0878000 c0889470 c0908048 c0889464 00204059 511f00f2
[ 9.089874] 9f80: 00000000 00000000 00000000 c0879fa0 c007dbd8 c000f1a0 400b0013 ffffffff
[ 9.098052] [<c000dd80>] (__irq_svc+0x40/0x70) from [<c000f1a0>] (default_idle+0x24/0x2c)
[ 9.106201] [<c000f1a0>] (default_idle+0x24/0x2c) from [<c000f458>] (cpu_idle+0x5c/0xac)
[ 9.114196] [<c000f458>] (cpu_idle+0x5c/0xac) from [<c060af7c>] (rest_init+0x84/0x9c)
[ 9.122100] [<c060af7c>] (rest_init+0x84/0x9c) from [<c0840a54>] (start_kernel+0x368/0x3c4)
[ 9.130432] ---[ end trace 826fbc4fa566ec66 ]---
EDIT: Full log with mddi & msm_fb debugging enabled here: http://pastebin.com/Tj1izvyt
I don't see anything useful
I'm not familiar with these kernel building i know u people @android1234567 @DevConnection_Team @Christopher83 @johnnyslt @arco68 can help us building ION kernel for xperia 2011 devices ... sorry if I'm interrupting u .. thank you
mike maybe we need some specific changes in qcom_display_caf try to use arco'w variant
Does kernel panic if you exclude display driver?
Gesendet von meinem Xperia Neo V mit Tapatalk 2
deccen90 said:
I'm not familiar with these kernel building i know u people @android1234567 @DevConnection_Team @Christopher83 @johnnyslt @arco68 can help us building ION kernel for xperia 2011 devices ... sorry if I'm interrupting u .. thank you
Click to expand...
Click to collapse
Where is the stable pmem kernel source? and in what branch @mikeioannina tried to enable ION?
johnnyslt said:
Where is the stable pmem kernel source? and in what branch @mikeioannina tried to enable ION?
Click to expand...
Click to collapse
current pmem kernel: https://github.com/LegacyXperia/msm7x30-3.4.x-nAa/commits/cm-10.1
new ion kernel: https://github.com/mikeNG/android_kernel_semc_msm7x30/commits/cm-10.1-mutex-error
You can check the second post for more info.
mikeioannina said:
current pmem kernel: https://github.com/LegacyXperia/msm7x30-3.4.x-nAa/commits/cm-10.1
new ion kernel: https://github.com/mikeNG/android_kernel_semc_msm7x30/commits/cm-10.1-mutex-error
You can check the second post for more info.
Click to expand...
Click to collapse
I'm seeing that pmem_adsp doesn't get allocated and it should:
Code:
[ 3.558837] pmem: pmem_setup: unable to register pmem driver(pmem_adsp) - zero size passed in!
What adreno libs are you using?
Also are you using patched gralloc with PMEM_ADSP support?
hi @mikeioannina
I would like to help fix the fm radio in cm11. I am not a dev and I only have some basic C programming and github skills. If you think it is worth the time ( mine and yours), could you describe how to build the fm app for cm11 and where to look for bugs?
johnny.tifosi said:
hi @mikeioannina
I would like to help fix the fm radio in cm11. I am not a dev and I only have some basic C programming and github skills. If you think it is worth the time ( mine and yours), could you describe how to build the fm app for cm11 and where to look for bugs?
Click to expand...
Click to collapse
I believe that the FM app is broken because there is no wrapper for the SEMC FM libs...
johnny.tifosi said:
hi @mikeioannina
I would like to help fix the fm radio in cm11. I am not a dev and I only have some basic C programming and github skills. If you think it is worth the time ( mine and yours), could you describe how to build the fm app for cm11 and where to look for bugs?
Click to expand...
Click to collapse
kemoba said:
I believe that the FM app is broken because there is no wrapper for the SEMC FM libs...
Click to expand...
Click to collapse
You can pick this change: http://legacyxperia.us.to:8080/131 in order to build the TI FM stuff. It's only for cm10.1 currently but in my opinion it's the best version to work on FM, since we have the most complete code for msm7x30 & TI wl12xx in that version.
I'm afraid you won't manage to do anything since you need some knowledge of how android audio stuff works (I also haven't worked on audio stuff very much in the past and don't have much knowledge)
Anyway, the code is there for anyone who wants to try
mikeioannina said:
Kernel boots, lcd backlight is on but no image is shown.
I only get a display full of noise for half a second, after the following error occurs:
Code:
[ 8.994812] ------------[ cut here ]------------
[ 8.995025] WARNING: at /home/mike/android/cm10.1/kernel/semc/msm7x30/kernel/mutex.c:198 __mutex_lock_slowpath+0x70/0x27c()
[ 8.995483] Modules linked in:
[ 8.995758] [<c001428c>] (unwind_backtrace+0x0/0x11c) from [<c008a6f0>] (warn_slowpath_common+0x4c/0x64)
[ 8.996154] [<c008a6f0>] (warn_slowpath_common+0x4c/0x64) from [<c008a720>] (warn_slowpath_null+0x18/0x1c)
[ 8.996582] [<c008a720>] (warn_slowpath_null+0x18/0x1c) from [<c061b524>] (__mutex_lock_slowpath+0x70/0x27c)
[ 8.998138] [<c061b524>] (__mutex_lock_slowpath+0x70/0x27c) from [<c061b73c>] (mutex_lock+0xc/0x24)
[ 9.007171] [<c061b73c>] (mutex_lock+0xc/0x24) from [<c02988dc>] (mddi_host_timer_service+0x374/0x430)
[ 9.016448] [<c02988dc>] (mddi_host_timer_service+0x374/0x430) from [<c00949dc>] (run_timer_softirq+0x18c/0x260)
[ 9.026519] [<c00949dc>] (run_timer_softirq+0x18c/0x260) from [<c008fa1c>] (__do_softirq+0x74/0x120)
[ 9.035705] [<c008fa1c>] (__do_softirq+0x74/0x120) from [<c008fe8c>] (irq_exit+0x44/0xa8)
[ 9.043884] [<c008fe8c>] (irq_exit+0x44/0xa8) from [<c000f08c>] (handle_IRQ+0x68/0x8c)
[ 9.051788] [<c000f08c>] (handle_IRQ+0x68/0x8c) from [<c00084e4>] (vic_handle_irq+0x28/0x30)
[ 9.060119] [<c00084e4>] (vic_handle_irq+0x28/0x30) from [<c000dd80>] (__irq_svc+0x40/0x70)
[ 9.068511] Exception stack(0xc0879f58 to 0xc0879fa0)
[ 9.073547] 9f40: ffffffff 000000b0
[ 9.081634] 9f60: 00000001 00000000 c0878000 c0889470 c0908048 c0889464 00204059 511f00f2
[ 9.089874] 9f80: 00000000 00000000 00000000 c0879fa0 c007dbd8 c000f1a0 400b0013 ffffffff
[ 9.098052] [<c000dd80>] (__irq_svc+0x40/0x70) from [<c000f1a0>] (default_idle+0x24/0x2c)
[ 9.106201] [<c000f1a0>] (default_idle+0x24/0x2c) from [<c000f458>] (cpu_idle+0x5c/0xac)
[ 9.114196] [<c000f458>] (cpu_idle+0x5c/0xac) from [<c060af7c>] (rest_init+0x84/0x9c)
[ 9.122100] [<c060af7c>] (rest_init+0x84/0x9c) from [<c0840a54>] (start_kernel+0x368/0x3c4)
[ 9.130432] ---[ end trace 826fbc4fa566ec66 ]---
EDIT: Full log with mddi & msm_fb debugging enabled here: http://pastebin.com/Tj1izvyt
I don't see anything useful
Click to expand...
Click to collapse
Hello,
I'm porting 3.x kernel on an other xperia device (x10) and facing the same issue ... Did you managed to solve it ?
I'm using ion memory management and as johnnyslt wrote I got this line in log too :
PHP:
pmem: pmem_setup: unable to register pmem driver(pmem_adsp) - zero size passed in!
I'll look with for this (that musn't be a big deal to allocate pmem_adsp with fitting lines in board ... let's see if this is what is causing the trouble.
If you didn't find the solution yet, I'll let you know if I find
Regards
Tof37 said:
Hello,
I'm porting 3.x kernel on an other xperia device (x10) and facing the same issue ... Did you managed to solve it ?
I'm using ion memory management and as johnnyslt wrote I got this line in log too :
PHP:
pmem: pmem_setup: unable to register pmem driver(pmem_adsp) - zero size passed in!
I'll look with for this (that musn't be a big deal to allocate pmem_adsp with fitting lines in board ... let's see if this is what is causing the trouble.
If you didn't find the solution yet, I'll let you know if I find
Regards
Click to expand...
Click to collapse
No, still having the problem. I have limited time these days so no much progress...
If you manage anything let me know
@mikeioannina
Hope it'll help ... you should have a look to your drivers/video/msm/logo.c and msm_fb.c and .h files
In the last 2 files the lines which are dealing with fb_msm_logo ...
I ported 3.4 video drivers in the 3.0.8 kernel I use and add the same issue.
I add this problem too with 3.0.8 drivers and solving the problem of fb_msm_logo did it.
If you disable fb_msm_logo in your config file but still have the issue this means you're mising lines specific for your device.
If 3.0.X kernel is already working on your device, try to make a diff with video drivers.
I'll take a look at your repo when I'll have a little time
Regards
Tof37 said:
@mikeioannina
Hope it'll help ... you should have a look to your drivers/video/msm/logo.c and msm_fb.c and .h files
In the last 2 files the lines which are dealing with fb_msm_logo ...
I ported 3.4 video drivers in the 3.0.8 kernel I use and add the same issue.
I add this problem too with 3.0.8 drivers and solving the problem of fb_msm_logo did it.
If you disable fb_msm_logo in your config file but still have the issue this means you're mising lines specific for your device.
If 3.0.X kernel is already working on your device, try to make a diff with video drivers.
I'll take a look at your repo when I'll have a little time
Regards
Click to expand...
Click to collapse
Thanks for the hints,
hmm... I think I have tried without bootlogo with no luck, I will try again to be sure.
3.0.8 works fine on our devices, 3.4 works too but with 3.0.8 video drivers. When I try pure 3.4 it doesn't boot with the above error.
EDIT:
I tried disabling bootlogo with no change, still no display.
Making a diff of 3.0.8/3.4 drivers/video/msm is almost impossible since there are too many changes involved, I already tried it with no luck, spent hours and it didn't even compile.
I'm really sad with this situation, I'm working for 3 months on this kernel with the exact same issue. where the hell is the problem?
mikeioannina said:
Thanks for the hints,
hmm... I think I have tried without bootlogo with no luck, I will try again to be sure.
3.0.8 works fine on our devices, 3.4 works too but with 3.0.8 video drivers. When I try pure 3.4 it doesn't boot with the above error.
EDIT:
I tried disabling bootlogo with no change, still no display.
Making a diff of 3.0.8/3.4 drivers/video/msm is almost impossible since there are too many changes involved, I already tried it with no luck, spent hours and it didn't even compile.
I'm really sad with this situation, I'm working for 3 months on this kernel with the exact same issue. where the hell is the problem?
Click to expand...
Click to collapse
I see so I'm facing exactly the same problem ...
do you have this problem with your kernel with pmem ?
I didn't try with mine (only tried with the one where ion is enabled)
Even in the ion enabled version, pmem_adsp is allocated but still have the problem.
ps : It's been nearly 1 year I started to port 3.0.8 kernel on x10 ... I got nearly 6 months (including 2 months to not work on it) to try to solve display problem
@mikeioannina
You should try this ...
in drivers/video/msm/mddi.c
in void pmdh_clk_enable() you've got
PHP:
if (mddi_host_timer.function)
mddi_host_timer_service(0);
In my .32 video drivers this if is in static int mddi_resume ...
Try to get the the above function like this :
PHP:
static int mddi_resume(struct platform_device *pdev)
{
mddi_host_type host_idx = MDDI_HOST_PRIM;
if (!mddi_is_in_suspend)
return 0;
mddi_is_in_suspend = 0;
if (mddi_power_locked)
return 0;
pmdh_clk_enable();
mddi_host_reg_out(PAD_CTL, mddi_pad_ctrl);
[B]if (mddi_host_timer.function)
mddi_host_timer_service(0);[/B]
return 0;
}
The mddi_host_timer_service error in log dissapeared ... seems there are some problems is it stays in pmdh_clk_enable...
Tof37 said:
@mikeioannina
You should try this ...
in drivers/video/msm/mddi.c
in void pmdh_clk_enable() you've got
PHP:
if (mddi_host_timer.function)
mddi_host_timer_service(0);
In my .32 video drivers this if is in static int mddi_resume ...
Try to get the the above function like this :
PHP:
static int mddi_resume(struct platform_device *pdev)
{
mddi_host_type host_idx = MDDI_HOST_PRIM;
if (!mddi_is_in_suspend)
return 0;
mddi_is_in_suspend = 0;
if (mddi_power_locked)
return 0;
pmdh_clk_enable();
mddi_host_reg_out(PAD_CTL, mddi_pad_ctrl);
[B]if (mddi_host_timer.function)
mddi_host_timer_service(0);[/B]
return 0;
}
The mddi_host_timer_service error in log dissapeared ... seems there are some problems is it stays in pmdh_clk_enable...
Click to expand...
Click to collapse
that did nothing, still getting the same error...
mikeioannina said:
that did nothing, still getting the same error...
Click to expand...
Click to collapse
Have to solve a |kgsl_mh_intrcallback| axi read error interrupt: error in my kernel and will take a more attentive look to 3.4 video drivers .
Stay tuned
btw if you ever have a solution for my problem
Thanks
mikeioannina said:
Code:
[ 8.994812]
[ 8.995025] WARNING: at /home/mike/android/cm10.1/kernel/semc/msm7x30/kernel/mutex.c:198 __mutex_lock_slowpath+0x70/0x27c()
Click to expand...
Click to collapse
I'm going to just throw this out, is it possible that you are building a kernel for CM10.1 and booting it on CM11 ?

Poco F1 with Black/Blue screen and reboot

Hi there,
It's my first post here, I landed here a lot of times and always found answers to my questions, many thanks to this community. I hope my frenchglish remains understandable.
The problem is that my poco F1 crashes randomly. I get a black, sometimes blue screen and then the device reboots to the OS normally, without any loop.
It can happen after 10 seconds or 1 hour and I cannot detect what is causing these crashes. Maybe something related to wifi.
How can I investigate to find a clue ?
About the device :
- I bought it used, already unlocked
- I tried with /e/, CalyxOS (2.7.0 and 2.9.0), and with miui (flashed with MiFlash)
- I tried several firmware versions
- I don't see anything relevant in logcat last messages, a lot of errors but different at each crash
There are these errors that are happening a lot of time, but I don't know if it's the cause because they seem to happen constantly :
- CANNOT LINK EXECUTABLE "/vendor/bin/wifidisplayhalservice": library "libwfdaac_vendor.so" not found: needed by /vendor/lib/libwfdmmsrc_proprietary.so in namespace (default) (300 lines over 20mn)
- W libperfmgr: Failed to write to node: /proc/sys/kernel/sched_boost with value: 0, fd: -1 (500 lines over 20mn)
In dmesg, I have tons of these :
[ 176.525217] [schedu][3448610271][14:31:06.270389] wlan: [2652:E:WMI] Service id 258 but WMI ext2 service bitmap is NULL
[ 177.161869] init: starting service 'wifidisplayhalservice'...
[ 177.179652] init: Service 'wifidisplayhalservice' (pid 4373) exited with status 1
[ 177.179670] init: Sending signal 9 to service 'wifidisplayhalservice' (pid 4373) process group...
[ 177.179785] libprocessgroup: Successfully killed process cgroup uid 1000 pid 4373 in 0ms
[ 179.562273] [schedu][3506921340][14:31:09.307424] wlan: [2652:E:WMI] Service id 258 but WMI ext2 service bitmap is NULL
[ 179.562296] [schedu][3506922166][14:31:09.307467] wlan: [2652:E:WMI] Service id 258 but WMI ext2 service bitmap is NULL
[ 179.562314] [schedu][3506922495][14:31:09.307484] wlan: [2652:E:WMI] Service id 258 but WMI ext2 service bitmap is NULL
If anyone has an idea to solve these crashes, some ways to reproduce the crash, test hardware, how to get relevant logs...
Any help appreciated.
Same problem dude ?? Did u get the solution
heyhoy said:
Hi there,
It's my first post here, I landed here a lot of times and always found answers to my questions, many thanks to this community. I hope my frenchglish remains understandable.
The problem is that my poco F1 crashes randomly. I get a black, sometimes blue screen and then the device reboots to the OS normally, without any loop.
It can happen after 10 seconds or 1 hour and I cannot detect what is causing these crashes. Maybe something related to wifi.
How can I investigate to find a clue ?
About the device :
- I bought it used, already unlocked
- I tried with /e/, CalyxOS (2.7.0 and 2.9.0), and with miui (flashed with MiFlash)
- I tried several firmware versions
- I don't see anything relevant in logcat last messages, a lot of errors but different at each crash
There are these errors that are happening a lot of time, but I don't know if it's the cause because they seem to happen constantly :
- CANNOT LINK EXECUTABLE "/vendor/bin/wifidisplayhalservice": library "libwfdaac_vendor.so" not found: needed by /vendor/lib/libwfdmmsrc_proprietary.so in namespace (default) (300 lines over 20mn)
- W libperfmgr: Failed to write to node: /proc/sys/kernel/sched_boost with value: 0, fd: -1 (500 lines over 20mn)
In dmesg, I have tons of these :
[ 176.525217] [schedu][3448610271][14:31:06.270389] wlan: [2652:E:WMI] Service id 258 but WMI ext2 service bitmap is NULL
[ 177.161869] init: starting service 'wifidisplayhalservice'...
[ 177.179652] init: Service 'wifidisplayhalservice' (pid 4373) exited with status 1
[ 177.179670] init: Sending signal 9 to service 'wifidisplayhalservice' (pid 4373) process group...
[ 177.179785] libprocessgroup: Successfully killed process cgroup uid 1000 pid 4373 in 0ms
[ 179.562273] [schedu][3506921340][14:31:09.307424] wlan: [2652:E:WMI] Service id 258 but WMI ext2 service bitmap is NULL
[ 179.562296] [schedu][3506922166][14:31:09.307467] wlan: [2652:E:WMI] Service id 258 but WMI ext2 service bitmap is NULL
[ 179.562314] [schedu][3506922495][14:31:09.307484] wlan: [2652:E:WMI] Service id 258 but WMI ext2 service bitmap is NULL
If anyone has an idea to solve these crashes, some ways to reproduce the crash, test hardware, how to get relevant logs...
Any help appreciated.
Click to expand...
Click to collapse
maxpayne_69 said:
Same problem dude ?? Did u get the solution
Click to expand...
Click to collapse
Have you tried flashing persist partition? (you can find it at XIaomi Tools at in my collection)
Also did you tried to flash stock firmware according my guide? You can find all the guid in my POCO F1 Ultimate Collection & Guides.
maxpayne_69 said:
Same problem dude ?? Did u get the solution
Click to expand...
Click to collapse
Hi,
Nope. I changed the battery, it didn't solve anything but I read in several posts that it fixed the problem.
I also removed the mobo, put it in the oven. It was supposed to check if some soldering would be defective. It didn't solve anything.
I finally cancelled, I may try again later. I think it's a hardware issue.
Retrial said:
Have you tried flashing persist partition? (you can find it at XIaomi Tools at in my collection)
Also did you tried to flash stock firmware according my guide? You can find all the guid in my POCO F1 Ultimate Collection & Guides.
Click to expand...
Click to collapse
I'm not sure about persist partition. I flashed several times, with several firmwares and several roms. Is it part of these processes ?
I follow guides step by step without a good knowing of android, so I may have done a persist partition flash.
Thanks for this awesome collection anyway, the most things I did came from it.

Categories

Resources