[Q] Random rebooting - Nexus 5 Q&A, Help & Troubleshooting

Hi,
I recently bought a Nexus 5 in Antwerp, Belgium (about three weeks ago). The build number is KOT49H. The first few days I didn't receive a reboot but after downloading a couple of apps, my phone rebooted about 4 to 5 times a day. I decided to RMA the phone and since an employee from the store I bought it from said I didn't need to store it back to original settings I just deleted my personal information and some apps. Then the reboots just weren't as active as before, I received one or two that week and decided to just let it slide for another week or so. Now I rooted my phone for viper4android and to check the last_kmgs files and noticed the reboots are because of kernel panic.
[ 2591.876665] Kernel panic - not syncing: EXT4-fs panic from previous error
[ 2591.876667]
[ 2591.876788] [<c010de1c>] (unwind_backtrace+0x0/0x144) from [<c09ffa4c>] (dump_stack+0x20/0x24)
[ 2591.876864] [<c09ffa4c>] (dump_stack+0x20/0x24) from [<c0a0045c>] (panic+0x9c/0x21c)
[ 2591.876940] [<c0a0045c>] (panic+0x9c/0x21c) from [<c030f2d8>] (__ext4_abort+0xe0/0xf4)
[ 2591.876984] [<c030f2d8>] (__ext4_abort+0xe0/0xf4) from [<c030f664>] (ext4_journal_start_sb+0xa0/0x1a4)
[ 2591.877063] [<c030f664>] (ext4_journal_start_sb+0xa0/0x1a4) from [<c02fcb0c>] (ext4_rename+0x48/0x728)
[ 2591.877143] [<c02fcb0c>] (ext4_rename+0x48/0x728) from [<c0273334>] (vfs_rename+0x350/0x4c4)
[ 2591.877219] [<c0273334>] (vfs_rename+0x350/0x4c4) from [<c027366c>] (sys_renameat+0x1c4/0x1d4)
[ 2591.877295] [<c027366c>] (sys_renameat+0x1c4/0x1d4) from [<c02736a8>] (sys_rename+0x2c/0x30)
[ 2591.877341] [<c02736a8>] (sys_rename+0x2c/0x30) from [<c0107300>] (ret_fast_syscall+0x0/0x30)
[ 2592.877756] Rebooting in 5 seconds..
[ 2597.879359] Going down for restart now
[ 2597.880123] Calling SCM to disable SPMI PMIC arbiter
No errors detected
Boot info:
Last boot reason: kernel_panic
Click to expand...
Click to collapse
It also seems the reboots are almost always in the weekend when I am at my mother's house (in the week I live in a student room).
So if anyone has some advice or needs more information, just ask.
Thanks a lot.

Niurez said:
Hi,
I recently bought a Nexus 5 in Antwerp, Belgium (about three weeks ago). The build number is KOT49H. The first few days I didn't receive a reboot but after downloading a couple of apps, my phone rebooted about 4 to 5 times a day. I decided to RMA the phone and since an employee from the store I bought it from said I didn't need to store it back to original settings I just deleted my personal information and some apps. Then the reboots just weren't as active as before, I received one or two that week and decided to just let it slide for another week or so. Now I rooted my phone for viper4android and to check the last_kmgs files and noticed the reboots are because of kernel panic.
It also seems the reboots are almost always in the weekend when I am at my mother's house (in the week I live in a student room).
So if anyone has some advice or needs more information, just ask.
Thanks a lot.
Click to expand...
Click to collapse
Well..... If you had a phone and these problems happened because of "apps and viper4android" and then you got another phone and did the same thing and get the same result then it is obviously something you are doing. Did it do this before you loaded your apps and viper4android? What method did you use to root/ how did you do it? I highly doubt the time of the week has anything to do when it reboots but I could be wrong.
A kernel panic is defined as "A kernel panic is an action taken by an operating system upon detecting an internal fatal error from which it cannot safely recover."
You are obviously doing something that it does not like.
I searched some of the lines of code and compared it to this thread here: http://forum.xda-developers.com/showthread.php?t=2553949
Try loading a different kernel. It doesn't matter anyone and see if that fixes the problem, you are rooted so it should take three minutes.

mistahseller said:
Well..... If you had a phone and these problems happened because of "apps and viper4android" and then you got another phone and did the same thing and get the same result then it is obviously something you are doing. Did it do this before you loaded your apps and viper4android? What method did you use to root/ how did you do it? I highly doubt the time of the week has anything to do when it reboots but I could be wrong.
Click to expand...
Click to collapse
Well it started before I rooted the phone. The apps I do use are nothing too special just the regular games and chat services that almost any normal smartphone user has installed. The method I used to root was in a thread I found on this forum and on the first page of google. Well, my phone hasn't rebooted once when I was at my student room and has rebooted about 4 times this day when I am at my mom's. And I didn't receive another phone yet. This is still the phone I bought originally from Mediamarkt in Antwerp.

Niurez said:
Well it started before I rooted the phone. The apps I do use are nothing too special just the regular games and chat services that almost any normal smartphone user has installed. The method I used to root was in a thread I found on this forum and on the first page of google. Well, my phone hasn't rebooted once when I was at my student room and has rebooted about 4 times this day when I am at my mom's. And I didn't receive another phone yet. This is still the phone I bought originally from Mediamarkt in Antwerp.
Click to expand...
Click to collapse
I edited my previous post and may have a solution, try and load a different kernel since you are rooted.

mistahseller said:
I edited my previous post and may have a solution, try and load a different kernel since you are rooted.
Click to expand...
Click to collapse
Also the reboots happen when the phone is idle. It happened like two or three times the phone froze while using Google All Access and just rebooted. I am pretty sure the reboots aren't because of my faulty usage.
I will try the different kernel but I still feel not pretty comfortable that the original kernel just reboots. Maybe RMA is my only solution? Thing is the employee from Mediamarkt said I'd miss my phone for minimum three weeks. I don't even own my phone that long.

kernel panic is because of a different error. it can be caused by just about anything. in the partial last_kmsg that you posted, you didnt include the error, only the outcome of the error. chances are that its an app causing it though. yes, apps cause random reboots. there are too many that arent written very well. i suggest wiping your device and not adding any apps for a day. if you dont get any random reboots, add one app at a time until your phone starts rebooting. then youll know which app it is and isnt.

simms22 said:
kernel panic is because of a different error. it can be caused by just about anything. in the partial last_kmsg that you posted, you didny include the error, only the outcome of the error. chances are that its an app causing it though. yes, apps cause random reboots. there are too many that arent written very well. i suggest wiping your device and not adding any apps for a day. if you dont get any random reboots, add one app at a time until your phone starts rebooting. then youll know which app it is and isnt.
Click to expand...
Click to collapse
This is the last zip file syslog provided me. Hope it has more information.

Niurez said:
This is the last zip file syslog provided me. Hope it has more information.
Click to expand...
Click to collapse
looks ike an i/o error. it had trouble transferring data to a sector. i dont know what would have caused it. an app issue, a corrupted sector, whatever it was the phone doesnt like it.
id try running the phone without any installed apps for a day, see if it still reboots. if it doesnt, it was an app. if it still reboots, id wipe out the phone completely and flash the factory image. its also possible that a sector is corrupted somehow, or the data in it. a flash of the factory image should take care of it.
[ 2591.685522] mmc1: data txfr (0x00100000) error: -110 after 671 ms
[ 2591.685634] sdhci: =========== REGISTER DUMP (mmc1)===========
[ 2591.685674] sdhci: Sys addr: 0x80000008 | Version: 0x00003802
[ 2591.685745] sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000008
[ 2591.685785] sdhci: Argument: 0x003ea888 | Trn mode: 0x0000002b
[ 2591.685857] sdhci: Present: 0x01e80100 | Host ctl: 0x00000035
[ 2591.685897] sdhci: Power: 0x0000000b | Blk gap: 0x00000000
[ 2591.685967] sdhci: Wake-up: 0x00000000 | Clock: 0x00000007
[ 2591.686006] sdhci: Timeout: 0x0000000c | Int stat: 0x00000000
[ 2591.686077] sdhci: Int enab: 0x03ff800b | Sig enab: 0x03ff800b
[ 2591.686116] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
[ 2591.686186] sdhci: Caps: 0x642dc8b2 | Caps_1: 0x00008007
[ 2591.686257] sdhci: Cmd: 0x0000193a | Max curr: 0x00000000
[ 2591.686296] sdhci: Resp 1: 0x00000000 | Resp 0: 0x00000900
[ 2591.686367] sdhci: Resp 3: 0x00000900 | Resp 2: 0x00000000
[ 2591.686406] sdhci: Host ctl2: 0x00000003
[ 2591.686445] sdhci: ADMA Err: 0x00000003 | ADMA Ptr: 0x35a40008
[ 2591.686517] mmc1: clk: 200000000 clk-gated: 0 claimer: mmcqd/1 pwr: 10
[ 2591.686557] mmc1: rpmstatus[pltfm](runtime-suspend:usage_count:disable_depth)(0:0:0)
[ 2591.686629] sdhci: ===========================================
[ 2591.690787] mmcblk0: error -110 transferring data, sector 4106376, nr 8, cmd response 0x900, card status 0x100c02
[ 2591.690868] end_request: I/O error, dev mmcblk0, sector 4106376
[ 2591.690912] end_request: I/O error, dev mmcblk0, sector 4106376
[ 2591.691009] Aborting journal on device mmcblk0p28-8.
[ 2591.691995] journal commit I/O error
[ 2591.692242] done.
[ 2591.705472] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 2591.707353] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 2591.708900] Suspending console(s) (use no_console_suspend to debug)
[ 2591.785532] PM: suspend of devices complete after 74.713 msecs
[ 2591.786542] PM: late suspend of devices complete after 1.004 msecs
[ 2591.787851] PM: noirq suspend of devices complete after 1.302 msecs
[ 2591.788063] Disabling non-boot CPUs ...
[ 2591.788159] msm_pm_enter
[ 2591.788159] msm_pm_enter: power collapse
[ 2591.788159] msm_pm_enter: return
[ 2591.789882] PM: noirq resume of devices complete after 1.097 msecs
[ 2591.791208] PM: early resume of devices complete after 0.800 msecs
[ 2591.867621] PM: resume of devices complete after 76.407 msecs
[ 2591.869839] Restarting tasks ... done.
[ 2591.875706] EXT4-fs error (device mmcblk0p28): ext4_journal_start_sb:328: Detected aborted journal
[ 2591.875851] EXT4-fs (mmcblk0p28): Remounting filesystem read-only
[ 2591.876665] Kernel panic - not syncing: EXT4-fs panic from previous error
Click to expand...
Click to collapse

simms22 said:
looks ike an i/o error. it had trouble transferring data to a sector. i dont know what would have caused it. an app issue, a corrupted sector, whatever it was the phone doesnt like it.
id try running the phone without any installed apps for a day, see if it still reboots. if it doesnt, it was an app. if it still reboots, id wipe out the phone completely and flash the factory image. its also possible that a sector is corrupted somehow, or the data in it. a flash of the factory image should take care of it.
Click to expand...
Click to collapse
Thanks, the thing is though that it rebooted three times while laying on my nightstand this day, every time I checked to see what time it was it was on the sim lock screen. Now during the day with average use (only using whatsapp and all access) it hasn't rebooted a single time. If there was a way to ensure a reboot I seriously don't know how to. If a flash of the factory image would be the final step, it may be in my best interest to start with that immediately instead of trying one day without apps? As I sometimes don't register a single reboot in four days.

Niurez said:
Thanks, the thing is though that it rebooted three times while laying on my nightstand this day, every time I checked to see what time it was it was on the sim lock screen. Now during the day with average use (only using whatsapp and all access) it hasn't rebooted a single time. If there was a way to ensure a reboot I seriously don't know how to. If a flash of the factory image would be the final step, it may be in my best interest to start with that immediately instead of trying one day without apps? As I sometimes don't register a single reboot in four days.
Click to expand...
Click to collapse
i think a day without apps first would be best, at least it would tell us if it is an app or not. one time on my gnex, i started getting random reboots when there were none before. about 3 days worth of reboots had me confused. i was about to flash the factory img, but i remembered i installed an app the day before the reboots started. even though i only opened it one time since i installed it, i decided to try removing it first. so i removed it, and never had a random reboot on my gnex since.

simms22 said:
i think a day without apps first would be best, at least it would tell us if it is an app or not. one time on my gnex, i started getting random reboots when there were none before. about 3 days worth of reboots had me confused. i was about to flash the factory img, but i remembered i installed an app the day before the reboots started. even though i only opened it one time since i installed it, i decided to try removing it first. so i removed it, and never had a random reboot on my gnex since.
Click to expand...
Click to collapse
Oh ok, I'll try this as soon as I'm done with my finals monday since I still use whatsapp quite a lot to discuss studying material. I also only got like 5 apps. The only apps that aren't recognized worldwide might be "De Lijn" app, which I use to check the bus times and "MyMobistar" to check information about my provider. Could this also be because something is faulty in my phone itself and that the only resolution would be to RMA it?

Niurez said:
Oh ok, I'll try this as soon as I'm done with my finals monday since I still use whatsapp quite a lot to discuss studying material. I also only got like 5 apps. The only apps that aren't recognized worldwide might be "De Lijn" app, which I use to check the bus times and "MyMobistar" to check information about my provider. Could this also be because something is faulty in my phone itself and that the only resolution would be to RMA it?
Click to expand...
Click to collapse
its possible. if it still happens after flashing the factory img, and some time without any apps installed, then id say the phones hardware is faulty, and rma it.

simms22 said:
its possible. if it still happens after flashing the factory img, and some time without any apps installed, then id say the phones hardware is faulty, and rma it.
Click to expand...
Click to collapse
Ok, I'll keep you updated.
Much thanks.

Niurez said:
Ok, I'll keep you updated.
Much thanks.
Click to expand...
Click to collapse
Hi! I'm facing same problem as you: random reboots when not using the phone.
Even my bugreport shows something similar to yours.
Did you resolve it?

Related

[GPL][Kernel] 2.6.35 for HERC [AP #4/5]

Github:
I now consider this Release Candidate quality. Please do report issues (with logcats and dmesgs). Check the known bugs, etc, etc.
https://github.com/s0be/cm-kernel
the -amonra zip is for recoveries that don't take the FS type as the first argument of mount(...) If the regular zip fails complaining about missing files, try the -amonra version.
Latest official version:
no debug
http://heroc.s0be.com/HERC-2.6.35-AP-5.zip
http://heroc.s0be.com/HERC-2.6.35-AP-5-amonra.zip
Headset detection less broken. Now it always thinks there's a mic connected to anything plugged in.
http://heroc.s0be.com/HERC-2.6.35-AP-4.zip
http://heroc.s0be.com/HERC-2.6.35-AP-4-amonra.zip
If that download doesn't work for you, your OS likely has a broken ipv6 stack. Please check that you have ipv6 disabled if you don't actually have an ipv6 connection.
What works:
Ram console
Keypad
Screen
Touchscreen
GPS
Compass
G-Sensor
nand
Early Suspend
Bluetooth
Headset Detection
Camera
What Doesn't work or hasn't been tested:
Thanks to:
Elemag for the initial Hero 2.6.35 port, with Erasmux as a major contributor, Decadence for the 2.6.34/35 heroc board files, and riemervdzee for his pointers at fixes needed to get it working and his continued drive to get this kernel full featured and stable, and everyone they pulled from (Darch, Toast, Cyanogen, etc, etc). If I've forgotten anyone, please let me know the names to add.
See first post for current. This is just historic releases.
Headset detection fixed. Mic detection not working yet.
Weird audio program related crashes fixed
http://heroc.s0be.com/HERC-2.6.35-AP-3.zip
http://heroc.s0be.com/HERC-2.6.35-AP-3-amonra.zip
Rebased on Pershoot's G1 2.6.35.11 Kernel Tree
New base .config
BFS Disabled
Headset detection re-broken. Will be reviewing this currently.
http://heroc.s0be.com/HERC-2.6.35-AP-2.zip
http://heroc.s0be.com/HERC-2.6.35-AP-2-amonra.zip
Camera fix from JayBob via decad3nce
http://heroc.s0be.com/HERC-2.6.35-AP-1.zip
http://heroc.s0be.com/HERC-2.6.35-AP-1-amonra.zip
Pulls some changes from Decad3nce for the camera (still doesn't work) and some i2c speedups from riemervdzee
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-114.zip
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-114-amonra.zip
Fixes most of what I broke in 106
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-109.zip
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-109-amonra.zip
Disabled some ****
Changed some ****
This is an attempt to fix the power issues through voodoo
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-106.zip
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-106-amonra.zip
Fixed headset detection. Haven't figured out if the button works.
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-101.zip
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-101-amonra.zip
Went back to #55(never released) config
Disabled Debug
All updates from #56 still apply
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-57.zip
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-57-amonra.zip
Merged with upstream
Updated msm-camera
Updated msm-i2c
Ripped out a bunch of stuff, disabled debugging
This probably isn't going to be completely happy
This is definitely not happy...
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-56.zip
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-56-amonra.zip
Restored device mapper with crypt support. This may fix missing app issues
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-47.zip
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-47-amonra.zip
tun.ko Enabled - NOT TESTED AT ALL, PLEASE REPORT IF I GOT IT RIGHT
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-45.zip
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-45-amonra.zip
Enabled > 6912000 CPU speeds. Boots capped at 691 though
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-44.zip
Fix ramzswap/compcache
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-42-2.zip
h2w still broken
Camera almost works
Bluetooth is fixed
Touchscreen may not be problematic now.
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-42.zip
Merged MDP changes from upstream
Fixed h2w (I think) someone with a headset, try plugging it
Camera almost works on occasion. Can catch a preview frame now and then.
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-30.zip
Re-enabled netfilter modules
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-23.zip
changed the early_suspend.level value of the synaptics_i2c_rmi driver to match 2.6.29.
Last attempt til next week
still capped at 691200
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-18.zip
Clamped to 691200 max freq
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-17.zip
Maybe solved TS issues??? Testing now.
Fixed USB Mass Storage
Enabled PerfLock
CURRENT MAX IS AT 768000, throwing together a #14 with a 691200 cap.
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-13.zip
First alpha
http://heroc.s0be.com/HERC-2.6.35-sl0ppy_s0be-5.zip
what kind of performance increase will this bring? and will it be nice to have when we get a fully working GB rom?
Unfortunally the current .35 build for the Hero GSM version is slower than any .29 kernel.
But yeah, seems we have to reimplement a lot of optimalisations.
It is nice that we actually get something out of the HeroC though
riemervdzee said:
Unfortunally the current .35 build for the Hero GSM version is slower than any .29 kernel.
But yeah, seems we have to reimplement a lot of optimalisations.
It is nice that we actually get something out of the HeroC though
Click to expand...
Click to collapse
There are other advantages of course, we have to remember. Performance is king, but features are definitely queen. Getting to a recent kernel (2.6.29 is coming up on 2 years old), makes future updates to Heroc a lot easier. Going to up-to-date drivers may allow us to eliminate some of the binary cruft from the Heroc tree, etc, etc.
Two things I've tried:
1. In the xda "hero" dev forum, there was a post that there was a problem with the newer (>.34) yaffs2 code, and you needed to boot and wipe using a 1.7 RA recovery. So, I copied the yaffs2 code from deca's .29 kernel. It then oopsed at 1017 in msm_fb, which was the ifdef'd line for HERO.
2. So, I added "&& !defined(CONFIG_MACH_HEROC)" to line 1016. It then still rebooted, but last_kmsg was different after "vsync on gpio 97 now 0":
[ 3.626831] vsync on gpio 97 now 0
[ 3.632263] msmfb_probe() installing 320 x 480 panel
[ 3.640106] Registered led device: lcd-backlight
[ 3.650085] msm_serial: driver initialized
[ 3.654052] msm_serial_hs module loaded
[ 3.697570] loop: module loaded
[ 3.698760] pmem: 1 init
[ 3.702514] pmem_adsp: 0 init
[ 3.706420] pmem_camera: 0 init
[ 3.711578] Android kernel panic handler initialized (bind=kpanic)
[ 3.712524] AKM8973 compass driver: init
[ 3.718566] input: compass as /devices/virtual/input/input0
[ 3.731079] msm_nand: allocated dma buffer at ffa0a000, dma_addr 256fb000
[ 3.732696] msm_nand: read CFG0 = aa5400c0 CFG1 = 8744a
[ 3.733245] msm_nand: CFG0 cw/page=3 ud_sz=512 ecc_sz=10 spare_sz=4
[ 3.734069] msm_nand: NAND_READ_ID = 5501bcec
[ 3.735229] msn_nand: nandid 5501bcec status c03120
[ 3.735595] msm_nand: manuf Samsung (0xec) device 0xbc blocksz 20000 pagesz 800 size 20000000
[ 3.736114] msm_nand: save CFG0 = e85408c0 CFG1 = 4745e
[ 3.736419] msm_nand: CFG0: cw/page=3 ud_sz=516 ecc_sz=10 spare_sz=0 num_addr_cycles=5
[ 3.737121] msm_nand: DEV_CMD1: f00f3000
[ 3.737609] msm_nand: NAND_EBI2_ECC_BUF_CFG: 1ff
[ 3.738372] 6 cmdlinepart partitions found on MTD device msm_nand
[ 3.738708] Creating 6 MTD partitions on "msm_nand":
[ 3.739257] 0x00001ff60000-0x000020000000 : "misc"
[ 3.753509] 0x000002c60000-0x000003160000 : "recovery"
[ 3.776397] 0x000003160000-0x0000033e0000 : "boot"
[ 3.794219] 0x0000033e0000-0x000009be0000 : "system"
[ 4.070312] 0x000009be0000-0x000009fe0000 : "cache"
[ 4.098876] 0x000009fe0000-0x000020000000 : "userdata"
No errors detected
Don't know if this helps or not. BTW, I'm using Firerats's custom MTD partitions, so I modified the boot parameters.
dbayub said:
Two things I've tried:
1. In the xda "hero" dev forum, there was a post that there was a problem with the newer (>.34) yaffs2 code, and you needed to boot and wipe using a 1.7 RA recovery. So, I copied the yaffs2 code from deca's .29 kernel. It then oopsed at 1017 in msm_fb, which was the ifdef'd line for HERO.
2. So, I added "&& !defined(CONFIG_MACH_HEROC)" to line 1016. It then still rebooted, but last_kmsg was different after "vsync on gpio 97 now 0":
<SNIP>
Don't know if this helps or not. BTW, I'm using Firerats's custom MTD partitions, so I modified the boot parameters.
Click to expand...
Click to collapse
yeah, I had that fixed in my tree, forgot to commit the || -> && change I didn't do that yaffs2 change, but I just tested it with identical results.
Sweet. I'll spend more time on it this weekend. Swamped with homework atm.
Hopefully we'll have something super stable!
Decad3nce said:
Sweet. I'll spend more time on it this weekend. Swamped with homework atm.
Hopefully we'll have something super stable!
Click to expand...
Click to collapse
Made some more progress:
http://android.pastebin.com/AWysQDNk
s0be, i think you're going to blow up the hero scene again. with deca and you working together there's been a lot of progress recently and i want to thank both of you. i really love my hero and you guys keep it feeling young.
AND HOW!!!!!
Sent from my HERO200 using XDA App
jmkarnai01 said:
AND HOW!!!!!
Sent from my HERO200 using XDA App
Click to expand...
Click to collapse
More commits
More Progress
http://android.pastebin.com/rqm0Vn1p
You guys are pure AWESOME!
S0be, i was wondering your opinion, once this kernel is completed and we get GB running smoothly, will the supposed 2.4 GB update break everything that is already working or just maybe the new stuff will have to be worked in properly?
Pocker09 said:
S0be, i was wondering your opinion, once this kernel is completed and we get GB running smoothly, will the supposed 2.4 GB update break everything that is already working or just maybe the new stuff will have to be worked in properly?
Click to expand...
Click to collapse
no clue
http://android.pastebin.com/SSRM5MKB
Dang sobe making progress good work man. Thanks!!!!!!!!!!!"!
Sent from my HTC Hero CDMA using XDA App
oostah said:
Dang sobe making progress good work man. Thanks!!!!!!!!!!!"!
Sent from my HTC Hero CDMA using XDA App
Click to expand...
Click to collapse
http://android.pastebin.com/qKr6wEtY
Some more progress, looks like just the smd and i2c errors are left to fix
Looking forward to this. And wow you work like super man lol but thank for the time and hard work.
Root-Hack-Mod-Always™
Just curious, will you guys be running AOSP's GB or will this kernel allow for a less tweaked version of GB? Thanks! Great Job!
The smd stuff is because it used to call both v1 and v2 alloc, and as long as one succeeded, it was OK. Now it's ifdef'd to use different code depending on if CONFIG_MSM_SMD_PKG3 is set or not. Looks like the package 4 code is what works on heroc. With that change, the smd code works.
[ 3.684967] smd_alloc_channel() cid=01 size=08192 'SMD_DIAG'
[ 3.686340] smd_alloc_channel() cid=02 size=08192 'SMD_RPCCALL'
etc. Then it's the i2c failures:
[ 3.841674] msm_i2c msm_i2c.0: Error during data xfer 1e (-5)
[ 3.852203] msm_i2c msm_i2c.0: error, status 63c8
and oops:
[ 4.861785] Internal error: Oops: 80000005 [#1] PREEMPT
[ 4.863433] last sysfs file:
[ 4.864318] Modules linked in:
[ 4.866058] CPU: 0 Not tainted (2.6.35.10-cyanogenmod #11)
[ 4.867706] PC is at 0x0
[ 4.868682] LR is at microp_i2c_probe+0xb70/0x1438
[ 4.869598] pc : [<00000000>] lr : [<c0217e64>] psr: 60000013
[ 4.869659] sp : cc219e10 ip : cc219d10 fp : cc219e74
[ 4.872100] r10: c040eef4 r9 : 00000000 r8 : 00000005
[ 4.873748] r7 : cc255da0 r6 : c040ea10 r5 : cc255d80 r4 : cc48a760
[ 4.874694] r3 : c040ea2c r2 : 00000002 r1 : cc219ce0 r0 : cc219e3c
[ 4.876342] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel

Broken phone? Extremely bizarre problems

My Desire S broke a few days ago. At first, it didn't boot - it vibrates seven times on the HTC logo, and stops there. Nothing works at that point, not even holding power and volume buttons to reset. As far as I can tell, there's nothing to do except pull the battery, which I know is a bad idea... but there's no other choice.
Other times, it ends up on the Android boot animation, and stays there forever.
Other times, it actually boots up, usually with the date set to Jan 6th 1980. When it does, it's partially usable - browsing, playing music, playing games all mostly works.
It ran stability test for 1.5 hours without "errors", but a ton of background apps crashed during that run (especially the keyboard, which of course wasn't actually used at all). Max temp ~37 C.
Now, here comes the weird stuff... No changes are saved between reboots, none at all. I get absolutely no errors about write protection, write errors etc. - but if I change a text file, complete a level in a game (that always saves automatically), etc. - and reboot - I'm back where I was.
On every boot, the GPS is on, and it asks about allowing Google location tracking. Every time.
However, that's not even the most bizarre thing... I figured I would try a full wipe and new ROM, just in case it actually IS a software problem/FS corruption (which I've doubted all along, but still). So, I backed it up with nandroid - first backup failed... Weird. I tried again after a reboot, and it worked.
I then wiped /data and /cache manually - no errors, installed the ROM which wiped /system as well - no errors here, either!
I boot it up... and I'm STILL BACK ON THE OLD ROM! What the hell?!?! Everything is EXACTLY as it was before, with the GPS question, the icons, my notes, my game progress... Not ONE difference, despite an apparently successful wipe. I kid you not.
Now, obviously, the wipe failed on some level, but why would it report success when it clearly didn't actually write the changes to flash?!
S-OFF via Revolutionary. HBOOT-6.98.1002, RADIO-38.03.02.11_M - both of which I've flashed exactly once, when rooting, back when I got the phone.
CWM Touch 5.8.1.5 - I've had that since at least 2-3 months, no problems.
Any ideas? I'm out of warranty (second-hand phone), and I assume I'll need to buy a replacement... Even then, I'd prefer an explanation of what the heck is going on here!
Edit: Yep... I opened a shell (via adb), created a file in /data, sync'ed and rebooted. It's gone.
BTW, I get "permission denied" to even ls in /data when I'm not root... Is that normal? I expect the answer is no...?
RUU is the best solution for me.
Sent from my HTC Desire S using xda app-developers app
Your description of the problem sounds like a broken chip. Well I can't be 100% sure but the same problems occur when a hard drive is failing. Maybe /proc/last_kmsg can report these kind of errors.
Sent from my Desire S using xda app-developers app
[ 6.944305] EXT4-fs (mmcblk0p27): warning: mounting fs with errors, running e2fsck is recommended
[ 6.950500] EXT4-fs (mmcblk0p27): recovery complete
Hmm, I wonder if that's a one-off. How do you even fsck the internal partitions? I'd have no problems doing that on a computer, but...
Also, there's this (repeated a few times):
[ 605.030731] INFO: task krmt_storagecln:467 blocked for more than 120 seconds.
[ 605.031433] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 605.032135] krmt_storagecln D c0444614 0 467 2 0x00000000
[ 605.033203] Backtrace:
[ 605.033966] [<c0444218>] (schedule+0x0/0x490) from [<c0040e50>] (rpc_clients_cb_thread+0x98/0x1b0)
[ 605.034729] [<c0040db8>] (rpc_clients_cb_thread+0x0/0x1b0) from [<c00a2bf0>] (kthread+0x84/0x8c)
[ 605.035461] [<c00a2b6c>] (kthread+0x0/0x8c) from [<c008f4e4>] (do_exit+0x0/0x69c)
[ 605.036193] r7:00000013 r6:c008f4e4 r5:c00a2b6c r4:e5c27df0
[ 605.037963] INFO: task voice:750 blocked for more than 120 seconds.
[ 605.038665] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 605.039062] voice D c0444614 0 750 2 0x00000000
[ 605.040527] Backtrace:
[ 605.041259] [<c0444218>] (schedule+0x0/0x490) from [<c0444d60>] (schedule_timeout+0x24/0x23c)
[ 605.041992] [<c0444d3c>] (schedule_timeout+0x0/0x23c) from [<c0444b70>] (wait_for_common+0x11c/0x1dc)
[ 605.042694] r7:e4920000 r6:00000002 r5:c061a6f0 r4:7fffffff
[ 605.044464] [<c0444a54>] (wait_for_common+0x0/0x1dc) from [<c0444d10>] (wait_for_completion+0x1c/0x20)
[ 605.045196] [<c0444cf4>] (wait_for_completion+0x0/0x20) from [<c0051118>] (voice_thread+0x6c/0x574)
[ 605.045928] [<c00510ac>] (voice_thread+0x0/0x574) from [<c00a2bf0>] (kthread+0x84/0x8c)
[ 605.046661] [<c00a2b6c>] (kthread+0x0/0x8c) from [<c008f4e4>] (do_exit+0x0/0x69c)
[ 605.047058] r7:00000013 r6:c008f4e4 r5:c00a2b6c r4:e5c27f28
Click to expand...
Click to collapse
Not good...
... I ran fsck, and it didn't look good. Tons of errors on /system, even though I ran it multiple times. (e2fsck -fyv)
Something's pretty effed up.
Doesn't seem encouraging ! I'm not a kernel hacker so I can't provide much help for the messages. I would not recommend formatting either as if you have a chip hardware problem you will end up with a bricked phone.
Sent from my Desire S using xda app-developers app

[ROOT][SECURITY] Root exploit on Exynos

EDIT: For general discussion about this topic, please post in the following location (and not here): http://forum.xda-developers.com/showthread.php?t=2057818
Now find a one-click root application at http://forum.xda-developers.com/showthread.php?t=2130276. More exploits coming.
Hi,
Recently discover a way to obtain root on S3 without ODIN flashing.
The security hole is in kernel, exactly with the device /dev/exynos-mem.
This device is R/W by all users and give access to all physical memory ... what's wrong with Samsung ?
Its like /dev/mem but for all.
Three libraries seems to use /dev/exynos-mem:
/system/lib/hw/camera.smdk4x12.so
/system/lib/hw/gralloc.smdk4x12.so
/system/lib/libhdmi.so
Many devices are concerned :
Samsung Galaxy S2
Samsung Galxy Note 2
MEIZU MX
potentialy all devices who embed exynos processor (4210 and 4412) which use Samsung kernel sources.
The good news is we can easily obtain root on these devices and the bad is there is no control over it.
Ram dump, kernel code injection and others could be possible via app installation from Play Store. It certainly exists many ways
to do that but Samsung give an easy way to exploit. This security hole is dangerous and expose phone to malicious apps.
Exploitation with native C and JNI could be easily feasible.
Edited
Some details :
/dev/exynos-mem seems to be used for graphic usage like camera, graphic memory allocation, hdmi.
By activating pid display in kmsg, surfaceflinger do mmap on the device (via one of the three shared libraries above ?? I have not see reference in binary to these libraires)
The operations allowed on the device are (from linux/drivers/char/mem.c) :
Code:
static const struct file_operations exynos_mem_fops = {
.open = exynos_mem_open,
.release = exynos_mem_release,
.unlocked_ioctl = exynos_mem_ioctl,
.mmap = exynos_mem_mmap,
}
and the default permissions (from linux/drivers/char/mem.c) :
Code:
#ifdef CONFIG_EXYNOS_MEM
[14] = {"exynos-mem", S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH
| S_IWOTH, &exynos_mem_fops},
#endif
ioctl request on /dev/exynos-mem permit to clean / flush L1 and L2 cache, set non cacheable page memory and set physical memory address for use with mmap.
Now the interesting part : mmap operation.
The only limit is to restrict access to lowmem (from linux/drivers/char/exynos-mem.c) :
Code:
/* TODO: currently lowmem is only avaiable */
if ((phys_to_virt(start) < (void *)PAGE_OFFSET) ||
(phys_to_virt(start) >= high_memory)) {
pr_err("[%s] invalid paddr(0x%08x)\n", __func__, start);
return -EINVAL;
}
The comment in above code could be frightening.
And an eye in Documentation/arm/memory.txt say :
Code:
Start End Use
--------------------------------------------------------------------------
PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region.
This maps the platforms RAM, and typically
maps all platform RAM in a 1:1 relationship.
In other words, this device only permit to own the physical memory including kernel code.
The question is why permissions are set to read/write for all in kernel AND in ueventd.smdk4x12.rc:
samsung developper in charge of this would lose his job
some samsung apps with basic rights need to access it (I doubt it)
a huge mistake
A simple patch could be to set permissions to 0660 or 0600 in ueventd.smdk4x12.rc, but I don't know how it would affect samsung applications/services.
In attachment, binary and source to obtain for root shell.
Removing either read or write permissions will kill the camera. I didn't see any other deterioration in anything else.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
My guess the best fix would be to limit the access to the DMA memory spaces which this thing actually needs, the definition of the different CMA areas are in /arch/arm/mach-exynos/mach-midas.c for the S3 and N2.
Front camera for example:
Code:
#ifndef CONFIG_USE_FIMC_CMA
{
.name = "fimc1",
.size = CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1 * SZ_1K,
#if defined(CONFIG_MACH_GC1)
.start = 0x5ec00000,
#else
.start = 0x65c00000,
#endif
},
#endif
Generally all memory areas allocated through s5p_cma_region_reserve in /arch/arm/plat-s5p/reserve_mem.c would be treated as exceptions and everything else needs to be blocked.
Update: Low-level kernel fix for developers posted here.
A kernel based fix as I posted above is the only method to fix the security hole while also not breaking the camera. In all other cases if you are not able or willing to flash a kernel, use Chainfire's application.
Very interesting. Thanks for bringing that up. (Have also flagged some Samsung engineers to read this)
Also, I'm building an APK for this to make it easy.
EDIT: APK posted here: http://forum.xda-developers.com/showthread.php?t=2050297, download, install, run, and your device is rooted with SuperSU.
EDIT#2: This app now also lets you disable the exploit
@alephzain thanks for sharing the source code of the exploit: short, elegant, efficient, to me that's art
Your short documentation and clean writing style even made easier to learn from it.
Hey curio,
No need, here is a very quickly put together app in 5 mins that lets you toggle on/off world writability to /dev/exynos-mem
So you can toggle the fix off if you want to use the camera, then toggle it back on afterwards.
Github source: https://github.com/Ryan-ZA/exynosfix
APK Download: https://github.com/Ryan-ZA/exynosfix/raw/master/exynosfix.apk
Ryan
MOD EDIT: Removed attached download, as it is out of date compared to the linked download
jcase said:
Please explain how this is a remote exploit? This looks entirely local to me. Vulns happen, every vendor gets hit with them. Google does, Apple does Motorola does, HTC does, LG does, Samsung does, ASUS does, Nvidia, Qualcomm etc etc, it is all part of the game. Hell go look at the recent qualcomm disclosures, almost every qualcomm since 2009, wide open! Sh*t happens. Any device with root on it, be it exploit or whatever is open to permanent damage from malicious, want to nuke an htc with root? dd if=/dev/zero of=/dev/block/mmcblk0p4. Pantech/LG/Mostqualcoms hit all the bootloaders. Hell system user is enough on LG phones, and most other brands to brick them.
I'm not sure about rewards, but I have reported vulns and bugs to every major vendor, and the only three who ever respond to me are Google, Samsung and Motorola. All three respond promptly and polite, and occasionally follow up if requested. Vendor not getting back to you? [email protected] is quite good at getting them to respond, just tell them the vendor is not responding. More than once they have gotten a dialog with a vendor opened with me.
Understanding update timelines is another issue, vendor updates generally have to go through development, QA at the vendor (sent back if major issues found), then in the case of Sprint and other carriers, sent to carrier QA (returned to OEM if major issues found) . Major changes to the radio? Yep off to the FCC as well! Updates can take considerable time. Not excusing the "superbrick" bug, just pointing out a few weeks (or in the case of sprint or Vernon a few months) can be expected. Want faster updates? Buy an international device, and get a GSM carrier.
Click to expand...
Click to collapse
OK, we're getting into technicalities here, but I consider anything that can be exploited by a Market app without explicit user intervention beyond installing an app (reboot cycles, ADB, etc.) to be "remote". Adam covered how easy it is to bypass Bouncer at BABBQ, so relying on that is a bad idea.
Prior to this, all exploits (restoreRoot, mempodroid, etc) for ICS on Exynos4 devices required ADB to be involved. This doesn't.
And no, you can't cause permanent damage to an HTC with root. The example you provided isn't permanent damage, it can be repaired via JTAG at a service center. Superbrick is *permanent unrecoverable damage that requires a motherboard replacement - JTAG cannot bring a device that has been damaged back to operation*. That's a difference between 0 material costs and maybe 30 minutes of labor to repair at a service center and $200-300+ in material costs and significantly more labor.
And your "updates take considerable time" is bull****. Sprint FI27 was built on September 27 (check the kernel build date), 3 weeks after Samsung had the final version of their protection patch, and was deployed on Kies a matter of *days* later. They had an update scheduled, a patch ready to go for three weeks before the update was built, and they shipped without the patch. There's no excuse for that. At that time, it was an "open source problem" because it only affected custom firmwares, and any root exploits known required ADB. Their approach was dependent on an assumption that *an exploit like this would never happen* - which is a horrible assumption.
This exploit changes things - there is no a root exploit that can be used by an app straight from the market, in the background, with little to no user intervention.
As to the negative effects of 600 permissions on operation (such as killing camera) - as an interim, setting things to 660 instead of 666 makes things somewhat better protected but not as protected as they should be. I will run some tests later today to confirm that at least any old APK can't get privilege elevation if things are set so only the graphics group can diddle with the memory regions.
RyanZA said:
Hey curio,
No need, here is a very quickly put together app in 5 mins that lets you toggle on/off world writability to /dev/exynos-mem
So you can toggle the fix off if you want to use the camera, then toggle it back on afterwards. Will update this post shortly with github source.
Ryan
Click to expand...
Click to collapse
Yes what I also started writing allows to restore permissions on /dev/exynos-mem in case you need to use camera, I agree its useful!
fards said:
Camera is insisting on 666 on some builds.
Curious how some devices using same base code are using camera with diff permissions.
Neither my N7000 or N 8010 will play nicely with 600 or 660..
Click to expand...
Click to collapse
The assumption of similar base code isn't a good one... You'd be shocked how many deltas there are between I9100/I777/N7000 stock firmware codebases that shouldn't be there given how similar the devices are.
In the region of the system we're dealing with here (graphics memory allocation), there are significant differences in operation between Exynos 4210 and 4412. There are also significant deltas between the implementations in all of Samsung Mobile's devices and the official public reference source, and frequently deltas between Samsung's implementations for various handsets/tablets that shouldn't be there as you've discovered.
For example, the official reference source does allocations from FIMC1 memory regions in gralloc to support various graphics items. Nearly all of Mobile's implementations allocate ION memory instead of FIMC1 memory even when FIMC1 memory is requested (and yes, this change affects camera operation more than anything else.)
Thanks for the headsup on N80xx, I'll def. have to do a rebuild on N8013. It's pretty frequent for us to have brokenness that doesn't exist on I9300 and vice versa.
Hmm, odd... even when chmodded 660 system.graphics, the exploit appears to succeed on CM10.1 from within an ADB shell...
I need to look more closely at this.
Seems like the shell user is a member of the graphics group...
I think AndreiLux's approach he's working on may be the best.
Has anyone tested to see what the effect of 0600 is on hwaccel video playback? (Seems to be none on CM10.1).
Looks like it's anything that wants FIMC memory that needs exynos-mem, I'll double check ION, that should have failed...
Edit: Yeah, gralloc only accesses exynos-mem when attempting to access FIMC1 memory. I think camera is the main other place where FIMC is used. Actually, in any shipped handset, gralloc should never actually access exynos-mem - gralloc will give ION memory when you ask it for FIMC1 memory, and ION memory allocation doesn't use exynos-mem (hmm, unless libsecion does... I need to check that...)
Entropy512 said:
Hmm, odd... even when chmodded 660 system.graphics, the exploit appears to succeed on CM10.1 from within an ADB shell...
I need to look more closely at this.
Seems like the shell user is a member of the graphics group...
I think AndreiLux's approach he's working on may be the best.
Click to expand...
Click to collapse
Because your shell is in graphics group.
supercurio said:
Because your shell is in graphics group.
Click to expand...
Click to collapse
I was beginning to suspect that, thanks for confirming.
dennis.l said:
if this is a Samsung kernel issue would any of the custom kernel have the same flaws? otherwise would I be able to workaround the problem by installing a CM10 ROM instead of stock?
Click to expand...
Click to collapse
Right now older custom kernels will. CM's codebase was just patched earlier today to restrict that node to system.graphics 0660
It was done in the 10.1 branch, so it won't immediately affect all devices. We're working on transitioning all exynos4 devices over to 10.1 this week - it's about halfway done.
@alephzain, when running the exploit in an adb shell, sometimes the privilege escalation fails with:
Code:
[*] s_show->seq_printf format string found at: 0xC07A70A8
[*] sys_setresuid found at 0xC00945A0
[*] patching sys_setresuid at 0xC00945E4
[!] set user root failed: Operation not permitted
And it typically succeed after 1 or 2 more attempts.
Does it ring a bell?
ExynosAbuse APK updated to v1.10
I've just updated the ExynosAbuse APK to v1.10 !
This version allows you to disable the exploit (which may break camera), re-enable the exploit (if you need the camera) and to disable the exploit at boot (before any Android app runs). These options do require root (SuperSU or Superuser) to be installed as well. This is for people who actually *want* root. If you don't want root, you should use Supercurio's solution as it doesn't depend on being rooted it for dis/reenabling the exploit.
http://forum.xda-developers.com/showthread.php?t=2050297
Voodoo Instant fix for Exynos Mem Abuse vulnerability released.
I'm glad I have a blog, because things tend to disappear here ^^
Edit: Please use the following thread to discuss this specific solution: http://forum.xda-developers.com/showthread.php?t=2051290
RyanZA said:
Hey curio,
No need, here is a very quickly put together app in 5 mins that lets you toggle on/off world writability to /dev/exynos-mem
So you can toggle the fix off if you want to use the camera, then toggle it back on afterwards.
Github source: https://github.com/Ryan-ZA/exynosfix
APK Download: https://github.com/Ryan-ZA/exynosfix/raw/master/exynosfix.apk
Ryan
Click to expand...
Click to collapse
As per requests, I added in 'fix vulnerability on boot' functionality for those who like an open source fix.
Nice work on that app, curio.
Sooooo....
Here's a low-level fix for the kernel.
Source @ https://github.com/AndreiLux/Perseus-S3/commit/fb36195dab87e002721c7d1a8294a400c6b40a71
Edit: Follow-up commit for Note 2 (Possibly N8000 too) users @ https://github.com/AndreiLux/Perseus-S3/commit/81c95f6046880be48ef377ebae4e42c791f0813e
I did what I said in the first post. The mmap function checks the given memory addresses against all of the current CMA memory spaces on the device and denies access if the space it out of bound of any of the defined blocks. Furthermore on my S3 I, for now, couldn't find anything breaking beyond the main camera. So I added an additional condition that checks that the accessed memory block is "s3c-fimc" (The camera DMA block) and ignores the other blocks. The whole thing is totally neutered if CONFIG_CMA_DMA isn't used in the device configuration (Note 2 / Exynos 4412 devices with 2GB RAM). Edit: Fix works now the same for all devices.
Defined memory spaces:
Code:
[ 0.000000] c0 cma: CMA: reserved 16 MiB at 65800000
[ 0.000000] c0 [cma_region_descriptor_add] adding [s3c-fimc] (0x65800000)-(0x00f00000)
[ 0.000000] c0 cma: CMA: reserved 40 MiB at 5c800000
[ 0.000000] c0 [cma_region_descriptor_add] adding [s3c-mfc] (0x5c800000)-(0x02800000)
....
....
[ 0.000000] c0 S5P/CMA: Reserved 0x70000000/0x00a00000 for 'fimc_is'
[ 0.000000] c0 [cma_region_descriptor_add] adding [fimc_is] (0x70000000)-(0x00a00000)
[ 0.000000] c0 S5P/CMA: Reserved 0x71700000/0x00800000 for 'fimd'
[ 0.000000] c0 [cma_region_descriptor_add] adding [fimd] (0x71700000)-(0x00800000)
[ 0.000000] c0 S5P/CMA: Reserved 0x6c300000/0x03d00000 for 'fimc0'
[ 0.000000] c0 [cma_region_descriptor_add] adding [fimc0] (0x6c300000)-(0x03d00000)
[ 0.000000] c0 S5P/CMA: Reserved 0x71600000/0x00100000 for 'srp'
[ 0.000000] c0 [cma_region_descriptor_add] adding [srp] (0x71600000)-(0x00100000)
[ 0.000000] c0 [cma_region_descriptor_add] adding [mfc-normal] (0x64000000)-(0x00400000)
[ 0.000000] c0 S5P/CMA: Reserved 0x64000000/0x00400000 for 'mfc-normal'
[ 0.000000] c0 [cma_region_descriptor_add] adding [mfc-normal] (0x64000000)-(0x00400000)
[ 0.000000] c0 S5P/CMA: Reserving 0x6800000 for secure region aligned by 0x4000000.
[ 0.000000] c0 S5P/CMA: Reserved 0x5c000000/0x06800000 for 'secure_region'
[ 0.000000] c0 S5P/CMA: Reserved 0x5c000000/0x00800000 for 'sectbl'
[ 0.000000] c0 [cma_region_descriptor_add] adding [sectbl] (0x5c000000)-(0x00800000)
[ 0.000000] c0 S5P/CMA: Reserved 0x5c100000/0x03100000 for 'mfc-secure'
[ 0.000000] c0 [cma_region_descriptor_add] adding [mfc-secure] (0x5c100000)-(0x03100000)
[ 0.000000] c0 S5P/CMA: Reserved 0x5f200000/0x02f00000 for 'ion'
[ 0.000000] c0 [cma_region_descriptor_add] adding [ion] (0x5f200000)-(0x02f00000)
Running the exploit:
Code:
[email protected]:/ $ export PATH=/data/local/bin:$PATH
[email protected]:/ $ ./exynos-abuse
[!] Error mmap: Invalid argument|00000004
Behind the scenes during that:
Code:
[ 119.290791] c1 [exynos_mem_open:50] private_data(0xd0340b80)
[ 119.290889] c1 [exynos_mem_mmap] requesting access to (0x40000000)-(0x41000000)
[ 119.290960] c1 [exynos_mem_mmap] Checking space paddr(0x65800000)-(0x66700000) from 's3c-fimc'
[ 119.291046] c1 [exynos_mem_mmap] Checking space paddr(0x5c800000)-(0x5f000000) from 's3c-mfc'
[ 119.291299] c1 [exynos_mem_mmap] Checking space paddr(0x70000000)-(0x70a00000) from 'fimc_is'
[ 119.291386] c1 [exynos_mem_mmap] Checking space paddr(0x71700000)-(0x71f00000) from 'fimd'
[ 119.291465] c1 [exynos_mem_mmap] Checking space paddr(0x6c300000)-(0x70000000) from 'fimc0'
[ 119.291545] c1 [exynos_mem_mmap] Checking space paddr(0x71600000)-(0x71700000) from 'srp'
[ 119.291631] c1 [exynos_mem_mmap] Checking space paddr(0x64000000)-(0x64400000) from 'mfc-normal'
[ 119.291711] c1 [exynos_mem_mmap] Checking space paddr(0x64000000)-(0x64400000) from 'mfc-normal'
[ 119.291801] c1 [exynos_mem_mmap] Checking space paddr(0x5c000000)-(0x5c800000) from 'sectbl'
[ 119.291888] c1 [exynos_mem_mmap] Checking space paddr(0x5c100000)-(0x5f200000) from 'mfc-secure'
[ 119.291967] c1 [exynos_mem_mmap] Checking space paddr(0x5f200000)-(0x62100000) from 'ion'
[ 119.292034] c1 [exynos_mem_mmap] invalid paddr(0x40000000)-(0x41000000), accessing outside of DMA spaces
[ 119.292798] c1 [exynos_mem_release:58] private_data(0xd0340b80)
I didn't care about the permissions set to the sysfs interface as they don't matter anymore.
I'll be deploying the fix tomorrow throughout my kernels.
The only things that needs to be checked by then is if something else breaks, as HDMI or so. I can't test any of that since I don't have a dongle. In that case anyway the kernel log will tell you what other memory space is accessed and I can open that one up too if needed.
Note: Galaxy S2 / 4210 developers may have to add cma_region_descriptor_add calls to from wherever the memory blocks are defined (Machine file definition or arch/arm/plat-s5p/reserve_mem.c). My commit will work as is on S3 and N2 sources.
I'm off to bed.
Chainfire said:
and to disable the exploit at boot (before any Android app runs).
Click to expand...
Click to collapse
supercurio said:
Cannot protect efficiently against some potential attacks (typically, on boot).
Click to expand...
Click to collapse
First, thank you both for the hard work and quick release.
The main question here is, how efficient is the current implementation in both applications, regarding the protection at start up?
As long as I understand Chainfire somehow ensures that the fix will be applied before running any other (normal) application. Is it possible to install a new application, which to put itself on top of execution chain and exploit the hole, before your application is able to do a 0600 chmod?
If I understand correctly the supercurio's app doesn't promise anything on that matter?! If that is the case, then I guess the recommended app (for rooted phones) will be the Chainfire's solution, right?
julandroid said:
First, thank you both for the hard work and quick release.
The main question here is, how efficient is the current implementation in both applications, regarding the protection at start up?
As long as I understand Chainfire somehow ensures that the fix will be applied before running any other (normal) application. Is it possible to install a new application, which to put itself on top of execution chain and exploit the hole, before your application is able to do a 0600 chmod?
If I understand correctly the supercurio's app doesn't promise anything on that matter?! If that is the case, then I guess the recommended app (for rooted phones) will be the Chainfire's solution, right?
Click to expand...
Click to collapse
Correct.
At the moment, Supercurio's method relies on Android starting it at boot, using the same method any Android app uses to launch at boot. There is no guaranteed order of these apps being launched, and as such, a malicious app could be executing malicious code before the exploit is disabled.
RyanZA's method relies on the same mechanism as well and as such is still vulnerable. Furthermore, unlike Supercurio's and my own patch, RyanZA's patch chmod's to 0600 while ours chmod to 0400 or 0000. With 0600, system user can still run the exploit, so chaining a half-exploit that only gives system user followed by ExynosAbuse may still grant an attacker root access.
My method requires proper root and modifies /system, and disabling the exploit is done before any normal Android app (like those installed from the Play store) have a chance to execute their code. As long as you tell my app to disable the exploit at boot before you install a malicious app, and providing you do not grant a malicious app root (through SuperSU), this should protect against any exploit. Also note that after enabling applying the patch at boot, you can unroot in SuperSU again (SuperSU --> Settings --> Full Unroot) and the patch will keep working, but you'll be unrooted again (if you don't want root). On some devices it takes a reboot for SuperSU to truly disappear after that, by the way.
With my patch, I do advise testing the exploit was disabled after a reboot by running ExynosAbuse again, and verifying both checkboxes next to "Disable exploit" and "Disable exploit on boot" are enabled. These auto-detect the current state, and if the patch on boot was succesful both will be checked.
Chainfire said:
Correct.
At the moment, Supercurio's method relies on Android starting it at boot, using the same method any Android app uses to launch at boot. There is no guaranteed order of these apps being launched, and as such, a malicious app could be executing malicious code before the exploit is disabled.
RyanZA's method relies on the same mechanism as well and as such is still vulnerable. Furthermore, unlike Supercurio's and my own patch, RyanZA's patch chmod's to 0600 while ours chmod to 0400. With 0600, system user can still run the exploit, so chaining a half-exploit that only gives system user followed by ExynosAbuse may still grant an attacker root access.
My method requires proper root and modifies /system, and disabling the exploit is done before any normal Android app (like those installed from the Play store) have a chance to execute their code. As long as you tell my app to disable the exploit at boot before you install a malicious app, and providing you do not grant a malicious app root (through SuperSU), this should protect against any exploit. Also note that after enabling applying the patch at boot, you can unroot in SuperSU again (SuperSU --> Settings --> Full Unroot) and the patch will keep working, but you'll be unrooted again (if you don't want root). On some devices it takes a reboot for SuperSU to truly disappear after that, by the way.
With my patch, I do advise testing the exploit was disabled after a reboot by running ExynosAbuse again, and verifying both checkboxes next to "Disable exploit" and "Disable exploit on boot" are enabled. These auto-detect the current state, and if the patch on boot was succesful both will be checked.
Click to expand...
Click to collapse
As a preliminary quick-fix the chmod could also be handled in ramfs to ensure it's applied as soon as possible in the boot process.
By the way chmodding to 600 didn't brake any of both cameras on a Samsung 4.1.2 based ROM using the old libs with an update 6 kernel on my dev. S3. Will check if it's also behaving like this on 4.1.1 later today.
JP.
Sent from my custom Paranoid Android 2.54 / Yank555.lu CM10 kernel v1.3b Aroma (Linux 3.0.56) powered Galaxy S3 i9300 using Tapatalk 2
Yank555 said:
As a preliminary quick-fix the chmod could also be handled in ramfs to ensure it's applied as soon as possible in the boot process.
By the way chmodding to 600 didn't brake any of both cameras on a Samsung 4.1.2 based ROM using the old libs with an update 6 kernel on my dev. S3. Will check if it's also behaving like this on 4.1.1 later today.
Click to expand...
Click to collapse
Correct. Modifying it in initramfs would be even quicker, but a generic app can't do that. Also chmod to 0400, not 0600.

Trim not supported

I run CROMI-X 4.6.9 with hundsbuah 3.0.6 Kernel with Data2SD mod. I tried to run premium version of LagFix and it said that Trim is not supported on any partition. It always worked perfectly fine, so what is wrong?
Arquiteto said:
I run CROMI-X 4.6.9 with hundsbuah 3.0.6 Kernel with Data2SD mod. I tried to run premium version of LagFix and it said that Trim is not supported on any partition. It always worked perfectly fine, so what is wrong?
Click to expand...
Click to collapse
No idea I run Lagfix fine on CROMi-X. I haven't tried it on hunds but I will now and let you know.
sbdags said:
No idea I run Lagfix fine on CROMi-X. I haven't tried it on hunds but I will now and let you know.
Click to expand...
Click to collapse
Well. This is not a kernel issue. I flashed _that3 kernel and tried it, then I went back to hunds - both time when I run LagFix my tf700 rebooted. After reboot I tried again and then got "TRIM not supported by \cache, \data partition". Might this be problem with ext2 partition of my MicroSD?
Arquiteto said:
Well. This is not a kernel issue. I flashed _that3 kernel and tried it, then I went back to hunds - both time when I run LagFix my tf700 rebooted. After reboot I tried again and then got "TRIM not supported by \cache, \data partition". Might this be problem with ext2 partition of my MicroSD?
Click to expand...
Click to collapse
Just ran it on hunds and that v4 and it worked fine on both so something else is causing the conflict and the reboot. Grab the last_kmsg from /proc directly after such a reboot and post it so we can see what it was doing when it rebooted.
Well, I'm surprised too as it always worked for me.
Code:
[ 2281.200283] EXT4-fs error (device mmcblk1p2): ext4_mb_generate_buddy:738: group 106, 32253 blocks in bitmap, 32254 in gd
[ 2281.200715] Kernel panic - not syncing: EXT4-fs (device mmcblk1p2): panic forced after error
[ 2281.200728]
[ 2281.201185] [<c00182dc>] (unwind_backtrace+0x0/0x144) from [<c096ec68>] (dump_stack+0x20/0x24)
[ 2281.201475] [<c096ec68>] (dump_stack+0x20/0x24) from [<c0970f28>] (panic+0x94/0x1c4)
[ 2281.201780] [<c0970f28>] (panic+0x94/0x1c4) from [<c023ae7c>] (ext4_handle_error.part.115+0x70/0xa8)
[ 2281.202071] [<c023ae7c>] (ext4_handle_error.part.115+0x70/0xa8) from [<c023c744>] (__ext4_grp_locked_error+0xe4/0x1d8)
[ 2281.202359] [<c023c744>] (__ext4_grp_locked_error+0xe4/0x1d8) from [<c024eeb8>] (ext4_mb_generate_buddy+0x140/0x290)
[ 2281.202526] [<c024eeb8>] (ext4_mb_generate_buddy+0x140/0x290) from [<c02519e4>] (ext4_mb_init_cache+0x85c/0xc68)
[ 2281.202805] [<c02519e4>] (ext4_mb_init_cache+0x85c/0xc68) from [<c0251ecc>] (ext4_mb_init_group+0xdc/0x108)
[ 2281.203085] [<c0251ecc>] (ext4_mb_init_group+0xdc/0x108) from [<c02587a8>] (ext4_trim_fs+0x31c/0x330)
[ 2281.203373] [<c02587a8>] (ext4_trim_fs+0x31c/0x330) from [<c0227740>] (ext4_ioctl+0x5f0/0x86c)
[ 2281.203664] [<c0227740>] (ext4_ioctl+0x5f0/0x86c) from [<c018759c>] (do_vfs_ioctl+0x8c/0x2e0)
[ 2281.203943] [<c018759c>] (do_vfs_ioctl+0x8c/0x2e0) from [<c0187838>] (sys_ioctl+0x48/0x6c)
[ 2281.204115] [<c0187838>] (sys_ioctl+0x48/0x6c) from [<c00100c0>] (ret_fast_syscall+0x0/0x30)
[ 2281.204529] CPU2: stopping
[ 2281.204709] [<c00182dc>] (unwind_backtrace+0x0/0x144) from [<c096ec68>] (dump_stack+0x20/0x24)
[ 2281.204994] [<c096ec68>] (dump_stack+0x20/0x24) from [<c00085e4>] (do_IPI+0x208/0x218)
[ 2281.205273] [<c00085e4>] (do_IPI+0x208/0x218) from [<c000fbf8>] (__irq_svc+0x38/0xd0)
[ 2281.205422] Exception stack(0xc78d3ee8 to 0xc78d3f30)
[ 2281.205692] 3ee0: c78d3f38 10624dd3 00000000 000f4240 00006f5f 00000000
[ 2281.205967] 3f00: c7ac9c00 c7ac9c70 1fbe3005 00000213 c0df9384 c78d3f64 00000000 c78d3f30
[ 2281.206119] 3f20: c03b2168 c005be20 20000153 ffffffff
[ 2281.206410] [<c000fbf8>] (__irq_svc+0x38/0xd0) from [<c005be20>] (tegra_idle_enter_lp2.part.2+0xb8/0x114)
[ 2281.206692] [<c005be20>] (tegra_idle_enter_lp2.part.2+0xb8/0x114) from [<c005bef0>] (tegra_idle_enter_lp2+0x74/0x78)
[ 2281.206981] [<c005bef0>] (tegra_idle_enter_lp2+0x74/0x78) from [<c068420c>] (cpuidle_idle_call+0x114/0x38c)
[ 2281.207150] [<c068420c>] (cpuidle_idle_call+0x114/0x38c) from [<c00113d0>] (cpu_idle+0xd4/0x11c)
[ 2281.207434] [<c00113d0>] (cpu_idle+0xd4/0x11c) from [<c096bf48>] (secondary_start_kernel+0x154/0x158)
[ 2281.207719] [<c096bf48>] (secondary_start_kernel+0x154/0x158) from [<8096b814>] (0x8096b814)
[ 2281.207995] Rebooting in 10 seconds..
[ 2291.220771] Restarting Linux version 3.1.10-hundsbuah-v3.0.6-oc ([email protected]) (gcc version 4.6.3 (Sourcery CodeBench Lite 2012.03-56) ) #1 SMP PREEMPT Mon May 13 18:42:19 CEST 2013
[ 2291.220794]
No errors detected
May it be that LagFix is trying to trim ext4 fs while this is really ext2?
What comes before this bit?
[2281.200283] EXT4-fs error (device mmcblk1p2): ext4_mb_generate_buddy:738: group 106, 32253 blocks in bitmap, 32254 in gd
[2281.200715] Kernel panic - not syncing: EXT4-fs (device mmcblk1p2): panic forced after error
Here is whole last_kmsg:
http://db.tt/TYhb9rUF
I pasted everything that seemed important, but I'm not an expert. It looked like regular jobs.
Arquiteto said:
Here is whole last_kmsg:
http://db.tt/TYhb9rUF
Click to expand...
Click to collapse
[ 2281.200283] EXT4-fs error (device mmcblk1p2): ext4_mb_generate_buddy:738: group 106, 32253 blocks in bitmap, 32254 in gd
Your filesystem metadata is inconsistent. Information about free blocks is stored twice in the filesystem - in a bitmap to track free blocks one by one, and as a number per blockgroup to quickly find groups with free blocks. Here, the filesystem has detected an inconsistency between those two.
Fix: run fsck on the partition. Since it's mounted in Android, either use an external card reader on a PC, or run fsck from the recovery.
_that said:
Fix: run fsck on the partition. Since it's mounted in Android, either use an external card reader on a PC, or run fsck from the recovery.
Click to expand...
Click to collapse
I run fsck through adb in recovery and now everything is working fine. Thank you
Hi,
I'm working on completely different hardware, but I have such errors all the time.
_that said:
Your filesystem metadata is inconsistent. Information about free blocks is stored twice in the filesystem - in a bitmap to track free blocks one by one, and as a number per blockgroup to quickly find groups with free blocks. Here, the filesystem has detected an inconsistency between those two.
Click to expand...
Click to collapse
My question is, what is cause of such filesystem corruption?
What can I do to avoid this?
Using no journal?
Or maybe I did something wrong with the partitioning?
Or there is bad voltage/speed of eMMC memory?
_that said:
Fix: run fsck on the partition. Since it's mounted in Android, either use an external card reader on a PC, or run fsck from the recovery.
Click to expand...
Click to collapse
What to do, if there isn't CWM and recovery has no fsck option (or will have no such option for user)?

[ROM] Unofficial LineageOS 14.1 [NJH47F] for ZTE Blade S6 (P839F30)

Code:
[I]DISCLAIMER[/I]
All information and files — both in source and compiled form — are provided on an as is basis. No guarantees or warranties are given or implied. The user assumes all risks of any damages that may occur, including but not limited to loss of data, damages to hardware, or loss of business profits. Please use at your own risk. Note that unless explicitly allowed by the warranty covering your device, it should be assumed that any warranty accompanying your device will be voided if you tamper with either the system software or the hardware.
Introduction
This is my unofficial build of LineageOS 14.1 for the ZTE Blade S6 aka P839f30.
This is a beta release, so just some basic functions will be given.
I have tested this version with my AS variant device. Other variants have to be tested.
Click to expand...
Click to collapse
Features
working:
ril: calls, sms, data.
wifi: good.
sensors
gps
sound: clear and loud.
camera: rear and front.
torch
headphone detection
flash is working in new test builds.
not working:
We have to test to find more.
Click to expand...
Click to collapse
Installation instructions
It is best to have installed the latest stock rom beforehand, so modem and all other vendor stuff is up to date.
If you like you can use this mod to have a unified data partition, please proceed with caution.
You will need TWRP or any other custom recovery.
Reboot into recovery and do a nand backup.
Do a factory format.
Download Rom and put it on your phone or use adb sideload.
Install the rom and then clear cache and dalvik cache.
optional: install su and/or gapps.
optional: install your favourite kernel tool and set the cpu governor to interactive for example - do not use performance it will drain your battery, while you are using your device - not for the new test builds.
Click to expand...
Click to collapse
Changelog:
11.10.2018 - test build:
update los sources, security patch level 05.09.
04.03.2018:
make flashlight work.
integrate headphone detection.
update los sources, security patch level 05.02.
14.06.2018 - test build:
flashlight works also in stock camera.
governor are set by the system, no need to set them.
cores are managed by the system, shuting down and launching them one by one. This should save energy.
back and menu button can be toggled in the settings -> additional buttons.
Using stock venus files, video recording is working also hd playback should be fine.
Update sensor hub firmware to version 2.8.
update los sources, security patch level 05.06.
13.02.2018:
rebasing lots of things like kernel and device tree and using different vendor blobs.
Thus wifi signal is great and the microphone is better.
update los sources, security patch level 05.01.
22.11.2017:
reboot to recovery, download mode and power off should work fine now.
update los sources, security patch level 06.11.
19.10.2017:
device reboot fixed, no reboot if the device attempts to suspend.
wifi signal strength is better now.
5GHz wifi support is activated - to be tested.
remove nfc things.
Click to expand...
Click to collapse
Downloads
test build - 11.10.2018:
Google Drive
beta version - 04.03.2018:
Google Drive
If you want root use the lineage addon package found here - download arm version.
Install it after flashing the rom or download your favourite root package and install it.
Sources
device
vendor
kernel
Click to expand...
Click to collapse
FAQ
Here you will find some answers to common question which could arise.
Q: How to give root access to an app or adb?
A: First install the su extra package from Lineage OS or any other su tool you like. Then go into settings and about device, click there multiple times on the build number until you unlocked the developer options. Go to developer options and look for root access.
Q: I thing I found an issue, what to do now?
A: Do a logcat or grab a dmesg while having the issue, otherwise we can't say what is happening. Report as much info as possible. Quote your stock rom your device shipped with or which device variant you possess.
Click to expand...
Click to collapse
XDA:DevDB Information
Unofficial LineageOS 14.1 [NJH47F] P839F30, ROM for all devices (see above for details)
Contributors
lightwars
ROM OS Version: 7.x Nougat
ROM Kernel: Linux 3.10.x
Based On: LineageOS 14.1
Version Information
Status: Beta
Current Beta Version: NJH47F
Beta Release Date: 2018-10-11
Created 2017-09-21
Last Updated 2018-10-11
Awesome, lightwars. Thank you for this Rom and the work you put into it.
I installed it on my EU Blade S6 and can confirm your points on working / non-working.
A couple additional points I discovered so far:
- phone reboots regulary after a couple of minutes (I did a couple of tests cycles with phone going to standby after 1 m inute and switching the phone "off"):
- reboots after 1.5, 2 and 3 minutes with phone going to standby after 1 minute
- reboots after 8.5 and 9 minutes if phone is switched off (standby)
- not able to turn phone off, shutdown and reboot both trigger reboot (with shutdown phone seems to stay "off" a little bit longer than with reboot)
- Wifi has weak signal, but works.
- Wifi only available for 2.4 Ghz, I haven't used the phone for a while, but believe it Supports 5 Ghz as well. Maybe that is connected to the weak 2.4 Ghz signal as well.
- could not get any GPS lock, even location using WLAN and mobile broadcast did not work.
- Screen Mirroring not working, I believe connected to the Wifi issues as well.
- NFC is shown in Settings, but not possible to activate (does the S6 even has NFC?)
Apart from that everything it working great. The phone feels way faster than in stock Rom, videos play smoothly in 720p, 3d performance seemed ok (only tried Google earth, that was way better than in stock rom).
Only issue preventing me from using the phone are the reboots.
Again thank you very much for your great work. Please let me know, if I can help with anything.
xris99 said:
I installed it on my EU Blade S6 and can confirm your points on working / non-working.
A couple additional points I discovered so far:
- phone reboots regulary after a couple of minutes (I did a couple of tests cycles with phone going to standby after 1 m inute and switching the phone "off"):
- reboots after 1.5, 2 and 3 minutes with phone going to standby after 1 minute
- reboots after 8.5 and 9 minutes if phone is switched off (standby)
- not able to turn phone off, shutdown and reboot both trigger reboot (with shutdown phone seems to stay "off" a little bit longer than with reboot)
- Wifi has weak signal, but works.
- Wifi only available for 2.4 Ghz, I haven't used the phone for a while, but believe it Supports 5 Ghz as well. Maybe that is connected to the weak 2.4 Ghz signal as well.
- could not get any GPS lock, even location using WLAN and mobile broadcast did not work.
- Screen Mirroring not working, I believe connected to the Wifi issues as well.
- NFC is shown in Settings, but not possible to activate (does the S6 even has NFC?)
Click to expand...
Click to collapse
It's good to hear, that this rom also work for the EU variant. Before,we have used different kernels...
Sadly I had discovered the reboots also. Thanks for doing some more testing.:good:
Will get some logs to see,if we could do something easily about it. Thought that it coul be related to just some kernel config mismatches, but it don't have to...
NFC is just left over from the starting point... It will be removed, but a little bit curious, that some variants have NFC support activated in the kernel config...
Out of curiousity, have you checked the GPS.conf? I've always had trouble with GPS on this phone but have got it mostly working after lots of fiddling, so I could post if that would be helpful.
xris99 said:
Awesome, lightwars. Thank you for this Rom and the work you put into it.
I installed it on my EU Blade S6 and can confirm your points on working / non-working.
A couple additional points I discovered so far:
- phone reboots regulary after a couple of minutes (I did a couple of tests cycles with phone going to standby after 1 m inute and switching the phone "off"):
- reboots after 1.5, 2 and 3 minutes with phone going to standby after 1 minute
- reboots after 8.5 and 9 minutes if phone is switched off (standby)
- not able to turn phone off, shutdown and reboot both trigger reboot (with shutdown phone seems to stay "off" a little bit longer than with reboot)
- Wifi has weak signal, but works.
- Wifi only available for 2.4 Ghz, I haven't used the phone for a while, but believe it Supports 5 Ghz as well. Maybe that is connected to the weak 2.4 Ghz signal as well.
- could not get any GPS lock, even location using WLAN and mobile broadcast did not work.
- Screen Mirroring not working, I believe connected to the Wifi issues as well.
- NFC is shown in Settings, but not possible to activate (does the S6 even has NFC?)
Apart from that everything it working great. The phone feels way faster than in stock Rom, videos play smoothly in 720p, 3d performance seemed ok (only tried Google earth, that was way better than in stock rom).
Only issue preventing me from using the phone are the reboots.
Again thank you very much for your great work. Please let me know, if I can help with anything.
Click to expand...
Click to collapse
Willing you on for success with this.
I have an EU model which I'd like to install this on once it's functional enough (my regular daily phone).
I also have an old AS model that I may be able to revive for testing purposes (backlight failing intermittently after I dropped it, possibly a loose connection).
Thank you for trying lightwars. You are the only one who work for zte blade s6. I hope you build a stable version soon.
; Wow, many thanks @lightwars !!!
Hopefully soon you'll be have a stable on, that's my hope from ID version...
Regards,
Killermonk
Ok guys i want to install this rom but i cant. I cant find a tutorial here how to root the device. I try to install the recovery [RECOVERY][p839f30 / ZTE Blade S6] UNOFFICIAL TWRP [3.1.0-0] first but i failed too. There is a full guide how to do this? And if I install this there is a way back to the stock rom. Thanks.
@lagos911, rooting is easy. Just use Mobilego like in this video https://www.youtube.com/watch?v=dPDbAdm7B1c
Installing recovery isn't hard either. http://konstakang.com/devices/blades6/TWRP/
It is possible that the adress of the sdcard is different. (For example: sdcard0 in stead of sdcard), use the correct adress.
i install the rom at my phone (eu version) I get black screen after the install for 3 minites and then the device is shuting down.
What I do wrong? I wipe the device and I install the rom from my external sdcard.
lagos911 said:
i install the rom at my phone (eu version) I get black screen after the install for 3 minites and then the device is shuting down.
What I do wrong? I wipe the device and I install the rom from my external sdcard.
Click to expand...
Click to collapse
After installing the rom and you push reboot system, if the black screen (download mode probably) appears, hold the power button until the phone vibrates and reboots.
Now the ZTE splash screen should come up and the phone should boot hopefully.
lightwars said:
After installing the rom and you push reboot system, if the black screen (download mode probably) appears, hold the power button until the phone vibrates and reboots.
Now the ZTE splash screen should come up and the phone should boot hopefully.
Click to expand...
Click to collapse
Yes I do that some times from the second time and after because i didnt want to wait. But black screen continues to appear.
I rewipe (all king of wipes) and reinstall the rom 5 times but nothing happend.
I install the old rom because i was needed the phone. Phone start to loop reboot when I found out the bootfix and now its OK.
Maybe I try lineageOS 14.1 again at the weekend.
So I try to install the rom yesterday. I keep get the black screen after the I reboot the phone. This time I install the fix boot EU from the cyanogen rom. I reboot the phone and I saw the animation boot logo. I think I did it but the animation never go away. I let the phone for 30 minites but i never saw the menu of the new android.
lagos911 said:
So I try to install the rom yesterday. I keep get the black screen after the I reboot the phone. This time I install the fix boot EU from the cyanogen rom. I reboot the phone and I saw the animation boot logo. I think I did it but the animation never go away. I let the phone for 30 minites but i never saw the menu of the new android.
Click to expand...
Click to collapse
Ok, so we've got some problems with EU devices... maybe there are more variants, I'm think of EU, DE, UK, ES, PT and who knows... Could be small differences have an impact here...
To say it clearly to install the boot EU fix from the CM-12.1 thread has installed an other boot image for your phone which have kernel which will not work with nougat.
But anyway I believe I know why the device reboots itself, cause it can't suspend itself in the right manner. Let me show you a kernel log, how it should be:
Code:
<6>[ 189.766084] PM: suspend entry 2017-10-13 04:49:15.725432575 UTC
<6>[ 189.767479] mmc1: Starting deferred resume
<6>[ 189.767983] mmc0: Starting deferred resume
<6>[ 189.861591] mmc0: Deferred resume completed
<6>[ 189.907006] mmc1: Deferred resume completed
<6>[ 189.766118] PM: Syncing filesystems ... done.
<3>[ 189.999154] Error: returning -512 value
<6>[ 189.998043] Freezing user space processes ... (elapsed 0.008 seconds) done.
<6>[ 190.006568] Freezing remaining freezable tasks ... (elapsed 0.005 seconds) done.
<6>[ 190.011790] Suspending console(s) (use no_console_suspend to debug)
<6>[ 190.018262] [AK4375] ak4375_suspend(1402)
<6>[ 190.025845] [TP:CORE]Enter fb_notifier_callback.
<6>[ 190.025845]
<6>[ 190.025892] [TP:CORE]Enter fb_notifier_callback.
<6>[ 190.025892]
<7>[ 190.034218] --CWMCU--CWMCU_suspend
<6>[ 190.046580] PM: suspend of devices complete after 33.038 msecs
<6>[ 190.048343] PM: late suspend of devices complete after 1.737 msecs
<6>[ 190.053764] PM: noirq suspend of devices complete after 5.409 msecs
<6>[ 190.053774] Disabling non-boot CPUs ...
<6>[ 190.081114] CPU0:msm_cpu_pm_enter_sleep mode:3 during suspend
...
<6>[ 400.663545] Enabling non-boot CPUs ...
<6>[ 400.664692] CPU1 is up
<6>[ 400.665735] CPU2 is up
<6>[ 400.666779] CPU3 is up
<6>[ 400.668230] CPU4 is up
<6>[ 400.669120] CPU5 is up
<6>[ 400.670027] CPU6 is up
<6>[ 400.670974] CPU7 is up
<6>[ 400.671561] PM: noirq resume of devices complete after 0.570 msecs
<6>[ 400.672983] PM: early resume of devices complete after 0.796 msecs
<7>[ 400.679137] --CWMCU--CWMCU_resume
<6>[ 400.689515] PM: resume of devices complete after 16.510 msecs
<6>[ 400.690769] runin_work:BatteryTestStatus_enable = 0 chip->usb_present = 0
<6>[ 400.690573] Restarting tasks ... done.
<6>[ 400.696613] PM: suspend exit 2017-10-13 05:59:11.279104088 UTC
But at the moment the device hangs up while trying to freeze the user space processes and fails.
I found that there is a problem with the device tree image of the kernel, so using the stock one everything is well.
I will make changes and a new version will appear soon.
In the meantime please try out flashing this bootimages after installing LOS-14.1:
Boot - LOS-14.1 standard image(AS)
Boot EU -LOS-14.1
Hopefully one of these works and the reboot issue shouldn't happen also.
lightwars said:
Ok, so we've got some problems with EU devices... maybe there are more variants, I'm think of EU, DE, UK, ES, PT and who knows... Could be small differences have an impact here...
To say it clearly to install the boot EU fix from the CM-12.1 thread has installed an other boot image for your phone which have kernel which will not work with nougat.
But anyway I believe I know why the device reboots itself, cause it can't suspend itself in the right manner. Let me show you a kernel log, how it should be:
Code:
<6>[ 189.766084] PM: suspend entry 2017-10-13 04:49:15.725432575 UTC
<6>[ 189.767479] mmc1: Starting deferred resume
<6>[ 189.767983] mmc0: Starting deferred resume
<6>[ 189.861591] mmc0: Deferred resume completed
<6>[ 189.907006] mmc1: Deferred resume completed
<6>[ 189.766118] PM: Syncing filesystems ... done.
<3>[ 189.999154] Error: returning -512 value
<6>[ 189.998043] Freezing user space processes ... (elapsed 0.008 seconds) done.
<6>[ 190.006568] Freezing remaining freezable tasks ... (elapsed 0.005 seconds) done.
<6>[ 190.011790] Suspending console(s) (use no_console_suspend to debug)
<6>[ 190.018262] [AK4375] ak4375_suspend(1402)
<6>[ 190.025845] [TP:CORE]Enter fb_notifier_callback.
<6>[ 190.025845]
<6>[ 190.025892] [TP:CORE]Enter fb_notifier_callback.
<6>[ 190.025892]
<7>[ 190.034218] --CWMCU--CWMCU_suspend
<6>[ 190.046580] PM: suspend of devices complete after 33.038 msecs
<6>[ 190.048343] PM: late suspend of devices complete after 1.737 msecs
<6>[ 190.053764] PM: noirq suspend of devices complete after 5.409 msecs
<6>[ 190.053774] Disabling non-boot CPUs ...
<6>[ 190.081114] CPU0:msm_cpu_pm_enter_sleep mode:3 during suspend
...
<6>[ 400.663545] Enabling non-boot CPUs ...
<6>[ 400.664692] CPU1 is up
<6>[ 400.665735] CPU2 is up
<6>[ 400.666779] CPU3 is up
<6>[ 400.668230] CPU4 is up
<6>[ 400.669120] CPU5 is up
<6>[ 400.670027] CPU6 is up
<6>[ 400.670974] CPU7 is up
<6>[ 400.671561] PM: noirq resume of devices complete after 0.570 msecs
<6>[ 400.672983] PM: early resume of devices complete after 0.796 msecs
<7>[ 400.679137] --CWMCU--CWMCU_resume
<6>[ 400.689515] PM: resume of devices complete after 16.510 msecs
<6>[ 400.690769] runin_work:BatteryTestStatus_enable = 0 chip->usb_present = 0
<6>[ 400.690573] Restarting tasks ... done.
<6>[ 400.696613] PM: suspend exit 2017-10-13 05:59:11.279104088 UTC
But at the moment the device hangs up while trying to freeze the user space processes and fails.
I found that there is a problem with the device tree image of the kernel, so using the stock one everything is well.
I will make changes and a new version will appear soon.
In the meantime please try out flashing this bootimages after installing LOS-14.1:
Boot - LOS-14.1 standard image(AS)
Boot EU -LOS-14.1
Hopefully one of these works and the reboot issue shouldn't happen also.
Click to expand...
Click to collapse
I try to install the boot but file is corrupted
lagos911 said:
I try to install the boot but file is corrupted
Click to expand...
Click to collapse
I downloaded both files and they install just fine.
You have to switch from ZIP installing to image installing at the install dialog from twrp the button at the bottom right.
lightwars said:
I downloaded both files and they install just fine.
You have to switch from ZIP installing to image installing at the install dialog from twrp the button at the bottom right.
Click to expand...
Click to collapse
Yea i didnt know that with the image flashing. Thanks.
Actually I did it and I install the rom with your boot EU fix. No big diffrents at the interface from the 12.1 cm.
I dont working a lot with lineageOS but many thinks dont work. I enable wifi and disable automatic. Flashlight and some other thinks.
I hope you build a stable rom.
P.S. Now i have install the CM12.1 and when I try to enter the bootloader the device stuck.
Also I try to delete some system apps with ES explorer PRO and I get that my device its not rooted.
I have done something wrong with the rooting?
lagos911 said:
P.S. Now i have install the CM12.1 and when I try to enter the bootloader the device stuck.
Also I try to delete some system apps with ES explorer PRO and I get that my device its not rooted.
I have done something wrong with the rooting?
Click to expand...
Click to collapse
I am not sure I can follow your description... What means stuck? bootloader displays just a black screen.
Normally you can activate root in the developer settings, which are displayed after clicking serveral times on the build number. There you will find an option to enable/disable root for apps and adb.
Or if you prefer other tools like supersu install it first, then try again.
Remember to ask question for CM12.1 inside the appropriate thread.
Sorry for the wrong topic. I didint know that the bootloader appearing a black screen. Usually they have a menu.
I forgot to mention that the option for root explorer at ES explorer PRO you can activated from here.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Please help :/
I've installed this onto my zte blade s6 but my internet doesn't turn on on the phone and I flashed the eu fix by lightwars on my recovery so now i don't have a recovery and my phone isn't rooted. PLEASE HELP.

Categories

Resources