Database Info

What .ko's from kernel build?

I just successfully built a kernel with my phone over nfs (wifi). I used gcc-armhf or rather to be specific, when it complained I set 'CROSS_COMPILER=/usr/bin/', cleaned, and retried. Everything seems to have went fine, and as expected I have the zImage in arch/arm/boot and the modules are scattered around, but theres a list on stdout I can use to copy them somewhere.
1.) Which kernel object files do I need?
2.) I will look at the device/samsung/d2spr/extract-files.sh file to see where I should put them, but where should I put the ones that may have been created from the config changes and are not listed?
My first couple of trys failed due to the kernel being too large, so I changed some things to modules that I think can wait to load or set up an init script. I also didn't use mkbootimg, I used abootimg, that may have been why, not too sure. I used unmkbootimg and saved the stdout to a file this time and built the kernel on my phone, still, those are some questions I still have.
Edit: Another way to ask this question...
3.) Do I need to replace the 'blobs' that I got from the official CM ROM with the ones I just built?
4.) Do the modules I built contain the proprietary code to run the hardware, or where some (wifi driver for instance) 'filled' in with 'dummy code'?
Note: The zImage built was 3699216 bytes or about 3.6 MB. The zImage I need to replace is "Kernel size 3907440" or roughly 3.9MB, things are looking good, for once! :highfive:

Just use a script to find and copy all of them
Code:
find . -iname '*.ko' -exec cp {} MODULES_OUTPUT_FOLDER_HERE \;
Run from the root folder of your kernel source
Kernel modules go in the system/lib/modules folder
They contain code to assist the kernel, it's not so much proprietary blobs like pulling libs from stock to get AOSP working but they are device and kernel specific. The entire source for each module is there...so it's not proprietary or else someone would get sued
And no, they don't get filled in with dummy code, they get built with drivers that have been adapted for the specific board and then for the specific phone model and kernel code. Modules add in what the kernel leaves out...the kernel might say "initialize wifi chip, load driver and then connect", but the main code with all the specifics of how to do that is actually stored in the wifi module (dhd.ko)

CNexus said:
Just use a script to find and copy all of them
Code:
find . -iname '*.ko' -exec cp {} MODULES_OUTPUT_FOLDER_HERE \;
Run from the root folder of your kernel source
Kernel modules go in the system/lib/modules folder
They contain code to assist the kernel, it's not so much proprietary blobs like pulling libs from stock to get AOSP working but they are device and kernel specific. The entire source for each module is there...so it's not proprietary or else someone would get sued
And no, they don't get filled in with dummy code, they get built with drivers that have been adapted for the specific board and then for the specific phone model and kernel code. Modules add in what the kernel leaves out...the kernel might say "initialize wifi chip, load driver and then connect", but the main code with all the specifics of how to do that is actually stored in the wifi module (dhd.ko)
Click to expand...
Click to collapse
Well, I hope all is not lost.
I took my last working zip I built and used an archive manager to crack it open, I replaced the zImage with the one I built on my phone. Then I replaced all .ko files that where built in system/lib/modules and closed the archive. I flashed it to my phone and installed it, now I am stuck in aboot loop and can't get to recovery.
What should I do? Can I fix it with Oden or something? That is what I used to originally root it.

Scratch that, I pulled the battery and pushed the buttons more cautiously (nervous shakes), in recovery.
What do ya think it coulda been?
I disabled paranoid networking, removed CIFS, and changed NFS to Modules instead of built-ins.
Edit: I'll try cross compiling on my lap-top, maybe had to do with the toolchain and arm abei(sp?), maybe wifi nfs is unreliable in witing to the disk?
Maybe if I use the original .ko files that I pulled from the device as per the CM extract-files.sh script, and just add the new kernel and new modules that didn't already exit?
I'll have to brute this out and hope I don't brick my phone in the process.

Kernels won't brick your phone unless it overclocks to the point where it's melting, otherwise you're good
What it sounds like is something went wrong and you had a kernel panic...or maybe the kernel didn't load at all
Check /proc/last_kmsg to see if it loaded at all

CNexus said:
Kernels won't brick your phone unless it overclocks to the point where it's melting, otherwise you're good
What it sounds like is something went wrong and you had a kernel panic...or maybe the kernel didn't load at all
Check /proc/last_kmsg to see if it loaded at all
Click to expand...
Click to collapse
My bad, as soon as I got into recovery I flashed a known working zip.
I am going to keep trying to build a custom kernel but I would like to figure out how to configure it within my source tree and let it get compiled with a rom.
but here is a cat of /proc/last_kmsg just incase it survived.
Code:
[ 0.000000] Truncating memory at 0xc0000000 to fit in 32-bit physical address space
[ 0.000000] smem_find(137, 80): wrong size 72
[ 0.023561] AXI: msm_bus_fabric_init_driver(): msm_bus_fabric_init_driver
[ 0.056035] msm_rpm_get_status(): Status id 433 not defined for target
[ 0.056035] msm_rpm_get_status(): Status id 433 not defined for target
[ 0.056065] msm_rpm_get_status(): Status id 433 not defined for target
[ 0.056065] msm_rpm_get_status(): Status id 433 not defined for target
[ 0.056065] msm_rpm_get_status(): Status id 433 not defined for target
[ 0.056096] msm_rpm_get_status(): Status id 433 not defined for target
[ 0.056096] msm_rpm_get_status(): Status id 433 not defined for target
[ 0.056096] msm_rpm_get_status(): Status id 433 not defined for target
[ 0.076056] msm_gpiomux_install: write failure: -14
[ 0.076056] msm_gpiomux_install: write failure: -14
[ 0.076056] msm_gpiomux_install: write failure: -14
[ 0.076087] msm_gpiomux_install: write failure: -14
[ 0.125194] [msm8960_init_cam:1572]setting done!!
[ 0.177262] i2c i2c-14: Invalid 7-bit I2C address 0x00
[ 0.177384] i2c i2c-14: Can't create device at 0x00
[ 0.177872] i2c i2c-19: Failed to register i2c client cmc624 at 0x38 (-16)
[ 0.177964] i2c i2c-19: Can't create device at 0x38
[ 0.178483] Error-Bad Function Input
[ 0.179185] max8952 19-0060: DVS modes disabled because VID0 and VID1 do not have proper controls.
[ 0.407630] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: scm_pas
[ 0.418953] smd_channel_probe_worker: allocation table not initialized
[ 0.429757] msm_ipc_router_init: Unable to create IPC logging for IPC RTR
[ 0.430581] msm_ipc_router_ipc_log_init: Unable to create IPC logging for Req/Resp
[ 0.430856] msm_ipc_router_ipc_log_init: Unable to create IPC logging for Indications
[ 0.437082] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: acpuclk-8960
[ 0.473950] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: dtv
[ 0.477857] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: mdp
[ 0.491316] pm_runtime: fail to wake up
[ 0.991881] hdmi_msm hdmi_msm.1: external_common_state_create: sysfs group eeb42a08
[ 0.993804] Inside writeback_driver_init
[ 0.994353] Inside writeback_probe
[ 1.534289] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: rotator
[ 1.548023] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: grp3d
[ 1.558583] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: grp2d0
[ 1.568686] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: grp2d1
[ 1.602289] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: qsee
[ 1.789500] cm36651_setup_reg: initial proximity value = 0
[ 1.910697] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: usb
[ 1.930016] mms_ts 3-0048: [TSP] ISC Ver [0xbd] [0x22] [0x22]
[ 1.934777] mms_ts 3-0048: [TSP] fw is latest. Do not update.
[ 1.947077] [__s5c73m3_probe:3868] S5C73M3 probe
[ 1.950862] [s5c73m3_sensor_probe_cb:3843] Entered
[ 1.955562] [s5c73m3_i2c_probe:3725] Entered
[ 1.959896] [s5c73m3_init_client:3424] Entered
[ 1.965359] [s5c73m3_i2c_probe:3745] Exit
[ 1.968655] [s5c73m3_sensor_probe:3776] Entered
[ 1.973081] [s5c73m3_spi_init:226] Entered
[ 1.977170] [s5c73m3_spi_probe:191] Entered
[ 1.981321] [s5c73m3_spi_probe:201] s5c73m3_spi successfully probed
[ 1.987669] [s5c73m3_sensor_probe : 3799] Probe_done!!
[ 2.042698] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: msm_sdcc
[ 2.049076] couldn't get usb power supply
[ 2.057530] mmc0: No card detect facilities available
[ 2.064153] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: msm_sdcc
[ 2.081245] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: msm_sdcc
[ 2.093575] aat1290a_led_probe : Probe
[ 2.378849] bam_dmux_init : unable to create IPC Logging Context
[ 2.419594] cypress_touchkey 16-0020: Touchkey FW Version: 0x06
[ 2.534594] init: invalid uid 'fm_radio'
[ 2.950068] enable_store: android_usb: already disabled
[ 2.954768] init: Unable to open persistent property directory /data/property errno: 2
[ 87.924614] SysRq : Emergency Remount R/O
[ 88.153181] Restarting system.
No errors detected
Maybe disabling Android's Paranoid Networking breaks other things?
If this wont work, maybe I will try writing a post installation script for apt-get and try to get Android to recognize the new packages nd define some permission for that .xml file I know is hiding somewhere. I might have to create a database of permissions required for all the packages in the repos (that would suck). But really, if I could just get basic Linux filesystem permissions I wouldn't need to do all of that. That whole, "only allow certain groups to create sockets" option is pulling the chair out from under me. I'll have to study the source for the filesystem a little deeper, maybe I can disable it (or at least allow root) from the source without taking it out of the kernel config.
For instance, postgresql needs to open a socket and bind to a port, it tries ipv4 an ipv6 AF_INET and AF_INET6, and this paranoid feature will check the processes gid as well as other permissions I think to see if it can. So I tried setting the gid bit to run /etc/init.d/postrgresql as gid AID_INET but it still fails, probably because the file is not listed in that .xml file I mentioned earlier. I think a post installation script might work best if I can't turn the feature off or fix it to be more permissive.

I think the packing have some issue.. Go into my github check moto_tool their u can see unpack repack txt file open it. Change the value as per you phone and you are done

[Q] Photon Q GAPPS Lockup

I've installed the newest build for Cyanogengmod 11 that supports my exact phone (XT897c) and it works great. I've only been using it for a few days now and haven't ran into any major issues but one. The problem I continue to have is I cannot install Gapps and have the phone work properly. Everytime I install the correct Gapps (or any other variant for that matter) the phone stays locked up at the initial Motorola boot logo and will never continue loading. I've redownloaded and reinstalled both CM11 and various Gapps KK from different sites and methods without fixing the problem. Anyone have a suggestion?

sulken2000 said:
I've installed the newest build for Cyanogengmod 11 that supports my exact phone (XT897c) and it works great. I've only been using it for a few days now and haven't ran into any major issues but one. The problem I continue to have is I cannot install Gapps and have the phone work properly. Everytime I install the correct Gapps (or any other variant for that matter) the phone stays locked up at the initial Motorola boot logo and will never continue loading. I've redownloaded and reinstalled both CM11 and various Gapps KK from different sites and methods without fixing the problem. Anyone have a suggestion?
Click to expand...
Click to collapse
Download these cm11 gapps from dhacker29 (supports both dalvik and art).
Install CM11. let it boot
Install gapps. reboot which will probably fail.
if the above failed: re-install cm11, wipe cache/dalvik and reboot.

sulken2000 said:
I've installed the newest build for Cyanogengmod 11 that supports my exact phone (XT897c) and it works great. I've only been using it for a few days now and haven't ran into any major issues but one. The problem I continue to have is I cannot install Gapps and have the phone work properly. Everytime I install the correct Gapps (or any other variant for that matter) the phone stays locked up at the initial Motorola boot logo and will never continue loading. I've redownloaded and reinstalled both CM11 and various Gapps KK from different sites and methods without fixing the problem. Anyone have a suggestion?
Click to expand...
Click to collapse
If you're using xt897c CM11 build, you're using very outdated build.
Your exact phone is not xt897c, you have just xt897, as anyone else.
There's no such thing as xt897c phone, xt897c is something I've made up as a temporary measure until we'll be able to do a single world-phone build that will support both GSM and CDMA networks.
Since long time ago, xt897 (gsm) and xt897c (cdma) builds have been unified into a single xt897 (world phone) build which made xt897c builds obsolete.
Later on, the builds for the whole 1st gen family of Motorola msm8960 devices (razr hd, razr m, atrix hd, electrify m and photon q) have been unified into a single moto_msm8960 build. All those devices are very similar and have used a single common kernel from the beginning, since the CM 10.1 time).
If you want to install CM11 on your phone, you should install this:
http://download.cyanogenmod.org/?device=moto_msm8960
Any other CM11 build is obsolete.
Links to recommended CM 11 gapps can be found here:
http://wiki.cyanogenmod.org/w/Gapps

mrvek said:
Download these cm11 gapps from dhacker29 (supports both dalvik and art).
Install CM11. let it boot
Install gapps. reboot which will probably fail.
if the above failed: re-install cm11, wipe cache/dalvik and reboot.
Click to expand...
Click to collapse
I did in fact, download, redownload, install, reinstall, the Gapps from the link you provided, and got no advancements =( Unfortunately, I'll have to start all over from scratch most likely. I really appreciate your prompt response.

kabaldan said:
If you're using xt897c CM11 build, you're using very outdated build.
Your exact phone is not xt897c, you have just xt897, as anyone else.
There's no such thing as xt897c phone, xt897c is something I've made up as a temporary measure until we'll be able to do a single world-phone build that will support both GSM and CDMA networks.
Since long time ago, xt897 (gsm) and xt897c (cdma) builds have been unified into a single xt897 (world phone) build which made xt897c builds obsolete.
Later on, the builds for the whole 1st gen family of Motorola msm8960 devices (razr hd, razr m, atrix hd, electrify m and photon q) have been unified into a single moto_msm8960 build. All those devices are very similar and have used a single common kernel from the beginning, since the CM 10.1 time).
If you want to install CM11 on your phone, you should install this:
http://download.cyanogenmod.org/?device=moto_msm8960
Any other CM11 build is obsolete.
Links to recommended CM 11 gapps can be found here:
http://wiki.cyanogenmod.org/w/Gapps
Click to expand...
Click to collapse
That version still didn't work with Gapps. I've tried the many different ways of clearing cache, system, data, dalvik cache, etc etc. Nothing gets me past the Moto Logo. But, I've made another discovery, once I've installed CM11 on my phone, regardless of which of the two, once the phone has been turned off, it won't properly boot back up because it stays stuck that the Moto logo. The version you suggested loaded properly without Gapps installed just as the xt897c version did. But they both have the same "only works the first time no rebooting allowed" problem and neither work with Gapps.
One thing to note, I've used the CM10.1.3 (Stable) listed in the "xt897c" category as well as the Gapps (20130812) from the cyanogenmod website. Its what gave me the idea that my only option for CM via the CM website is the "xt897c" since that version of CM works flawlessly with Gapps installed (minus the lack of proper data connection (C Spire version) due to the rom having Sprint connection settings)
p.s. that is something I've been trying to search and "fix" for ages. I really hate being with a "lesser" company (C Spire) because of the lack of aftermarket and development support.

sulken2000 said:
That version still didn't work, I've tried the many different ways of clearing cash,system,data,dalvik,cache, etc etc. Nothing gets me past the Moto Logo. Hope there is another way.
One thing to note, I've used the CM10.1.3 (Stable) listed in the "xt897c" category as well as the Gapps (20130812) from the cyanogenmod website. Its what gave me the idea that my only option for CM via the CM website is the "xt897c" since that version of CM works flawlessly with Gapps installed (minus the lack of proper data connection (C Spire version) due to the rom having Sprint connection settings)
p.s. that is something I've been trying to search and "fix" for ages. I really hate being with a "lesser" company (C Spire) for the lack of aftermarket and development support.
Click to expand...
Click to collapse
Please, post the the info I requested here:
http://forum.xda-developers.com/showthread.php?t=2656570
I'm still waiting for any C Spire Photon Q owner to respond, so I could finally add the support for C Spire variant of XT897 to CM 11.0 moto_msm8960 unified builds.
Thanks.

kabaldan said:
Please, post the the info I requested here:
http://forum.xda-developers.com/showthread.php?t=2656570
I'm still waiting for any C Spire Photon Q owner to respond, so I could finally add the support for C Spire variant of XT897 to CM 11.0 moto_msm8960 unified builds.
Thanks.
Click to expand...
Click to collapse
Thanks for the prompt response. I have definitely come across that post in the past few days while trying to fix this irritating problem. I'll do some research to learn how to do that first and try to get you that info asap.

sulken2000 said:
...both have the same "only works the first time no rebooting allowed" problem and neither work with Gapps.
...
Click to expand...
Click to collapse
I noticed your remark above only now.
The symptom you mention seems to be caused by formatting of /data partition by recovery, which causes some not yet preciously determined filesystem corruption.
The second boot seems to be stalled, but what actually happens is that /data filesystem check and repair is running. And this repair will eventually finish, even though it can take tens of minutes. After the repair is done, the Android system boots fine and subsequent reboots are fine and fast.
Which recovery are you using? I use OpenRecovery 2.09 ( http://forum.xda-developers.com/showthread.php?t=2211579 ; see the last pages of the thread for a working download link), which actually does not re-format the /data partition filesystem when you do a data wipe/factory reset, it just deletes the content of the partition. So when using OpenRecovery, this corruption should not happen.

TWRP2.7.0.1

Sadly I'm also having troubles with my second Photon Q, this time from CSpire. Like Sulken's phone (also from CSpire) it doesn't survive reboot - however mine stops on unlocked bootloader warning. I was flashing Carbon 4.4 and suggested GAPPS first, but it wierdly let me send&receive smses and call people while on GSM network, however nobody could call me - line was busy. So I tried with CM11 and here everything is fine, however it also didn't survive reboot. On my first photon I always used TWRP but on this one, from CSpire, it cannot do factory reset - reboots on /data wiping, so I'm using OpenRecovery 2.09 now. Another very weird thing is that the phone won't boot after reflashing custom ROM. I'm doing a factory reset, flashing once again for example CM11 and it won't pass the unlocked bootloader warning, so I have to first do RSDLite+stock CSpire ROM and then flash CM11 once again, and then it works as long as I don't reboot...
I can't believe that nobody before tried SIM-mod & custom ROM on PhotonQ from CSpire... What's wrong? :/

micx_pl said:
Sadly I'm also having troubles with my second Photon Q, this time from CSpire. Like Sulken's phone (also from CSpire) it doesn't survive reboot - however mine stops on unlocked bootloader warning. I was flashing Carbon 4.4 and suggested GAPPS first, but it wierdly let me send&receive smses and call people while on GSM network, however nobody could call me - line was busy. So I tried with CM11 and here everything is fine, however it also didn't survive reboot. On my first photon I always used TWRP but on this one, from CSpire, it cannot do factory reset - reboots on /data wiping, so I'm using OpenRecovery 2.09 now. Another very weird thing is that the phone won't boot after reflashing custom ROM. I'm doing a factory reset, flashing once again for example CM11 and it won't pass the unlocked bootloader warning, so I have to first do RSDLite+stock CSpire ROM and then flash CM11 once again, and then it works as long as I don't reboot...
I can't believe that nobody before tried SIM-mod & custom ROM on PhotonQ from CSpire... What's wrong? :/
Click to expand...
Click to collapse
See my comment here: https://jira.cyanogenmod.org/browse...issuetabpanels:comment-tabpanel#comment-25465
How long have you let the phone to sit at the boot screen after the first reboot from working CM11?
(Make sure the battery is near full and keep the phone plugged to USB or power supply when attempting to wait over this stalled boot.)
If you want to get some information about what's going on while the boot is stalled, you should force a reboot by holding power button while waiting at the boot logo for some time already and also hold the volume-up button to reboot directly to recovery. Then post the content of /proc/last_kmsg captured via adb while the phone is in recovery after this forced reboot.
Code:
adb pull /proc/last_kmsg

Output of /proc/last_kmsg:
Code:
[ 0.211841,0] mot_init_factory_kill: Factory Kill Circuit: enabled
[ 0.221303,0] select_freq_plan: ACPU PVS: Fast
[ 0.221394,0] select_freq_plan: Max ACPU freq: 1512000 KHz
[ 0.224599,0] cpufreq_table_init: CPU0: 12 scaling frequencies supported.
[ 0.224721,0] cpufreq_table_init: CPU1: 12 scaling frequencies supported.
/////////////////////// CUT /////////////////////////
[ 0.946711,0] i2c-core: driver [tabla-i2c-core] using legacy suspend method
[ 0.946772,0] i2c-core: driver [tabla-i2c-core] using legacy resume method
[ 0.947352,0] Loading pn544 driver
[ 0.947443,0] pn544_probe : Probing pn544 driver
[ 0.947627,0] pn544_probe : PN544 Misc Minor: 26
[ 0.947718,0] pn544_probe : requesting IRQ 394
[ 0.948206,0] SCSI Media Changer driver v0.25
[ 0.948939,0] PPP generic driver version 2.4.2
[ 0.949092,0] PPP Deflate Compression module registered
[ 0.949183,0] PPP BSD Compression module registered
[ 0.949824,0] PPP MPPE Compression module registered
[ 0.949885,0] NET: Registered protocol family 24
[ 0.950007,0] SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256) (6 bit encapsulation enabled).
[ 0.950129,0] CSLIP: code copyright 1989 Regents of the University of California.
[ 0.950465,0] tun: Universal TUN/TAP device driver, 1.6
[ 0.950587,0] tun: (C) 1999-2004 Max Krasnyansky <[email protected]>
[ 0.951228,0] usbcore: registered new interface driver asix
[ 0.951381,0] usbcore: registered new interface driver cdc_ether
[ 0.951472,0] usbcore: registered new interface driver net1080
[ 0.951625,0] usbcore: registered new interface driver cdc_subset
[ 0.951777,0] usbcore: registered new interface driver zaurus
[ 0.951869,0] usbcore: registered new interface driver MOSCHIP usb-ethernet driver
[ 0.951991,0] cdc_ncm: 04-Aug-2011
[ 0.952083,0] usbcore: registered new interface driver cdc_ncm
[ 0.952235,0] usbcore: registered new interface driver rmnet_usb
[ 0.952601,0] rmnet usb ctrl Initialized.
[ 0.952723,0] wcnss_wlan probed in built-in mode
[ 0.953151,0] rmnet_init: BAM devices[8]
[ 0.955989,0] msm_otg msm_otg: msm_otg probe
[ 0.956142,0] msm_otg msm_otg: OTG regs = e18a8000
[ 0.958492,0] msm_otg_probe: MSM OTG Driver will operate in ACCY CONTROL mode
[ 0.958614,0] msm_otg_init_sm: setting default inputs for ACCY mode
[ 0.959072,0] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.959621,0] usbcore: registered new interface driver cdc_acm
[ 0.959682,0] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 0.959865,0] usbcore: registered new interface driver usblp
[ 0.959926,0] Initializing USB Mass Storage driver...
[ 0.960079,0] usbcore: registered new interface driver usb-storage
[ 0.960140,0] USB Mass Storage support registered.
[ 0.960262,0] usbcore: registered new interface driver ums-alauda
[ 0.960384,0] usbcore: registered new interface driver ums-cypress
[ 0.960537,0] usbcore: registered new interface driver ums-datafab
[ 0.960689,0] usbcore: registered new interface driver ums-freecom
[ 0.960781,0] usbcore: registered new interface driver ums-isd200
[ 0.960933,0] usbcore: registered new interface driver ums-jumpshot
[ 0.961025,0] usbcore: registered new interface driver ums-karma
[ 0.961178,0] usbcore: registered new interface driver ums-onetouch
[ 0.961269,0] usbcore: registered new interface driver ums-sddr09
[ 0.961422,0] usbcore: registered new interface driver ums-sddr55
[ 0.961544,0] usbcore: registered new interface driver ums-usbat
[ 0.961727,0] usbcore: registered new interface driver usbserial
[ 0.961788,0] usbserial: USB Serial Driver core
[ 0.961941,0] USB Serial support registered for Qualcomm USB modem
[ 0.962032,0] usbcore: registered new interface driver qcserial
[ 0.962185,0] usbcore: registered new interface driver usb_ehset_test
[ 0.962307,0] usbcore: registered new interface driver diag_bridge
[ 0.962459,0] usbcore: registered new interface driver mdm_bridge
[ 0.963131,0] msm_hsusb msm_hsusb: [usb_gadget_probe_driver] hw_ep_max = 32
[ 0.964413,0] android_usb gadget: Mass Storage Function, version: 2009/09/11
[ 0.964535,0] android_usb gadget: Number of LUNs=1
[ 0.964596,0] lun0: LUN: removable file: (no medium)
[ 0.965237,0] android_usb gadget: android_usb ready
[ 0.966366,0] diagchar initialized now
[ 0.966549,0] mousedev: PS/2 mouse device common for all mice
[ 0.966854,0] gpio_set_debounce: gpio-184 status -22
[ 0.967037,0] gpio_set_debounce: gpio-11 status -22
[ 0.967312,0] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[ 0.967373,0] added keypad filter to input dev gpio-keys
[ 0.968533,0] input: keypad_8960 as /devices/platform/msm_ssbi.0/pm8921-core/pm8xxx-keypad/input/input1
[ 0.968655,0] added keypad filter to input dev keypad_8960
[ 0.968930,0] usbcore: registered new interface driver xpad
[ 0.969113,0] usbcore: registered new interface driver usb_acecad
[ 0.969174,0] acecad: v3.2:USB Acecad Flair tablet driver
[ 0.969327,0] usbcore: registered new interface driver aiptek
[ 0.969418,0] aiptek: v2.3 (May 2, 2007):Aiptek HyperPen USB Tablet Driver (Linux 2.6.x)
[ 0.969510,0] aiptek: Bryan W. Headley/Chris Atenasio/Cedric Brun/Rene van Paassen
[ 0.969662,0] usbcore: registered new interface driver gtco
[ 0.969723,0] GTCO usb driver version: 2.00.0006
[ 0.969845,0] usbcore: registered new interface driver hanwang
[ 0.970028,0] usbcore: registered new interface driver kbtab
[ 0.970090,0] kbtab: v0.0.2:USB KB Gear JamStudio Tablet driver
[ 0.970242,0] usbcore: registered new interface driver wacom
[ 0.970303,0] wacom: v1.52:USB Wacom tablet driver
[ 0.970517,0] atmxt_probe: Driver: atmxt-i2c, Version: YN-04-01, Date: 2012-06-28
[ 0.971799,0] atmxt_probe: Probe successful.
[ 0.972195,0] input: light-prox as /devices/virtual/input/input2
[ 0.972470,0] ct406_probe: CT406 part detected
[ 0.973416,0] input: pmic8xxx_pwrkey as /devices/platform/msm_ssbi.0/pm8921-core/pm8xxx-pwrkey/input/input3
[ 0.973935,0] using input dev keypad_8960 for key reset
[ 0.973996,0] using input dev pmic8xxx_pwrkey for key reset
[ 0.974851,0] using rtc device, pm8xxx_rtc, for alarms
[ 0.974942,0] rtc-pm8xxx rtc-pm8xxx: rtc core: registered pm8xxx_rtc as rtc0
[ 0.975309,0] i2c /dev entries driver
[ 0.975614,0] Linux media interface: v0.10
[ 0.975766,0] lirc_dev: IR Remote Control driver registered, major 235
[ 0.975888,0] IR NEC protocol handler initialized
[ 0.975949,0] IR RC5(x) protocol handler initialized
[ 0.976041,0] IR RC6 protocol handler initialized
[ 0.976102,0] IR JVC protocol handler initialized
[ 0.976224,0] IR Sony protocol handler initialized
[ 0.976285,0] IR RC5 (streamzap) protocol handler initialized
[ 0.976377,0] IR LIRC bridge handler initialized
[ 0.976438,0] Linux video capture interface: v2.00
[ 0.976590,0] usbcore: registered new interface driver uvcvideo
[ 0.976712,0] USB Video Class driver (v1.1.0)
[ 0.976987,0] ov8820_power_up R:97 P:95 D:0 A:54 1.8:8921_l29
[ 0.977109,0] ov8820_regulator_on: 8921_l29 1800000
[ 1.069922,0] ov8820 chipid: 8820
[ 1.394750,0] ov8820: match_id success
[ 1.395116,0] msm_sensor_register mctl_node_name[0] = video1
[ 1.395177,0] ov8820_power_down
[ 1.430337,0] ov8820_regulator_off: 1.8
[ 1.440500,0] mt9m114_power_up R:76 D:89 A:82 CLK:24000000
[ 1.500137,0] mt9m114 id: 2481
[ 1.500198,0] mt9m114: match_id success
[ 1.500381,0] msm_sensor_register mctl_node_name[1] = video3
[ 1.500503,0] mt9m114_power_down
[ 1.504379,0] Driver for 1-wire Dallas network protocol.
[ 1.521318,0] lm75 10-0048: hwmon0: sensor 'tmp105'
[ 1.542041,0] pm8xxx_tm_probe: OK
[ 1.542591,0] device-mapper: uevent: version 1.0.3
[ 1.542957,0] device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialised: [email protected]
[ 1.543293,0] cpuidle: using governor ladder
[ 1.543415,0] cpuidle: using governor menu
[ 1.543781,0] mmc0: mci-version: 18
[ 1.545460,0] mmc0: bam physical base=0x12402000
[ 1.545582,0] mmc0: bam virtual base=0xe18b4000
[ 1.545643,0] mmc0: BAM device registered. bam_handle=0xe06d3a00
[ 1.545856,0] sps:REVISION of BAM 0xe18b4000 is 0x5.
[ 1.546162,0] mmc0: Qualcomm MSM SDCC-BAM at 0x0000000012402000 irq 130
[ 1.546284,0] mmc0: Qualcomm MSM SDCC-DML at 0x0000000012400800
[ 1.546375,0] mmc0: No card detect facilities available
[ 1.546650,0] mmc0: Qualcomm MSM SDCC-core at 0x0000000012400000 irq 136,0 dma -1 dmacrcri -1
[ 1.546741,0] mmc0: 8 bit data mode enabled
[ 1.546833,0] mmc0: 4 bit data mode disabled
[ 1.546894,0] mmc0: polling status mode disabled
[ 1.547016,0] mmc0: MMC clock 400000 -> 96000000 Hz, PCLK 0 Hz
[ 1.547077,0] mmc0: Slot eject status = 0
[ 1.547138,0] mmc0: Power save feature enable = 1
[ 1.547260,0] mmc0: SPS-BAM data transfer mode available
[ 1.547474,0] mmc1: mci-version: 18
[ 1.550495,0] mmc1: bam physical base=0x12182000
[ 1.550556,0] mmc1: bam virtual base=0xe18fc000
[ 1.550648,0] mmc1: BAM device registered. bam_handle=0xdff1c000
[ 1.550831,0] sps:REVISION of BAM 0xe18fc000 is 0x5.
[ 1.551106,0] mmc1: Qualcomm MSM SDCC-BAM at 0x0000000012182000 irq 128
[ 1.551228,0] mmc1: Qualcomm MSM SDCC-DML at 0x0000000012180800
[ 1.551838,0] mmc1: Qualcomm MSM SDCC-core at 0x0000000012180000 irq 134,651 dma -1 dmacrcri -1
[ 1.551899,0] mmc1: 8 bit data mode disabled
[ 1.552021,0] mmc1: 4 bit data mode enabled
[ 1.552083,0] mmc1: polling status mode disabled
[ 1.552144,0] mmc1: MMC clock 400000 -> 96000000 Hz, PCLK 0 Hz
[ 1.552235,0] mmc1: Slot eject status = 1
[ 1.552327,0] mmc1: Power save feature enable = 1
[ 1.552418,0] mmc1: SPS-BAM data transfer mode available
[ 1.552784,0] pm8xxx_rgb_led_probe: num_leds is 3
[ 1.552968,0] Registered led device: red
[ 1.553029,0] create_pm8xxx_rgb_led: LED class red, gpio 175, can sleep = 1
[ 1.553151,0] create_pm8xxx_rgb_led: requested pwm for red, pwm_id=0
[ 1.553273,0] Registered led device: green
[ 1.553334,0] create_pm8xxx_rgb_led: LED class green, gpio 176, can sleep = 1
[ 1.553456,0] create_pm8xxx_rgb_led: requested pwm for green, pwm_id=1
[ 1.553639,0] Registered led device: blue
[ 1.553700,0] create_pm8xxx_rgb_led: LED class blue, gpio 177, can sleep = 1
[ 1.553822,0] create_pm8xxx_rgb_led: requested pwm for blue, pwm_id=2
[ 1.555440,0] Registered led device: torch-flash
[ 1.557424,0] usbcore: registered new interface driver usbhid
[ 1.557485,0] usbhid: USB HID core driver
[ 1.557820,0] logger: created 1024K log 'log_main'
[ 1.557942,0] logger: created 512K log 'log_events'
[ 1.558095,0] logger: created 64K log 'log_radio'
[ 1.558248,0] logger: created 64K log 'log_system'
[ 1.558492,0] zram: num_devices not specified. Using default: 1
[ 1.558583,0] zram: Creating 1 devices ...
[ 1.559072,0] zcache: using lzo compressor
[ 1.559438,0] zcache: cleancache enabled using kernel transcendent memory and compression buddies
[ 1.559804,0] usbcore: registered new interface driver snd-usb-audio
[ 1.560781,0] tabla_probe
[ 1.561666,0] msm_pcm_probe: dev name msm-voip-dsp
[ 1.562368,0] msm_pcm_probe: dev name msm-pcm-dsp
[ 1.562612,0] msm_pcm_probe: dev name msm-multi-ch-pcm-dsp
[ 1.562856,0] msm_pcm_probe: dev name msm-lowlatency-pcm-dsp
[ 1.563619,0] msm_compr_probe: dev name msm-compr-dsp
[ 1.563985,0] msm-pcm-lpa msm-pcm-lpa: msm_pcm_probe: dev name msm-pcm-lpa
[ 1.564840,0] msm8960_configure_headset_mic_gpios: US_EURO_, AV_SWITCH gpios not configured!!!
[ 1.564962,0] msm8960_audio_init Fail to configure headset mic gpios
[ 1.753639,0] MMI Battery EEPROM Read 192 Bytes
[ 1.753761,0] MMI Battery EEPROM Page 2 Checksum = 0
[ 1.753822,0] MMI Battery EEPROM Page 3 Checksum = 0
[ 1.753883,0] MMI Battery EEPROM Copyright Valid = 1
[ 1.754005,0] MMI Battery Full Capacity 0xAE
[ 1.754066,0] MMI Battery Peak Voltage 0xB9
[ 1.754188,0] MMI Battery DC Impedance 0x5E
[ 1.754249,0] MMI Battery Cell ID 0x4157
[ 1.772531,0] asoc: snd-soc-dummy-dai <-> MultiMedia1 mapping ok
[ 1.772928,0] asoc: snd-soc-dummy-dai <-> MultiMedia2 mapping ok
[ 1.773233,0] asoc: snd-soc-dummy-dai <-> CS-VOICE mapping ok
[ 1.773630,0] asoc: snd-soc-dummy-dai <-> VoIP mapping ok
[ 1.773935,0] asoc: snd-soc-dummy-dai <-> MultiMedia3 mapping ok
[ 1.774271,0] asoc: snd-soc-dummy-dai <-> SLIMBUS0_HOSTLESS mapping ok
[ 1.774668,0] asoc: snd-soc-dummy-dai <-> INT_FM_HOSTLESS mapping ok
[ 1.774942,0] asoc: msm-stub-rx <-> msm-dai-q6.241 mapping ok
[ 1.775278,0] asoc: msm-stub-tx <-> msm-dai-q6.240 mapping ok
[ 1.775614,0] asoc: snd-soc-dummy-dai <-> MultiMedia4 mapping ok
[ 1.776010,0] asoc: snd-soc-dummy-dai <-> AUXPCM_HOSTLESS mapping ok
[ 1.776316,0] asoc: snd-soc-dummy-dai <-> HDMI_HOSTLESS mapping ok
[ 1.776682,0] asoc: snd-soc-dummy-dai <-> VoLTE mapping ok
[ 1.777018,0] asoc: snd-soc-dummy-dai <-> Voice2 mapping ok
[ 1.777353,0] asoc: snd-soc-dummy-dai <-> MultiMedia5 mapping ok
[ 1.777628,0] asoc: msm-stub-rx <-> msm-dai-q6.12288 mapping ok
[ 1.777933,0] asoc: msm-stub-tx <-> msm-dai-q6.12289 mapping ok
[ 1.778208,0] asoc: msm-stub-rx <-> msm-dai-q6.12292 mapping ok
[ 1.778513,0] asoc: msm-stub-tx <-> msm-dai-q6.12293 mapping ok
[ 1.778788,0] asoc: msm-stub-rx <-> msm-dai-q6-hdmi.8 mapping ok
[ 1.779063,0] asoc: msm-stub-rx <-> msm-dai-q6.224 mapping ok
[ 1.779337,0] asoc: msm-stub-tx <-> msm-dai-q6.225 mapping ok
[ 1.779642,0] asoc: msm-stub-rx <-> msm-dai-q6.2 mapping ok
[ 1.779917,0] asoc: msm-stub-tx <-> msm-dai-q6.3 mapping ok
[ 1.780192,0] asoc: msm-stub-rx <-> msm-dai-q6.32773 mapping ok
[ 1.780497,0] asoc: msm-stub-tx <-> msm-dai-q6.32772 mapping ok
[ 1.780802,0] asoc: msm-stub-tx <-> msm-dai-q6.32771 mapping ok
[ 1.781107,0] msm8960_audrx_init : Tabla version 2
[ 1.781413,0] tabla_codec tabla_codec: Failed to add route ANCRight Headset Mic->MIC BIAS3 Internal1
[ 1.816847,0] asoc: tabla_rx1 <-> msm-dai-q6.16384 mapping ok
[ 1.818373,0] asoc: tabla_tx1 <-> msm-dai-q6.16385 mapping ok
[ 1.818953,0] asoc: tabla_tx2 <-> msm-dai-q6.16389 mapping ok
[ 1.819471,0] asoc: tabla_rx3 <-> msm-dai-q6.16388 mapping ok
[ 1.821364,0] input: msm8960-snd-card Button Jack as /devices/platform/soc-audio.0/sound/card0/input4
[ 1.821669,0] input: msm8960-snd-card Headset Jack as /devices/platform/soc-audio.0/sound/card0/input5
[ 1.824721,0] oprofile: using arm/armv7-krait
[ 1.824965,0] GACT probability NOT on
[ 1.825057,0] Mirror/redirect action on
[ 1.825118,0] u32 classifier
[ 1.825209,0] Actions configured
[ 1.825331,0] Netfilter messages via NETLINK v0.30.
[ 1.825423,0] nf_conntrack version 0.5.0 (12661 buckets, 50644 max)
[ 1.826033,0] ctnetlink v0.93: registering with nfnetlink.
[ 1.826155,0] NF_TPROXY: Transparent proxy support initialized, version 4.1.0
[ 1.826247,0] NF_TPROXY: Copyright (c) 2006-2007 BalaBit IT Ltd.
[ 1.826705,0] xt_time: kernel timezone is -0000
[ 1.826888,0] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 1.827132,0] arp_tables: (C) 2002 David S. Miller
[ 1.827285,0] TCP bic registered
[ 1.827346,0] TCP cubic registered
[ 1.827407,0] TCP htcp registered
[ 1.827529,0] Initializing XFRM netlink socket
[ 1.828139,0] NET: Registered protocol family 10
[ 1.829391,0] Mobile IPv6
[ 1.829482,0] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 1.829696,0] IPv6 over IPv4 tunneling driver
[ 1.830489,0] NET: Registered protocol family 17
[ 1.830581,0] NET: Registered protocol family 15
[ 1.830703,0] Bridge firewalling registered
[ 1.830947,0] Bluetooth: RFCOMM TTY layer initialized
[ 1.831039,0] Bluetooth: RFCOMM socket layer initialized
[ 1.831130,0] Bluetooth: RFCOMM ver 1.11
[ 1.831191,0] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 1.831313,0] Bluetooth: BNEP filters: protocol multicast
[ 1.831374,0] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[ 1.831619,0] L2TP core driver, V2.0
[ 1.831680,0] Registering the dns_resolver key type
[ 1.831741,0] VFP support v0.3: implementor 51 architecture 64 part 4d variant 1 rev 0
[ 1.831954,0] Registering SWP/SWPB emulation handler
[ 1.841385,0] clock_late_init() disabled 199 unused clocks
[ 1.849504,0] MSM Watchdog Initialized
[ 1.854509,1] registered taskstats version 1
[ 1.855943,0] Powering up HoneyBadger
[ 1.909690,0] EMU-det(request_gpios): requesting gpio[2] EMU_SCI_OUT_GPIO-205
[ 1.909812,0] EMU-det(request_gpios): gpio 205 is IN
[ 1.909964,0] EMU-det(request_gpios): exporting gpio EMU_SCI_OUT_GPIO-205
[ 1.910056,0] EMU-det(request_gpios): couldn't find OPTIONAL EMU_ID_EN_GPIO
[ 1.910117,0] EMU-det(request_gpios): requesting gpio[0] EMU_MUX_CTRL0_GPIO-107
[ 1.910239,0] EMU-det(request_gpios): gpio 107 is OUT
[ 1.910300,0] EMU-det(request_gpios): requesting gpio[1] EMU_MUX_CTRL1_GPIO-96
[ 1.910422,0] EMU-det(request_gpios): gpio 96 is OUT
[ 1.910483,0] EMU-det(request_gpios): requesting gpio[4] SEMU_PPD_DET_GPIO-174
[ 1.910605,0] EMU-det(request_gpios): gpio 174 is IN
[ 1.910788,0] EMU-det(request_gpios): exporting gpio SEMU_PPD_DET_GPIO-174
[ 1.910849,0] EMU-det(request_gpios): requesting gpio[5] SEMU_ALT_MODE_EN_GPIO-186
[ 1.911033,0] EMU-det(request_gpios): exporting gpio SEMU_ALT_MODE_EN_GPIO-186
[ 1.911094,0] EMU-det(request_gpios): couldn't find OPTIONAL EMU_ID_GPIO
[ 1.911216,0] EMU-det(request_gpios): requesting gpio[7] DMB_PPD_DET_GPIO-204
[ 1.911338,0] EMU-det(request_gpios): gpio 204 is IN
[ 1.911460,0] EMU-det(request_gpios): exporting gpio DMB_PPD_DET_GPIO-204
[ 1.911582,0] EMU-det(request_gpios): requesting gpio[8] DPLUS_GPIO-192
[ 1.911643,0] EMU-det(request_gpios): requesting gpio[9] DMINUS_GPIO-172
[ 1.911765,0] EMU-det(request_gpios): requesting gpio[10] WHISPER_UART_TX_GPIO-18
[ 1.911857,0] EMU-det(request_gpios): gpio 18 is OUT
[ 1.911979,0] EMU-det(request_gpios): exporting gpio WHISPER_UART_TX_GPIO-18
[ 1.912101,0] EMU-det(request_gpios): requesting gpio[11] WHISPER_UART_RX_GPIO-19
[ 1.912162,0] EMU-det(request_gpios): gpio 19 is IN
[ 1.912345,0] EMU-det(request_gpios): exporting gpio WHISPER_UART_RX_GPIO-19
[ 1.912406,0] EMU-det(request_gpios): requesting gpio[12] TX_PAIR_GPIO-173
[ 1.912528,0] EMU-det(request_gpios): requesting gpio[13] RX_PAIR_GPIO-193
[ 1.912650,0] EMU-det(emu_id_protection_setup): No neccessary action
[ 1.912711,0] EMU-det(emu_det_probe): done with gpios
[ 1.933496,0] mmc0: new high speed DDR MMC card at address 0001
[ 1.934411,0] mmcblk0: mmc0:0001 008G4B 7.40 GiB
[ 1.936365,0] mmcblk0boot0: mmc0:0001 008G4B partition 1 2.00 MiB
[ 1.936975,0] mmcblk0boot1: mmc0:0001 008G4B partition 2 2.00 MiB
[ 1.937158,1] msm_otg msm_otg: phy_reset: success
[ 1.943171,0] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15 p16 p17 p18 p19 p20 p21 p22 p23 p24 p25 p26 p27 p28 p29 p30 p31 p32 p33 p34 p35 p36 p37 p38 p39
[ 1.947077,0] apanic: Bound to mmc block device 'mmcblk0p33(259:1)'
[ 1.947169,0] apanic: No panic data available
[ 1.950160,0] mmcblk0boot1: unknown partition table
[ 1.953120,0] mmcblk0boot0: unknown partition table
[ 2.039859,1] EMU-det(request_irqs): requesting irq[1] EMU_SCI_OUT_GPIO-577
[ 2.040470,1] EMU-det(request_irqs): requesting irq[0] SEMU_PPD_DET_GPIO-654
[ 2.040866,1] EMU-det(emu_det_probe): done with irqs
[ 2.041233,1] EMU-det(emu_det_probe): registered callback with PM8921
[ 2.042698,1] EMU-det(emu_det_probe): EMU detection driver started
[ 2.043522,1] rtc-pm8xxx rtc-pm8xxx: setting system clock to 2014-04-06 07:20:10 UTC (1396768810)
[ 2.045444,0] Battery Cell ID Found: 3
[ 2.046909,0] read_shutdown_soc: shutdown_soc = 72
[ 2.048069,0] read_ocv_trim: program rev reg is 0x4b
[ 2.053349,0] adjust_remaining_charge_for_shutdown_soc: shutdown_soc = 72 forcing it now
[ 2.053715,0] adjust_remaining_charge_for_shutdown_soc: To force shutdown_soc = 72, rc = 1263806, pc = 72, ocv mv = 4027
[ 2.054082,0] adjust_remaining_charge_for_shutdown_soc: test revlookup pc = 73 for ocv = 4027
[ 2.054265,0] calculate_state_of_charge: Forcing SHUTDOWN_SOC = 72
[ 2.054631,0] pm8921_bms_probe: OK battery_capacity_at_boot=72 volt = 3755310 ocv = 4027000
[ 2.057652,0] get_prop_batt_status: alarm_state=0,batt_valid=0
[ 2.061193,0] pm8921_is_battery_charging: called before init
[ 2.061468,0] calculate_state_of_charge: Forcing SHUTDOWN_SOC = 72
[ 2.070502,0] get_prop_batt_status: alarm_state=0,batt_valid=0
[ 2.070837,0] get_prop_batt_status: alarm_state=0,batt_valid=0
[ 2.073462,0] calculate_state_of_charge: Forcing SHUTDOWN_SOC = 72
[ 2.083503,0] EMU-det(emu_det_vbus_state): PM8921 USBIN callback: out
[ 2.086464,0] Battery Cell ID Found: 3
[ 2.089760,0] ALSA device list:
[ 2.089913,0] #0: msm8960-snd-card
[ 2.090248,0] Warning: unable to open an initial console.
[ 2.092415,0] Freeing init memory: 992K
[ 2.108713,1] SELinux: 1024 avtab hash slots, 3544 rules.
[ 2.113749,1] SELinux: 1024 avtab hash slots, 3544 rules.
[ 2.113810,1] SELinux: 1 users, 2 roles, 344 types, 1 bools, 1 sens, 1024 cats
[ 2.114054,1] SELinux: 84 classes, 3544 rules
[ 2.114878,1] SELinux: Completing initialization.
[ 2.114970,1] SELinux: Setting up existing superblocks.
[ 2.115061,1] SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
[ 2.115183,1] SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
[ 2.115305,1] SELinux: initialized (dev bdev, type bdev), not configured for labeling
[ 2.115428,1] SELinux: initialized (dev proc, type proc), uses genfs_contexts
[ 2.115550,1] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[ 2.115641,1] SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts
[ 2.121806,1] SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
[ 2.121928,1] SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
[ 2.121989,1] SELinux: initialized (dev anon_inodefs, type anon_inodefs), not configured for labeling
[ 2.122112,1] SELinux: initialized (dev devpts, type devpts), uses transition SIDs
[ 2.122264,1] SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts
[ 2.122386,1] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[ 2.122539,1] SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
[ 2.129772,0] EMU-det(detection_work): state CONFIG, time since last run -297880 ms
[ 2.130169,0] EMU-det(alt_mode_setup): SEMU_ALT_MODE_EN is standard
[ 2.139783,0] EMU-det(detection_work): state SAMPLE, time since last run 10 ms
[ 2.141217,0] EMU-det(adc_vbus_get): vbus=34 mV
[ 2.199816,0] EMU-det(get_sense): SEMU_PPD_DET: ID floating
[ 2.252189,1] type=1403 audit(1396768810.700:2): policy loaded auid=4294967295 ses=4294967295
[ 2.252403,1] SELinux: Loaded policy from /sepolicy
[ 2.256493,1] SELinux: Loaded file_contexts from /file_contexts
[ 2.260247,0] EMU-det(get_sense): No need to check DMB_PPD_DET_N
[ 2.260613,0] EMU-det(sense_dp_dm): D+/D- mask: 0x10
[ 2.260827,0] EMU-det(get_sense): irq=0, SESS_END, FLOAT, NO_DCD,
[ 2.261132,0] EMU-det(detection_work): SAMPLE keep waiting ...
[ 2.269952,0] EMU-det(detection_work): state SAMPLE, time since last run 130 ms
[ 2.271448,0] EMU-det(adc_vbus_get): vbus=34 mV
[ 2.329925,0] EMU-det(get_sense): SEMU_PPD_DET: ID floating
[ 2.389928,0] EMU-det(get_sense): No need to check DMB_PPD_DET_N
[ 2.390141,0] EMU-det(sense_dp_dm): D+/D- mask: 0x10
[ 2.390477,0] EMU-det(get_sense): irq=0, SESS_END, FLOAT, NO_DCD,
[ 2.390691,0] EMU-det(detection_work): state IDENTIFY, time since last run 120 ms
[ 2.392217,0] EMU-det(adc_vbus_get): vbus=34 mV
[ 2.460369,0] EMU-det(get_sense): SEMU_PPD_DET: ID floating
[ 2.519975,0] EMU-det(get_sense): No need to check DMB_PPD_DET_N
[ 2.520189,0] EMU-det(sense_dp_dm): D+/D- mask: 0x10
[ 2.520524,0] EMU-det(get_sense): irq=0, SESS_END, FLOAT, NO_DCD,
[ 2.520708,0] EMU-det(detection_work): no accessory
[ 2.521043,0] EMU-det(notify_accy): EMU detection Notify: NONE
[ 2.521471,0] EMU-det(alt_mode_setup): SEMU_ALT_MODE_EN is standard
[ 2.521776,0] EMU-det(emu_id_protection_setup): No neccessary action
[ 2.521989,0] msm_otg msm_otg: received DISCONNECTED event
[ 2.522325,0] msm_otg msm_otg: UNDEFINED --> IDLE
[ 2.523638,0] pm8921_chg_accy_notify: pm8921_chg_accy_notify: accy_state: 7
[ 2.524767,0] msm_otg msm_otg: USB in low power mode
[ 2.526781,0] calculate_state_of_charge: Forcing SHUTDOWN_SOC = 72
[ 3.609095,1] init: could not import file '/init.carrier.rc' from '/init.rc'
[ 3.610621,1] init (1): /proc/1/oom_adj is deprecated, please use /proc/1/oom_score_adj instead.
[ 3.611689,1] init: do_chown: Could not access /selinux/booleans
[ 3.668213,0] calculate_state_of_charge: Forcing SHUTDOWN_SOC = 72
[ 4.120921,1] SELinux: initialized (dev cgroup, type cgroup), uses genfs_contexts
[ 4.122325,1] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[ 4.129742,1] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[ 4.130627,1] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[ 4.131603,1] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[ 4.280970,1] SELinux: initialized (dev cgroup, type cgroup), uses genfs_contexts
[ 4.311277,0] zcache: created ephemeral tmem pool, id=0, client=65535
[ 4.312620,0] EXT4-fs (mmcblk0p37): recovery complete
[ 4.312833,0] EXT4-fs (mmcblk0p37): mounted filesystem with ordered data mode. Opts: noauto_da_alloc,barrier=1
[ 4.313200,0] SELinux: initialized (dev mmcblk0p37, type ext4), uses xattr
[ 4.324034,0] zcache: created ephemeral tmem pool, id=1, client=65535
[ 4.324767,0] EXT4-fs (mmcblk0p39): mounted filesystem with ordered data mode. Opts: nomblk_io_submit,errors=remount-ro
[ 4.325164,0] SELinux: initialized (dev mmcblk0p39, type ext4), uses xattr
[ 4.325927,0] zcache: destroyed pool id=1, cli_id=65535
[ 4.360842,1] fs_mgr: Running /system/bin/e2fsck on /dev/block/platform/msm_sdcc.1/by-name/userdata
[ 4.368197,1] atmxt_tdat_callback: Processing atmxt-r2.tdat...
[ 4.369082,1] input: atmxt-i2c as /devices/virtual/input/input6
[ 4.401312,0] atmxt_set_ic_state: IC state UNKNOWN -> PRESENT
[ 4.401709,0] atmxt_restart_ic: Family ID: 0x82, Variant ID: 0x1A, Version: 0x10, Build: 0xAA, Matrix: 24x14, Objects: 22
[ 4.408484,0] atmxt_message_handler6: Touch IC reset complete.
[ 4.408698,0] atmxt_message_handler6: Touch IC is calibrating.
[ 4.409064,0] atmxt_set_ic_state: IC state PRESENT -> ACTIVE
[ 4.409705,0] atmxt_set_drv_state: Driver state INIT -> ACTIVE
[ 4.410254,0] atmxt_tdat_callback: Touch initialization successful.
[ 4.411719,1] atmxt_active_handler: Received invalid data: 0xFF 0x90 0xE9 0xD5 0x0C 0x00 0x00 0x00 0xFF 0x90 0xE9 0xD5 0x0C 0x00 0x00 0x00.
[ 4.412238,1] atmxt_active_handler: Touch active handler failed with error code -22.
[ 4.413764,1] atmxt_message_handler6: Touch IC calibration complete.
[ 4.558583,1] atmxt_message_handler6: Touch IC is calibrating.
[ 4.591271,1] atmxt_message_handler6: Touch IC calibration complete.
[ 5.421303,0] lm3532_bl_work: enabling PWM
[ 32.090920,0] shutdown_soc_work: not forcing shutdown soc anymore
[ 1404.024049,0] Report pwrkey press event
[ 1404.087501,0] pm8xxx_irq_mask_ack: mask acking rouge irq=664 pmirq=224
[ 1410.810773,0] resout_irq_handler PMIC Initiated shutdown
[ 1410.810834,0] PMIC Initiated shutdown cpu_power_off cpu=0
[ 1410.810834,1] PMIC Initiated shutdown cpu_power_off cpu=1
[ 1410.811017,0] Powering off the SoC
[ 1410.811109,0] Calling scm to disable arbiter
[ 1410.811231,0] SCM returned even when asked to busy loop rc=-4
[ 1410.811292,0] waiting on pmic to shut msm down
18 Corrected bytes, 0 unrecoverable blocks
CPU type is ACPU PVS: Fast
That was after like 20-30 minutes of booting. Thanks in advance
EDIT:
Oups. "The text that you have entered is too long (39454 characters). Please shorten it to 30000 characters long." I'll cut the begining...
EDIT2:
It booted up! I rebooted it once again and left it at my desk. When I came back after 1h, it was already on the home screen! thanks for help kabaldan I think such info could be put as NOTICE on main rom page, I think normally everyone would consider its stuck when it's not booting in a few minutes...

Thank you Kabaldan!
It took exactly 40 minutes my Photon Q to reboot from /data filesystem check. I used:
* cm-11-20140505-SNAPSHOT-M6-moto_msm8960.zip from download.cyanogenmod.org/?type=snapshot&device=moto_msm8960
* TWRP 2.7.0.1
* gapps-kk-20140105-signed.zip from wiki.cyanogenmod.org/w/Google_Apps

micx_pl said:
Output of /proc/last_kmsg:
Code:
…
[ 4.591271,1] atmxt_message_handler6: Touch IC calibration complete.
[ 5.421303,0] lm3532_bl_work: enabling PWM
[U][ 32.090920,0] shutdown_soc_work: not forcing shutdown soc anymore[/U]
[ 1404.024049,0] Report pwrkey press event
[ 1404.087501,0] pm8xxx_irq_mask_ack: mask acking rouge irq=664 pmirq=224
[ 1410.810773,0] resout_irq_handler PMIC Initiated shutdown
…
Click to expand...
Click to collapse
Thanks for that intel. Am I right, that this is the "breaking point" in the log, when the mentioned repair starts and -later- the reset is initiated? My log has the same "breaking point" in it: https://www.dropbox.com/s/0iqdr30jmhft2co/last_kmsg
So is this the same phenomenon? This is the first time I pulled a log using adb, but do not recognise anything going on here.
kabaldan said:
If you want to get some information about what's going on while the boot is stalled, …
Click to expand...
Click to collapse
Edit:
May this also help with errors mounting certain partions within TWRP and is there a way to fix this - maybe through adb? Because doing a quick search I found this guide (fore theKindle, though): http://forum.xda-developers.com/showthread.php?t=1949372

Schattenspieler said:
Thanks for that intel. Am I right, that this is the "breaking point" in the log, when the mentioned repair starts and -later- the reset is initiated? My log has the same "breaking point" in it: https://www.dropbox.com/s/0iqdr30jmhft2co/last_kmsg
So is this the same phenomenon? This is the first time I pulled a log using adb, but do not recognise anything going on here.
Edit:
May this also help with errors mounting certain partions within TWRP and is there a way to fix this - maybe through adb? Because doing a quick search I found this guide (fore theKindle, though): http://forum.xda-developers.com/showthread.php?t=1949372
Click to expand...
Click to collapse
The significant point in the above log is:
Code:
[ 4.360842,1] fs_mgr: Running /system/bin/e2fsck on /dev/block/platform/msm_sdcc.1/by-name/userdata
and the important fact is that it is not followed by any more e2fsck messages, which means that for the duration of the log, e2fsck hasn't finished the work yet.
e2fsck is still repairing userdata and the init is waiting for userdata mount to continue the boot process, but in the end the user keeps power button pressed to enforce reboot, so e2fsck is aborted and the filesystem left damaged.
In your log, you can even see that the active process at the point of premature, user-enforced reboot was e2fsck:
Code:
[ 279.105569,0] Report pwrkey press event
[ 286.105966,0] Power key held for 7 seconds; will reboot on release.
[ 286.473981,1] current process is 140:e2fsck, prio is 120.

kabaldan said:
In your log, you can even see that the active process at the point of premature, user-enforced reboot was e2fsck:
Click to expand...
Click to collapse
Now that you mention it! I didn't think, e2fsck was a specific command, but more of a boot state code (sort of thing). But I should have searched. Now i see the "e2fs" (the filesystem) and "ck" as in check. :silly:
I now restored a TWRP backup with 4.4.3 and have been fine since. So there is either something wrong with the 4.4.4 CarbonROM on the Photon oder with TWRP, when installing the/some ROMs. Seeing this thread, I tend towards the second.

Schattenspieler said:
Now that you mention it! I didn't think, e2fsck was a specific command, but more of a boot state code (sort of thing). But I should have searched. Now i see the "e2fs" (the filesystem) and "ck" as in check. :silly:
I now restored a TWRP backup with 4.4.3 and have been fine since. So there is either something wrong with the 4.4.4 CarbonROM on the Photon oder with TWRP, when installing the/some ROMs. Seeing this thread, I tend towards the second.
Click to expand...
Click to collapse
If you had let it boot, it probably would have been fine.

[Q&A] [ROM] [AeroKernel] Unofficial CyanogenMod 11

Q&A for [ROM] [AeroKernel] Unofficial CyanogenMod 11
Some developers prefer that questions remain separate from their main development thread to help keep things organized. Placing your question within this thread will increase its chances of being answered by a member of the community or by the developer. Thanks for understanding and for helping to keep XDA neat and tidy! :smile:

any chance of having that dual sim memory option?
for example: i set a contact number to call from SIM 1 automatically.. and other from SIM 2... but the default option is to "ask me wich sim to use"
great job by the way...
almost no bugs with me so far..
i'm using the Quarx's nightlies on an XT1033

Can i install this rom only wiping cache/davilk cache? im on CM11

moquiwa said:
any chance of having that dual sim memory option?
for example: i set a contact number to call from SIM 1 automatically.. and other from SIM 2... but the default option is to "ask me wich sim to use"
great job by the way...
almost no bugs with me so far..
i'm using the Quarx's nightlies on an XT1033
Click to expand...
Click to collapse
Yes, this is good option. I'll take a look into it.
Sent from my Moto G

Hi Quarx,
Is there any problem with XT1039 as I am about to deploy your ROM over the weekend?
Cheers

Hi quarx
Please take look if you can.
The quiet hours dont silent calls and not respect the options for it.
On dual sim version
Enviado de meu Moto G usando Tapatalk

data not working on sim2
hi quarx ,
i m on 23oct nightly.Everything seems to be working fine (not tested wifi yet).
Only issue im facing that data is not working on sim2.
what could be possible reason ?
---------- Post added at 06:22 PM ---------- Previous post was at 06:03 PM ----------
mangesh511 said:
hi quarx ,
i m on 23oct nightly.Everything seems to be working fine (not tested wifi yet).
Only issue im facing that data is not working on sim2.
what could be possible reason ?
Click to expand...
Click to collapse
quarx,
if i disabled sim1 then only internet is working on sim2 .looks like its a bug.
---------- Post added at 06:27 PM ---------- Previous post was at 06:22 PM ----------
after deactivating & activating both sim resolved issue.
thanks.

@Quarx
Not able to update via Cm updater, and this is not even new bug. It is lasting since 10 oct or so. Can u plz check?

network speed indicator
how to get network speed indicator on statusbar ?
thanks.

battery drain issue - 23 oct nightly
after full day usage i am seeing high battery drain issue compare to stock rom.
screen is showing maximum battery usage. Any suggestion.

issue after update
quarx,
currently on 25th oct nightly. contact setting is giving fc.
also play store giving issue.

i am using 24 oct nightly since last 2 days.
everything working smooth).no issue.
thanks quarx.

I Love this rom but is there a way to make the signal as strong as the stock roms.... where i barely have service on stock i have no service at all on this rom... any tips for help greatly

Do I need to convert to gpe for this rom to work, or can I just "wipe and install?" (xt1032, eu retail)

Same Problem
I have the same problem with Led Notif that always on (not fading).
Also after update to nightly 12112014. I can't detect the hidden wifi.

The rom is very nica but my reboots when i volume up/down while watching a video
Sent from my Moto G using XDA Premium 4 mobile app

Better Battery Life?
For the past few weeks, every CM ROM I use has an idle battery drain of 2-3% which means I get an average of 16 hours with 4 hours of SOT while with earlier builds, I used to get much better battery life? Which kernel settings relating to this should I modify to get a better battery life?

CM11 for Moto G 2nd Gen 2014 XT1068
There seems to be no specific ROM for the dual sim XT1068 version of the Moto G Second Gen.
Does this ROM work for the XT1068 and does anyone have experience with this?
If so, what kind of bugs can I expect?
I have the European (don't know if it matters) Moto G 2014 Titan (XT1068) version.
Android 4.4.4
Baseband MSM862BP_1032.394.88.00R

CM11 issues (bugs or features???)
I have quarx CM11 build (cm-11-20141216-NIGHTLY-falcon.zip)
Can someone tell me why this rom is missing following (I have XT1033 phone)
1. Not available to add (missing in possible choices) "Network Mode" tile. I was told that it's hidden in 2sim phones. Is it correct or is it a bug? I need this tile very much
2. Periodically function "Ascending ringtone" stops working. I remember that after wiping of "data" in a recovery and installing a new build it starts working but it seems like after every upgrade it stops working
3. Why there is no switcher in systems settings - Mobile Networks (like in Wi-Fi or Bluetooth)?
4. In the "Mobile Networks" I usually have 2g in "Preferred network type". And when I click to choose 3g there in 90% I still have 2g mode. And only second tap chooses 3g
As I know these issues do exist in all CM11 builds (not only the ones from Quarx). Any ideas why?

Does anyone got otg working. Whatever I connect, it keeps giving me following errors: (last 100 dmesg lines after trying 2 times)
Spoiler
[ 382.170269,0] gic_show_resume_irq: 203 triggered
[ 382.170269,0] gic_show_resume_irq: 222 triggered
[ 382.170750,0] PM: resume_noirq longest - msm_watchdog(0xc015964c) (0.002 msecs)
[ 382.171568,0] PM: noirq resume of devices complete after 0.966 msecs
[ 382.172041,0] Report pwrkey press event
[ 382.172565,0] PM: early resume of devices complete after 0.308 msecs
[ 382.175199,0] PM: resume of devices complete after 2.621 msecs
[ 382.178558,0] Restarting tasks ...
[ 382.182872,0] QSEECOM: qseecom_receive_req: Interrupted: exiting Listener Service = 8192
[ 382.183110,0] QSEECOM: qseecom_ioctl: failed qseecom_receive_req: -512
[ 382.183274,0] QSEECOM: qseecom_receive_req: Interrupted: exiting Listener Service = 12288
[ 382.183361,0] QSEECOM: qseecom_ioctl: failed qseecom_receive_req: -512
[ 382.183522,0] QSEECOM: qseecom_receive_req: Interrupted: exiting Listener Service = 11
[ 382.183677,0] QSEECOM: qseecom_ioctl: failed qseecom_receive_req: -512
[ 382.183771,0] QSEECOM: qseecom_receive_req: Interrupted: exiting Listener Service = 10
[ 382.183924,0] QSEECOM: qseecom_ioctl: failed qseecom_receive_req: -512
[ 382.188302,0] done.
[ 382.188817,0] PM: suspend exit 2014-12-22 09:45:14.885503349 UTC
[ 382.247446,0] ct406_work_prox_start: Prox mode start
[ 382.312725,0] ct406_disable_prox: Prox mode stop
[ 382.350206,0] Report pwrkey release event
[ 382.365178,0] mdss_dsi_on+: ctrl=e4818010 ndx=0
[ 382.388580,0] mdss_dsi_on-:
[ 382.388594,0] mdss_dsi_panel_on+: ctrl=e4818010 ndx=0
[ 382.579927,0] qup_i2c f9927000.i2c: QUP: I2C status flags :0xc1300c8, irq:131
[ 382.579956,0] qup_i2c f9927000.i2c: I2C slave addr:0x20 not connected
[ 382.579972,0] synaptics_dsx_i2c 5-0020: synaptics_rmi4_i2c_write: I2C retry 1
[ 382.607642,1] synaptics_dsx_sensor_state: state change SUSPEND -> ACTIVE
[ 382.608242,1] mdss_dsi_panel_on-. Pwr_mode(0x0A) = 0x9c
[ 382.625312,0] qcom,leds-qpnp leds-qpnp-e4a31400: backlight on
[ 382.781940,0] wlan: [1750:E :HDD] hdd_conf_arp_offload: 1106: fenable = 0
[ 394.456848,0] wlan: [1595:E :HDP] hdd_tx_rx_pkt_cnt_stat_timer_handler: Disable split scan
[ 395.851727,0] msm_otg f9a55000.usb: USB exited from low power mode
[ 396.066928,0] msm_hsusb_host msm_hsusb_host: Qualcomm On-Chip EHCI Host Controller
[ 396.067449,0] msm_hsusb_host msm_hsusb_host: new USB bus registered, assigned bus number 1
[ 396.096940,0] msm_hsusb_host msm_hsusb_host: irq 166, io mem 0xf9a55000
[ 396.116656,0] msm_hsusb_host msm_hsusb_host: USB 2.0 started, EHCI 1.00
[ 396.116875,0] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 396.117054,0] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 396.117229,0] usb usb1: Product: Qualcomm On-Chip EHCI Host Controller
[ 396.117329,0] usb usb1: Manufacturer: Linux 3.4.42-AeroKernel-g63fb0d2 ehci_hcd
[ 396.117506,0] usb usb1: SerialNumber: msm_hsusb_host
[ 396.118404,0] hub 1-0:1.0: USB hub found
[ 396.118604,0] hub 1-0:1.0: 1 port detected
[ 396.436776,0] usb 1-1: new full-speed USB device number 2 using msm_hsusb_host
[ 396.646861,0] usb 1-1: device descriptor read/64, error -71
[ 396.966841,0] usb 1-1: device descriptor read/64, error -71
[ 397.196715,0] usb 1-1: new full-speed USB device number 3 using msm_hsusb_host
[ 397.406833,0] usb 1-1: device descriptor read/64, error -71
[ 397.726637,0] usb 1-1: device descriptor read/64, error -71
[ 397.956848,0] usb 1-1: new full-speed USB device number 4 using msm_hsusb_host
[ 398.436832,0] usb 1-1: device not accepting address 4, error -71
[ 398.556844,0] usb 1-1: new full-speed USB device number 5 using msm_hsusb_host
[ 399.036691,0] usb 1-1: device not accepting address 5, error -71
[ 399.036908,0] hub 1-0:1.0: unable to enumerate USB device on port 1
[ 401.038723,0] msm_otg f9a55000.usb: USB in low power mode
[ 421.141393,0] wlan: [1595:E :HDD] wlan_hdd_tdls_check_bmps: 1755: pHddCtx or pHddTdlsCtx points to NULL
[ 481.407016,1] wlan: [1595:E :HDD] wlan_hdd_tdls_check_bmps: 1755: pHddCtx or pHddTdlsCtx points to NULL
[ 489.646823,0] wlan: [1595:E :HDP] hdd_tx_rx_pkt_cnt_stat_timer_handler: Disable split scan
[ 541.088392,0] wlan: [1595:E :HDD] wlan_hdd_tdls_check_bmps: 1755: pHddCtx or pHddTdlsCtx points to NULL
[ 602.071540,1] wlan: [1595:E :HDD] wlan_hdd_tdls_check_bmps: 1755: pHddCtx or pHddTdlsCtx points to NULL
[ 662.130080,0] wlan: [1595:E :HDD] wlan_hdd_tdls_check_bmps: 1755: pHddCtx or pHddTdlsCtx points to NULL
[ 676.210880,0] msm_otg f9a55000.usb: USB exited from low power mode
[ 676.216806,0] msm_hsusb_host msm_hsusb_host: remove, state 84
[ 676.356920,0] usb usb1: USB disconnect, device number 1
[ 676.359954,0] msm_hsusb_host msm_hsusb_host: USB bus 1 deregistered
[ 676.867350,0] msm_otg f9a55000.usb: USB in low power mode
[ 678.581483,0] msm_otg f9a55000.usb: USB exited from low power mode
[ 678.796950,0] msm_hsusb_host msm_hsusb_host: Qualcomm On-Chip EHCI Host Controller
[ 678.797570,0] msm_hsusb_host msm_hsusb_host: new USB bus registered, assigned bus number 1
[ 678.826732,0] msm_hsusb_host msm_hsusb_host: irq 166, io mem 0xf9a55000
[ 678.846582,0] msm_hsusb_host msm_hsusb_host: USB 2.0 started, EHCI 1.00
[ 678.846906,0] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 678.847148,0] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 678.847374,0] usb usb1: Product: Qualcomm On-Chip EHCI Host Controller
[ 678.847502,0] usb usb1: Manufacturer: Linux 3.4.42-AeroKernel-g63fb0d2 ehci_hcd
[ 678.847728,0] usb usb1: SerialNumber: msm_hsusb_host
[ 678.848817,0] hub 1-0:1.0: USB hub found
[ 678.849065,0] hub 1-0:1.0: 1 port detected
[ 679.166721,0] usb 1-1: new full-speed USB device number 2 using msm_hsusb_host
[ 679.376783,0] usb 1-1: device descriptor read/64, error -71
[ 679.696879,0] usb 1-1: device descriptor read/64, error -71
[ 679.926679,0] usb 1-1: new full-speed USB device number 3 using msm_hsusb_host
[ 680.136851,0] usb 1-1: device descriptor read/64, error -71
[ 680.456683,0] usb 1-1: device descriptor read/64, error -71
[ 680.686725,1] usb 1-1: new full-speed USB device number 4 using msm_hsusb_host
[ 681.166605,0] usb 1-1: device not accepting address 4, error -71
[ 681.286774,0] usb 1-1: new full-speed USB device number 5 using msm_hsusb_host
[ 681.766590,1] usb 1-1: device not accepting address 5, error -71
[ 681.766860,1] hub 1-0:1.0: unable to enumerate USB device on port 1
[ 683.989181,1] msm_otg f9a55000.usb: USB in low power mode
[ 722.101336,1] wlan: [1595:E :HDD] wlan_hdd_tdls_check_bmps: 1755: pHddCtx or pHddTdlsCtx points to NULL
[ 783.182826,0] wlan: [1595:E :HDD] wlan_hdd_tdls_check_bmps: 1755: pHddCtx or pHddTdlsCtx points to NULL
[ 843.167467,1] wlan: [1595:E :HDD] wlan_hdd_tdls_check_bmps: 1755: pHddCtx or pHddTdlsCtx points to NULL
[ 869.535005,1] wlan: [1750:E :SME] sme_FTUpdateKey: Unhandled state=0
[ 885.327543,2] IRQ40 no longer affine to CPU2
[ 888.582235,2] IRQ40 no longer affine to CPU2
[ 890.598683,3] IRQ40 no longer affine to CPU3
[ 903.098191,0] wlan: [1595:E :HDD] wlan_hdd_tdls_check_bmps: 1755: pHddCtx or pHddTdlsCtx points to NULL
[ 960.586653,1] wlan: [1595:E :HDP] hdd_tx_rx_pkt_cnt_stat_timer_handler: Disable split scan
Sent from my Moto G using XDA Free mobile app

My solution to BLU Life One 2015 X011Q_V04 screen off, music stops microSD unmounts

My phone is the BLU Life One, Android 4.4.4. Kernel 3.10.28. Build KTU84P. Custom build version BLU_XO11Q_V04_GENERIC 14-08-2015 12:15. Model Number BLU LIFE ONE. Processor info. Qualcomm Technologies, Inc MSM8916
EDIT:
Forget & ignore all mentions of my script(s) to keep the microsd from umounting. Whatever is causing this problem is stopped if the microsd is remounted as read-only.
If you adb shell into your phone then type "mount" you should see all mounts related to your microsd card. For my phone, that is sdcard1.
Code:
/dev/fuse /storage/sdcard1 fuse ro,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/block/vold/179:65 /mnt/media_rw/sdcard1 vfat ro,dirsync,relatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
You'll need root, then do:
Code:
mount -o ro,remount /mnt/media_rw/sdcard1
mount -o ro,remount /storage/sdcard1
That's it. Since 99% of the time I'm just listening to music not actively needing write-access to the microsd, this works perfect for me. I use this app: play.google.com/store/apps/details?id=os.tools.scriptmanager&hl=en to manage 2 scripts. One to mount it as read-only like the commands above, and another to mount it read-write again(just change "ro" to "rw"). If you want, you can jump to update#23 for the kernel source of this phone http://forum.xda-developers.com/showpost.php?p=64906734&postcount=8 and continue reading to follow my adventures of trying to update the kernel.
Code:
echo -------------------------
id
echo -------------------------
cd /storage/sdcard1
while true; do
ls -la . > ./ls_la.log 2>&1
sleep 1
ls -la . >> ./ls_la.log 2>&1
sleep 1
rm ./ls_la.log
sleep 10
done
First, note that the "/storage/sdcard1" is where my phone mounts the microSD to. Your phone might be different, be sure to change it to wherever your phone mounts the microSD to. That last adb shell command to run the script will hang because it's an infinite loop. You'll just have to yank out the usb-cord of your phone to break the connection. On my phone, the script continues to run. I know this because using a file-manager on the phone I can constantly refresh the file list on my microSD and see the logfile appear and disappear in 10-second intervals.
So with all this I start the music in my musicplaying app(poweramp in my case), press the power button to turn off my screen.... press the power button again to turn on the screen and see the lockscreen.... then leave my phone alone. Within 10 seconds, the screen goes off by itself if I don't enter a pin... and the music will play without any glitches or interruptions.
CONS
If my phone ever reboots, I need to go back to a PC with "adb" so I can rerun the command. This app: play.google.com/store/apps/details?id=os.tools.scriptmanager&hl=en ....can run the script but the user the script is started with doesn't have write-permissions to the microSD card for whatever reason. I have this problem because my phone is NOT rooted. I rooted it once before, but then used SuperSu's option to "unroot" and since then haven't been able to root again. If you have root, I'm sure a command like "su -c '/data/local/tmp/crazy_sdcard_wakelock.sh'" would start the script as root and it'll be able to write to the microSD. ......I rarely reboot my phone, so this isn't a big issue for me.
How did I come up with this?
Random googling about this problem lead me to a bunch of people talking about it on different devices with different symptoms: code.google.com/p/android/issues/detail?id=22763 , but more or less the same core issue. When the screen is off for awhile(for me it's 30mins), the microSD is unmounted apparently by faulty power-management in Android's OS or Manufacturer's hardware or whatever and if you're like me with tons of music on the microSD... your musicplayer(PowerAmp or whatever), stops working. So I started thinking about all the ways to prevent the microSD card from unmounting. On my home PC, running Linux mint, a mounted USB device cannot be unmounted if there's a bash process that is using it; i.e. if I open a terminal and "cd" to a directory on the usb-drive, I cannot unmount it until I exit that bash shell. That's why in the above script I do the cd command to the microSD card hoping for the same effect on Android. Then you see the infinite loop of "while true", where I repeatedly do:
I run "ls -la" to print out all details of files & folders at the root-level of the microSD card and save the output to a logfile.
I pause for 1 second.
I run "ls -la" command again, and append the already existing file so now the list is in that file twice.
I pause again for 1 second.
I delete the file
Pause for 10 seconds... then do it all again, and again, and again...
With a shell process having the microSD as its CWD and the constant opening, writing, deleting of a file every 10 seconds, along with the PowerManagerWakelock app and the periodically CPU usage reporting.... I've been doing this for a full day and the music never stops, no sdcard unmounting. This is the microSD I'm using: amazon.com/SanDisk-Mobile-MicroSDXC-Memory-Adapter/dp/B0081EAK34
I haven't done any testing to try and narrow stuff down to see if I truly need all 3 of these things to be running, but I don't care. It works for me and my battery life doesn't seem to be draining any faster than normal.
I'm posting this solution so maybe the hackers on this forum can understand exactly why my solution is working and maybe write an apk that'll do all this stuff by just tapping a button.
UPDATE:
Got root back by booting into TWRP(Installed before I removed root the first time) and flashing a SuperSU.zip to the device. Disabled the "Show CPU usage" and the solution still works. Using the PowerManagerWakeLock app by itself does _NOT_ work. So right now it's WakeLock+Script that seems to be working. Who knows, maybe the script will work all by itself. But I haven't tried it yet. Now if I reboot my phone, I can use the script-manager app mentioned above to run the script as root and it does keep the microSD mounted and everything works. I also added the "date" command to my script so in case it stops working, the scriptManager's console will show me the last time it worked before problems occurred. But, so far so good no problems and my buyer's regret on this phone is long gone. I hope other people see this post because I see a lot of people complaining about similar problems with other Android phones.
If this works for you, please reply and say so!
UPDATE#2
Just spent the whole day listening to uninterrupted music using only the script. So there you go! I was trying to find a way to do this without root using the ScriptManager app, I tried copying the /system/bin/sh file to /data/local/tmp and setting the sticky bit on it; but sticky bit logic doesn't seem to work for me on Android. So if you don't have root, you have to launch the script via "adb shell" command on a PC and don't reboot or do anything that stops the script.
UPDATE#3
So it appears that both Poweramp playing music and the script are required. If I stop playing music the script starts getting I/O Errors and "Transport endpoint is not connected" errors after like 4 hours or so. Kinda lame. And when this happens I have to reboot the phone to get the sdcard back. I suppose this means, be careful if you set the phone's camera to write to the microSD. You might find out later that photos and videos you thought you were capturing didn't actually get saved to the microSD. Should probably have camera save to internal memory then later on copy to microSD using the filemanager and verify that the copy actually worked before deleting from internal memory.
UPDATE#4
In an attempt to keep the sdcard mounted even if there's no music playing, I decided to add the "du" command thinking that command needs to do a lot to the sdcard to get its info. The result? After 3 to 4 hours, the card still went offline and all of its content erased! Luckily, I made a backup because I knew I was dealing with sdcard problems on this phone. So, what I think needs to happen now is to write a script that can somehow detect if the phone is idle for about 2 hours. Idle in this context means, screen off for 2 hours and no music playing... to automatically unmount the sdcard safely instead of whatever happened that causes me to lose everything. Or maybe after detecting idle-state, unmount & remount the sdcard to wake up whatever hardware/software components went to sleep. If that works, then perhaps just keep remounting the sdcard every 2 hours the phone is in an idle state. But so far, my original solution works in that as long as you're listening to music & running the script above there will be no interruptions for at least 8 hours straight.
UPDATE#5
Well, I can now reproduce 100% the sdcard umounting. If I set my phone's display to go off in 2mins of idle time, and immediately lock with pin. Then start Poweramp and listen to tunes, once the screen goes out the music will stop in less than 20 seconds and the sdcard is gone. If I run that script above, then the music continues and the sdcard is still there... so definitely that script is doing something. I see nothing suspicious running logcat while all this is happening other than the normal calls to PowerManager:
D/DisplayPowerController( 839): requestPowerState: screenState=0, useProximitySensor=false, screenBrightness=102, screenAutoBrightnessAdjustment=0.0, useAutoBrightness=true, blockScreenOn=false, waitForNegativeProximity=false
D/PowerManagerService( 839): updateScreenStateLocked: mDisplayReady=true, newScreenState=0, mWakefulness=0, mWakeLockSummary=0x1, mUserActivitySummary=0x0, mBootCompleted=true
D/PowerManagerService( 839): updateIsPoweredLocked: wasPowered=true, mIsPowered=true, oldPlugType=2, mPlugType=2, mBatteryLevel=100
Click to expand...
Click to collapse
I'm learning a lot of stuff about Android and sdcards in this phone. Informative commands, like:
dumpsys mount & dumpsys power, Also interesting processes:
[email protected]_LIFE_ONE:/ # ps |grep sdcard
media_rw 255 1 4144 1160 ffffffff b6f404ac S /system/bin/sdcard
media_rw 258 1 3528 432 ffffffff b6f7b4ac S /system/bin/sdcard
media_rw 260 1 3528 432 ffffffff b6f6d4ac S /system/bin/sdcard
media_rw 8948 1 4208 1204 ffffffff b6f5e4ac S /system/bin/sdcard
[email protected]_LIFE_ONE:/ # print `cat -v /proc/255/cmdline`
/system/bin/sdcard^@-u^@1023^@-g^@1023^@-l^@/data/media^@/mnt/shell/emulated^@
[email protected]_LIFE_ONE:/ # print `cat -v /proc/258/cmdline`
/system/bin/sdcard^@-u^@1023^@-g^@1023^@-w^@1023^@-d^@/mnt/media_rw/uicc0^@/storage/uicc0^@
[email protected]_LIFE_ONE:/ # print `cat -v /proc/260/cmdline`
/system/bin/sdcard^@-u^@1023^@-g^@1023^@-w^@1023^@-d^@/mnt/media_rw/usbotg^@/storage/usbotg^@
[email protected]_LIFE_ONE:/ # print `cat -v /proc/8948/cmdline`
/system/bin/sdcard^@-u^@1023^@-g^@1023^@-w^@1023^@-d^@/mnt/media_rw/sdcard1^@/storage/sdcard1^@
[email protected]_LIFE_ONE:/ #
Click to expand...
Click to collapse
Still looking around to see if I can figure out why it unmounts, or prevent it from unmount, or immediately remount it as soon as it disappears. I've noticed that when the glitchy-unmount happens, the status in "dumpsys mount" does not update. It still shows /storage/sdcard1 as mounted.
UPDATE#6
Okay, getting closer to narrowing it down. Definitely the music stops and sdcard problems when I tamper with the process related to the sdcard. From the example above, PID 8948, /system/bin/sdcard -u 1023 -g 1023 -w 1023 -d /mnt/media_rw/sdcard1 /storage/sdcard1. If I send that process a kill -9, the process immediately respawns with a new PID but within the next 20secs the music will skip. If I send a kill -STOP to that process, the music will halt completely and the sdcard access will be messed up within 20 seconds. I can return normal sdcard access by sending kill -CONT to the process. I've haven't verified it yet, but I bet something happens to that process when the sdcard unmounts suddenly and everyone is complaining about the problem. My 100% repro to make the sdcard unmount has stopped working so I can't quickly verify any changes in any attributes to files in /proc/$PID/. I've also just found this nice website with informative stuff: hxxp:\\source.android.com/devices/storage/config-example.html
UPDATE#7
So after a lot of research, I extracted the boot.img(/dev/block/bootdevice/by-name/boot) from this device, unpacked it, edited init.qcom.rc to start the sdcard service for the microSD using a different binary I named sdcard_studio6. I pull this file from my wife's BLU Studio6 phone. From just about any other android device I had around, the sdcard binary would complain about a missing symbol or something. I couldn't just replace the original sdcard binary, because doing that would mount the external microSD but won't mount the internal phone memory and logcat would be overflowing with fuse errors from sdcard. So I have to leave the original sdcard binary to work with all the other mounts, but only modify the service/deamon for the external storage. After rebooting the phone and running "ps|grep sdcard", sure enough I see the sdcard_studio6 binary handling the microSD. Interestingly enough, the custom_boot.img created by my editing was only 7 megs. Compared to the 32 meg one I got from doing dd if=/dev/block/bootdevice/by-name/boot of=/sdcard/boot.backup.img That was worrying, but apparently it works fine.
NOTE: I feel it's important to point out that the command "fastboot" can be used in 2 ways for booting. "fastboot flash boot /path/on/your/PC/to/boot.img" or "flashboot boot /path/on/your/PC/to/boot.img". The first command actually writes the change into your phone's memory, the 2nd command just uses the file to boot up the phone temporarily and holding down the power button for a few seconds to force powerdown & reboot will cause the phone to go back and use the image that's in the phone's internal memory. One of the times I did this i forgot to give mkbootimg a bunch of important options like --cmdline, --base, --pagesize, --ramdisk_offset, etc. When I booted the phone with the image I created, the phone was stuck on the white BLU logo screen and neither fastboot nor adb could detect the phone. Had I flashed that image into the phone, instead of temporarily loading it, the phone would have continued to use the bad boot.img and without fastboot or adb, I think I would have had a nice $189.99 brick. Moral, don't flash a boot.img permanently until you've booted up in temporary mode and used the phone a bunch and you're sure everything works. At the minimum, be sure adb or fastboot can still see it so you have some hope if things screw up later.
Unfortunately, this didn't solve the unmounting problem. I've started checking dmesg and noticed that when the sdcard disappears, it's shortly after these messages:
<3>[ 1864.773535] mmc1: data txfr (0x00200000) error: -84 after 0 ms
<6>[ 1864.773559] sdhci: =========== REGISTER DUMP (mmc1)===========
<6>[ 1864.773568] sdhci: Sys addr: 0x00000100 | Version: 0x00002e02
<6>[ 1864.773577] sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000100
<6>[ 1864.773586] sdhci: Argument: 0x053deb54 | Trn mode: 0x0000003b
<6>[ 1864.773594] sdhci: Present: 0x03280206 | Host ctl: 0x00000017
<6>[ 1864.773603] sdhci: Power: 0x0000000d | Blk gap: 0x00000000
<6>[ 1864.773611] sdhci: Wake-up: 0x00000000 | Clock: 0x00000007
<6>[ 1864.773619] sdhci: Timeout: 0x0000000a | Int stat: 0x00000000
<6>[ 1864.773628] sdhci: Int enab: 0x03ff800b | Sig enab: 0x03ff800b
<6>[ 1864.773636] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
<6>[ 1864.773645] sdhci: Caps: 0x322dc8b2 | Caps_1: 0x00008007
<6>[ 1864.773653] sdhci: Cmd: 0x0000123a | Max curr: 0x00000000
<6>[ 1864.773662] sdhci: Resp 1: 0x4c363447 | Resp 0: 0x00000900
<6>[ 1864.773670] sdhci: Resp 3: 0x00000900 | Resp 2: 0x30dac0c1
<6>[ 1864.773677] sdhci: Host ctl2: 0x0000000b
<6>[ 1864.773686] sdhci: ADMA Err: 0x00000003 | ADMA Ptr: 0xadac0018
<6>[ 1864.773693] ----------- VENDOR REGISTER DUMP -----------
<6>[ 1864.773704] Data cnt: 0x0001fe00 | Fifo cnt: 0x0001f600 | Int sts: 0x000c0000
<6>[ 1864.773714] DLL cfg: 0x07e76400 | DLL sts: 0x000001e4 | SDCC ver: 0x1000002e
<6>[ 1864.773725] Vndr func: 0x00010a1e | Vndr adma err : addr0: 0x009dca00 addr1: 0x00000000
<6>[ 1864.773749] Test bus[0 to 3]: 0x0000c846 0x000020ce 0x00007018 0x01c002f2
<6>[ 1864.773760] Test bus[4 to 7]: 0x00473fd8 0x0005c038 0x40000000 0xf923ffcb
<6>[ 1864.773771] Test bus[8 to 11]: 0x47fc1604 0x40a00002 0x2e03e089 0x00000cc0
<6>[ 1864.773782] Test bus[12 to 15]: 0xe04f0408 0x842501a0 0x0d000040 0x00000a88
<6>[ 1864.773794] Test bus[16 to 19]: 0x00020002 0x0102808c 0x138f369e 0x00002895
<6>[ 1864.773804] mmc1: clk: 200000000 clk-gated: 0 claimer: mmcqd/1 pwr: 12
<6>[ 1864.773814] mmc1: rpmstatus[pltfm](runtime-suspend:usage_count:disable_depth)(0:0:0)
<6>[ 1864.773820] sdhci: ===========================================
<3>[ 1864.781982] mmcblk1: error -84 transferring data, sector 87944020, nr 256, cmd response 0x900, card status 0xb00
<3>[ 1865.997717] mmc1: mmc_blk_reset: failed to reset -110
<3>[ 1865.997747] end_request: I/O error, dev mmcblk1, sector 87944020
<3>[ 1865.997776] end_request: I/O error, dev mmcblk1, sector 87944028
<3>[ 1865.997801] end_request: I/O error, dev mmcblk1, sector 87944036
<3>[ 1865.997824] end_request: I/O error, dev mmcblk1, sector 87944044
<3>[ 1865.997848] end_request: I/O error, dev mmcblk1, sector 87944052
<3>[ 1865.997871] end_request: I/O error, dev mmcblk1, sector 87944060
<3>[ 1865.997894] end_request: I/O error, dev mmcblk1, sector 87944068
<3>[ 1865.997917] end_request: I/O error, dev mmcblk1, sector 87944076
<3>[ 1865.997941] end_request: I/O error, dev mmcblk1, sector 87944084
<3>[ 1865.997963] end_request: I/O error, dev mmcblk1, sector 87944092
<3>[ 1865.998491] mmc1: sdhci_cmd_irq: AUTO CMD err sts 0x00000002
<3>[ 1866.002930] mmcblk1: error -110 sending status command, retrying
<3>[ 1866.005329] mmcblk1: error -110 sending status command, retrying
<3>[ 1866.007776] mmcblk1: error -110 sending status command, aborting
<3>[ 1866.018346] mmc_sd_detect(mmc1): Unable to re-detect card (-123)
<6>[ 1866.018411] mmc1: card 0007 removed
<3>[ 1866.205666] FAT-fs (mmcblk1p1): Directory bread(block 1133940) failed
<3>[ 1866.205720] FAT-fs (mmcblk1p1): Directory bread(block 1133941) failed
<3>[ 1866.205770] FAT-fs (mmcblk1p1): Directory bread(block 1133942) failed
<3>[ 1866.205811] FAT-fs (mmcblk1p1): Directory bread(block 1133943) failed
<3>[ 1866.205849] FAT-fs (mmcblk1p1): Directory bread(block 1133944) failed
<3>[ 1866.205888] FAT-fs (mmcblk1p1): Directory bread(block 1133945) failed
<3>[ 1866.205932] FAT-fs (mmcblk1p1): Directory bread(block 1133946) failed
<3>[ 1866.205971] FAT-fs (mmcblk1p1): Directory bread(block 1133947) failed
Click to expand...
Click to collapse
I should also note this entire issue with the sdcard doesn't happen with my old 32GB card, only with the 2 brand new sandisk 64gig cards that I bought to test this out. It's difficult for me to believe that both of these 64gig sdcards are defective. And both didn't come from the same place. One from amazon.com the other from walking into a Target store in San Francisco and buying it. And both these cards work fine in other devices. Still working on some kind of solution.
UPDATE#8
I noticed that sdcard binary on my phone actually prints out usage:
Code:
[email protected]_LIFE_ONE:/ $ /system/bin/sdcard
no source path specified
usage: sdcard [OPTIONS] <source_path> <dest_path>
-u: specify UID to run as
-g: specify GID to run as
-w: specify GID required to write (default sdcard_rw, requires -d or -l)
-t: specify number of threads to use (default 2)
-d: derive file permissions based on path
-l: derive file permissions based on legacy internal layout
-s: split derived permissions for pics, av
So I tried editing my init.qcom.rc to start with more threads; like 14.... still the problem remains that a screen off will cause the music to stop eventually.
UPDATE#9
Sending kill -STOP to the vold process seems to be working!
After messing with the sdcard binary for awhile I saw this link: hxxp://android.stackexchange.com/questions/75277/vold-makes-my-sd-card-disappear , and started researching /system/bin/vold. I do actually remember seeing vold & MountService unmount the card in logcat at least once. I thought about disabling vold in the init scripts, but it appears it's super important and disabling it will just make everything fail. I tried killing the process but it will restart and I suspect it'll eventually be needed again. I did notice that if I have music playing and I adb shell, su, "/system/bin/vold root", my music player will stop and I have to hit the play button again. I have a theory now that there are actually 3 issues here happening all at the same time confusing people and 2 of them are sorta red herrings.
Theory 1) If you buy a no-name-brand sdcard you might have problems. Don't do that, try to get a good card like those class 4 or even class 10. Having a low quality microSD can send you down the path of madness. It's just a red herring; get a good card before reaching any conclusions that you phone has any problems.
Theory 2) I now suspect some microsd card reading errors are normal. e.g. <3>[ 1864.781982] mmcblk1: error -84 transferring data, sector 87944020, nr 256, cmd response 0x900, card status 0xb00
, is probably something that'll happen from time to time and the underlying filesystem drivers and/or AndroidOS normally recovers from them as long as it doesn't happen way too often. This is the 2nd red herring I think people should just ignore unless there's a whole bunch close together all the time. In which case I think the microSD card is bad or your phone is bad. I think the phone being bad is very unlikely unless you bought a cheap counterfeit junk phone like..... "HTM Demon". Yes, "M", not "C". I have one from Aliexpress. It's junk.
Theory 3) For some reason unrelated to anything else, vold randomly decides the microsd is idle and tells the MountService to unmount it. When that happens, then you get:
<3>[ 1866.018346] mmc_sd_detect(mmc1): Unable to re-detect card (-123)
<6>[ 1866.018411] mmc1: card 0007 removed
<3>[ 1866.205666] FAT-fs (mmcblk1p1): Directory bread(block 1133940) failed
Click to expand...
Click to collapse
....and these are serious errors, but these errors didn't cause the unmounting. It's the vold unmounting that happened first which then creates these errors.
So, now I have 2 scripts: stop_vold.sh & resume_vold.sh
Code:
#
#This script stops the vold process. Not kill it, just suspend it so it cannot do anything.
#
ps vold
VOLD_PID=$( ps vold | grep -v PID | busybox awk '{print $2}' )
echo "[*] Sending KILLSTOP signal to PID $VOLD_PID"
kill -STOP $VOLD_PID
if [ $? -eq 0 ]
then
echo "[*] Success"
else
echo "[*] Problem sending KILLSTOP"
exit 1
fi
Then resume_vold.sh
Code:
#
#This script resumes the vold process.
#
ps vold
VOLD_PID=$( ps vold | grep -v PID | busybox awk '{print $2}' )
echo "[*] Sending KILLCONT signal to PID $VOLD_PID"
kill -CONT $VOLD_PID
if [ $? -eq 0 ]
then
echo "[*] Success"
else
echo "[*] Problem sending KILLCONT"
exit 1
fi
You need to be root to have permissions to suspend the vold process.
Also, you need busybox to be installed for that "awk" command. Most of those rooting kits out there have the busybox binary. Just make sure it's in /system/bin or /system/xbin, owned by root with permissions rwxr-xr-x.
Side Effects of a stopped vold process:
Here's what I've noticed so far. To avoid these issues, make sure to resume vold before doing any of the following:
- Since the vold process, apparently responsible for important storage/volume changes, is stopped...... if you do anything that makes Android call to vold to update storage info... it'll hang and go into a soft-reboot cycle. Soft, because while it keeps rebooting itself trying to get unstuck you can be in an adb-shell and it won't disconnect. The restart-loop can be fixed by either sending a kill -CONT to the vold process or holding down the power button on your phone for 10 seconds to force it to power-down for real. Then on bootup everything will be back to normal. So, connecting the phone to a PC or attempting to mount or unmount the sdcard in Settings->Storage->Un/MountSdCard is probably going to lead to trouble if vold is stopped when you attempt them.
- App installs/updates will cause the phone to freeze for about 45 seconds.
That's it, I think I like this solution the most. No more file writing every 10 seconds and no problems leaving the device to play 6 hours of music uninterrupted then sit idle for another 4 hours. I'll update this post again if I find a problem, but if not then I'm happy with this solution. -^_^-
UPDATE#10
After about 2 days, this stopped working. Instead of the microSD card unmounting, all the content just becomes invisible and phone says the card is 0kb used and 0kb available. After resuming the vold process, Unmounting and remounting in the Settings->Storage will report damaged card. Rebooting the phone makes the card work again and show all its content. Coincidentally, this is also when I added a bunch more music beyond the 32gig used marked. I'm starting to think the reason phone manufactures say the phone can support up to 32GB when bigger cards are detectable by Android, is because they know anything more than 32gb is like overclocking a CPU. You might be able to get a bit more performance but you also might just run into more errors. None of these microSD card problems happen with my 32gb card. Maybe if I got a class 10 64gb card this would work better. The fact that my ls-la script is still a working solution gives me hope that there's a more elegant solution to be found.
dmesg:
<3>[ 6732.453920] mmcblk1: error -84 transferring data, sector 27308860, nr 256, cmd response 0x900, card status 0xb00
<6>[ 6733.198026] mmc0: Deferred resume completed
<3>[ 6733.664116] mmc1: mmc_blk_reset: failed to reset -110
<3>[ 6733.664147] end_request: I/O error, dev mmcblk1, sector 27308860
<3>[ 6733.664177] end_request: I/O error, dev mmcblk1, sector 27308868
<3>[ 6733.664202] end_request: I/O error, dev mmcblk1, sector 27308876
<3>[ 6733.664228] end_request: I/O error, dev mmcblk1, sector 27308884
<3>[ 6733.664252] end_request: I/O error, dev mmcblk1, sector 27308892
<3>[ 6733.664276] end_request: I/O error, dev mmcblk1, sector 27308900
<3>[ 6733.664300] end_request: I/O error, dev mmcblk1, sector 27308908
<3>[ 6733.664324] end_request: I/O error, dev mmcblk1, sector 27308916
<3>[ 6733.664348] end_request: I/O error, dev mmcblk1, sector 27308924
<3>[ 6733.664371] end_request: I/O error, dev mmcblk1, sector 27308932
<3>[ 6733.664997] mmc1: sdhci_cmd_irq: AUTO CMD err sts 0x00000002
<3>[ 6733.669428] mmcblk1: error -110 sending status command, retrying
<3>[ 6733.672022] mmcblk1: error -110 sending status command, retrying
<3>[ 6733.674442] mmcblk1: error -110 sending status command, aborting
<3>[ 6733.684124] mmc_sd_detect(mmc1): Unable to re-detect card (-123)
<6>[ 6733.684186] mmc1: card 0007 removed
<6>[ 6734.164388] mmc1: new ultra high speed SDR104 SDXC card at address 0007
<6>[ 6734.164978] mmcblk1: mmc1:0007 SL64G 58.2 GiB
<6>[ 6734.166085] mmcblk1: p1
Click to expand...
Click to collapse
Notice how the card disappears and apparently is re-detected after about 1 second, but it's empty and with 0kb capacity.... and during all this vold is still suspended so maybe that's why everything about the card is zero.
logcat:
I/AudioFlinger( 221): BUFFER TIMEOUT: remove(4096) from active list on thread 0xb3f5e008
D/PowerManagerService( 912): updateWakeLockWorkSourceInternal: lock=1113296440 [AudioMix], ws=null
E/ffmpegdecoder.c( 1190): Can't open file /storage/sdcard1/myuzik/ToniChilds/Toni Childs - House Of Hope.mp3 err=-1 Operation not permitted
E/DecoderBase( 1190): native_open returned error=0
E/Pipeline( 1190): Failed to open decoder
E/Pipeline( 1190): com.maxmpz.audioplayer.decoder.DecoderBase$ll1: Can't open file /storage/sdcard1/myuzik/ToniChilds/Toni Childs - House Of Hope.mp3
E/Pipeline( 1190): at com.maxmpz.audioplayer.decoder.DecoderBase.ll1l(":30)
Click to expand...
Click to collapse
I wish I could find whatever that "mmc" process is. Still looking for answers...
UPDATE#11 is below in another comment. http://forum.xda-developers.com/showpost.php?p=64522019&postcount=4
That is all.

You mentioned having root access on this phone. How'd you get root? I've been searching forever for this exact model of the Life One and this is the only thread that makes mention of it.

areyouahobo said:
You mentioned having root access on this phone. How'd you get root? I've been searching forever for this exact model of the Life One and this is the only thread that makes mention of it.
Click to expand...
Click to collapse
towelroot, I think. I tried all kinds of rooting exploits for all kinds of phones... but it was towelroot that first caused SuperSU to prompt me Grant or Deny, then suddenly I had root.
I have a suspicion that it was a mix of towelroot, a file called "mt6589_rooting_pkg.zip" and do a google search for android rooting using this exploit CVE-2014-3153 . I wish I knew exactly which one, but I was just trying everything really fast. I didn't even notice SuperSU.apk getting installed. Just suddenly it popped up and I had root after trying all those exploits.
I can tell you though, that I did _not_ use Kingroot.

UPDATE#11
Research has taught me that the mmc thing is a kernel module (specifically linux/source/drivers/mmc/card/block.c) and if I want to update it, I need to modify the kernel image. Looking around, it appears that nobody really does that... what they do instead is simply compile from source using the config from the phone. So, I got boot.img then using mkboot command split the boot.img file into ramdisk and kernel. Using binwalk, found where the gzip part of the kernel was and gunzipped it, giving me an uncompressed kernel. Searching this uncompressed kernel image again with binwalk, located another gzip within. gunzipped that and I got the Kernel config. Comment at the top said "Linux/arm 3.10.28 Kernel Configuration", so I went to kernel.org and downloaded the source of kernel 3.10.28. In the downloaded linux source's directory, I copied the kernel-config I got from the kernel image and placed it in this dir as ".config" so the kernel would compile with the right options. I left everything else as default when asked. Wouldn't build because of some line containing __devinit but various googling for the error and I discovered some kernel devs actually submitted a patch to remove it, so I removed it from my source. Then it failed to compile because of some missing firmware blobs. PR1593801-s3203_n_dsx8232_JTOUCH.img and PR1593801-s3203_n_dsx8232_TTOUCH.img.
What I did then, was create a 250 byte file containing only the number "8" over and over again, then another file containing the number "9" over and over. Named them the above JTOUCH and TTOUCH images respectively and compiled the kernel. I then used a hexeditor to examine where in the uncompressed kernel image those 8s and 9s ended up. First, I noticed that the 2 files were concatenated together with no compression or encryption or padding or delimiting bytes in between. Then I noticed all the function names & bytes that appeared just before the 8s and just after all the 9s. I compared it to the kernel image from my phone and was able to deduce the general area of the 2 firmwares. I then notice a block of function names that didn't match anything else in the file, a block of functions starting with "msm8x16_wcd_*" then suddenly a block of functions starting with "wcd_mbhc_*". I concluded to extract this area of the kernel image and split on those function names to create the firmware images. The cool thing here is, even if I'm wrong on the split since they're concatenated together with no delimit mark... it didn't really matter where I chose to split them as long as I just don't misjudge the start of the first firmware and end of the 2nd. Or I could be wrong about this and somewhere else in the kernel the offset and length of the firmware is stored and referenced during bootup.
So then I "make clean" and rebuilt the kernel.
Code:
ARCH=arm SUBARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make
For this you gotta be sure you have arm-linux-gnueabi-gcc on your machine.
Then using mkbootimg --kernel /path/to/newly/built/zImage --ramdisk /path/to/old/ramdisk/extracted/from/boot.img/ramdisk.gz --dt /path/to/old/extracted/dt.img, created a boot.img containing the newly compiled kernel and the old ramdisk & dt.img
.....and..... it would have been amazing if this had worked, but of course it failed to boot, because I have no idea how to generate another dt.img that this phone needs and apparently using the old one from the boot.img I got doesn't work. I don't even get a chance to "adb shell logcat" or "adb shell dmesg" to see what went wrong. The phone goes into a fast reboot cycle. The while BLU logo screen appears for about a second then the screen goes blank and phone reboots, over and over. Maybe BLU has custom kernel modifications for the phone, who knows. I would have like it to boot up even if wifi, camera and all kinds of stuff was broken.
UPDATE#12
The size of the firmware is indeed stored in the kernel. I did a bunch of tests changing the size of the 2 fake imgs and I kept finding the little-endian representation of the sizes next to each other, always matching and just about in the same spot. i.imgur.com/smahbf4.png, so now I'm trying to find this same area in the real kernel. I've also noticed that I was sorta wrong about the no delimiters between the firmwares. Sometimes there is, sometimes there isn't. Through many tests increasing/decreasing the length of the function names that appear before my fake firmware as well as changing the size of the firmware itself, the kernel appears to be maintaining some kind of 4-byte-alignment. There is always 2 nulls after the function name and then the first firmware starts, and the beginning of the firmware must always be at an offset divisible by 4. The compile process add/removes padding zeroes just before the function name to maintain these rules. Even when the 2nd firmware starts, if it's not a place divisible by 4 then zeroes get padded between the first firmware and the 2nd one to force the 2nd firmware to start at a place divisible by 4.
This was annoying at first, but I now realize that these rules significantly narrow down exactly where the firmware will be in the real kernel image and I can sorta verify my guesses by finding the sizes in the binary that match. I've also noticed that the area containing the image sizes seems to have the value 0xC0 at every 4th byte, as you can see from the image. I suspect this area of the image is some kind of table-of-contents for all the files in the image.
UPDATE#13
So, after a bunch of attempts at booting the kernel and the phone rebooting immediately. I began to suspect that perhaps the kernel is signed in someway and some SHA1/CRC/etc didn't match so the phone bailed out without even trying to boot. To test this theory, I opened up the original zImage-format kernel image extracted from the phone... went to the center of the file and changed 3 bytes(that were not zero) arbitrarily to something else. My thinking here is this should be enough to fail any kind of kernel-signing process but not enough to completely ruin the boot up process. I was happy to see that the phone still proceeded to boot up even with those 3 bytes changed. I didn't use the phone enough to find out exactly what I broke by altering, but this at least made me confident that the entire image isn't somehow signed which would mean there's no hope of me getting anything to boot on it besides the one it came with. Then I went to try some other ways of creating the zImage. First, I used binwalk on the original zImage to tell me when the gzip archive starts for extracting the kernel image. I used dd to create a file that containing all bytes _before_ the gzip header and called that file zImage_header_bytes.bin. I then took the arch/arm/boot/Image file from my own kernel build process, gzipped it, and appended it to the zImage_header_bytes.bin file, then made a boot.img from it. Phone didn't boot. Then, I noticed that my make file has a "Image" and "zImage" target. So what I did then is "make zImage", then deleted the uncompressed Image, then ran "make zImage" again. Noticed that the build process must first create an Image then do whatever it does to make "zImage". So, I did this again but I took the original uncompressed kernel image and copied it arch/arm/boot/Image, then typed "make zImage" again. The result was a zImage file that was bigger than the one the build-process normally made which told me it used the original uncompressed Image file to create the zImage. I then tried making a boot.img out of this and... it still failed to boot. I then went back to my original kernel extraction process:
[email protected] ~/tmp1/initfiles $ binwalk originalboot/kernel
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
16619 0x40EB gzip compressed data, maximum compression, from Unix, NULL date (1970-01-01 00:00:00)
[email protected] ~/tmp1/initfiles $ dd if=originalboot/kernel skip=16619 bs=1 | gunzip > /dev/null
6600989+0 records in
6600989+0 records out
6600989 bytes (6.6 MB) copied, 9.34924 s, 706 kB/s
gzip: stdin: decompression OK, trailing garbage ignored
[email protected] ~/tmp1/initfiles $
Click to expand...
Click to collapse
The trailing garbage message reminded me that I actually threw away some bytes when retrieving the uncompressed image so now I'm working on figuring out the "footer" file, such that I can take my custom uncompressed image, gzip it and put the original header & footer on it. Though, if that were the case then I would have expected my trick of slipping in a different Image into the kernel build process to be made into zImage... would have given it the correct header & footer and should have booted up.... I dunno. Still trying. I'm convinced that, at the very least, I should be able to compile from source the same kernel that's already running on the phone and get the phone to boot up. Maybe it'll crash/freeze and I'll never get a chance to enter my pin, but I should at least be able to get past the initial white BLU logo and into the animated colorful video BLU logo where "adb shell" becomes available and allow me to look at dmesg & logcat for further errors to work on.
UPDATE#14
android.googlesource.com/kernel/msm.git/+/android-msm-dory-3.10-kitkat-wear , so I downloaded this kernel because it seemed much closer to the kernel already on the device. It has files that the kernel.org one does not. e.g., msm8916-sim.dts & msm8916-smp2p.dtsi because in my phone's settings screen the processor info says MSM8916. Also, going into the sound directory and running "find . -name '*.c' -exec grep -E msm8x\|wcd {} \; | grep static" reveals pretty much all the function names that I see the extracted kernel occupying the firmware blob area. I now strongly suspect that those firmware blobs are more or less the result of compiling the files in sound/soc/codecs. So I went ahead and built this kernel. A couple of errors about missing header files, but it's really that they're in a different folder. So I had to copy around 3 or 4 .h files. Then there was a complaint about a multiple declaration of a function, I simply appended a "1" to the function name in .c file defining the function a 2nd time. At the end, there was a complaint: "drivers/net/wireless/wcnss/wcnss_wlan.c:808: undefined reference to `wcnss_rf_read_reg'", I don't know what to do about that so I just commented out and changed the code around there so it wasn't called. I'm sure that brakes wifi, but my goal was to just boot the phone up even if wifi is broken. I can fix that later. So I eventually got my zImage, and I used it and the old dt.img to build a custom boot.img and ....... this time it took the phone much longer before giving up and rebooting! It was like it was just about to load the animated-coloful-logo. It's not the kernel size either, this custom zImage and the resulting boot.img are both smaller than my other custom_boot.img where I only alter the ramdisk contents... and that one does boot up the phone just fine. This makes me think that the phone progressed further in the start-up process before running into a fatal error. The fact that so much msm8196 stuff is in this kernel makes me think it has a much better chance at working. It even has a target like this:
Code:
ARCH=arm SUBARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make msm8916_defconfig
and unlike the kernel.org tar files, this one has arch/arm/boot/dts/qcom/msm8916*
I actually might try copying all the extra files from android.googlesource.com kernel into the plain vanilla one. The coloful animated logo has sound, so maybe trying to load the sound related stuff is why it crashed.
UPDATE#15
More progress! android-msm-angler-3.10-marshmallow-dr , doesn't crash at all. What happens is the while BLU logo screen appears then, very slowly fades to dark from the center out as if someone physically broke the screen. Like a black square slowly fades in at the center of the screen and grows larger until the whole screen is very dark greyish/black. "adb devices" and "fastboot devices" cannot detect the device. I have to hold the power button down for 10 seconds to force a power-down. This is good news because that means my attempts to boot a custom kernel are working. I might not know the exact configuration needed, but it's not a kernel-signing problem and it's not a problem with how I'm compiling and creating my zImage. The kernels are loading and executing, they just don't do the right thing. It wouldn't compile though without a few changes, I had to comment out the "tp_log_debug" and "tp_log_err" calls in hw_tp_common.c and in direct-io.c I had there was a function call that returned a value the code never used, "cmpxchg(&sb->s_dio_done_wq, NULL, wq)", the compiler gave a warning about it and then said something about some warnings will become errors due to compile flags somewhere. I just changed that code to do something harmless:
Code:
if(cmpxchg(&sb->s_dio_done_wq, NULL, wq)) {
wq = wq;
}
That way the return value of cmpxchg is being used in the if-statement and the "wq = wq" doesn't actually change anything. I just used a variable, "wq", that was declared earlier in the function. Oh and disable anything like CONFIG_EXT3 because stuff related to it gave compile errors. As far as I can tell from running the "mount" command in adb-shell, this phone only uses vfat, ext4 and "fuse". So yeah, there's hope! This kernel is 3.10.73 according to its Makefile.... I still really wish I could generate a dt.img from this source code. That dtbTool never works for me. Keeps saying "0 unique dtb" or something. I'm also getting a better idea of why I seem to be having better luck with these, h t t p android.googlesource.com/kernel ...the "msm" section has a description indicating it's for Qualcomm chipset which my BLU phone is definitely telling me in the Settings screen. My guess is BLU took this base kernel and made some changes perhaps. I don't see a 3.10.28-msm on googlesource.com. That would probably be the best thing to try.
UPDATE#16
More progress again! Now trying stuff with "android-msm-seed-3.10-marshmallow". This the only kernel were I only have to make a small one-line code change.
Code:
./kernel/sched/fair.c:static inline int select_best_cpu(struct task_struct *p, int target, int reason, int sync)
The compile failed because a declaration of this function was missing the "sync" parameter. Everywhere else in the file it had the sync value but I had to add it there. And in ./arch/arm/mach-msm/Kconfig the section "config PHYS_OFFSET" kept rewriting the .config PHYS_OFFSET to 0x00200000 even when I changed it to 0x80000000 to match the img_info I got from mkboot extracting the original boot.img. I had to add the line "default "0x80000000" if ARCH_MSM8916" so it would compile with the correct base address.
Also, Found this tool: /github.com/mypalmike/csplitb , that allows me to extract dtb files out of the dt.img that I got from mkboot pulling files out of the original boot.img. So now that I have a file called msm8916-0000.dtb in a dir called "dtbfiles", the command mkbootimg_tools/dtbToolCM -2 -o custom_dt.img -s 2048 -p k/android-msm-seed-3.10-marshmallow/scripts/dtc/ dtbfiles/ will produce a dt.img for the current kernel I'm compiling(3.10.49) and then I created a custom boot.img out of all this to attempt booting up the phone. I should note here it was important to use dtbToolCM, not the regular dtbTool. The regular will make a dt.img but when that's use to make a boot.img then "fastboot boot custom_boot.img", it'll complain "Failed remote: dtb not found". Only the dtbToolCM does it so that complaint doesn't occur. So after all this... I still get the growing fade-to-black square... but now I got a kernel that compiled with very minimal modifications and a dt.img that I believe matches the new kernel I'm trying to run. Now I just gotta think about what else I can look into. The phone doesn't have to work perfectly, just boot up enough that adb-shell works so I can look at logcat/dmesg for other error messages to work on.
Stay tuned!
UPDATE#17
More progress yet again! So I found out that the exact version of gcc used for a particular version of android are kept as static binaries on googlesource.com. Because binwalk on the original boot.img->kernel->extracted_gunzipped_kernel showed me the linux header and gcc 4.7, I decided to download that toolchain's tarball from "android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7/" to compile from now on. So I kept getting that fade-to-black screen. I looked carefully at my .config. Simply copying the .config I extracted from the boot.img into the kernel-source root works, but it asks me a ton of questions and rewrites stuff. I finally noticed one thing that looked important to me and was set by the new kernel "CONFIG_AUTO_ZRELADDR=y". The .config from the boot.img left this unset. When I changed it to "=n", the build failed with arm-eabi-4.7/bin/arm-eabi-ld:--defsym:2: syntax error. I reran the "make zImage" but this time like:
Code:
ARCH=arm SUBARCH=arm CROSS_COMPILE=../../arm-eabi-4.7/bin/arm-eabi- make zImage V=1
That V=1 makes it print out the exact commands it's running to do stuff, so I saw the problem:
Code:
../../arm-eabi-4.7/bin/arm-eabi-ld -EL --defsym _kernel_bss_size=1312864 --defsym zreladdr= -p --no-undefined -X -T arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.gzip.o arch/arm/boot/compressed/misc.o arch/arm/boot/compressed/decompress.o arch/arm/boot/compressed/string.o arch/arm/boot/compressed/hyp-stub.o arch/arm/boot/compressed/lib1funcs.o arch/arm/boot/compressed/ashldi3.o -o arch/arm/boot/compressed/vmlinux
See how zreladdr has no value set to it? A search for zreladdr in all of the kernel source showed me arch/arm/mach-msm/Makefile.boot had a hardcoded list of various ZRELADDRs for different chipsets but MSM8916, for my phone, was missing. I googled "MSM8916 zreladdr" and found various Makefile.boot that did have MSM8916, set as 0x80008000. Great! So I added that value to my Makefile.boot and ran the make-command again, it built the zImage without a problem! ....but still, fade-to-black-graphic-corruption. I also toyed around with changing the ZRELADDR randomly and it definitely had an effect. If I make it 0x00008000 the phone would crash & reboot immediately. If I made it 0xA0000000 the phone would hang. When it's 0x80008000, it would do the fade-to-black. One of these 3 things would happen for random values of ZRELADDR. This really made me think my problems are related to having an incorrect ZRELADDR for this new kernel. From reading about it, I learned ZRELADDR is where the kernel gets copied to after it's decompressed somewhere else in memory. Corruption can happen if the place it's being copied to overlaps with other important memory. So I started thinking that maybe the value 0x80008000 doesn't work for this phone for whatever reason. Again I felt the need to prove to myself that this kernel is actually running. Since everyone out there seems to have it set to 0x80008000 I decided to leave the value as that and run make menuconfig, go into kernel-hacking and I noticed a "CONFIG_BOOT_PRINTK_DELAY", that'll slow down the each message being printed by the kernel by N milliseconds. N being what you give on the kernel cmdline, e.g. "boot_delay=250". If my kernel did get uncompressed and started running, then putting a boot_delay=250 should definitely delay when my screen fades to black. I went ahead an enabled the delay, added to boot.img-creation process the 250 millisecond delay and again attempt to run it. To my delight, the phone did take much longer before the fade-to-black occurred! Then I set the boot_delay=0 and tried booting the exact same custom_boot.img again. This time the fade-to-black was immediate. Excellent, so this kernel is getting unpacked and starts to run... prints out some messages... then something goes wrong. At this point, I'm sure professionals have a UART cable to do a serial-connection and actually see what the messages are. I'm sure something very helpful is in there, but I don't have such a cable.
I'm still thinking of what to do.... I feel like I'm close. Even if I don't ultimately figure this out I've gained a ton of knowledge in this quest.
Hopefully I'll be back with another update!
UPDATE#18
Further down the rabbit hole! So when I have display problems on my Linux PC, I usually have to do something like video=vesa on the kernel cmdline temporarily while I try to get some kind of proprietary video-driver-binary-blob to load. I just noticed that /proc/cmdline has more stuff in it than what was supplied when I assembled the bootimg using mkbootimg.
androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x3F ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci androidboot.emmc=true androidboot.serialno=88e9844f androidboot.baseband=msm mdss_mdp.panel=1:dsi:0:qcom,mdss_dsi_otm1284a_720p_video
Click to expand...
Click to collapse
The only thing that the mkboot reported after extracting stuff from the original boot.img stops after androidboot.bootdevice. That's also the only stuff I give mkbootimg when combining the zImage, ramdisk and dt.img into customboot.img. Everything starting at androidboot.emmc is coming from... I have no idea. But the one thing that really caught my attention was qcom,mdss_dsi_otm1284a_720p_video! I never put any kind of value like that in my custom-kernel. Maybe that's the problem? To verify it, I ran the strings command on the uncompressed original kernel and sure enough the string was in that kernel image, but not in mine. Then, I searched the ramdisk and dt.img. The dt.img file also has the string in it! While looking around to learn more about dt.img, I discovered the command "dtc -I dtb -O dts msm8916-0000.dtb > ./msm8916.dts" will give me the human readable source; and it works the other direction too. So now I can go from dt.img-->.dtb--->dts and back again! I looked at the source and there was a huge section label "qcom,mdss_dsi_otm1284a_720p_video" with all kinds of stuff that definitely looked like it's describing how to control the screen. Hmm, so if the kernel is asking for a dt-entry that doesn't exist maybe the screen gets messed up? I know for sure my kernel doesn't have that string in it so probably whatever it's doing is wrong. I changed the name of this entry in the dts, then compiled it back into a dt.img and booted up the original boot.img hoping that now the name is changed, the original kernel wouldn't find it and the screen would fade to black. That would make me feel confident that the problem I was having is related to kernel & dt.img not matching screen-mode. Unfortunately, even with the name change the device booted up properly and the /proc/cmdline still showed the same normal-named video-mode. "Hmm..." I thought, then I noticed the width & height values. I changed the height from the original value(1280) to like 640. That worked! After the white-BLU-logo, at about the time the screen would fade to black for my kernel... original kernel started the animated-logo but it was half cut-off at the bottom by a big blue square and when the Android-UI showed up, all the icons and everything were shrunk down to fit in the top-half of the screen! OK THEN! So even though I changed the name, the kernel still found it. Next experiment, completely delete the entry from the dt.img. I did that...and the result was the screen faded to black after the white-BLU logo, just like my custom kernel does! So now I'm feeling pretty sure that my custom-kernel is requesting a video-mode not in the dt.img. The only place I see in the "make menuconfig" to supply this kind of info is CONFIG_CMDLINE, but the config file I extracted from the original boot.img does not use that. I then noticed an option for creating a "zImage-dtb" so I tried that but what it does is literally appends the .dtb file to the end of the zImage. I see the data in hexedit, but the kernel I got from the phone has that strings _AFTER_ it's been uncompressed. So I was expecting the dtb to be inserted into the Image AND THEN compressed into zImage-dtb. I tested it and zImage-dtb still doesn't boot my phone. Still looking around for another way to do this. If I can just push this custom-kernel to boot up enough for adb to kick-in, I can start actually looking at errors from dmesg, /proc/kmsg and logcat.
UPDATE#19
Step by Step!!! So after compiling my kernel and careful comparing of what I see in my hexeditor, I tracked down the file BLU-devs hardcoded that "qcom,mdss_dsi_otm1284a_720p_video" string in. drivers/video/msm/mdss/mdss_mdp.c . When I added a variable holding that string near the top of "static int mdss_mdp_get_pan_cfg(struct mdss_panel_cfg *pan_cfg)", my compiled kernel looked just like theirs in the same hex area. Maybe IDApro could disassemble this kernel and show me clearly what's going on, but I don't have that. What I do have is a fade-to-black screen. I thought to myself, what if I could put some code in here that'll stop the screen from fading out? Then I'd have an idea of what lines of code the kernel reached. I first wanted to do an infinite-loop, but looking at init/main.c I saw a thread started. I don't want any other threads interfering; I want everything to just halt. Google'd how to cause a kernel-panic and found, in hindsight is obvious, that causing a segfault will kill the whole process. Someone gave an example and I put it into my function:
Code:
static void screen_stay_on() {
int *p = 0;
printk("%d", *p); //invalid memory access, will cause segfault.
}
I tested this code right in the init function in the mdss_mdp.c and sure enough, the screen didn't fade out. It just stayed at the white-BLU logo. Excellent!!! I then moved screen_stay_on() into all the error-checking parts of the code, one-by-one, many-many-many recompiles and "fastboot boot custom_boot.img" for a few hours. Eventually I narrowed it down to this:
Code:
rc = of_property_read_u32(pdev->dev.of_node, "qcom,max-mixer-width", &mdata->max_mixer_width);
if (rc) {
pr_err("device tree err: failed to get max mixer width\n");
screen_stay_on();
return -EINVAL;
}
Okay!!!! So if it called my function then I know for sure the error message above must have been sent to the UART-console. Remember a few updates earlier I said I can decompile the dt.img->dtb->dts to actually see its source code? Well I checked the source and sure enough, "qcom,max-mixer-width" was missing! I google'd msm8916 qcom,max-mixer-width and found other dtsi(differnet from dts) with just about all the same values I have and qcom,max-mixer-width = <2048>;. So I just went ahead and added that value right above other values that the kernel was checking for. Recreated the dt.img and tried to boot again. The screen faded to black! So I solved that error!!!!! Now as it turns out, after moving my screen_stay_on() code to all error-handling within mdss_mdp.c I can now say for certain that no errors occur in that file. The main function in here is static int mdss_mdp_probe(struct platform_device *pdev), and by the time that function reaches the end it has called all the other functions in the file and they all must have succeeded without error, so I put the screen_stay_on() in the error-handling at the end and the screen still fades out, so probing for the screen is working. Also, in mdss_mdp_get_pan_cfg I put:
Code:
if(strcmp("dsi:0:qcom,mdss_dsi_otm1284a_720p_video", pan_name) == 0)
screen_stay_on();
The code did some processing beforehand that appears to remove the "1:" at the beginning, so by doing this and seeing that the screen didn't fade out informed me that the correct video-mode string was being sent. I guess it's in the bootloader because I didn't put it in the cmdline when creating the boot.img and I removed my variable containing that value from the code. This conclusion is further enforced in that nowhere in the kernel-source can I find a call to "mdss_mdp_probe", so I guess the bootloader is what called it. Now, the fact that this drivers/video/msm/mdss/, is in the "videos" folder and my kernel-config file has CONFIG_FB_MSM=y and CONFIG_FB_MSM_MDSS=y seems to indicate that if I slowly work my way through all the .c files in msm and mdss, I'll eventually succeed in getting the device to start up enough for adb-shell. I think this because based on timing, the screen seems to be the last thing before the animated screen shows up and the moment that appears(actually even like a split second before) adb-shell starts working. Stay tuned!

UPDATE#20
I shortened the crashing code into a one-liner, printk("%d crash me now!", *(int *)0); because it's easier to clean-up and remove when I'm done looking at a particular file.
So... the game has changed a bit. What I just found out by accident, is that if I remove "qcom,mdss_dsi_otm1284a_720p_video" from dt.img.. the stock kernel will fade out the screen, but if I wait long enough it will still boot up. The screen won't work but adb-shell does and I can see all the kmsg errors about not being able to setup the framebuffer.... and a devide-by-zero error somewhere. This means my newer kernel has 2 problems. One is the screen and the 2nd is something else because apparently starting up the screen is not a fatal error to Android. Sounds hopeless, but hold on! A couple of other things I've just discovered....
In the file mdss_mdp_splash_logo.c:
Code:
rc = mdss_mdp_splash_parse_dt(mfd);
if (rc) {
pr_err("splash memory reserve failed\n");
goto end;
}
if (!mfd->splash_info.splash_logo_enabled) {
rc = -EINVAL;
printk("%d crash me now!", *(int *)0);
goto end;
}
mfd->splash_info.splash_thread = kthread_run(mdss_mdp_splash_thread,
mfd, "mdss_fb_splash");
end:
return rc;
In the parse code, it sets mfd->splash_info.splash_logo_enabled to whatever it found by asking the dt.img for "qcom,mdss-fb-splash-logo-enabled"... at least it looks that way to me, however no matter how I manually added that to the dt.img this code kept saying no. Eventually, I just decided to remove that if-statement entirely forcing the code path to go start that splash thread. The result? After the while-BLU-logo, the screen went immediately blank then immediately blue! ....Hmm!
Above I said that even if I remove the main video-mode from the dt, the phone will still boot up just without a display, but there is an interesting detail here. When the stock-kernel tries to show the animated logo, the display blinks for a moment like it's switching modes(makes sense).... then fades out when apparently things didn't work out but continues the bootup process to allow adb-shell to work. My custom kernel just fades out without that blink. But I can cause a very similar looking blink by forcing that splash-thread to start. I also noticed that even with a stock-kernel AND stock dt.img, the screen does blink for a moment before starting the animated boot. If I use the stock kernel BUT a dt.img with _ALL_ splash-enable tags removed, then the screen blinks for a moment, the white logo is cut in half by a blue square on the lower half of the screen... then it fades out just like my custom-kernel.... but then suddenly the animated boot screen shows up and the phone works normally from there! I find that interesting too!
Also, there are comments in the file "./mdss/mdss_mdp_overlay.c" that suggest that this code where the switch from the bootloader logo to the animated one will happen - or at least is very imminent. Because the splash code that changed the screen blue was started in a kthread, I now suspect whatever code I'm looking for that starts the boot-animation will be a kthread started thing as well. In a way, that makes sense. The kernel shouldn't start the gui in its own main process.(pid 1 I assume, judging from init/main.c). I think I'm close. I'm hoping to solve this issue and reach an animated-boot-logo. But I still need another way to communicate what's going on because it doesn't appear that I can rely on the screen-fade to help me. That'll be especially true if I manage to fix stuff and reach the animated-boot-logo, but then the phone gets stuck there. I looked in the dt.img and saw what appeared to be the video region:
Code:
memory {
device_type = "memory";
reg = <0x0 0x0 0x0 0x0>;
#address-cells = <0x2>;
#size-cells = <0x2>;
[email protected] {
linux,reserve-contiguous-region;
linux,reserve-region;
linux,remove-completely;
reg = <0x0 0x86000000 0x0 0x800000>;
label = "external_image_mem";
};
The above "reg" section says image starts at 0x86000000 and is the size of 0x00800000. I hoped that was video-ram so I wrote code to set all the bits in that memory region
Code:
int i = 0
for(i = 0; i < 0x00800000; i ++)
*(char*)(0x86000000 + i) = 255 ;
...but I didn't see anything appear on screen.
I haven't given up, seeing the screen change blue from the splash-logo code gave me hope that this kernel can find & draw to the screen beyond the bootloader's hardcoded white-BLU logo.
UPDATE#20.b
To help avoid getting myself confused, I've gone into my ramdisk/init.rc and removed the bootanimation service completely. So now my device seems to boot up faster, straight from white-logo to android homescreen. A bunch of widgets are still loading though because they weren't ready in time. So now the stock-kernel with my custom-ramdisk boots straight to AndroidHomeScreen as fast as possible while my custom kernel fades out. This way I don't need to concern myself about the boot-animation working and keeps the scope of my problem smaller; just focus on getting android(the zygote service in init.rc?) to start up properly instead of the fade out. If it turns out that my custom kernel works as long as boot-animation is disabled, I can live without that feature.
UPDATE#20.c
Earlier I concluded that static int mdss_mdp_probe(struct platform_device *pdev) was called by the bootloader since I couldn't find any calls to it. That was wrong, I was searching the codebase for that exact string but I've since discovered that structs with similar variables/members are being used to share function-pointers and called from there. e.g.,
Code:
static struct platform_driver mdss_mdp_driver = {
.probe = mdss_mdp_probe,
.remove = mdss_mdp_remove,
.suspend = mdss_mdp_suspend,
.resume = mdss_mdp_resume,
.shutdown = NULL,
.driver = {
/*
* Driver name must match the device name added in
* platform.c.
*/
.name = "mdp",
.of_match_table = mdss_mdp_dt_match,
.pm = &mdss_mdp_pm_ops,
},
};
So now, any code call can do variableName->probe() to call mdss_mdp_probe. I'm looking for that now. I've also installed an app called "LiveBoot" by Chainfire that can save dmesg and kmsg to /cache/liveboot.log. Apparently it only starts up as soon as the /data partition is mounted. When I attempt to boot the kernel with this program, screen fade, wait a bit, reboot to TWRP, I don't see a /cache/liveboot.log file so it seems my custom kernel didn't make it far enough for that program to start logging.
UPDATE#20.d
A sidenote, the original problem I had with phone's microSD disappearing. I've updated the script I use to prevent that. I noticed that if the script is running when there is no music playing, it seems to cause issues with the microSD. And I keep forgetting to stop the script when music stops playing. So, in this updated script it won't write to the sdcard unless music is actually playing. That way all you have to do is remember to use the ScriptManager app from the PlayStore to start this script in the morning and for the whole day, listening to music shouldn't be a problem:
Code:
#increase read-ahead, supposedly this helps too.
echo -n 2048 > /sys/devices/virtual/bdi/179\:0/read_ahead_kb
echo -------------------------
id
echo -------------------------
cd /storage/sdcard1
while true; do
IS_SOUND_PLAYING=$( lsof | grep /dev/snd | grep pcm )
if [ -z "$IS_SOUND_PLAYING" ]; then
echo "[`date`] No sound detected"
else
echo "[`date`] Sound is playing"
ls -la . > ./ls_la.log 2>&1
sleep 1
ls -la . >> ./ls_la.log 2>&1
sleep 1
rm ./ls_la.log
fi
sleep 9
done
....and that probe code from my previous sub-update, traced back to generic probing code for all hardware in the linux-kernel world. When a device is probed isn't necessarily when it is used so that ended that chain of events. I'm looking at this problem from more than one angle.
Fixing the screen fade would be nice... but more important is getting access to the error-logs by:
- /fstab has this in its listening "/devices/platform/msm_hsusb /storage/usbotg vfat nosuid,nodev wait,voldmanaged=usbotg:auto", USBOTG implies serial-console over USB port. I need to buy a usbotg cable and give it a shot.
- Getting the phone to at least start up enough for liveboot app to save the logs to the /cache/liveboot.log file so I can reboot into stock and get the file, then I won't be trying a bunch of stuff blindly.
- Get CONFIG_FRAMEBUFFER_CONSOLE to work so that the bootloader will show the kernel-logs right away even if nothing else works and I'd have exact error messages to work on.
- Also editing the mdss_mdp entries in the dt.img to see if I can make the stock kernel fail like my custom kernel. Giving me more of an idea of what I should be looking for. Right now, I'm still of the mindset that the stock dt needs updating for the new kernel. I just don't know exactly what to change yet.
I hope to have a major'ish update next time!

UPDATE#21
Okay! So various Googling about Qualcomm and MSM8916 and I found a pdf on qualcomm's site pointing to https://codeaurora.org/projects/all-active-projects/android-msm ....I spent quite a bunch of time looking through the dozens of branches to find a kernel as close to 3.10.28 as possible and containing msm8916 files in arch/arm/configs/ , git cloning the entire thing is madness; way too big. So instead I found git commands for cloning only a specific branch and only the HEAD of that branch without history(I think).
git clone -b <tagName> --depth 1 <git://URL>
Click to expand...
Click to collapse
I couldn't find it, but I ran into another XDA post that did find it!!!! forum.xda-developers.com/android/development/rom-mokee-opensource-project-t2922088
https://www.codeaurora.org/cgit/qui...X_ANDROID_LNX.LA.3.7.2.1_RB1.04.04.04.157.010
Click to expand...
Click to collapse
If you click on "tree", you'll see the whole file/folder structure of the kernel. Also note that XDA post is for a different phone... but the same Android 4.4.x I have, same Kernel 3.10.28 my stock kernel is from and the same MSM8916 chipset! This is the closest I've seen so far.
So, given that url... to clone the exact branch/tag without downloading that gigantic repo..... click on summary and scroll to the bottom, you'll see a git clone URL, git://codeaurora.org/quic/la/kernel/msm-3.10 . Then notice that in the previous link there was an "h=LNX.LA.3.7.2.1_rb1", so in your terminal you type:
git clone -b LNX.LA.3.7.2.1_rb1 --depth 1 git://codeaurora.org/quic/la/kernel/msm-3.10
This will just download the files you see when you're in the tree tab; a quick download. In contrast, go ahead and try just doing a git clone without the depth or -b option and watch it take forever. So compiling this kernel using the .config I got from the boot.img will crash the phone. But, if I go force the splash-thread to run like in my previous updates... I get the familiar Linux penguin! No blue screen, and this kernel doesn't fade out the screen either! I think I've just gotten rid of one of my 2 problems! I tried enabling the FRAMEBUFFER_CONSOLE in .config and enabling the splash-screen, hoping that along with that linux-penguin I'd get kernel logs scrolling by(that's what happens for Linux on my PC). But that didn't happen.
UPDATE#21.b
So, in the upper-righthand corner of the page www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/Makefile is a dropdown, it looks like everything in that list starting with LNX.LA.3.7* has kernel 3.10.28. I might have to try all of them! I've also learned something else, there really was no hope for the other kernels I was trying to use. Once I notice this kernel behaving properly with the screen I ran "diff -r android-msm-seed-3.10-marshmallow/drivers/video/msm/mdss LNX.LA.3.7.2.1_rb1/drivers/video/msm/mdss", the differences are substantial and impossible to guess. Stuff like this:
171c192
< qpic_send_pkt(OP_EXIT_SLEEP_MODE, NULL, 0);
---
> qpic_panel_set_cmd_only(OP_EXIT_SLEEP_MODE);
176c197
< qpic_send_pkt(OP_ENTER_NORMAL_MODE, NULL, 0);
---
> qpic_panel_set_cmd_only(OP_ENTER_NORMAL_MODE);
181c202
< qpic_send_pkt(OP_SET_DISPLAY_ON, NULL, 0);
---
> qpic_panel_set_cmd_only(OP_SET_DISPLAY_ON);
Click to expand...
Click to collapse
Even with the fact I have very little idea how this code works, seeing functions with different names and different number of params confirms comments I read when ROM-devs say you need to use the right kernel for your device. The differences can be way to big to solve with changes to .config, and definitely too problematic without having a serial-console to see kernel messages during boot up. Realistically/cynically speaking, the chances that I'll get this to work are kinda low... but I have learned a lot making these attempts and the fact that despite the odds, I've made progress little by little, gives me hope to continue. I'll probably be trying a bunch of these kernels; it's gonna be awhile because it takes like 25mins to compile one and they usually have errors I have to fix by copying .h files to the correct directory. e.g., I always get complaints about msm_csid.h & msm_csiphy.h missing, but really they're just not in the dir that the compile-process is looking at. An with each of these kernels, I'll be retrying the FRAMEBUFFER_CONSOLE and watching /cache/liveboot.log for any entries.
And the penguin splash screen, I figured out how to get it without changing the code. The code is actually checking the fb_primary section, so in my dt.img I've added qcom,mdss-fb-splash-logo-enabled to that area and now even the stock kernel gets the Linux-penguin on startup, then the liveboot logs start scrolling by.
Code:
qcom,mdss_fb_primary {
cell-index = <0x0>;
compatible = "qcom,mdss-fb";
qcom,mdss-fb-splash-logo-enabled;
qcom,memblock-reserve = <0x83200000 0xfa0000>;
linux,phandle = <0x44>;
phandle = <0x44>;
}
Crossing my fingers for some luck here. I hoping for a booting kernel, or at least being able to see the kernel-logs of why it won't boot.

UPDATE#22
LNX.LA.3.7.c7 , whoa... this kernel hangs on the linux-penguin then silence for about 2mins..... then the phone's screen goes off and my Linux PC's dmesg suddenly does this:
Code:
[2238301.946062] usb 1-2: new high-speed USB device number 92 using xhci_hcd
[2238302.074180] usb 1-2: config 1 has an invalid interface number: 20 but max is 1
[2238302.074193] usb 1-2: config 1 has no interface number 1
[2238302.074604] usb 1-2: New USB device found, idVendor=05c6, idProduct=9006
[2238302.074607] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2238302.074610] usb 1-2: Product: QHSUSB__BULK
[2238302.074612] usb 1-2: Manufacturer: Qualcomm CDMA Technologies MSM
[2238302.074615] usb 1-2: SerialNumber: 1234567890ABCDEF
[2238302.075131] usb-storage 1-2:1.20: USB Mass Storage device detected
[2238302.075815] scsi host24: usb-storage 1-2:1.20
[2238303.074290] scsi 24:0:0:0: Direct-Access Qualcomm MMC Storage 1.00 PQ: 0 ANSI: 2
[2238303.075024] sd 24:0:0:0: Attached scsi generic sg1 type 0
[2238303.075591] sd 24:0:0:0: [sdb] 30785536 512-byte logical blocks: (15.7 GB/14.6 GiB)
[2238303.075725] sd 24:0:0:0: [sdb] Write Protect is off
[2238303.075732] sd 24:0:0:0: [sdb] Mode Sense: 0f 0e 00 00
[2228723.862956] usb 1-2: USB disconnect, device number 85
[2228726.011441] usb 1-2: new high-speed USB device number 86 using xhci_hcd
[2228726.202432] usb 1-2: New USB device found, idVendor=18d1, idProduct=d00d
[2228726.202443] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2228726.202449] usb 1-2: Product: Android
[2228726.202453] usb 1-2: Manufacturer: Google
[2228726.202457] usb 1-2: SerialNumber: 88c8934f
[2228727.560892] usb 1-2: USB disconnect, device number 86
[2228759.996611] usb 1-2: new high-speed USB device number 87 using xhci_hcd
[2228760.125561] usb 1-2: New USB device found, idVendor=05c6, idProduct=9039
[2228760.125569] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2228760.125574] usb 1-2: Product: Android
[2228760.125578] usb 1-2: Manufacturer: Android
[2228760.125581] usb 1-2: SerialNumber: 88c8934f
[2228786.600155] usb 1-2: USB disconnect, device number 87
[2228788.971409] usb 1-2: new high-speed USB device number 88 using xhci_hcd
[2228789.162432] usb 1-2: New USB device found, idVendor=18d1, idProduct=d00d
[2228789.162441] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2228789.162446] usb 1-2: Product: Android
[2228789.162450] usb 1-2: Manufacturer: Google
[2228789.162454] usb 1-2: SerialNumber: 88c8934f
[2228790.051869] usb 1-2: USB disconnect, device number 88
[2228822.708616] usb 1-2: new high-speed USB device number 89 using xhci_hcd
[2228822.837663] usb 1-2: New USB device found, idVendor=05c6, idProduct=9039
[2228822.837669] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2228822.837672] usb 1-2: Product: Android
[2228822.837675] usb 1-2: Manufacturer: Android
[2228822.837677] usb 1-2: SerialNumber: 88c8934f
[2230472.557985] usb 1-2: USB disconnect, device number 89
[2238176.773860] usb 1-2: new high-speed USB device number 90 using xhci_hcd
[2238176.964854] usb 1-2: New USB device found, idVendor=18d1, idProduct=d00d
[2238176.964866] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2238176.964873] usb 1-2: Product: Android
[2238176.964878] usb 1-2: Manufacturer: Google
[2238176.964882] usb 1-2: SerialNumber: 88c8934f
[2238177.447102] usb 1-2: USB disconnect, device number 90
[2238297.707378] usb 1-2: new high-speed USB device number 91 using xhci_hcd
[2238297.837015] usb 1-2: New USB device found, idVendor=05c6, idProduct=9039
[2238297.837024] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2238297.837029] usb 1-2: Product: Android
[2238297.837033] usb 1-2: Manufacturer: Android
[2238297.837036] usb 1-2: SerialNumber: 88c8934f
[2238298.881636] usb 1-2: usbfs: USBDEVFS_CONTROL failed cmd adb_Linux rqt 128 rq 6 len 256 ret -71
[2238298.882319] usb 1-2: USB disconnect, device number 91
[2238303.075855] sd 24:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[2238303.088454] sdb: sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 sdb13 sdb14 sdb15 sdb16 sdb17 sdb18 sdb19 sdb20 sdb21 sdb22 sdb23 sdb24 sdb25 sdb26 sdb27 sdb28 sdb29 sdb30
[2238303.093730] sd 24:0:0:0: [sdb] Attached SCSI disk
[2238314.750365] EXT4-fs (sdb23): mounted filesystem with ordered data mode. Opts: (null)
[2238327.410965] EXT4-fs (sdb25): recovery complete
[2238327.411781] EXT4-fs (sdb25): mounted filesystem with ordered data mode. Opts: (null)
[2238333.447632] EXT4-fs (sdb30): recovery complete
[2238333.448440] EXT4-fs (sdb30): mounted filesystem with ordered data mode. Opts: (null)
[2238339.389827] EXT4-fs (sdb24): recovery complete
[2238339.390653] EXT4-fs (sdb24): mounted filesystem with ordered data mode. Opts: (null)
And so far, it appears 5 different volumes are mounted! They appear to be the various partitions(boot, aboot(bootloader), recovery, etc). The phone couldn't be seen by adb or fastboot, makes sense because it appears to have switched into some mode emulating 5 USB drives. I looked through the files and all I saw were the system apks, bin dir, etc but no logs.
I... guess I just keep going! One of these kernels might actually boot this phone up!
UPDATE#22.b
Hmm.... I just realized something, all the partitions get mounted to the connected PC as read/write(first you have to be root on your Linux box though); even the system partition. So even if I didn't have an exploit to root this phone previously, booting up with this messed up kernel allowed me to create any arbitrary files in /system and when I reboot the phone to run it's built-in stock kernel, the file is still there and owned by root. I could have just copied the "su" binary out of SuperSU.apk and put it in /system/bin, then reboot the phone to stock-kernel. /system/bin/su would still remain there and it'd be owned by root and I could become root that way...... interesting strategy. Note that this only seems to work on a LinuxPC, on a macosx I just see a bunch of these appear in dmesg:
Code:
USBMSC Identifier (non-unique): 0x00000000 0x5c6 0x9091 0x0, 2
[0xffffff8023be5600](1)/(5) Device not responding
Also, I see lines like this during stock-kernel's bootup: ltr553_L5510.c ltr553_als_set_enable: enable = 1 which I assume goes alone with the stock-kernel's config CONFIG_PROJECT_L5510=y. I'm assuming L5510 is some kind of BLU internal project-ID for their work on this phone. I've noticed that some branches on msm-3.10, e.g. LA.BF64.1.1_rb1.9, contain a file /drivers/input/misc/ltr553.c . What I'm guessing is that BLU modified this file in some way for this phone. From googling around, it appears this LTR553 stuff is for the little light sensor on the front of the phone that is used when you set brightness to automatic. Probably also somehow used when the camera is trying to auto-adjust for lighting as well. I wanted to know which branches & kernel versions had ltr553, but using the WebUI for this took too long and I kept losing my place. I ultimately ended up cloning the entire repo to machine, and then running this command & script:
git branch -a | sed 's/ //g' |while read b; do bash ./search_ltr553.sh $b ; done > searchresults.log 2>&1
Click to expand...
Click to collapse
search_ltr553.sh containing:
Code:
echo "************** $1 *************"
git checkout -f $1
cat Makefile |grep SUBLEVEL.=
find . -name ltr553.c
echo "************* END $1 ********"
I grep the sublevel because I'm looking for "28", from 3.10.28... then the find command searches for ltr553.c. Probably could be faster by simply "ls /drivers/input/misc/ltr553.c", either it's there or it's not.
I didn't find any 3.10.28 kernels containing the ltr553 sensor module. I wanted to focus on kernels that containing the ltr553 code but those kernels aren't 3.10.28, and so far only 3.10.28 can start up the phone's LCD properly. Everything else seems to fade the screen to black.
Well, the attempts continue. I should probably note that I'm also emailing BLU periodically for the kernel source to this phone.

UPDATE#23
https://github.com/SMTDDR/BLULifeOne
Meh, anti-climatic finish. After emailing BLU several times they gave me the kernel source and the firmware images. It works, phone starts with no problems. In fact, they actually gave the kernel source to a lot of their devices. I'm downloading them all now, but it'll be awhile. It's a very slow download. Using "wget -r ftp://<username>:<password>@<IP_address>/"
I guess I'll just continue on trying to make 3.10.49 work, but now I'll have a working kernel-source to work from. Then I'll see if the sdcard-unmount issue still exists. Then try messing around with ./drivers/mmc/card/block.c because that looks like where the errors are coming from according to dmesg.
If I manage to make a progress, I'll just update the repo.
I hope someone out there learned something from all my posts here.
UPDATE#23.b
Oh, and I got the newer kernel to config the LCD properly. It turns out that 3.10.49 was ignoring my dt.img file, it seems to only pay attention to the dtb that is concatenated into the zImage. And I mean that literally, like "cat /path/to/zImage /path/to/msm8916.dtb > zImage-dtb". Then creating a boot.img from zImage-dtb without providing a --dt custom_dt.img , that works. First I compiled 3.10.49 as "make zImage-dtb". Then I ran csplitb.py --prefix msm8916- --suffix .dtb --number 4 D00DFEED /path/to/zImage-dtb. This gave me 46 dtb files. I put all these files in one dir and ran the command "file . -name '*.dtb' -exec bash ./to_dts.sh {} \;" and the script to_dts.sh contained only one line: ../k/LNX.LA.3.7.1.1_rb1.49/scripts/dtc/dtc -I dtb -O dts ./$1 > ${1%dtb}dts, so now I had all the .dts source code files. Then I ran: find . -name '*.dts' -exec grep "model = " {} /dev/null \;|grep Q to print out each filename and the chipset that it's for. The dts file I got from the stock-kernel's dt.img had this at the top: model = "Qualcomm Technologies, Inc. MSM 8916 QRD SKUI";, so that was what I was looking for. Found it as file msm8916-0011.dts, so I took that file... added the section "qcom,mdss_dsi_otm1284a_720p_video" from the stock dt.img and then went to the section called "qcom,[email protected]" and changed the value qcom,dsi-pref-prim-pan to equal the phandle value in the video-section I just added. Note, for all sections the phandle should be the same as linux,phandle ...also.. these values should be unique throughout the whole file! No 2 sections should have the same phandle or linux,phandle. Then created a dtb from this modified dts, LNX.LA.3.7.1.1_rb1.49/scripts/dtc/dtc -I dts -O dtb /path/to/modified.dts > fixedup_msm8916.dtb. Then took this .dtb and appended it to the zImage, cat /path/to/zImage /path/to/fixedup_msm8916.dtb > zImage-dtb. Then created the boot image, mkbootimg_tools/mkbootimg --kernel /path/to/zImage-dtb --ramdisk boot/custom_ramdisk.gz --cmdline "androidboot.hardware=qcom msm_rtb.filter=0x3F ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci" --base 0x80000000 --ramdisk_offset 0x01000000 -o custom_boot.img ....and the resulting custom_boot.img used with "fastboot boot custom_image.img" gave me the nice linux-penguin.
UPDATE#23.c
Download finished, if anyone wants these... give me some place to upload them to.
Code:
.Energy X E010Q
.Dash 5.0 D410
.Life Pure XL L260
.Life Play S L150
.Studio 5.0 S II D572
.Life Mark L0030EE
.Neo 3.5 S370
.Neo 4.5
.Dash M D030
.Life One L120
.Studio 5.0 HD LTE & Studio 6.0 LTE
.Advance 4.0 A270
.Dash C Music D390U-L
.Dash Music Jr D390
.Studio 5.0 C D536
.Studio XL D850Q
.Pure XL P0010UU
.Studio One
.LIfe One X L132
.Studio 5.5 S D630
.Studio Selfie S070Q
.Life One X010Q <------ This is the one that runs on my phone, even though it's labeled X010Q here, and my phone is X011Q.
.Studio Energy 2 S0090UU
.Life Play KitKat L100
.Studio 5.0 C E D536
.Studio C Mini D670
.Dash Jr D140
.Studio G Plus S510
.Vivo Air D980L
.Life 8 L280
.Studio 5.0 C HD D534
.MT6589
.Studio 5.0 S D570
.Life One M L131
.Studio 5.0 II D532
.Studio 5.0 D530
.Studio Energy D810
.Studio 5.5 D610
.Life One XL X030Q
.Dash 3.5 II D352
.Studio C
.Dash X D010
.Life View L110
.Vivo IV D970L
.Dash 3.5 D171
.Dash 4.5 D310
.Life Play 2 L190
.Studio 5.0 K D530K
About 26 gigs in total.
Anyways... off I go...
UPDATE#23.d
All that stuff I said to edit .dts file? Don't do that, make the changes in the dts & dtsi files in arch/arm/boot in the dts folder and its subfolder "qcom". It turns out that there are values reference from different files and when the whole thing is "compiled" into a dtb, things get IDs(phandle) or different values 'n stuff. Cut & paste from a dts that came from somewhere else directly into another dts that was decompiled from someplace else can lead to complicated problems. .e.g., I talked about copying the whole video section into the other dts... but what I didn't know was stuff like the following: There is a file for a different resolution called arch/arm/boot/dts/qcom/dsi-panel-otm1283a-720p-video.dtsi , inside this file is this line: qcom,mdss-dsi-panel-controller = <&mdss_dsi0>; and the file that imports this one with an #include statement, arch/arm/boot/dts/qcom/msm8916-qrd-skui.dtsi, does stuff like this:
Code:
&mdss_dsi0{
qcom,dsi-pref-prim-pan = <&dsi_otm1284a_720p_video>;
pinctrl-names = "mdss_default","mdss_sleep";
pinctrl-0 = <&mdss_dsi_active>;
pinctrl-1 = <&mdss_dsi_suspend>;
com,platform-reset-gpio = <&msm_gpio250>;
};
&dsi_otm1284a_720p_video{
qcom,cont-splash-enabled;
};
All those &name stuff gets resolved during compile and it appears phandle and linux,phandle are caculated as well. Just cutting and pasting dts stuff from one kernel to another, skipping the compile process, can cause you a headache if you don't know exactly what values came from where. It's best to just make the changes in the kernel's dts&dtsi source files, compile to zImage-dtb and then look at the result. For me, that dtb file is ultimately: arch/arm/boot/dts/msm8916-qrd-skui.dtb that's created during the zImage-dtb process. At least decompiling this file into a .dts and editing is safer since you know that you're at least starting with all the &name stuff replaced with the correct values. But just beware that some values in there might be referring to other values elsewhere in the file so just changing them without understand, will break relationships and almost definitely cause your device not to work.

UPDATE#24
So, right now I'm on git clone -b kk_rb5 --depth 1 git://codeaurora.org/quic/la/kernel/msm-3.10 kk_rb5, commit fe85dc23da0b36704f10b7d980017a5d82fabb8a kernel 3.10.40. It seems be the one that accepts the .config from the stock kernel while asking the least amount of questions. I still get my linux penguin on start up since I enable that in the dt files, then all the ext4 partitions get mounted on my PC.
I really want to see the boot messages, so far I've tried:
/proc/last_kmsg - I don't have and I see no where in menuconfig to enable it
Framebuffer-console - Doesn't work, even with BLU's kernel source the device just boots up normally and I see nothing. But, "adb reboot" and the whole device freezes for 2mins before the reboot happens.
CONFIG_PSTORE_CONSOLE , is suppose to give me /sys/fs/pstore/* a bunch of logs from a previous kernel boot. I get nothing. I think drivers have to register to be part of this with pstore_register().
github.com/Tasssadar/kernel/commit/b1c614341dbc04ec1ace604f0b4903944dd8aa9d , from this thread forum.xda-developers.com/showthread.php?t=1295621. I tried using my intuition to make these changes in my newer kernel(the code isn't exactly the same as the code that person modified), but didn't work. Phone just stays on white-BLU-logo, no penguin.
USBOTG, still haven't tried this.
UPDATE#24.b
Random googling about my phone's partitions mounting to my computer turned up some info. QHSUSB__BULK is a known issue with Android phones in specific situations. The productID seems to serve as an error code. With the kernel I'm working with now, I get:
Code:
[4039781.339003] usb 1-2: New USB device found, idVendor=05c6, idProduct=9091
[4039781.339010] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[4039781.339013] usb 1-2: Product: QHSUSB__BULK
That Product ID (PID), 9091, is trying to tell me something. I don't see a chart out there telling me what all the error codes are. The only thing people talking are doing is to bring the phone into a state where they can flash it into a known good state. I don't want to flash my phone into a known good state, I want this kernel to work.

UPDATE#25
Whoa, so... the screen comes on but is blank... and... MY MUSIC APP PLAYS MUSIC WHEN THE HEADPHONES ARE PLUGGED IN!!!!!! Even the Volume buttons work!
This is amazing to me! That means this kernel is good enough to run, that Android starts up and PowerAmp can play music! ....from the external microSD card even!
I'm very shocked that adb still doesn't see the phone though.... that's odd.
The changes I made to reach this point, was comparing the dts & dtsi files that BLU sent me and slowly try to add missing sections to the new kernel, but not modify sections that already exist.
UPDATE#25.b
After some more testing, the configuration to get music playing is very specific. I have to go into the dts & dtsi files and remove splash screen, that means in the fb_primary section I remove qcom,mdss-fb-splash-logo-enabled; and in the file "msm8916-qrd-skui.dtsi" remove the part that adds qcom,cont-splash-enabled; to the selected video-mode:
Code:
&dsi_otm1284a_720p_video {
/* qcom,cont-splash-enabled; ....I'm commenting this out */
}
Then, in .config enable FRAMEBUFFER_CONSOLE & Peguin logo:
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
Click to expand...
Click to collapse
You won't see a peguin or any framebuffer showing you boot up logs. The white-BLU bootloader logo will flicker a few times then the screen will go blank. Then in about a minute or so my music app kicks in through the headphones.

UPDATE#26
Success! Got the logs! So, because the music files that are on my sdcard started playing, I knew that the microSD card must have mounted successfully. There's a file in the ramdisk called init.qcom.rc that's responsible for mounting that microSD so that script must have ran. So, I added another service below it:
service fuse_sdcard1 /system/bin/sdcard -u 1023 -g 1023 -d /mnt/media_rw/sdcard1 /storage/sdcard1
class late_start
service getdmesg /system/bin/getdmesg
class late_start
Click to expand...
Click to collapse
That getdmesg is just a bash script that I wrote, containing:
#!/system/bin/sh
sleep 45
dmesg > /data/local/tmp/dmesg.log
dmesg > /storage/sdcard1/dmesg.log
logcat -d *:d > /data/local/tmp/logcat.log
logcat -d *:d > /storage/sdcard1/logcat.log
sleep 5
reboot
Click to expand...
Click to collapse
And that's it. "fastboot boot custom_boot.img" and wait for sleeps to complete. The device reboots itself to the working kernel that's flashed on it(without the modification to init.qcom.rc) and the previous kernel's dmesg & logcat are indeed located at /data/local/tmp.
DMESG:
Code:
6>[ 0.000000] Booting Linux on physical CPU 0x0
<6>[ 0.000000] Initializing cgroup subsys cpu
<6>[ 0.000000] Initializing cgroup subsys cpuacct
<5>[ 0.000000] Linux version 3.10.40-g354f6d4-dirty ([email protected]) (gcc version 4.7 (GCC) ) #15 SMP PREEMPT Tue Feb 9 16:07:18 PST 2016
<4>[ 0.000000] CPU: ARMv7 Processor [410fd030] revision 0 (ARMv7), cr=10c5387d
<4>[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
<6>[ 0.000000] Machine: Qualcomm Technologies, Inc. MSM 8916 (Flattened Device Tree), model: Qualcomm Technologies, Inc. MSM 8916 QRD SKUI
<6>[ 0.000000] Node qcom,mdss_fb_primary memblock_reserve memory 83200000-841a0000
<6>[ 0.000000] cma: Found [email protected], memory base 0x86000000, size 8 MiB, limit 0xffffffff
<6>[ 0.000000] cma: Found [email protected], memory base 0x86800000, size 78 MiB, limit 0xffffffff
<6>[ 0.000000] cma: Found [email protected], memory base 0x8b600000, size 6 MiB, limit 0xffffffff
<6>[ 0.000000] cma: Found [email protected], memory base 0x00000000, size 109 MiB, limit 0xffffffff
<6>[ 0.000000] cma: Found [email protected], memory base 0x00000000, size 18 MiB, limit 0x90000000
<6>[ 0.000000] cma: Found [email protected], memory base 0x00000000, size 3 MiB, limit 0xffffffff
<6>[ 0.000000] cma: Found [email protected], memory base 0x83000000, size 18 MiB, limit 0xffffffff
<3>[ 0.000000] cma: CMA: failed to reserve 20 MiB
<6>[ 0.000000] cma: CMA: reserved 8 MiB at 0x86000000 for external_image_mem
I see this a couple of times too:
<4>[ 27.955392] mdss_fb_wait_for_fence: mdp-fence: sync_fence_wait timed out! Waiting 10 more seconds
Click to expand...
Click to collapse
LOGCAT:
Code:
/QC-QMI ( 284): qmi_ctl_tx_msg: qmi_qmux_tx_msg failed
E/QC-QMI ( 284): qmi_ctl_handle_request: qmi_ctl_tx_msg call failed
E/QC-QMI ( 284): qmi_qmux_open_connection: connection is disabled for conn_id=57
E/QC-QMI ( 284): qmi_qmux_tx_msg: failed to open inactive connd_id=57
E/QC-QMI ( 284): qmi_qmux: TX failed, connection inactive or in reset, conn_id=57, status_flags=4
E/QC-QMI ( 284): qmi_ctl_tx_msg: qmi_qmux_tx_msg failed
E/QC-QMI ( 284): qmi_ctl_handle_request: qmi_ctl_tx_msg call failed
E/USB_UICC( 240): Timeout! No signal received. Retry num = 22
E/VoldConnector( 1096): NDC Command {7 asec list} took too long (2430ms)
I/PackageManager( 1096): Deleting stale container for com.enfeel.birzzle-1
I/PackageManager( 1096): Deleting stale container for com.natenai.artofglow-2
I/PackageManager( 1096): Deleting stale container for com.ssb.droidsound-1
W/PackageManager( 1096): Unknown permission com.baidu.permission.QCCLOUD_PROVIDER in package com.android.contacts
W/PackageManager( 1096): Unknown permission com.android.firewall.READ_GRAVITY in package com.android.contacts
W/PackageManager( 1096): Unknown permission com.android.firewall.WRITE_GRAVITY in package com.android.contacts
W/PackageManager( 1096): Unknown permission com.android.firewall.READ_GRAVITY in package com.android.phone
W/PackageManager( 1096): Not granting permission android.permission.WRITE_SECURE_SETTINGS to package com.yahoo.android.locker (protectionLevel=50 flags=0x8be44)
W/PackageManager( 1096): Unknown permission com.android.vending.billing.IBillingAccountService.BIND2 in package com.google.android.gsf.login
W/PackageManager( 1096): Unknown permission android.permission.RECOVERY in package com.updatelogic.netready.da.svc
W/PackageManager( 1096): Unknown permission com.android.launcher.permission.READ_SETTINGS in package com.android.launcher3
W/PackageManager( 1096): Unknown permission com.android.launcher.permission.WRITE_SETTINGS in package com.android.launcher3
W/PackageManager( 1096): Unknown permission android.permission.INSTALL_DRM in package com.android.mms
W/PackageManager( 1096): Unknown permission android.permission.OBSERVE_GRANT_REVOKE_PERMISSIONS in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.RECOVERY in package com.google.android.gms
W/PackageManager( 1096): Not granting permission android.permission.READ_DREAM_STATE to package com.google.android.gms (protectionLevel=2 flags=0x40c83ec5)
W/PackageManager( 1096): Unknown permission android.permission.PROVIDE_TRUST_AGENT in package com.google.android.gms
W/PackageManager( 1096): Unknown permission com.google.android.apps.enterprise.dmagent.permission.AutoSyncPermission in package com.google.android.gms
W/PackageManager( 1096): Not granting permission android.permission.PACKAGE_USAGE_STATS to package com.google.android.gms (protectionLevel=18 flags=0x40c83ec5)
W/PackageManager( 1096): Unknown permission android.permission.MANAGE_VOICE_KEYPHRASES in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.REAL_GET_TASKS in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.READ_WIFI_CREDENTIAL in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.SCORE_NETWORKS in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.CONTROL_INCALL_EXPERIENCE in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.USER_ACTIVITY in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.MODIFY_AUDIO_ROUTING in package com.google.android.gms
W/PackageManager( 1096): Unknown permission com.google.android.wearable.READ_SETTINGS in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.INTENT_FILTER_VERIFICATION_AGENT in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.LOCAL_MAC_ADDRESS in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.CHANGE_DEVICE_IDLE_TEMP_WHITELIST in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.BODY_SENSORS in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.NOTIFY_PENDING_SYSTEM_UPDATE in package com.google.android.gms
W/PackageManager( 1096): Unknown permission com.android.voicemail.permission.READ_VOICEMAIL in package com.google.android.gms
W/PackageManager( 1096): Unknown permission com.google.android.gallery3d.permission.PICASA_STORE in package com.android.dreams.phototable
Now I can really debug this kernel and figure out what's going on.
UPDATE#26.b
So I got a bunch of these constantly happening in dmesg:
Code:
<3>[ 14.151255] mdss_dsi_reg_status_check: Read back value from panel is incorrect
<3>[ 14.151358] mdss_check_dsi_ctrl_status: Panel has gone bad, sending uevent - PANEL_ALIVE=0
Looking around the source code from where these error messages are coming from, I discovered that BLU-devs made a bunch of modifications to mdss_dsi_host.c , mdss_dsi.h, mdss_dsi_panel.c. I cannot simply copy the source file from the BLU kernel source into the new kernel because function definitions have changed and I have to think about how to apply their patches to the new kernel. e.g. in mdss_dsi_host.c:
mdss_dsi_buf_alloc(&ctrl->status_buf, SZ_4K);
//LINE <lcm> <DATE20141218> <read more register> limi.zhan
mdss_dsi_buf_alloc(&ctrl->status_buf_two, SZ_4K);
ctrl->cmdlist_commit = mdss_dsi_cmdlist_commit;
Click to expand...
Click to collapse
That 2nd line of code referencing status_buf_two was added by them. In my newer kernel, that same code looks like this:
mdss_dsi_buf_alloc(ctrl_dev, &ctrl->status_buf, SZ_4K);
ctrl->cmdlist_commit = mdss_dsi_cmdlist_commit;
Click to expand...
Click to collapse
Notice that the newer 3.10.40 kernel, the function mdss_dsi_buf_alloc() takes _THREE_ parameters rather than 2 from the original stock 3.10.28 kernel version. So, I have to patch it to look like this:
mdss_dsi_buf_alloc(ctrl_dev, &ctrl->status_buf, SZ_4K);
mdss_dsi_buf_alloc(ctrl_dev, &ctrl->status_buf_two, SZ_4K);
ctrl->cmdlist_commit = mdss_dsi_cmdlist_commit;
Click to expand...
Click to collapse
....I then get an error about that struct not containing any member status_buf_two and thus discover that BLU-devs also modified the .h file containing the definition of the struct to make sure that field existed, so I gotta go modify that too. This is the slow process I'm going through in hopes to solve this panel-error that I think is causing the display not to work. I also see errors related to wlan so I'm pretty sure the wifi is broken and I see usb related errors that are probably why adb/fastboot don't see the phone when this kernel starts the phone. This is going to take awhile.... but at least I have logs that I'm working from now.
UPDATE#26.c
adb sees the device now! The problem was this:
&usb_otg {
qcom,hsusb-otg-mode = <3>;
qcom,usbid-gpio = <&msm_gpio 110 0>;
pinctrl-names = "default";
pinctrl-0 = <&usbid_default>;
vbus_otg-supply = <&smb1360_otg_supply>;
};
Click to expand...
Click to collapse
That is located at the bottom of msm8916-qrd-skui.dts in the stock 3.10.28 kernel, and the BLU-devs commented that stuff out. I didn't see this at all in the newer 3.10.40 kernel so I just went on my way, but then I just noticed that the newer kernel's msm8916-qrd-skui.dtsi(NOTE the "i" at the end of this file, not the same as the .dts) did have the same usb_otg entry. I commented it out and now adb sees the device and I can adb-shell into it! I can't become root though, I've actually never been able to become root before the device fully starts up and the android-GUI appears.

UPDATE#27
So, after manually patching my newer kernel video driver files to match what appears to be the intents of the BLU-dev in the older kernel... the panel gets init'ed properly. Now, I got tired of having to wait for the reboot to the flashed-working kernel before I could pull the dmesg.log. I wanted root while my newer kernel was running. That way I could see dmesg right there and reboot directly back into fastboot-mode for my next attempts. Before, I said that when I ran "su" it'd always fail. I discovered that is the intentional design of the "su" binary from the SuperUser.apk. They want "su" to communicate with it and since my device isn't booting up enough for the AndroidGUI(zygote?) to start up, SuperUser.apk apparently can't work either. Probably because SuperUser.apk cannot display that "toast" message I normally see "Adb Shell has been granted root permissions".
After some research, I ran into this thread: forum.xda-developers.com/showthread.php?t=1463829 , they compiled a su that doesn't talk to SuperUser.apk. The link in that thread is broken, but this link: forum.xda-developers.com/showthread.php?t=1197486 has a ROM (version 0.8.1) that contains f-su according to the change-log. So I downloaded this ROM and extracted its contents, searched and found the "su" binary. I then booted up my phone with the working kernel, became root, and copied this su binary into /system/xbin as "ultimate_su" and chmod'ed it 4755(rwsr-xr-x). Then booted into the newer kernel.
When I ran ultimate_su at first, it segfaulted, but if I waited long enough... maybe about 45secs after boot... then it gave me root. Interestingly enough however, while uid did return info indicating I was root... "dmesg" command still said operation-not-permitted. What I had to do was run the SuperUser's su, and because I was already uid=0 from ultimate_su, then SuperUser's su gave me root without talking to the apk. In summary, 45secs after boot I did this to get fully-powered root: ultimate_su -c su.
The issue I'm dealing with now is the following:
<3>[ 1.618188] msm-tlmm-pinctrl 1000000.pinctrl: pin gp-13 already requested by 5-0038; cannot claim for 5-0070
<3>[ 1.618198] msm-tlmm-pinctrl 1000000.pinctrl: pin-13 (5-0070) status -22
<3>[ 1.618206] msm-tlmm-pinctrl 1000000.pinctrl: could not request pin 13 on device msm-pinctrl
<3>[ 1.618214] synaptics_rmi4_i2c 5-0070: Error applying setting, reverse things back
<3>[ 1.618221] synaptics_rmi4_i2c 5-0070: can not set pmx_ts_active pins
<4>[ 1.618632] synaptics_rmi4_i2c: probe of 5-0070 failed with error -22
Click to expand...
Click to collapse
I'm pretty confused on this one. I do know that in the msm8916-pinctrl.dtsi , there's this:
pmx_ts_int_active {
qcom,pins = <&gp 13>;
qcom,pin-func = <0>;
qcom,num-grp-pins = <1>;
label = "pmx_ts_int_active";
ts_int_active: ts_int_active {
drive-strength = <16>;
bias-pull-up;
};
};
Click to expand...
Click to collapse
If I change that 13 to a different number, then the error message still appears but it'll talk about that number instead of 13. I read stuff in this link elinux.org/EBC_Exercise_11a_Device_Trees , that taught me how to find pins that are free to use. Supposedly if I cat /sys/kernel/debug/pinctrl/1000000.pinctrl/pinmux-pins | grep "(MUX UNCLAIMED) (GPIO UNCLAIMED)" I get a list of pins I could use. For me, pin-50 was free so I changed the qcom,pins in pmx_ts_int_active to 50.... but I still got the error; just complaining about gp-50 instead of gp-13. Looking at the dts from the old working kernel, they also seem to be using the same pin with no problem. So I don't what to do yet... still researching & trying.

UPDATE#28
So, after awhile of staring at this error message I decided to see if I really even needed thsi "msm-tlmm-pinctrl". Turns out, that the older kernel compiles version 4 of this. CONFIG_PINCTRL_MSM_TLMM_V4=y , while my newer kernel seems to have the first version "CONFIG_PINCTRL_MSM_TLMM=y". So, I did a search for all *.c & *.h files containing the string "TLMM_V4"(case INsensitive) on the older kernel to get an idea of how/where this tlmm_v4 module was used....then I modified the following:
* modified my .config to V4.
* In arch/arm/mach-msm/Kconfig, section config ARCH_MSM8916, modified it to V4.
* In ./drivers/pinctrl/Kconfig, copied the V4 version into it from the Kconfig of the older kernel.
* In ./drivers/pinctrl/pinctrl-msm.c, there was an "#ifdef CONFIG_PINCTRL_MSM_TLMM_V4" block of code that had to be copied into my newer kernel source.
* Copied whole file ./drivers/pinctrl/pinctrl-msm-tlmm-v4.c to my newer kernel, because my newer kernel didn't have that file at all.
* In drivers/pinctrl/Makefile, added dependency to cause the v4.c code to compile: obj-$(CONFIG_PINCTRL_MSM_TLMM_V4) += pinctrl-msm.o pinctrl-msm-tlmm-v4.o
And for my troubles, I got the compile error:
Code:
drivers/pinctrl/pinctrl-msm-tlmm-v4.c:883:3: warning: initialization from incompatible pointer type [enabled by default]
error, forbidden warning: pinctrl-msm-tlmm-v4.c:883
Looking at the code at that line, and the struct it's initializingstruct msm_pintype_info in drivers/pinctrl/pinctrl-msm.h, there is indeed a difference in the pointer-type. It's actually a pointer to a function, but the function signature in the newer kernel has more parameters than the old... and there are some other things as well. It'll take time for me to figure out how to change this stuff without breaking other stuff or if I can just get TLMM_V4 wholesale and copy the entire .c & .h and whatever else is the TLMM_V4 version into my newer kernel.
UPDATE#28.b
I tried just copying over the files pinctrl-msm.c & pinctrl-msm.h from old kernel to the new one. Surprisingly it compiled, but the result was a phone that couldn't boot up, no adb-shell access and didn't progress enough to read init.qcom.rc allowing me to get it to dump dmesg to a file like I did before.

UPDATE#29
Okay, I surrender now. I cannot upgrade PINCTRL_MSM_TLMM to V4 without the boot process falling on its face and I can't see any error messages. This is probably where I'll be stopping unless I suddenly have a eureka moment in a dream or something.
It was fun and I did learn a lot trying all this. I hope someone finds some good info from my adventures of kernel tampering.

USB otg device not detected

Iam on omni ROM 6. When I attach my external HDD through a (powerd) otg cable my tabe doesn't detect it. It used to work before. Looking at the dmesg I get
241.787292] accessorry_id irq handler: dock_irq gpio val = 1
[ 241.787567] 30pin: duplicated otg connection event,ignore(1).
[ 241.791503] accessorry_id irq handler: dock_irq gpio val = 0
[ 242.488281] Accessory attached, adc=2728
[ 242.488708] adc change notified: acc_adc = 2728
[ 242.488922] 30pin_c: detect: device=0
[ 242.489166] cable detect: otg attach, current device = 0x0001
[ 242.489562] [espresso_usb_host_attach]
[ 242.489776] accessory_power: acc_device 0x0, new 0 : OFF
[ 242.490173] accessory_power: force turn off
[ 242.491638] otg espresso_otg_work(864): current device 0001
[ 242.492065] accessory_power: acc_device 0x0, new 2 : ON
[ 242.551055] accessorry_id irq handler: dock_irq gpio val = 0
[ 242.551483] 30pin: duplicated otg connection event,ignore(0
I rebooted several time but still I have the same message.