The Nexus 5 turn to be asked this hehe
I've just now experienced this in the course of fixing another issue.
Normally in spite of how much i change ROMS whenever I set time manually and uncheck network derived time the date/ time maintains across restarts, now it doesnt.
It looks like a 4.4.4 issue? Dunno
Any help / ideas welcome.
What I did so far:
clean ROM not dirty flashed
switching between stock OMNI and Minux OMNI
all combinations of option in date/ time settings while
Each and everytime after reset the date time is 13 Aug 1970. Even if is set to automatic that date briefly appears before a connection to the net is made.
Did you find the solution?
Could be related to the RTC not storing the time. The qpnp-rtc-write device tree option controls whether the time can be set with hwclock. If set to 0 or omitted, you will not be able to set the RTC time through the standard RTC interfaces (hwclock -w). Now, apparently these Qualcomm devices have a proprietary time_daemon program which is supposed to store these values permanently. It is invoked through the TimeService.apk program which is some thin glue that calls into libTimeService.so which invokes the time_genoff_operation function. I guess that this function should ultimately update the RTC time, but have not investigated further.
TL;DR check whether your TimeService.apk is working. It should contain a classes.dex file (deodexed). For Android 5.1, note that the files from the factory images are ART-optimized. You can undo that using Riddle's oat2dex.jar tool.
Edit: apparently these Qualcomm RTCs cannot be written from software (at least, not directly). A Qualcomm consultant mentioned this during patch review:
Anirudh Ghayal (Qualcomm consultant) said:
In some of our MSM/QSD designs, we have a single RTC shared by multiple
processors (other than the ones running Linux). Thus, the need to have a
non-writable RTC using this pdata.
Click to expand...
Click to collapse
Someone already tried to patch the property in the kernel, but writing via hwclock was still not possible. I can confirm this for a Nexus 5 (rev_11, tested with this recovery image patching tool):
Code:
~ # /system/xbin/hwclock -w
hwclock: RTC_SET_TIME: Operation not permitted
<3>[ 25.821247] spmi_pmic_arb fc4cf000.qcom,spmi: pmic_arb_wait_for_done: transaction denied (0x5)
<3>[ 25.821338] qcom,qpnp-rtc qpnp-rtc-ee162000: SPMI write failed
<3>[ 25.821408] qcom,qpnp-rtc qpnp-rtc-ee162000: Write to RTC reg failed
In the end, I decided to accept this problem and be stuck with a RTC set to 1970. Note that this device has not been network-connected since I started experimenting.
As for the TimeService.apk/time_genoff/time_daemon functionality, all these components do is maintaining an offset in the /data/system/time/ats_X files. These are read on startup and applied as offset. Nast hack, and there are alternative opensource alternatives. Really, the only functional thing that this daemon does is reading the RTC time and then applying the offsets over it. It has no code to write back the actual time to the RTC. It is no magic. (Found by reverse engineering the binaries and libraries.)
Lekensteyn said:
Could be related to the RTC not storing the time. The qpnp-rtc-write device tree option controls whether the time can be set with hwclock. If set to 0 or omitted, you will not be able to set the RTC time through the standard RTC interfaces (hwclock -w). Now, apparently these Qualcomm devices have a proprietary time_daemon program which is supposed to store these values permanently. It is invoked through the TimeService.apk program which is some thin glue that calls into libTimeService.so which invokes the time_genoff_operation function. I guess that this function should ultimately update the RTC time, but have not investigated further.
TL;DR check whether your TimeService.apk is working. It should contain a classes.dex file (deodexed). For Android 5.1, note that the files from the factory images are ART-optimized. You can undo that using Riddle's oat2dex.jar tool.
Edit: apparently these Qualcomm RTCs cannot be written from software (at least, not directly). A Qualcomm consultant mentioned this during patch review:
Someone already tried to patch the property in the kernel, but writing via hwclock was still not possible. I can confirm this for a Nexus 5 (rev_11, tested with this recovery image patching tool):
Code:
~ # /system/xbin/hwclock -w
hwclock: RTC_SET_TIME: Operation not permitted
<3>[ 25.821247] spmi_pmic_arb fc4cf000.qcom,spmi: pmic_arb_wait_for_done: transaction denied (0x5)
<3>[ 25.821338] qcom,qpnp-rtc qpnp-rtc-ee162000: SPMI write failed
<3>[ 25.821408] qcom,qpnp-rtc qpnp-rtc-ee162000: Write to RTC reg failed
In the end, I decided to accept this problem and be stuck with a RTC set to 1970. Note that this device has not been network-connected since I started experimenting.
As for the TimeService.apk/time_genoff/time_daemon functionality, all these components do is maintaining an offset in the /data/system/time/ats_X files. These are read on startup and applied as offset. Nast hack, and there are alternative opensource alternatives. Really, the only functional thing that this daemon does is reading the RTC time and then applying the offsets over it. It has no code to write back the actual time to the RTC. It is no magic. (Found by reverse engineering the binaries and libraries.)
Click to expand...
Click to collapse
Hi, great explanation.. I didn't have this issue in stock Marshmallow, but now I have it in custom ROM.. maybe it's something related to some permissions?
bart.found said:
Hi, great explanation.. I didn't have this issue in stock Marshmallow, but now I have it in custom ROM.. maybe it's something related to some permissions?
Click to expand...
Click to collapse
There is a SELinux policy that must allow access, you can check your kernel logs (dmesg or maybe even logcat) for SELinux denials. The /data/system/time/ location must also be accessible for the time daemon.
Related
I am trying to implement a simple system call hook. My method was the same method used by standard linux rootkits like adore. this method worked for hooking sys_open and other file IO system calls. but when i tried to hook sys_fork and other process related system calls my android phone crashes (Nexus one, Motorola Milestone, and emulator). Something inherently different about Android either ARM or android kernel is different from basic linux machines which wont allow me to use the same method to hook the system call fork. Basically my method is below, this is implemented via a LKM on a phone that i have root access on.
//save pointer to original function
orig_fork = sys_call_table[__NR_fork];
//point sys_fork to my fm_fork function
sys_call_table[__NR_fork] = my_fork;
//call original fork call (simplest case)
asmlinkage int my_fork(struct pt_regs *regs)
{
pid_t pid;
pid = (*orig_fork)(regs);
return pid;
}
Some how i think the stack is getting messed up. I looked at the source code for the kernel and found that the sys_fork isnt actually in the system call table. Instead it is a sys_fork_wrapper. This wrapper is an assembler function with two commands which lead it to branching to sys_fork. Sys_fork in turn calls another function called do_fork. Through debugging methods i was able to confirm that my call to the original fork function was returning correctly, but when i try to return the pid within my own function the crash occurs. Now whats interesting is that I was able to confirm that do_fork is called many times without calling sys_fork for many processes on the phone. So when i do the simplest process i can think of by starting up a shell the phone didnt crash. But it wont open up a shell. The terminal locks up when i try to open the shell. Starting up a shell will call a sys_fork_wrapper->sys_fork->do_fork like expected. Starting up another more complicated process such as calculator it will call sys_fork_wrapper->sys_fork->do_fork->do_fork->do_fork->do_fork.... so bacially i am left with lots of questions about why hooking sys_fork is not working.
Root Tracker is source code for a super-simple Android 2.2+ device tracking system that responds to SMS messages with embedded control passwords.
Root Tracker is designed to be installed on a rooted device in /system/app, so it can survive a hard reset. Root Tracker has no user interface, all the better for hiding it from a thief. The code must be customized for the particular user and device, as passwords and other configuration items are hard coded, and each user should change the package name and other details to make it sound like a system package, in order to even better hide the package from a thief. Don't use the current values in the source, as a smart thief (there aren't many, I expect, but there may be some). Plus, I expect that different users will have different requirements.
After customizing and installing, go to your system Settings and set Root Tracker's device admin class as a Device Administrator.
Actions available:
gps
wipe
lock (locks screen [if set as Device Administrator; otherwise, sets screen timeout to a very short value to make device very hard to use], turns off adb, disables NoLock)
unlock
root shell command (output returned via SMS).
I wrote Root Tracker because I was uncomfortable about having my phone tracked and potentially wiped by a closed source app, like the various anti-theft trackers currently available. A crucial design principle was to make RT simple enough that one can easily verify from the source code what exactly it is doing.
The passwords are plain text in the apk. You can replace this with hashing if you like, but I didn't bother.
Also, instead of invoking the Android system's data wiping, which is known to be of problematic quality on some devices, it uses dd to overwrite the data partition, which may be more reliable (but of course, you have to ensure RT is installed in /system/app). Moreover, this means that the wipe works even if the thief is clever enough to go to the device settings and revoke Root Tracker's device administrator status. I don't know how well this works. This is a feature I did not test since I don't want to deal with restoring a backup. I worry that wiping the data partition will cause a reboot at some point. (Still, I have deleted the contents of /data before, and restored them via tar, and the device did not reboot while deleting.)
The gps command responds instantly with last cached GPS and Network location, then turns on GPS (even if disabled) and Network location (this one may show a dialog, so I recommend keeping Network location on in your Settings, or else disabling the Network location code). Then it waits for a GPS fix. If while waiting for a GPS fix, it gets a new Network location value, it sends that, but keeps on waiting for a GPS fix. If it gets a GPS fix before getting a Network fix, it quits looking for the Network fix (you can change that in the source code).
Note: Installing this on a device that isn't yours (unless you're law enforcement with an appropriate warrant) is likely illegal and is certainly not nice. This is designed for one's own use.
Hi Everyone,
Was hoping I could ask a few people to help me out here. Since Feb 28th(ish), I get random kernel panics on CM11 or any ROMs based on the unified moto8960 tree.
To help me out to see if it's just me or a wider problem, all you need to do is install this app:
https://play.google.com/store/apps/details?id=se.mumu21.bootlog
Which will keep track of your uptime. It needs root privileges in order to copy last_kmsg and trying to view from the logs will FC the app. This is fine, it still copies the logs which you can then view/etc from your filemanager (default is to save to internal sd card)
Once the app is installed, you need not do anything more other than grant it root privs (head into preferences of the app and enable all 4 check marks) -- If your phone reboots, there'll be a record and can capture the last_kmsg file and hopefully push this up to the CM team, if there's an issue.
The app is smart enough to detect between user reboot and unexpected reboots, you'll see it listed as "crash" in the logs.
Thanks to anyone who decides to help out!
EDIT:
For reference, I'm including links to my last_kmsg in the two times I caught it on two separate builds (same error)
http://forum.xda-developers.com/showpost.php?p=51000973&postcount=1567
http://forum.xda-developers.com/showpost.php?p=50707021&postcount=1477
End of the day, for me it appears to be here:
Code:
[11746.588339,0] PM: Preparing system for mem sleep
[11746.588522,0] pm_debug: suspend uah=154646
[11746.591849,0] Freezing user space processes ...
[11746.596732,1] msm_server_control: wait_event error -512 for command10
[11746.596855,1] msm_open send open server failed
[11746.624903,0] ov8820_power_down
[11746.670164,0] msm_open: destroy ion client(elapsed 0.08 seconds) done.
[11746.924399,0] Freezing remaining freezable tasks ...
[11746.925681,0] active wake lock alarm_rtc, time left 73
[11746.926291,0]
[11746.926536,0] Freezing of tasks aborted
[11746.930625,0]
[11746.930869,0] Restarting tasks ...
[11746.949212,0] Unable to handle kernel NULL pointer dereference at virtual address 00000000
Can see logging around going into mem sleep plenty of times before, this time it fails. On AOSP builds, the error also happens (moto_msm8960) but the error is not with msm_server_control but rather:
Code:
[ 5630.051304,1] PM: Preparing system for mem sleep
[ 5630.051548,1] pm_debug: suspend uah=106686
[ 5678.901571,0] [0:986:E :DAT] Set DXE Power state 0
[ 5680.681793,0] [0:986:E :DAT] Set DXE Power state 2
[ 5680.689881,0] [WLAN][987:E :TL ] WLAN TL:No station registered with TL at this point
[ 5690.081214,1] **** Suspend timeout
[ 5690.081366,1] kworker/u:16 D c08131e0 0 22912 2 0x00000000
[ 5690.081671,1] [<c08131e0>] (__schedule+0x780/0x90c) from [<c081457c>] (__mutex_lock_slowpath+0x178/0x1e4)
[ 5690.081824,1] [<c081457c>] (__mutex_lock_slowpath+0x178/0x1e4) from [<c081463c>] (mutex_lock+0x54/0x6c)
[ 5690.082007,1] [<c081463c>] (mutex_lock+0x54/0x6c) from [<c0172480>] (cpu_hotplug_disable_before_freeze+0x8/0x20)
[ 5690.082190,1] [<c0172480>] (cpu_hotplug_disable_before_freeze+0x8/0x20) from [<c01724e0>] (cpu_hotplug_pm_callback+0x28/0x40)
[ 5690.082373,1] [<c01724e0>] (cpu_hotplug_pm_callback+0x28/0x40) from [<c08181c8>] (notifier_call_chain+0x38/0x68)
[ 5690.082526,1] [<c08181c8>] (notifier_call_chain+0x38/0x68) from [<c0193a1c>] (__blocking_notifier_call_chain+0x40/0x54)
[ 5690.082709,1] [<c0193a1c>] (__blocking_notifier_call_chain+0x40/0x54) from [<c0193a44>] (blocking_notifier_call_chain+0x14/0x18)
[ 5690.082892,1] [<c0193a44>] (blocking_notifier_call_chain+0x14/0x18) from [<c01a70d8>] (pm_notifier_call_chain+0x14/0x2c)
[ 5690.083075,1] [<c01a70d8>] (pm_notifier_call_chain+0x14/0x2c) from [<c01a8010>] (enter_state+0x68/0x13c)
[ 5690.083167,1] [<c01a8010>] (enter_state+0x68/0x13c) from [<c01a92f0>] (suspend+0x68/0x180)
[ 5690.083350,1] [<c01a92f0>] (suspend+0x68/0x180) from [<c0189aa8>] (process_one_work+0x228/0x434)
[ 5690.083533,1] [<c0189aa8>] (process_one_work+0x228/0x434) from [<c0189e88>] (worker_thread+0x1a8/0x2c8)
[ 5690.083686,1] [<c0189e88>] (worker_thread+0x1a8/0x2c8) from [<c018e2a8>] (kthread+0x80/0x8c)
[ 5690.083869,1] [<c018e2a8>] (kthread+0x80/0x8c) from [<c0106714>] (kernel_thread_exit+0x0/0x8)
[ 5690.083991,1] Unable to handle kernel NULL pointer dereference at virtual address 00000000
Curious to see if others are hitting the same thing.
Had a random reboot a few hours ago on cm11 (March 11th). Just installed the app, let's see what we can get now.
CWGSM3VO said:
Hi Everyone,
...
Click to expand...
Click to collapse
The issue captured in the second log is long known to us.
It's caused by msm-dcvs CPU governor and despite a few already applied kernel patches, it remains problematic.
So the current recommendation is: do not use msm-dcvs CPU governor.
(for the reference, see https://github.com/razrqcom-dev-team/android_kernel_motorola_msm8960-common/issues/12 )
The issue captured by the first log is something new and I already experienced it myself today (for the first time).
It's obviously a race condition during suspend/resume of camera kernel drivers.
It needs to be investigated. At this point I have no idea which commit brought this issue to surface.
kabaldan said:
The issue captured in the second log is long known to us.
It's caused by msm-dcvs CPU governor and despite a few already applied kernel patches, it remains problematic.
So the current recommendation is: do not use msm-dcvs CPU governor.
(for the reference, see https://github.com/razrqcom-dev-team/android_kernel_motorola_msm8960-common/issues/12 )
The issue captured by the first log is something new and I already experienced it myself today (for the first time).
It's obviously a race condition during suspend/resume of camera kernel drivers.
It needs to be investigated. At this point I have no idea which commit brought this issue to surface.
Click to expand...
Click to collapse
With regards to the second capture, that makes sense and knew Epinter's commits were merged but will stay away from the governor again. And the explanation of the first is muched appreciated. I do know however, I've experienced the panic using interactive as well in effort to stay as "stock" as one can be.
I'll switch back (so far so good on 03-12) to interactive again and go from there.
Thanks again for responding.
Joying "N2" firmware.
Looking into the process for booting to recovery, I started looking into the Joying firmware, specifically, the file fwu_image.bin. This is an interesting file, it appears to be a bootloader and/or some kind of hypervisor.
Some strings in it led me to find a tool called the "Intel Phone Flash Tool"
There is a LOT of potentially useful information in this thread; http://forum.xda-developers.com/gen...70-3g-sofia-atom-x3-c3130-quad-t3103085/page2
Other interesting strings;
USB Driver Bootcore module --- something about booting via USB?
There is a bunch of stuff about **fastboot**.
"rockchip,power-key-pressed-time" -- interesting. Does it respond differently to holding the power key for different lengths of time?
"%s BCB is boot-normal, set NVM to normal mode." -- this seems to be related to selecting boot modes based on data on NVM, i.e., what happens when you issue "reboot recovery".
Wonder what would happen if you ran "reboot bootloader"?
Some stuff about "special" key...
This stuff.... some kernel parameters, and, of course, the SERIAL NUMBER that freaks tomtom out;
Code:
phyBlk = 0x%x die = %d block_in_die = 0x%x 0x%x
0123456789abcdef
(null)
0123456789ABCDEF
bug in vfprintf: bad base
SF_3GR_ver 1639.400
1639.400_M1S1
,dDK
,DDK
androidboot.bootloader
androidboot.serialno
loader_charged
normal
androidboot.mode
ptest
charger
0123456789012345678901234567890
0123456789012345
update-radio/hboot
boot-fb-pt-updated
boot-fastboot
boot-recovery
update-psi
fb_update_bl
At least partial kernel commandline as; "console=ttyFIQ0,115200n8 idle=halt earlyprintk=xgold notsc apic=sofia androidboot.hardware=sofiaboard nolapic_pm firmware_class.path=/system/vendor/firmware androidboot.selinux=permissive x86_intel_xgold_timer=soctimer_only vmalloc=512m slub_max_order=2 uvcvideo.en_autosuspend=0 selinux=0 limit_cpu=disable mvpipe.at_dbg_port=1"
Note: serial console on ttyFIQ0, I wonder where that could be found.
Also note: selinux is in a pointless state. Major copout.
There are a *LOT* of strings in there that tie it to the FYT SoM. The bootloader is, no doubt, incompatible with MTCD boards.
There seem to be a LOT of references to hardware that these units do not have. Even found the string "huawei" in it. Makes me thing that this is a lot more than just a simple bootloader. This looks like it actually contains a *complete Linux kernel*. No wait, actually TWO.
This is really weird. Perhaps a bootloader followed by 2 kernels?
"/local/zengguan/RK-release-for-eoi/1511-official-release/mobilevisor/core"
"Mobilevisor/bootloader boot shared info structure version mismatch!"
Ok, so here is what I'm thinking;
1) It might have fastboot.
2) The USB keyboard - boot to recovery process may well avoid starting the boot partition, I think that it may be starting one of the kernels in the hypervisor partition, and using that to adjust the NVM to cause a recovery boot.
3) NEITHER of those are guaranteed, further study would be required.
Found THIS immediately before what appears to be fastboot:
"-----BOOT_REASON_LONG_ON_KEY-----"
So what does that mean? Boots to fastboot if you hold down the ON key for a long time? What is an ON key?
This comes AFTER fastboot:
"------display screen start------"
Could be that fastboot mode has no display output.
Hmm...
%s line=%d DOWN bit is set
%s line=%d DOWN and Power bit is set
Another edit... they aren't calling it a hypervisor, they're calling it a MICROVISOR. Essentially, a combined hypervisor + microkernel. The main kernel accesses security sensitive resources via the microkernel. Think of it as TRUSTZONE.
I *think* that the watchdog is implemented in the microvisor. With any luck, they didn't completely bonehead it -- a complete mess up should (if implemented in a sane manner) result in a reboot into some mode where recovery is possible, such as fastboot or recovery.
Found this; https://translate.google.ca/transla...96%87%E4%BB%B6%E6%8F%90%E5%8F%96/&prev=search
First thing I notice is that the partition table of THAT device, aligns with Joying N2 devices. This is very good news, because it means that we can learn about our device from it.
So that big file "fwu_image.bin" that I was looking into, is being written to ImcPartID122. This is important, because that website I linked above indicates that 122 is something of a "special" partition. Ok, by special, I really mean SCREWBALL.
Normally, your storage devices are laid out as following;
/dev/typeN --- for the "base" device, representing the entire storage area as a single file. Counts from 0 up.
and
/dev/typeNpM which splits out the different partitions of the device.
So if you just wanted to write a block of binary data to the beginning of the storage device, you normally would dd if=source of=/dev/typeN and be done with it.
But these devices are a bit screwball. ImcPartID122, for instance, seems to link to /dev/block/nand0p12 <-- 12th partition? Ok, its labeled as "ALL", so I think we can assume that this is somewhat similar in concept to /dev/block/nand0. Or maybe with some special offset? Probably would make a bit of sense for me to actually look at the real partition table to figure out what is going on.
NOTE: Yes, it is certainly possible for device partitions to overlap. Nothing to worry about in that regard.
So "ALL", explains why I was able to find two copies of the linux kernel in there. It actually *INCLUDES* both the boot and the recovery partitions! Or maybe boot and boot-backup, don't quite know just yet. So next you're going to say that this can't be so, since the file isn't sparse, and the boot partition comes after the system partition.... while it *looks* like the boot partition comes after the system partition (boot: ImcPartID071, system: ImcPartID068), this is not actually the case. Those "ImcPartID"'s are actually just names. 068 -> /dev/block/nand0p14, 071 -> /dev/block/nand0p9... Plus, the partition number really doesn't have to correspond to its physical ordering on the device, and as the "All" partition indicates, on these, it doesn't. So no conflicts -- that is good.
Great stuff @doitright!
Finding the location of that long serial number in the fwu_image.bin is promising for a TomTom fix. Many consider it the best offline navigation app for when there might not be an internet connection for proper function of Waze/GoogleMaps. Do you think its possible to overwrite the serial number in place on the /dev/block partition or would editing the bin and reflashing be the best bet?
The only ON key I can imagine on the capacitive button units is the recessed POW button. I tried holding it beyond 30 seconds but there is no boot into recovery. Issuing "reboot bootloader" or "reboot recovery" from root terminal on the unit unfortunately seems to just reboot the unit normally.
The latest firmware Joying emailed has the MCU dated 10/31 and ROM dated 11/15 if that is different from the one you're looking at: http://forum.xda-developers.com/showpost.php?p=69755292&postcount=426 Though I assume any changes would be minimal from the previous versions. Running everything on top of this microvisor sounds different from the MTCB/C D units. We are lucky to have you looking at it!
rcll said:
Great stuff @doitright!
Finding the location of that long serial number in the fwu_image.bin is promising for a TomTom fix. Many consider it the best offline navigation app for when there might not be an internet connection for proper function of Waze/GoogleMaps. Do you think its possible to overwrite the serial number in place on the /dev/block partition or would editing the bin and reflashing be the best bet?
The only ON key I can imagine on the capacitive button units is the recessed POW button. I tried holding it beyond 30 seconds but there is no boot into recovery. Issuing "reboot bootloader" or "reboot recovery" from root terminal on the unit unfortunately seems to just reboot the unit normally.
The latest firmware Joying emailed has the MCU dated 10/31 and ROM dated 11/15 if that is different from the one you're looking at: http://forum.xda-developers.com/showpost.php?p=69755292&postcount=426 Though I assume any changes would be minimal from the previous versions. Running everything on top of this microvisor sounds different from the MTCB/C D units. We are lucky to have you looking at it!
Click to expand...
Click to collapse
I used to use tomtom... back in around 2005-2008. They had a version that ran on PalmOS 5.whatever, so it was good for the old Treo 650. I'm not at all fond of the subscription model that they've taken on -- to hell with that!
For offline nav, I use Alk Copilot: https://play.google.com/store/search?q=copilot&c=apps&hl=en
As far as changing the serial number, I'm going to have to track it to what partition it is actually in, and figure out its layout.... determine if there are any other implications to altering it besides just changing the serial number. Would hate to see it cause BRICKING.
Hi, I need a technical advice before putting my LG G6 H870 to the garbage ...
Since a few weeks, I started getting some random app crashes and a few boot-loops while running an updated stock rom.
A factory reset leads to the same way and even a reset to refurbished stock rom version raises the same errors: so the issue comes from the hardware.
After installing TWRP and formatting system partition I tried to identify if it was an internal storage issue (and spoiler alert: it was :crying.
I knew that I should be able to identify bad blocks to tell the filesystem to not used them, but the problem if the use of a Flash Translation Layer (FTL) by the hardware that is obfuscating real nand memory addresses by design.
If i run a one-pass badblocks:
Code:
/dev/block/platform/soc/624000.ufshc/by-name # badblocks -wsvt 0xFF system
Checking for bad blocks in read-write mode
From block 0 to 5726207
Testing with pattern 0xff: done
Reading and comparing: 103464% done, 0:47 elapsed
103466
103468
103470
288888
288890
288892
288894
3197580 done, 0:54 elapsed
3197582
3197584
3197586
3358788
3358790
3358792
3358794
done
Pass completed, 16 bad blocks found.
And If I run a 4-pass badblocks:
Code:
/dev/block/platform/soc/624000.ufshc/by-name # badblocks -wsv system
Checking for bad blocks in read-write mode
From block 0 to 5726207
Testing with pattern 0xaa: done
Reading and comparing: 110968% done, 0:47 elapsed
110970
110972
110974
303396
303398
303400
303402
3205312 done, 0:54 elapsed
3205314
3205316
3205318
3351108
3351110
3351112
3351114
done
Testing with pattern 0x55: done
Reading and comparing: 109356% done, 1:48 elapsed
109358
109360
109362
306392
306394
306396
306398
3206852 done, 1:55 elapsed
3206854
3206856
3206858
3353208
3353210
3353212
3353214
done
Testing with pattern 0xff: done
Reading and comparing: 110848% done, 2:48 elapsed
110850
110852
110854
304640
304642
304644
304646
3206292 done, 2:55 elapsed
3206294
3206296
3206298
3353228
3353230
3353232
3353234
done
Testing with pattern 0x00: done
Reading and comparing: 111992% done, 3:48 elapsed
111994
111996
111998
304668
304670
304672
304674
3215112 done, 3:55 elapsed
3215114
3215116
3215118
3353828
3353830
3353832
3353834
done
Pass completed, 64 bad blocks found.
Oh surprise (no it's not), bad blocks are never the sames because of the FTL, and that's probably why the badblocks binary is not a part of the standard recovery binaries list.
But since the hardware via the FTL should take care of bad sectors, why it's not the case for my LG G6 ?
Is there a way to enforce this check at low-level ?
My readings before posting:
https://android.stackexchange.com/q...d-sector-on-my-android-with-adb-recovery-mode
https://android.stackexchange.com/q...-bad-ram-addresses-and-fix-bad-storage-blocks