Q&A for: [STOCK KERNELS] selinux enforcing and rootable - Galaxy Note5 Q&A, Help & Troubleshooting

Please jump to the last post in this thread for the most current information. These kernels are no longer needed.
Old Post:
Q&A thread for the stock kernels I posted here:
http://forum.xda-developers.com/note5/development/stock-kernels-selinux-enforcing-rootable-t3222333
If you have a device with an unlocked bootloader and would like me to make the ramdisk changes, you need to obtain the factory ODIN firmware. Then, upload the boot.img from within it, and provide that to me, along with the full firmware string (settings -> about -> software info -> build number) If you got the firmware image from sammobile, you can just give me the full filename of the image archive (the first part of that is the firmware string I want.)
I'm only going to keep posted a single kernel for each device. So, one n920i, one n920c, etc. I'll try to keep them up to the newest version, but the kernel images tend to be compatible across minor firmware updates for a given device.
Q: Where is the source?
A: Wherever samsung posted it. These kernels aren't recompiled.. only the ramdisk is modified. The modifications are documented in this thread: http://forum.xda-developers.com/note5/orig-development/kernel-discussion-root-recompiling-t3219990
Q: Will you make the kernels auto-root my device?
A: No. The goal of this was to retain boot images as close as possible to stock while allowing a user to choose to install a functioning SuperSU and/or modify the system partition without headaches such as boot loops.
Q: Which version of SuperSU was this tested with?
A: Beta 2.51
Q: What about xposed?
A: If xposed can work with SEAndroid in enforcing mode and/or makes the proper policy requests from SuperSU, then it should work. However, that's outside the scope of this (or any other) kernel.
Q: Will this allow me to root an AT&T or Verizon device?
A: Not unless the bootloader for those devices becomes unlocked or another way is found to flash a boot image safely.
Q: Why are you so user unfriendly?
A: This is a developer forum.

SM-N9208
SM-N9208 -> N9208ZTU1AOH4 -> boot.img is here:
https://drive.google.com/file/d/0B8l6BzXcGjjmcHVPdzZjUnFGQ0k/view?usp=sharing
Please and thank you.

@garyd9 Thanks i think you are doing a great job for our Note 5.

@Class said:
SM-N9208 -> N9208ZTU1AOH4
Click to expand...
Click to collapse
http://forum.xda-developers.com/showpost.php?p=63237528&postcount=2

garyd9 said:
http://forum.xda-developers.com/showpost.php?p=63237528&postcount=2
Click to expand...
Click to collapse
Thanks a lot, but it says same as before, KERNEL IS NOT SEANDROID ENFORCING and boot loops. Had to go back to SpaceX for it to boot.

@Class said:
Thanks a lot, but it says same as before, KERNEL IS NOT SEANDROID ENFORCING and boot loops. Had to go back to SpaceX for it to boot.
Click to expand...
Click to collapse
That red notification is normal (and it'll show for ANY modified image.. it IS enforcing.) As for it looping, I'll take a look.. it's possible that my fstab change got munged.
fstab changes are fine... No reason for it to boot loop. Tell me about your configuration... What about it is different from a stock device?

garyd9 said:
That red notification is normal (and it'll show for ANY modified image.. it IS enforcing.) As for it looping, I'll take a look.. it's possible that my fstab change got munged.
Click to expand...
Click to collapse
Thanks ready and waiting. Will post the logcat if the next one fails. Clear cache / dalvik cache did not help.

@Class said:
Thanks ready and waiting. Will post the logcat if the next one fails. Clear cache / dalvik cache did not help.
Click to expand...
Click to collapse
No need to clear dalvik or caches for a kernel change (unless the kernel is installing crap into /system.)
I edited my post above... the fstab is fine (support_scfs is removed.) Can you tell me about your device and the boot loop?
How is your device different from a completely stock one? (recovery, and firmware/system)
Also, please describe the boot loop.

Flashed on my SM-N920I as well. Same result. Went into boot loop after Samsung logo. Flashed Arter to get it to boot again. Not a big deal

https://goo.gl/mWPHUc
LMY47X.N920TUVU2COI5

Odd. Those that looped, which method did you use to flash it? I want to repeat...
Sent from my SM-N920I using Tapatalk

Thanks... Is there one for Tmobile or did I miss it? Either way, thanks for this...

garyd9 said:
Odd. Those that looped, which method did you use to flash it? I want to repeat...
Sent from my SM-N920I using Tapatalk
Click to expand...
Click to collapse
ODIN. The only real difference from stock is TWRP and the kernel.
Edit: Bootloop gets to the Samsung logo then black screens. Logcat does not enable. I have the last_kmesg though. Posting in a minute after it reboots...

last_kmsg.txt:
https://drive.google.com/file/d/0B8l6BzXcGjjma0ZqdElhTGtUTHc/view?usp=sharing
Looks like the crash occurred near:
Code:
<3>[ 29.939533] [4: jbd2/sda16-8: 2943] Aborting journal on device sda16-8.
<3>[ 29.939564] [4: jbd2/sda16-8: 2943] Buffer I/O error on device sda16, logical block 65536
<4>[ 29.939584] [4: jbd2/sda16-8: 2943] lost page write due to I/O error on sda16
<3>[ 29.939604] [4: jbd2/sda16-8: 2943] JBD2: Error -5 detected when updating journal superblock for sda16-8.
<4>[ 29.939653] [4: jbd2/sda16-8: 2943] EXT4-fs (sda16): discard request in group:33 block:1454 count:213 failed with -5
<4>[ 29.939686] [4: jbd2/sda16-8: 2943] EXT4-fs (sda16): discard request in group:417 block:198 count:1 failed with -5
<3>[ 29.949256] [7: kworker/u16:6: 1686] Buffer I/O error on device sda16, logical block 0
<4>[ 29.949277] [7: kworker/u16:6: 1686] lost page write due to I/O error on sda16
<2>[ 29.949296] [7: kworker/u16:6: 1686] EXT4-fs error (device sda16): __ext4_journal_start_sb:62: Detected aborted journal
<2>[ 29.949316] [7: kworker/u16:6: 1686] EXT4-fs (sda16): Remounting filesystem read-only
<0>[ 29.949334] [7: kworker/u16:6: 1686] Kernel panic - not syncing: EXT4-fs panic from previous error
<0>[ 29.949334] [7: kworker/u16:6: 1686]
<0>[ 29.949371] [7: kworker/u16:6: 1686] s3c2410-wdt 10020000.watchdog: watchdog is stopped
<4>[ 29.949394] [7: kworker/u16:6: 1686] CPU: 7 PID: 1686 Comm: kworker/u16:6 Not tainted 3.10.61-5412543 #1
<4>[ 29.949422] [7: kworker/u16:6: 1686] Workqueue: writeback bdi_writeback_workfn (flush-8:0)
<4>[ 29.949441] [7: kworker/u16:6: 1686] Call trace:
<4>[ 29.949466] [7: kworker/u16:6: 1686] [<ffffffc00020da90>] dump_backtrace+0x0/0x110
<4>[ 29.949486] [7: kworker/u16:6: 1686] [<ffffffc00020dbb0>] show_stack+0x10/0x1c
<4>[ 29.949508] [7: kworker/u16:6: 1686] [<ffffffc000a046d0>] dump_stack+0x1c/0x28
<4>[ 29.949527] [7: kworker/u16:6: 1686] [<ffffffc000a023d0>] panic+0xe8/0x220
<4>[ 29.949550] [7: kworker/u16:6: 1686] [<ffffffc000381af0>] __ext4_abort+0x108/0x11c
<4>[ 29.949569] [7: kworker/u16:6: 1686] [<ffffffc00038f75c>] __ext4_journal_start_sb+0x11c/0x158
<4>[ 29.949591] [7: kworker/u16:6: 1686] [<ffffffc0003711e8>] ext4_da_writepages+0x288/0x4f0
<4>[ 29.949613] [7: kworker/u16:6: 1686] [<ffffffc0002b42e8>] do_writepages+0x24/0x40
<4>[ 29.949630] [7: kworker/u16:6: 1686] [<ffffffc00030af84>] __writeback_single_inode+0xb0/0x2a0
<4>[ 29.949648] [7: kworker/u16:6: 1686] [<ffffffc00030c03c>] writeback_sb_inodes+0x1c0/0x35c
<4>[ 29.949664] [7: kworker/u16:6: 1686] [<ffffffc00030c254>] __writeback_inodes_wb+0x7c/0xc4
<4>[ 29.949681] [7: kworker/u16:6: 1686] [<ffffffc00030c420>] wb_writeback+0x184/0x2fc
<4>[ 29.949698] [7: kworker/u16:6: 1686] [<ffffffc00030c91c>] wb_do_writeback+0x19c/0x21c
<4>[ 29.949715] [7: kworker/u16:6: 1686] [<ffffffc00030ca1c>] bdi_writeback_workfn+0x80/0x1e8
<4>[ 29.949734] [7: kworker/u16:6: 1686] [<ffffffc00023c9c4>] process_one_work+0x274/0x3ec
<4>[ 29.949752] [7: kworker/u16:6: 1686] [<ffffffc00023d9bc>] worker_thread+0x1f8/0x318
<4>[ 29.949773] [7: kworker/u16:6: 1686] [<ffffffc000242d58>] kthread+0xac/0xb8
<4>[ 29.949791] [7: kworker/u16:6: 1686] Sched Debug Version: v0.10, 3.10.61-5412543 #1
<4>[ 29.949808] [7: kworker/u16:6: 1686] ktime : 29940.780597
<4>[ 29.949825] [7: kworker/u16:6: 1686] sched_clk : 29949.787718
<4>[ 29.949841] [7: kworker/u16:6: 1686] cpu_clk : 29949.787843
<4>[ 29.949857] [7: kworker/u16:6: 1686] jiffies : 4294940290
There are lines closer to the top with complaints about the file system...

garyd9 said:
Odd. Those that looped, which method did you use to flash it? I want to repeat...
Sent from my SM-N920I using Tapatalk
Click to expand...
Click to collapse
I used Philz recovery... Same thing, boots to Samsung logo and then restarts

guaneet said:
https://goo.gl/mWPHUc
LMY47X.N920TUVU2COI5
Click to expand...
Click to collapse
Going to hold off putting anymore together until I repeat/resolve the boot looping...
It's odd, as I'm not having the problem at all on a n920i...

Those with bootloops - are you running encryption?
@@Class, can you please run the following command (from a shell - either adb or android terminal - doesn't matter) and send me the output?
Code:
ls -l /dev/block/platform/15570000.ufs/by-name/
I just need to make sure that the partitions are mapped the same as mine.
What I'm really not understanding is the person with n920i having the bootloop. There MUST be something different about their device compared to mine (also an 'i') and the only thing I can think of would be encryption...
It's annoying when I test something for 2 days and it's running perfectly, and then it completely blows up for other people. (Not your fault... just annoying to me.)
A general question: Is it working properly for ANYONE (other than me)? Is it only boot looping for 2 people?
If I can't repeat a problem, I need as many details as I can get to blindly feel my way though... Too much information is significantly better than not enough. (Of course, I can only take guesses right now as to which specific details are significant.)
Gary

Not encrypted. Also my link above contains the entire last_kmsg.txt, maybe its more helpful.
Code:
[email protected]:/ # ls -l /dev/block/platform/15570000.ufs/by-name/
lrwxrwxrwx root root 2015-10-10 21:44 BOOT -> /dev/block/sda5
lrwxrwxrwx root root 2015-10-10 21:44 BOTA0 -> /dev/block/sda1
lrwxrwxrwx root root 2015-10-10 21:44 BOTA1 -> /dev/block/sda2
lrwxrwxrwx root root 2015-10-10 21:44 CACHE -> /dev/block/sda15
lrwxrwxrwx root root 2015-10-10 21:44 CPEFS -> /dev/block/sdd1
lrwxrwxrwx root root 2015-10-10 21:44 DNT -> /dev/block/sda10
lrwxrwxrwx root root 2015-10-10 21:44 EFS -> /dev/block/sda3
lrwxrwxrwx root root 2015-10-10 21:44 OTA -> /dev/block/sda7
lrwxrwxrwx root root 2015-10-10 21:44 PARAM -> /dev/block/sda4
lrwxrwxrwx root root 2015-10-10 21:44 PERSDATA -> /dev/block/sda13
lrwxrwxrwx root root 2015-10-10 21:44 PERSISTENT -> /dev/block/sda11
lrwxrwxrwx root root 2015-10-10 21:44 RADIO -> /dev/block/sda8
lrwxrwxrwx root root 2015-10-10 21:44 RECOVERY -> /dev/block/sda6
lrwxrwxrwx root root 2015-10-10 21:44 STEADY -> /dev/block/sda12
lrwxrwxrwx root root 2015-10-10 21:44 SYSTEM -> /dev/block/sda14
lrwxrwxrwx root root 2015-10-10 21:44 TOMBSTONES -> /dev/block/sda9
lrwxrwxrwx root root 2015-10-10 21:44 USERDATA -> /dev/block/sda16
[email protected]:/ #

@Class said:
Not encrypted. Also my link above contains the entire last_kmsg.txt, maybe its more helpful.
Click to expand...
Click to collapse
Thanks.. I'm going to have to spend some time trying to work this out. Damn puzzles. Oh, I made a copy of that kmesg, so you don't need to keep it around if you don't want to.
Thanks
Gary

On that '8' variant, the partition table is different from what i expected. That might explain the loops.. will put another image together tomorrow to test the theory...
That doesn't explain the 'i' variant loop, as it SHOULD have the same partition table as my device.
Sent from my SM-N920I using Tapatalk

Related

[Q] OneNAND Wear Leveling

512MB SLC Nand, and (384MB LPDDR [2 piece 166Mhz Mobile DDR] + 128 MB Nand) OneNand, all packaged on a MPC with the PowerVr+Hummingbird core.
Then a 16GB piece MoviNand (samsung's version of MLC based eMMC), all manufactured by samsung.
Click to expand...
Click to collapse
This is the stuff we have in the SGS. We know (well, Samsung claims) that the MoviNAND has wear leveling, so replacing the RFS in /data is a no brainer. However, a lot of Linux/Android is sitting inside the /system partition.
/dev/block/stl9 /system rfs ro,relatime,vfat,log_off,check=no,gid/uid/rwx,iochar
set=utf8 0 0
Click to expand...
Click to collapse
STL9 should be the OneNAND described above, and it is shared across /system, /cache, /dbdata as stl9, stil11 and stl10 (same device according to dmesg)
From wikipedia, some info on what SLC (Single-Level Cell) NAND is:
Single-level cell
Flash memory stores data in individual memory cells, which are made of floating-gate transistors. Traditionally, one bit of data was stored in each cell in so-called single-level cells, or SLC flash memory. SLC memory has the advantage of faster write speeds, lower power consumption and higher cell endurance. However, because it stores less data per cell, it costs more per megabyte of storage to manufacture. Due to faster transfer speeds, SLC flash technology is used in high-performance memory cards.
SLC NAND Flash is typically rated at about 100K cycles (Samsung OneNAND KFW4G16Q2M)
Click to expand...
Click to collapse
Basically, if we can determine if the OneNAND chip has a memory controller, then it is more than likely going to have wear leveling too. Or we could try and dig through the RFS source to see if wear leveling is being performed on the OneNAND (not a guarantee that it's required, though).
So this question is aimed at people who like investigating / have inside samsung info / have huge hardware nand knowledge:
Is there wear leveling on the OneNAND chip inside the SGS?
Here is some (likely irrelevant, but maybe it will help someone work it out?) information that appears in dmesg in regards to the OneNAND device:
Code:
1.
<4>[ 2.062865] [BIF:IN ] ++FSR_BML_Init(nFlag: 0x0)
2.
<4>[ 2.062887] [PAM: ] ++FSR_PAM_Init
3.
<4>[ 2.063667] [PAM: ] OneNAND physical base address : 0xb0000000
4.
<4>[ 2.063690] [PAM: ] OneNAND virtual base address : 0xe8980000
5.
<4>[ 2.063711] [PAM: ] OneNAND nMID=0xec : nDID=0x50 Page size=4
6.
<4>[ 2.063725] [PAM: ] --FSR_PAM_Init
7.
<4>[ 2.063815] [BIF: ] FSR VERSION: FSR_1.2.1p1_b129_RTM
8.
<4>[ 2.063841] [OND:INF] FSR_OND_4K_Open(nDev:0, pParam:0xc4f83e00, nFlag:0x00000000) / 1033 line
9.
<4>[ 2.063859] pstOND4kCxt->nBaseAddr: 0xe8980000
10.
<4>[ 2.063875] nDev=0, nMID=0x00ec, nDID=0x0050, nVID=0x013e
11.
<4>[ 2.063891] [OND:INF] pstOND4kCxt->nSysConf1:0xf006 / 1116 line
12.
<4>[ 2.063906] [OND:INF] pstOND4kCxt->nBlksForSLCArea[0]:2048 / 1133 line
13.
<4>[ 2.064097] [OND:INF] Transfered 4096 bytes to DataRAM in 162 usec
14.
<4>[ 2.064111] calculated Word Write Cycle: 78 nano second
15.
<4>[ 2.064256] [OND:INF] Transfered 4096 bytes from DataRAM in 129 usec
16.
<4>[ 2.064270] calculated Word Read Cycle: 62 nano second
17.
<4>[ 2.064284] [OND:INF] pstOND4kCxt->nIntID :0x0000 / 1231 line
18.
<4>[ 2.064298] [OND:INF] 1X_CACHEPGM CMD : 0x007f
19.
<4>[ 2.064309] [OND:INF] 1X_PLOAD CMD : 0x0003
20.
<4>[ 2.064592] [BBM:INF] Scan from 2004 to 2047 to find BML meta blocks (die: 0)
21.
<4>[ 2.064816] [BBM:INF] ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
22.
<4>[ 2.066853] [BBM:INF] ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
23.
<4>[ 2.068935] [BBM:INF] ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
24.
<4>[ 2.070972] [BBM:INF] ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
25.
<4>[ 2.073042] [BBM:INF] a5a5 a5a5 ffff
26.
<4>[ 2.098443] [BBM: ] << DevNO:0, DieNO: 0 MAPPING INFORMATION >>
27.
<4>[ 2.098457] [BBM: ] Bad Mark Information
28.
<4>[ 2.098469] [BBM: ] - Bad Mark (0x2222) by erase error
29.
<4>[ 2.098482] [BBM: ] - Bad Mark (0x4444) by write error
30.
<4>[ 2.098725] [BBM: ] 0000: Sbn[ 98]==>Rbn[ 2042] / BadMark: 0x0000 / SLC / Lock: UL
31.
<4>[ 2.098748] [BBM: ] << Total : 1 BAD-MAPPING INFORMATION >>
32.
<4>[ 2.098763] [BIF: ] nPartition Information (nVol : 0)
33.
34.
<4>[ 2.098775] nVer : 0xffffffff
35.
<4>[ 2.098789] 00 / nID:0x00 / nAttr:0x00001002 / 1stVun: 0 / Units: 1
36.
<4>[ 2.098807] 01 / nID:0x01 / nAttr:0x00001002 / 1stVun: 1 / Units: 1
37.
<4>[ 2.098825] 02 / nID:0x20 / nAttr:0x00001101 / 1stVun: 2 / Units: 40
38.
<4>[ 2.098843] 03 / nID:0x03 / nAttr:0x00001002 / 1stVun: 42 / Units: 5
39.
<4>[ 2.098861] 04 / nID:0x04 / nAttr:0x00001002 / 1stVun: 47 / Units: 5
40.
<4>[ 2.098879] 05 / nID:0x21 / nAttr:0x00001101 / 1stVun: 52 / Units: 20
41.
<4>[ 2.098896] 06 / nID:0x06 / nAttr:0x00001002 / 1stVun: 72 / Units: 30
42.
<4>[ 2.098914] 07 / nID:0x07 / nAttr:0x00001002 / 1stVun: 102 / Units: 30
43.
<4>[ 2.098932] 08 / nID:0x22 / nAttr:0x00001101 / 1stVun: 132 / Units: 1146
44.
<4>[ 2.098950] 09 / nID:0x23 / nAttr:0x00001101 / 1stVun: 1278 / Units: 536
45.
<4>[ 2.098968] 10 / nID:0x24 / nAttr:0x00001101 / 1stVun: 1814 / Units: 140
46.
<4>[ 2.098986] 11 / nID:0x11 / nAttr:0x00001002 / 1stVun: 1954 / Units: 50
47.
<4>[ 2.099005] [BBM:INF] The registered blocks in ERL are handled
48.
<4>[ 2.099018] [BBM:INF] (number of blocks: 0)
49.
<4>[ 2.109453] BML: Registered BML Driver.
50.
<4>[ 2.146634] [BIF:IN ] ++FSR_BML_Init(nFlag: 0x0)
51.
<4>[ 2.146659] [BIF: ] FSR_BML_Init(nFlag:0x0, nRe:FSR_BML_ALREADY_INITIALIZED) / 1034 line
52.
<4>[ 2.156468] FSR: Registered STL Driver.
53.
<4>[ 2.326875] [BIF: ] FSR VERSION: FSR_1.2.1p1_b129_RTM
54.
<4>[ 2.326908] [BIF: ] FSR_BML_Open(nVol:0, nFlag:0x0, nOpenCnt:2) / 1176 line
55.
<4>[ 2.326986] [SIF:INF] ===> STL Clst[ 1] Scan Root Info
56.
<4>[ 2.327780] [SIF:INF] ===> STL Zone[ 1, 0] Open Zone Meta
57.
<4>[ 2.328963] [SIF:INF] Latest Header Index ( 1) Vbn ( 3)
58.
<4>[ 2.329912] [SIF:INF] Latest Header Clean Page Offset ( 4)
59.
<4>[ 2.329927] [SIF:INF] POR write timer : 0x74
60.
<4>[ 2.330144] [SIF:INF] Latest Context BlockIdx ( 1) Offset ( 3) Vpn ( 195)
61.
<4>[ 2.330371] [SIF:INF] Number of Free Block ( 4)
62.
<4>[ 2.330385] [SIF:INF] Active Log List : Num ( 1)
63.
<4>[ 2.330399] [SIF:INF] ===> STL Zone[ 1, 0] Open Zone Post
64.
<4>[ 2.330614] [SIF:INF] Partition [0, 21] open is success
65.
<4>[ 2.339451] [SIF:INF] Zone[ 1, 0]: nDgn( 2) nVbn( 12) S( 0)-E( 11) nCPOffs( 12)
66.
<6>[ 2.354295] param_init
67.
<6>[ 2.363111] load_lfs_param_value: param.blk read successfully.
68.
<4>[ 2.365465] [BIF: ] FSR VERSION: FSR_1.2.1p1_b129_RTM
69.
<4>[ 2.365497] [BIF: ] FSR_BML_Open(nVol:0, nFlag:0x0, nOpenCnt:3) / 1176 line
70.
<4>[ 2.365537] [SIF:INF] ===> STL Clst[ 2] Scan Root Info
71.
<4>[ 2.366343] [SIF:INF] ===> STL Zone[ 2, 0] Open Zone Meta
72.
<4>[ 2.377062] [SIF:INF] Latest Header Index ( 16) Vbn ( 18)
73.
<4>[ 2.379315] [SIF:INF] Latest Header Clean Page Offset ( 11)
74.
<4>[ 2.379330] [SIF:INF] POR write timer : 0x62
75.
<4>[ 2.379969] [SIF:INF] Latest Context BlockIdx ( 16) Offset ( 10) Vpn ( 1162)
76.
<4>[ 2.380206] [SIF:INF] Number of Free Block ( 2)
77.
<4>[ 2.380219] [SIF:INF] Active Log List : Num ( 8)
78.
<4>[ 2.380234] [SIF:INF] ===> STL Zone[ 2, 0] Open Zone Post
79.
<4>[ 2.381760] [SIF:INF] Partition [0, 22] open is success
[REF] Public documents / information about RFS and XSR
neldar said:
[REF] Public documents / information about RFS and XSR
Click to expand...
Click to collapse
Thanks, might help! This is more of a hardware issue though, and what we really need is some kind of spec on the Samsung OneNAND in the SGS. Not sure if such a spec exists, but maybe someone knows..?
EDIT:
Well we know that
(1) MoviNAND is meant to have wear leveling at the hardware level.
(2) MoviNAND is using XSR to communicate between linux and the hardware. (<-- Is this true?)
(3) XSR has wear leveling built in.
Does this mean that wear leveling is being done twice on the MoviNAND?
Also we know
(2) OneNAND is using XSR to communicate between linux and the hardware. (<-- Is this true?)
(3) XSR has wear leveling built in.
XSR is under the filesystem level, and exists in the kernel driver (true?), so therefore replacing RFS with anything else still leaves us using XSR (true?)
In that case, the OneNAND should have wear leveling no matter what filesystem is used, because the wear leveling is done in software, inside the XSR.
Can anybody confirm or deny any of this please?
MoviNAND has an MMC/SD interface. Which means it will show up as a normal block device, like any SD card will.
If you look at the source of XSR (it is GPL code, and is in the Samsung patch set - thanks Samsung!!) you will notice that it has a very low level interface specific to OneNAND, with configuration data, caring about what data is on what specific silicon chip (die), what goes into SLC and what in MLC, and so on.
So I do not think XSR is involved in MoviNAND, as it is no fit for the device from what I've seen in the code comments.
jutezak said:
MoviNAND has an MMC/SD interface. Which means it will show up as a normal block device, like any SD card will.
If you look at the source of XSR (it is GPL code, and is in the Samsung patch set - thanks Samsung!!) you will notice that it has a very low level interface specific to OneNAND, with configuration data, caring about what data is on what specific silicon chip (die), what goes into SLC and what in MLC, and so on.
So I do not think XSR is involved in MoviNAND, as it is no fit for the device from what I've seen in the code comments.
Click to expand...
Click to collapse
Thanks for that!
So I guess the question then is: If we replace RFS with EXT, does the EXT still run on top of XSR without issue? If so, then wear leveling is taken care of.
RyanZA said:
Thanks for that!
So I guess the question then is: If we replace RFS with EXT, does the EXT still run on top of XSR without issue? If so, then wear leveling is taken care of.
Click to expand...
Click to collapse
Yes the STL in the XSR does the wear leveling, but we do not know if the RFS interact with wear leveling.
See this figure:
{
"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"
}
from: Samsung: XSR v1.6.1 Porting Guide
We have access to the nand through the STL with wear leveling (virtual block device) and we could get access to the nand through BML ("direct" block access).
neldar said:
Yes the STL in the XSR does the wear leveling, but we do not know if the RFS interact with wear leveling.
See this figure:
from: Samsung: XSR v1.6.1 Porting Guide
We have access to the nand through the STL with wear leveling (virtual block device) and we could get access to the nand through BML ("direct" block access).
Click to expand...
Click to collapse
Thanks! So basically it comes down to determining if the RFS filesystem does some special talking to the XSR. I guess that could be as easy as searching the RFS driver for any interactions with XSR. Do you know what device the XSR is, or what channels RFS might use to talk to it with? This is out of my depth, I'm afraid, so hopefully someone can step in and point us in the right direction.
RFS does not talk special to XSR, it sees standard block device interface so XSR is transparent to RFS. Think of XSR as FTL (Flash translation layer) where it interacts to the NAND flash through LLD except it has wear leveling to translate virtual to physical addresses after wear leveling algorithm / table
raspdeep said:
RFS does not talk special to XSR, it sees standard block device interface so XSR is transparent to RFS. Think of XSR as FTL (Flash translation layer) where it interacts to the NAND flash through LLD except it has wear leveling to translate virtual to physical addresses after wear leveling algorithm / table
Click to expand...
Click to collapse
Thanks! So it's safe to change /dbdata and /system over to EXT - awesome!
Check Secondary Bootloader code.
Richthofen said:
Check Secondary Bootloader code.
Click to expand...
Click to collapse
Thanks for the cryptic hint! I think!
Anyway... I didn't know the bootloader code was public. Unless it's included somewhere in the kernel? I can't seem to find it.
"And repartition may damage wear-level of the device"
"Metal" WL for both AP NAND and eMMC afaik.
Richthofen said:
"And repartition may damage wear-level of the device"
"Metal" WL for both AP NAND and eMMC afaik.
Click to expand...
Click to collapse
AP NAND being the OneNAND, and eMMC being the MoviNAND, correct? So repartition may damage the wear leveling in the MoviNAND? That's not such good news, but I guess it does have a 'may'.
I'd guess that this refers to the current state of wear leveling being wiped when you do a repartition. I don't think that's really a problem though - main use for wear leveling is where one block would be re-written many many times in a row. If we are repartitioning the whole device, then that means each block will get only 1 write, and then wear leveling will start over again.
At any rate, the quote there seems to imply that wear leveling on /data (movinand) is the same as wear leveling on /system (onenand).
EDIT: Also to add: the recovery mode and kernel checks repartition the partitions into fat32/rfs if they detect something wrong. So the stock kernel isn't following that advice very closely, as it defaults to repartitioning if anything goes wrong.
jutezak said:
MoviNAND has an MMC/SD interface. Which means it will show up as a normal block device, like any SD card will.
If you look at the source of XSR (it is GPL code, and is in the Samsung patch set - thanks Samsung!!) you will notice that it has a very low level interface specific to OneNAND, with configuration data, caring about what data is on what specific silicon chip (die), what goes into SLC and what in MLC, and so on.
So I do not think XSR is involved in MoviNAND, as it is no fit for the device from what I've seen in the code comments.
Click to expand...
Click to collapse
Did Samsung change the licensing?
In the RFS faq (http://www.samsung.com/global/business/semiconductor/products/fusionmemory/Products_FAQs_RFS.html) they say RFS and XSR are non-gpl:
RFS package includes two parts - bootloader and kernel modules.
The former includes Tiny-Bml that is a GPL code.
Therefore you can open this code.
The latter includes three kinds of modules ; Tiny-bml, RFS and XSR. Tiny-bml is a GPL code that should be statically linked into kernel and root file system that is stored into OneNAND can be initialized using this.
Both XSR and RFS are non-GPL codes that should be dynamically linked into kernel using insmod after root file system was initialized.
In conclusion, Tiny-Bml that is included in both U-boot and Kernel is an open source code. And both XSR and RFS should be built as a module not to open.
Click to expand...
Click to collapse
What about converting /data /system and others thing to xsr as filesystem?
RFS is not open source. It's samsung proprietary garbage with serious fsync flaws. It uses Tiny-Bml as a GPL compatibility layer in the linux kernel.
phzi said:
RFS is not open source. It's samsung proprietary garbage with serious fsync flaws. It uses Tiny-Bml as a GPL compatibility layer in the linux kernel.
Click to expand...
Click to collapse
That's what it seems, reading the faq, yes.
Not really sure what is the low level driver (the other component XSR interfaces with) license is either: http://www.samsung.com/global/business/semiconductor/products/fusionmemory/Products_DownloadLLD.html
I am not an expert nor i have clear understanding about hardware or any fs. But as a user or high level programmer, i doubt that any fs has to deal with the hardware directly. Personally i believe that any fs is just a table containing lots of data and blocks, while other drivers r used to talk to the hardware layer.
I dono if i am correct and i am happy to learn and listen
Maybe it's worth trying to get an answer directly from Samsung about this? I think there was an email address for samsung's head of development floating around these forums

[Tutorial] Chainfire 3D Installation (Root necessary)

Original tutorial found here http://www.htcmania.com/showthread.php?t=310924
This is a rough translation and I haven't tested it yet. Use at your own discretion.
If someone could natively translate this I'd appreciate it.
Prerequisites:
Root access/SDE Enabled
3.2.78 EXT4 Rom NOT SQUASHFS
Root Explorer (Maybe ES File Manager could work also?)
Chainfire 3D
Plugins for Chainfire 3D
Open root explorer, go to the folder /system/app and look for the application: GravitronLWP.apk
Move it to the storage folder or the root of the sdcard and exit.
If you haven't already, open the market.
Download and install Chainfire 3D.
https://market.android.com/details?id=eu.chainfire.cf3d
Open the Chainfire 3D. It will request Root Access, checkmark the box to always accept and hit accept.
Go to first screen of the application:
{
"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"
}
Once on this screen click on "CF3D driver"
On the next screen click on "Install".
The application will warn that will begin to install and then it will reboot.
Pressing accept again "Install"
We'll see how to execute some commands and restart the terminal
Once you have restarted the terminal, you have to download plugins from a pc from this link http://www.mediafire.com/?jmyx1mldkfwn11o
We will see that we have downloaded a compressed file. Now click the right mouse button and unzip it on your PC
3 appear. Zip files, which are the need
We connect the tablet to the PC via USB
We spent the 3 files. Zip we have unzipped to the internal SD
It is important that they are at the root of the SD, and not in any folder
Once past the files, disconnect the USB tablet
Now we return to the application Chainfire3D. We opened it again
We will see that on the main screen, at the bottom it says "Install plugins / shaders". Press there.
Just make a file read and take us to the next screen
Now we are pressing on each of the 3. Zip files that are in the "Install plugins and shaders"
When we go giving one to one, without running and slowly, we agree on "OK" after uploading files.
Once complete return to the previous screen with the "back"
We return to the home screen
Where it says "Default OpenGL setting" press
Appear in a new screen
Where it says "Use Plugin" select and open the NEXT screen:
Now you can choose which plugin you want to use for each game, either Nvidia Tegra 2, Qualcomm or PowerVR.
Once selected, leave the application and restart the tablet for safety.
You are now ready to use whatever game you want on your tablet. Enjoy!
Failure to do this correctly may or may not result in a bootloop. Worst case scenario, you'd have to reflash.
Google translate seems readable
http://translate.google.com/transla...velopers.com/showthread.php?t=1433946&act=url
zando2712 said:
http://translate.google.com/transla...velopers.com/showthread.php?t=1433946&act=url
Click to expand...
Click to collapse
Yea I guess that works to an extent. Thanks.
heyyy ese tutorial es mio.
jejeje.
un saludo
@lauri19david Muchas gracias, amigo!
Help for those having trouble installing plugins!
I have successfully rooted my Archos 80 G9 to 3.2.79 (thanks, @surdu_petru, @letima and all who contributed!), and I was able to install Chainfire3D and driver, but the Chainfire3D app would not see the plugins. I tried placing them at root ( "/" ) and on the sdcard root ( "/mnt/sdcard" ) and rebooting the device several times, but each time Chainfire3D comes back with "No files found!"
After several hours of frustration and lost productivity, I carefully watched the list of folders being scanned as it flashed by and noticed that one of the folders being scanned was TitaniumBackup. So I copied the plugin files to the TitaniumBackup folder:
Code:
adb push libGLEMU_NVIDIA.zip /data/media/TitaniumBackup
adb push libGLEMU_POWERVR.zip /data/media/TitaniumBackup
adb push libGLEMU_QUALCOMM.zip /data/media/TitaniumBackup
I ran the "Install Plugins" step again, et voila! Plugins galore!!!
Hope this helps someone else in their quest for Chainfire3D glory!
- Stealth Dave
Deleted because i posted nonsense
Have fun,
scholbert
scholbert said:
For the Archos tablet using OMAP processors including PowerVR GPU you'll need the POWERVR plugin only.
The others are meaningless on this platform.
Click to expand...
Click to collapse
I'm curious why that is, and perhaps it's my understanding of how the plugin system for Chainfire3D works. I thought that the plugins emulate missing architecture, so if your tablet uses a PowerVR GPU (which the Archos G9 series does), isn't that the plugin you wouldn't need since it's supported natively?
I'm using this post for reference: forum [dot] mobilism [dot] org/viewtopic.php?p=783945#783945
(Sorry, I can't post links yet. Still a 'n00b'.)
Hi stealthdave!
stealthdave said:
I'm curious why that is, and perhaps it's my understanding of how the plugin system for Chainfire3D works. I thought that the plugins emulate missing architecture, so if your tablet uses a PowerVR GPU (which the Archos G9 series does), isn't that the plugin you wouldn't need since it's supported natively?
Click to expand...
Click to collapse
Uuuups i guess you're right... just grabbed some more information about these specific plugins.
I'm sorry for confusing you
Cheers,
scholbert
dead space loaded before i installed chainfire however graphics were all white, nova 2 loads but will force close as soon as video intro stops however first time i installed it loaded and i played for about 20 secs before it force closed, what programs have been benefited by the installation of chainfire, what works now that didnt before?
soulclaimed said:
dead space loaded before i installed chainfire however graphics were all white, nova 2 loads but will force close as soon as video intro stops however first time i installed it loaded and i played for about 20 secs before it force closed, what programs have been benefited by the installation of chainfire, what works now that didnt before?
Click to expand...
Click to collapse
Chainfire allows many tegra-specific games to work. Since I installed it I'm able to play Fruit Ninja THD version. If you want the benefits of chainfire without compromising your previously working games you change the plugin to "NONE" under the "Per-app OpenGL settings" for your specific games in the chainfire app.
Edit: Well in theory, that should work. If not, you can switch back and forth manually in the "Default OpenGL settings".
I'm using the NVIDIA driver with CF3D
I go into the NVIDIA Tegra Zone, search for Fruit Ninja THD, hit on the Get it NOW and when it leads to the Android Market it says: Your device is not compatible with this element!
How can I install this game(s) of NVIDIA?
I still can't get the nvidia tegra zone app to install neither play dark meadow...
Anyone has any idea why?
nice tutorial
thanks for the nice tutorials, root and everything were done successfully, unfortunately I could run nothing new which I wanted before, but it didn't screw up anything at all... I think I'll keep changes it can be useful when it comes to developing my own apps... my 3 fav games that I could run originally and now too without problems: GTA3 1.0.2, ShadowGun, Skateboard Party (MikeV stuff)
if anyone has any concrete method to make work Modern Combat 2, NOVA 2-3 or 9MM, I'd lovely hear that
CF3d won't install
Hi all,
Downloaded Chainfire3d from the Play Store yesterday evening and tried to install, but even though no error messages are displayed at all during the installation process (either standard or using the CWM v3+ option), the results are always the same; after the reboot, when restarting CF3d, it says that the driver still needs to be installed.
I have the 250gb version with surdu_petru's unaltered but rooted 407 firmware installed (the update from yesterday evening). ES File Explorer does not complain when I set the /system folder to readwrite so I guess that means that the device is actually rooted, but maybe there is another way to check.
Unfortunately I do not have the possibility to follow the installation process with ADB logcat from my computer as I cannot seem to get the ADB drivers to work for this device (it does work with my Samsung Galaxy Spica)
About adb: try "adb over wi-fi" from playstore.
solved
Thanks Dragos!
edit:
The problem was solved after reinstalling the kernel; seems that this kernel problem caused the installation to fail. Below the logcat entries related to the cf3d installation that i thought pointed to the underlying problem:
/edit
What I found in logcat:
---------------------------------------------------------
number one (these few lines repeat a couple of times during the installation process):
D/AndroidRuntime( 3347): >>>>>> AndroidRuntime START com.android.internal.os.RuntimeInit <<<<<<
D/AndroidRuntime( 3347): CheckJNI is OFF
D/SpxUtils( 3347): Sys_pk_build_product_key [6KGNU8UMT5TDWE] [6KGN-U8UM-T5TD-WE]
D/AndroidRuntime( 3347): Calling main entry com.android.commands.am.Am
D/AndroidRuntime( 3347): Shutting down VM
I/AndroidRuntime( 3347): NOTE: attach of thread 'Binder Thread #3' failed
D/dalvikvm( 3347): GC_CONCURRENT freed 98K, 81% free 489K/2560K, paused 0ms+1ms
D/su ( 3345): 10093 eu.chainfire.cf3d executing 0 /system/bin/sh using shell /system/bin/sh : sh
E/su ( 3359): sudb - Opening database
E/su ( 3359): sudb - Database opened
E/su ( 3359): sudb - Database closed
---------------------------------------------------------
number two (end of logcat until reboot):
D/su ( 3398): 10093 eu.chainfire.cf3d executing 0 /system/bin/sh using shell /system/bin/sh : sh
I/cat ( 664): <6>[ 722.407531] SysRq : Emergency Remount R/O
I/cat ( 664): <6>[ 722.413146] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
I/cat ( 664): <6>[ 722.440338] EXT4-fs (mmcblk0p4): re-mounted. Opts: (null)
I/cat ( 664): <3>[ 722.457061] Buffer I/O error on device loop0, logical block 139265
I/cat ( 664): <4>[ 722.457305] lost page write due to I/O error on loop0
I/cat ( 664): <3>[ 722.457794] JBD2: I/O error detected when updating journal superblock for loop0-8.
I/cat ( 664): <3>[ 722.458160] Buffer I/O error on device loop0, logical block 139265
I/cat ( 664): <4>[ 722.458587] lost page write due to I/O error on loop0
I/cat ( 664): <3>[ 722.458892] JBD2: I/O error detected when updating journal superblock for loop0-8.
I/cat ( 664): <3>[ 722.459503] Buffer I/O error on device loop0, logical block 139265
I/cat ( 664): <4>[ 722.459930] lost page write due to I/O error on loop0
I/cat ( 664): <3>[ 722.461059] JBD2: I/O error detected when updating journal superblock for loop0-8.
I/cat ( 664): <3>[ 722.461578] Buffer I/O error on device loop0, logical block 139265
I/cat ( 664): <4>[ 722.461853] lost page write due to I/O error on loop0
I/cat ( 664): <3>[ 722.463592] JBD2: I/O error detected when updating journal superblock for loop0-8.
I/cat ( 664): <3>[ 722.463958] Buffer I/O error on device loop0, logical block 1
I/cat ( 664): <4>[ 722.464385] lost page write due to I/O error on loop0
I/cat ( 664): <6>[ 722.470794] EXT4-fs (loop0): re-mounted. Opts: (null)
D/PowerManagerService( 762): HARD DRIVE UEVENT: {SUBSYSTEM=platform, DEVPATH=/devices/platform/jm20329, SEQNUM=1597, ACTION=change, DRIVER=jm20329, MODALIAS=platform:jm20329}
I/cat ( 664): <4>[ 722.484100] jm20329_wakeup
I/cat ( 664): <6>[ 722.900726] usb 1-1: new high speed USB device number 9 using ehci-omap
I/cat ( 664): <6>[ 723.064849] usb 1-1: New USB device found, idVendor=0424, idProduct=2512
I/cat ( 664): <6>[ 723.064910] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
I/cat ( 664): <6>[ 723.066833] hub 1-1:1.0: USB hub found
I/cat ( 664): <6>[ 723.067810] hub 1-1:1.0: 2 ports detected
I/cat ( 664): <6>[ 723.354095] usb 1-1.1: new high speed USB device number 10 using ehci-omap
D/UsbSettingsManager( 762): usbDeviceAttached, sending Intent { act=archos.intent.action.USB_DEVICE_ATTACHED (has extras) }
---
I/cat ( 664): <6>[ 723.479003] usb 1-1.1: New USB device found, idVendor=152d, idProduct=2329
I/cat ( 664): <6>[ 723.479125] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=5
I/cat ( 664): <6>[ 723.479187] usb 1-1.1: Product: USB to ATA/ATAPI bridge
I/cat ( 664): <6>[ 723.479309] usb 1-1.1: Manufacturer: JMicron
I/cat ( 664): <6>[ 723.479370] usb 1-1.1: SerialNumber: 801130168383
I/cat ( 664): <6>[ 723.481536] ums-jm20329 1-1.1:1.0: Quirks match for vid 152d pid 2329: 8020
D/PowerManagerService( 762): HARD DRIVE UEVENT: {SUBSYSTEM=platform, DEVPATH=/devices/platform/jm20329, SEQNUM=1604, ACTION=online, DRIVER=jm20329, MODALIAS=platform:jm20329}
I/cat ( 664): <6>[ 726.057098] EXT4-fs (sda1): re-mounted. Opts: (null)
I/cat ( 664): <4>[ 726.062408] Emergency Remount complete
D/WatchdogDaemon( 682): CPU temperature: 60400
D/WatchdogDaemon( 682): Watchdog is happy
D/PowerManagerService( 762): HARD DRIVE UEVENT: {SUBSYSTEM=platform, DEVPATH=/devices/platform/jm20329, SEQNUM=1607, ACTION=offline, DRIVER=jm20329, MODALIAS=platform:jm20329}
I/cat ( 664): <4>[ 747.931945] Sending hdd to sleep
I/cat ( 664): <4>[ 747.937744] jm20329_do_sleep
I/cat ( 664): <6>[ 748.521209] usb 1-1.1: USB disconnect, device number 10
I/cat ( 664): <6>[ 748.804840] mgr_blank while GO is set
I/cat ( 664): <7>[ 748.835876] panel_disable [xga8]
BTW... there is no need to move the gravitron live wallpaper... just install the app and install the driver
I have chainfire 3d installed but all my games crash after licence check. Anyone know why?

[Q] Internal SD corruption (format/deletion is not helping)

Hello everybody. I am facing INTERNAL SD CORRUPTION problem and hope this is the right thread where to post as many such articles have been found here.
When I try to format internal SD card via Windows (no Quick mode), repartition via adb, format via CWM, delete internal SD card via rm –rf, it does not work. File seems to be deleted until next mount of /sdcard or reflash.
I have tried many ROMs including PIT 512 file to reflash via Odin 1.3 or 1.85. Some of them stucked, some let me boot into Android but had problems with crashing applications.
JVU-RE, Ficeto JVB, Darky ROM 10.2 RE, ROMS with XWJVH/XXJVO/NEEJV3; XXJP2/XXJP2/OXAJP2; XXJVU/XXJVU/OXAJVU
I have been searching and trying for nearly a week. Would buy beers/whiskeys to the ONE who can help me to solve that. Thanks a lot for any valuable hint how to correct that.
FDISK
~ # fdisk -l /dev/block/mmcblk0p1
Disk /dev/block/mmcblk0p1: 6056 MB, 6056542208 bytes
4 heads, 16 sectors/track, 184831 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Device Boot Start End Blocks Id System
~ # fdisk -l /dev/block/mmcblk0p2
Disk /dev/block/mmcblk0p2: 2013 MB, 2013265920 bytes
4 heads, 16 sectors/track, 61440 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Device Boot Start End Blocks Id System
FSTAB
~ # more /etc/fstab
/dev/block/stl11 /cache rfs rw
/dev/block/mmcblk0p2 /data rfs rw
/dev/block/stl10 /datadata rfs rw
/dev/block/stl9 /system rfs rw
/dev/block/mmcblk0p1 /sdcard vfat rw
MOUNT
~ # mount
rootfs on / type rootfs (rw,relatime)
tmpfs on /dev type tmpfs (rw,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
/dev/block/stl6 on /mnt/.lfs type j4fs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
/dev/block/stl3 on /efs type rfs (rw,nosuid,nodev,relatime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8)
/sys/kernel/debug on /sys/kernel/debug type debugfs (rw,relatime)
/dev/block/mmcblk0p1 on /sdcard type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
DEV/BLOCK DIR
/dev/block # ls
bml0!c bml7 loop7 ram13 ram9 stl7 tfsr4
bml1 bml8 mmcblk0 ram14 stl1 stl8 tfsr5
bml10 bml9 mmcblk0p1 ram15 stl10 stl9 tfsr6
bml11 loop0 mmcblk0p2 ram2 stl11 tfsr0!c tfsr7
bml12 loop1 platform ram3 stl12 tfsr1 tfsr8
bml2 loop2 ram0 ram4 stl2 tfsr10 tfsr9
bml3 loop3 ram1 ram5 stl3 tfsr11
bml4 loop4 ram10 ram6 stl4 tfsr12
bml5 loop5 ram11 ram7 stl5 tfsr2
bml6 loop6 ram12 ram8 stl6 tfsr3
/dev/block # ls –l | grep mmcblk
brw------- 1 root root 179, 0 Apr 29 12:04 mmcblk0
brw------- 1 root root 179, 1 Apr 29 12:17 mmcblk0p1
brw------- 1 root root 179, 2 Apr 29 12:00 mmcblk0p2
PARTITIONING
/dev/block # parted mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
(parted) print
Model: MMC SEM08G (sd/mmc)
Disk /dev/block/mmcblk0: 8070MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.8kB 6057MB 6057MB primary fat32 lba
2 6057MB 8070MB 2013MB primary lba
(parted) rm 2
rm 2
rm 2
(parted) rm 1
rm 1
rm 1
(parted) print
Model: MMC SEM08G (sd/mmc)
Disk /dev/block/mmcblk0: 8070MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.8kB 6057MB 6057MB primary fat32 lba
2 6057MB 8070MB 2013MB primary lba
(parted) mkfs
mkfs
mkfs
Warning: The existing file system will be destroyed and all data on the
partition will be lost. Do you want to continue?
Yes/No? Yes
Yes
Yes
Partition number? 1
1
1
File system type? [ext2]? ext2
ext2
ext2
Error: Invalid superblock. Are you sure this is an ext2 file system?
Error: SEGV_MAPERR (Address not mapped to object)
Aborted
DMESG
/system/csc # dmesg
dmesg
S + ADB (Debugging mode)
<4>[ 58.641985] [composite_switch_work]config=0xc0d70b50
<3>[ 106.982404] FAT: Unrecognized mount option "check=no" or missing value
<3>[ 108.002658] FAT: Unrecognized mount option "check=no" or missing value
<3>[ 108.876726] FAT: Unrecognized mount option "check=no" or missing value
<4>[ 114.816057] [BIF: ] FSR VERSION: FSR_1.2.1p1_b139_RTM
<4>[ 114.816079] [BIF: ] FSR_BML_Open(nVol:0, nFlag:0x0, nOpenCnt:6) / 1171 line
<4>[ 114.816118] [SIF:INF] ===> STL Clst[ 3] Scan Root Info
<4>[ 114.816710] [SIF:INF] ===> STL Zone[ 3, 0] Open Zone Meta
<4>[ 114.818579] [SIF:INF] Latest Header Index ( 8) Vbn ( 10)
<4>[ 114.819247] [SIF:INF] Latest Header Clean Page Offset ( 5)
<4>[ 114.819257] [SIF:INF] POR write timer : 0x6
<4>[ 114.819519] [SIF:INF] Latest Context BlockIdx ( 8) Offset ( 4) Vpn ( 644)
<4>[ 114.819657] [SIF:INF] Number of Free Block ( 22)
<4>[ 114.819665] [SIF:INF] Active Log List : Num ( 0)
<4>[ 114.819676] [SIF:INF] ===> STL Zone[ 3, 0] Open Zone Post
<4>[ 114.819686] [SIF:INF] ===> STL Zone[ 3, 0] Validity check
<4>[ 114.819706] [SIF:INF] Partition [0, 23] open is success
<3>[ 116.209628] FAT: Unrecognized mount option "check=no" or missing value
<3>[ 144.052742] FAT: Unrecognized mount option "check=no" or missing value
<4>[ 182.622852] [BIF: ] FSR_BML_Close(nVol: 0, nFlag: 0x0, nOpenCnt: 5)
<4>[ 183.623957] [SIF:INF] INACTIVATED LOG BLOCKS nDgn( 4) nVbn( 95) nCPOffs( 33)
<4>[ 183.627334] [SIF:INF] INACTIVATED LOG BLOCKS nDgn( 0) nVbn( 96) nCPOffs( 3)
<4>[ 183.627851] [SIF:OUT] --FSR_STL_FlushAllMetaInfo()
<4>[ 183.627880] [BIF: ] FSR_BML_Close(nVol: 0, nFlag: 0x0, nOpenCnt: 4)
<4>[ 186.121411] [BIF: ] FSR_BML_Close(nVol: 0, nFlag: 0x0, nOpenCnt: 3)
<3>[ 1511.603164] init: untracked pid 673 exited
<7>[ 1741.143938] max8998_charging_control : chg(0) cable(1) dis(0) esafe(2) bat(76,0,0)
<7>[ 1741.144150] [TSP] TA NON-Detect!!!
<3>[ 1771.984929] init: untracked pid 680 exited
<7>[ 1801.268706] max8998_charging_control : chg(1) cable(1) dis(0) esafe(2) bat(76,0,0)
<7>[ 1801.269545] [TSP] TA Detect!!!
<4>[ 2833.138728] [BIF: ] FSR VERSION: FSR_1.2.1p1_b139_RTM
<4>[ 2833.138751] [BIF: ] FSR_BML_Open(nVol:0, nFlag:0x0, nOpenCnt:4) / 1171 line
<4>[ 2833.138790] [SIF:INF] ===> STL Clst[ 2] Scan Root Info
<4>[ 2833.139382] [SIF:INF] ===> STL Zone[ 2, 0] Open Zone Meta
<4>[ 2833.146141] [SIF:INF] Latest Header Index ( 16) Vbn ( 18)
<4>[ 2833.146829] [SIF:INF] Latest Header Clean Page Offset ( 6)
<4>[ 2833.146839] [SIF:INF] POR write timer : 0x6
<4>[ 2833.147222] [SIF:INF] Latest Context BlockIdx ( 16) Offset ( 5) Vpn ( 1157)
<4>[ 2833.147363] [SIF:INF] Number of Free Block ( 26)
<4>[ 2833.147372] [SIF:INF] Active Log List : Num ( 0)
<4>[ 2833.147382] [SIF:INF] ===> STL Zone[ 2, 0] Open Zone Post
<4>[ 2833.147392] [SIF:INF] ===> STL Zone[ 2, 0] Validity check
<4>[ 2833.147414] [SIF:INF] Partition [0, 22] open is success
<4>[ 3354.057290] [BIF: ] FSR VERSION: FSR_1.2.1p1_b139_RTM
<4>[ 3354.057313] [BIF: ] FSR_BML_Open(nVol:0, nFlag:0x0, nOpenCnt:5) / 1171 line
<4>[ 3354.057353] [SIF:INF] ===> STL Clst[ 4] Scan Root Info
<4>[ 3354.057959] [SIF:INF] ===> STL Zone[ 4, 0] Open Zone Meta
<4>[ 3354.058837] [SIF:INF] Latest Header Index ( 2) Vbn ( 4)
<4>[ 3354.059650] [SIF:INF] Latest Header Clean Page Offset ( 6)
<4>[ 3354.059660] [SIF:INF] POR write timer : 0x10
<4>[ 3354.059805] [SIF:INF] Latest Context BlockIdx ( 2) Offset ( 5) Vpn ( 261)
<4>[ 3354.059946] [SIF:INF] Number of Free Block ( 9)
<4>[ 3354.059955] [SIF:INF] Active Log List : Num ( 0)
<4>[ 3354.059965] [SIF:INF] ===> STL Zone[ 4, 0] Open Zone Post
<4>[ 3354.059975] [SIF:INF] ===> STL Zone[ 4, 0] Validity check
<4>[ 3354.059993] [SIF:INF] Partition [0, 24] open is success
Start over with flashing ezbase 3.0 or 4.0.(find it in insanity rom thread) with pit 512 and repatition ticked and untick reboot and flash via Odin.when flash is done unplug your phone remove battery,put it back and use 3button combo to get in recovery,under advanced press fix permissions and reboot.if u still get fc's go back to recovery/mount/storage and format system and data and flash a rom from recovery.
Thank you a lot for the answer. I have tried your step-by-step (just EZBase 2.0) nevertheless not working even flashing from recovery. I guess the problem is deeper. Whatever I use (Odin/recovery mode) every time internal memory is not cleaned from old files.
Also using fdisk in adb all seems fine until remounting of the /sdcard. Either the problem lies in partition table or....I don't know. I am not able to do any operation on internal SD from command line and that is weird.
When using recovery mode + install, I have to use adb push to upload the zip file, then flash. After restart or umount, zip file has gone, old files are back. Thanks to anybody for other hint what to check.
Sorry for that,sound like a partition mount fault.might be corrupted
somehow.
A long time ago there was some (i think) similar problems try search for "dbdata.tar" fix,but this is a longshot and i think it was in the froyo days,search here in xda and read
---------- Post added at 09:58 PM ---------- Previous post was at 09:25 PM ----------
OK I found the file.go to (rom) i9000xxjw4 (2.3.6)[19.03.2012] post 76 page 8.
Sorry I cant provide links I'm on my phone
But remember this is a longshot.
Thank you a lot! I really do appreciate your attitude. I have found the dbdata.tar in this post but when applied on EZBase 2.0 it started to reboot. Now I reflashed by JVU-RE and waiting on boot screen (I guess it checks rfs vs. ext4), but I really think the issue will be somewhere in the partitions or partition table.
Do you or somebody know where to check partition table? I tried to check via fdisk but no help. I think that the list of files are stored in header of those partitions. Is it possible to rebuild them from OS level or to rebuild the whole mmcblk0? It is Linux, it should be possible. Thanks a lot.
any news on that issue? i might have the same problem...
I also have this problem. I can partition mmcblk0p1 with FAT32 and mmcblk0p2 with ext4 or whatever, than format the partitions and after reboot (recovery) all files (pictures, documents, etc.) are completely restored. No chance at all to change files oder partitions permanent.
I have a SGS GT-I9000.
Does anybody have an idea? What information can I provide to support diagnosis?
same here, tried deleting, formating, installing ROM's... Nothing works..
ghostjak said:
same here, tried deleting, formating, installing ROM's... Nothing works..
Click to expand...
Click to collapse
Hey ghostjak, what is your model ? is it i9000 or i9000B, cause all the while I been trying to help you based on i9000 if it is i9000B than its very similar to my unit M110S both have a DMB TV and not compatible to i9000
any news on this issue ?
Have the same problem, formating, killing, dropping the phone, nothing helps, all old files are back and i cant do nothing !!!!!
igalva said:
Have the same problem, formating, killing, dropping the phone, nothing helps, all old files are back and i cant do nothing !!!!!
Click to expand...
Click to collapse
you do not have to back up data via Google? It sometimes can tease.
misacek said:
you do not have to back up data via Google? It sometimes can tease.
Click to expand...
Click to collapse
Please refer this, it seems you had a brick on sdcard, In turn the partition table got currupted due to formatting the sdcard using CMXX removery mode.
http://forum.xda-developers.com/showthread.php?t=1813386&page=2
kat0072 said:
Please refer this, it seems you had a brick on sdcard, In turn the partition table got currupted due to formatting the sdcard using CMXX removery mode.
http://forum.xda-developers.com/showthread.php?t=1813386&page=2
Click to expand...
Click to collapse
Yeah I know. Its fine now samsung customer care office helped me to reflash the firmware.
But now question is how to reset the custom rom count to 0 ??
Sent from my GT-N7105 using xda app-developers app
kat0072 said:
Yeah I know. Its fine now samsung customer care office helped me to reflash the firmware.
Click to expand...
Click to collapse
Could you revive the corrupted internal sd card? Is it just flashing a firmware and that's it?
Thanks in advance.
I dont know what exactly they have done to correct the partition table.
I guess they re-partitioned using the pit file.
Sent from my GT-N7105 using xda app-developers app
kat0072 said:
I dont know what exactly they have done to correct the partition table.
I guess they re-partitioned using the pit file.
Sent from my GT-N7105 using xda app-developers app
Click to expand...
Click to collapse
Hello,
I have the same problem... you mention samsung guys fixed, did you send the phone to them? Or did they give you the files?
I have the same problem on my Samsung.
If you found any solution to this problem could you please help me??
karamjit123 said:
If you found any solution to this problem could you please help me??
Click to expand...
Click to collapse
I dont know what problem ur facing but if sd internal corrupt, u should just follow this guy instruction
http://forum.xda-developers.com/showthread.php?t=845708
https://www.youtube.com/watch?v=zdMhYYdMB08
herolpx said:
Hello,
I have the same problem... you mention samsung guys fixed, did you send the phone to them? Or did they give you the files?
Click to expand...
Click to collapse
I just visited the near by Samsung customer care office in my area and they took 6hours to fix it and gave me back with no cost of repair. Remember even they fix this up the Custom ROM counter will still intact which was earlier. They will not reset it.
HTH
Sent from my GT-N7105 using xda app-developers app
can't open '/dev/block/mmcblk0p2': No such file or directory
parted /dev/block/mmcblk0
Error: Can't have a partition outside the disk!
~ # e2fsck -b8193 /dev/block/mmcblk0p2
e2fsck -b8193 /dev/block/mmcblk0p2
e2fsck 1.41.6 (30-May-2009)
e2fsck: No such file or directory while trying to open /dev/block/mmcblk0p2
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
~ # fdisk -l /dev/block/mmcblk0p2
fdisk -l /dev/block/mmcblk0p2
fdisk: can't open '/dev/block/mmcblk0p2': No such file or directory
more /etc/fstab
/dev/block/stl11 /cache rfs rw
/dev/block/mmcblk0p2 /data rfs rw
/dev/block/stl10 /datadata rfs rw
/dev/block/stl9 /system rfs rw
/dev/block/mmcblk0p1 /sdcard vfat rw
Please Help !!!

[DEV][Kernel][2.6.39] Fixing BSOD bug

When you install the offical V30C 2.6.39 kernel, sometimes there will be a BSOD bug. Espcially when you try to unplug your phone from the USB port, the system sometimes will try to enter suspend mode, tuning it's frequency to 216MHz, this bug will occure. It will take the system a very long time to wakeup, or just crash the system. So if you have a incoming call at this time, maybe the baseband will ring the Android, surely, the Android will not ring you. Then you will miss the incoming call.
By checking the dmesg log, you can found something like this:
Code:
<4>[ 1235.194084] muic_wq_func : [MUIC] Now...path retain mode, muic_mode = MUIC_AP_USB (8), charing = CHARGING_NONE (1)
<4>[ 1235.194092]
<6>[ 1235.201514] suspend: enter suspend
<6>[ 1235.201533] PM: Syncing filesystems ... done.
<7>[ 1235.208726] PM: Preparing system for mem sleep
<6>[ 1235.208750] Tegra cpufreq suspend: setting frequency to 216000 kHz
<3>[ 1235.210088] Failed to set dvfs regulator vdd_core
and a lot of this:
Code:
<6>[ 1235.607271] Switched to NOHz mode on CPU #1
<4>[ 1236.607867] ------------[ cut here ]------------
<4>[ 1236.607945] WARNING: at /home/marsgod/android/CM_JB/kernel/lge/star/drivers/i2c/busses/i2c-tegra.c:669 tegra_i2c_xfer+0x2c0/0x3b8()
<4>[ 1236.607987] Modules linked in:
<4>[ 1236.608073] [<c004c2b0>] (unwind_backtrace+0x0/0xe0) from [<c008020c>] (warn_slowpath_common+0x4c/0x64)
<4>[ 1236.608142] [<c008020c>] (warn_slowpath_common+0x4c/0x64) from [<c008023c>] (warn_slowpath_null+0x18/0x1c)
<4>[ 1236.608212] [<c008023c>] (warn_slowpath_null+0x18/0x1c) from [<c030eb8c>] (tegra_i2c_xfer+0x2c0/0x3b8)
<4>[ 1236.608282] [<c030eb8c>] (tegra_i2c_xfer+0x2c0/0x3b8) from [<c030b480>] (i2c_transfer+0xb0/0x104)
<4>[ 1236.608375] [<c030b480>] (i2c_transfer+0xb0/0x104) from [<c0275934>] (max8907c_i2c_read+0x54/0x98)
<4>[ 1236.608451] [<c0275934>] (max8907c_i2c_read+0x54/0x98) from [<c02759b0>] (max8907c_reg_read+0x10/0x2c)
<4>[ 1236.608548] [<c02759b0>] (max8907c_reg_read+0x10/0x2c) from [<c0244108>] (max8907c_regulator_ldo_is_enabled+0x18/0x44)
<4>[ 1236.608626] [<c0244108>] (max8907c_regulator_ldo_is_enabled+0x18/0x44) from [<c0240350>] (_regulator_is_enabled+0x1c/0x28)
<4>[ 1236.608700] [<c0240350>] (_regulator_is_enabled+0x1c/0x28) from [<c0241e88>] (_regulator_do_set_voltage+0x14/0x1f8)
<4>[ 1236.608773] [<c0241e88>] (_regulator_do_set_voltage+0x14/0x1f8) from [<c024224c>] (regulator_set_voltage+0xf8/0x100)
<4>[ 1236.608869] [<c024224c>] (regulator_set_voltage+0xf8/0x100) from [<c0064724>] (dvfs_rail_set_voltage+0x14c/0x254)
<4>[ 1236.608947] [<c0064724>] (dvfs_rail_set_voltage+0x14c/0x254) from [<c00645c4>] (dvfs_rail_update+0xec/0x100)
<4>[ 1236.609021] [<c00645c4>] (dvfs_rail_update+0xec/0x100) from [<c0064b4c>] (__tegra_dvfs_set_rate+0xb4/0xf0)
<4>[ 1236.609095] [<c0064b4c>] (__tegra_dvfs_set_rate+0xb4/0xf0) from [<c0064bb8>] (tegra_dvfs_set_rate+0x30/0x48)
<4>[ 1236.609176] [<c0064bb8>] (tegra_dvfs_set_rate+0x30/0x48) from [<c0057540>] (clk_enable_locked+0x3c/0xe4)
<4>[ 1236.609244] [<c0057540>] (clk_enable_locked+0x3c/0xe4) from [<c00578b0>] (clk_enable+0x38/0x68)
<4>[ 1236.609313] [<c00578b0>] (clk_enable+0x38/0x68) from [<c02b7130>] (tegra_otg_enable_clk+0x20/0x34)
<4>[ 1236.609377] [<c02b7130>] (tegra_otg_enable_clk+0x20/0x34) from [<c02b71b8>] (tegra_otg_resume_noirq+0x10/0x58)
<4>[ 1236.609455] [<c02b71b8>] (tegra_otg_resume_noirq+0x10/0x58) from [<c02601b0>] (platform_pm_resume_noirq+0x2c/0x40)
<4>[ 1236.609527] [<c02601b0>] (platform_pm_resume_noirq+0x2c/0x40) from [<c0262d4c>] (pm_noirq_op+0xcc/0x14c)
<4>[ 1236.609590] [<c0262d4c>] (pm_noirq_op+0xcc/0x14c) from [<c0262ea0>] (dpm_resume_noirq+0xd4/0x13c)
<4>[ 1236.609658] [<c0262ea0>] (dpm_resume_noirq+0xd4/0x13c) from [<c00af7e4>] (suspend_devices_and_enter+0x1d4/0x2e0)
<4>[ 1236.609724] [<c00af7e4>] (suspend_devices_and_enter+0x1d4/0x2e0) from [<c00af9b8>] (enter_state+0xc8/0x130)
<4>[ 1236.609789] [<c00af9b8>] (enter_state+0xc8/0x130) from [<c00b0860>] (suspend+0x60/0x124)
<4>[ 1236.609850] [<c00b0860>] (suspend+0x60/0x124) from [<c00938bc>] (process_one_work+0x200/0x370)
<4>[ 1236.609912] [<c00938bc>] (process_one_work+0x200/0x370) from [<c0093c4c>] (worker_thread+0x220/0x3c0)
<4>[ 1236.609984] [<c0093c4c>] (worker_thread+0x220/0x3c0) from [<c00976c0>] (kthread+0x7c/0x84)
<4>[ 1236.610065] [<c00976c0>] (kthread+0x7c/0x84) from [<c00471b8>] (kernel_thread_exit+0x0/0x8)
<4>[ 1236.610107] ---[ end trace c5d679c0ae895105 ]---
<3>[ 1236.610148] tegra-i2c tegra-i2c.3: i2c transfer timed out, addr 0x003c, data 0x07
<4>[ 1236.611241] max8907c_i2c_read Fail Error code(0xffffff92) retry cnt=0
<4>[ 1237.607386] ------------[ cut here ]------------
<4>[ 1237.607453] WARNING: at /home/marsgod/android/CM_JB/kernel/lge/star/drivers/i2c/busses/i2c-tegra.c:669 tegra_i2c_xfer+0x2c0/0x3b8()
<4>[ 1237.607494] Modules linked in:
<4>[ 1237.607566] [<c004c2b0>] (unwind_backtrace+0x0/0xe0) from [<c008020c>] (warn_slowpath_common+0x4c/0x64)
<4>[ 1237.607634] [<c008020c>] (warn_slowpath_common+0x4c/0x64) from [<c008023c>] (warn_slowpath_null+0x18/0x1c)
<4>[ 1237.607705] [<c008023c>] (warn_slowpath_null+0x18/0x1c) from [<c030eb8c>] (tegra_i2c_xfer+0x2c0/0x3b8)
<4>[ 1237.607774] [<c030eb8c>] (tegra_i2c_xfer+0x2c0/0x3b8) from [<c030b480>] (i2c_transfer+0xb0/0x104)
<4>[ 1237.607856] [<c030b480>] (i2c_transfer+0xb0/0x104) from [<c0275934>] (max8907c_i2c_read+0x54/0x98)
<4>[ 1237.607931] [<c0275934>] (max8907c_i2c_read+0x54/0x98) from [<c02759b0>] (max8907c_reg_read+0x10/0x2c)
<4>[ 1237.608017] [<c02759b0>] (max8907c_reg_read+0x10/0x2c) from [<c0244108>] (max8907c_regulator_ldo_is_enabled+0x18/0x44)
<4>[ 1237.608094] [<c0244108>] (max8907c_regulator_ldo_is_enabled+0x18/0x44) from [<c0240350>] (_regulator_is_enabled+0x1c/0x28)
<4>[ 1237.608166] [<c0240350>] (_regulator_is_enabled+0x1c/0x28) from [<c0241e88>] (_regulator_do_set_voltage+0x14/0x1f8)
<4>[ 1237.608238] [<c0241e88>] (_regulator_do_set_voltage+0x14/0x1f8) from [<c024224c>] (regulator_set_voltage+0xf8/0x100)
<4>[ 1237.608323] [<c024224c>] (regulator_set_voltage+0xf8/0x100) from [<c0064724>] (dvfs_rail_set_voltage+0x14c/0x254)
<4>[ 1237.608401] [<c0064724>] (dvfs_rail_set_voltage+0x14c/0x254) from [<c00645c4>] (dvfs_rail_update+0xec/0x100)
<4>[ 1237.608474] [<c00645c4>] (dvfs_rail_update+0xec/0x100) from [<c0064b4c>] (__tegra_dvfs_set_rate+0xb4/0xf0)
<4>[ 1237.608547] [<c0064b4c>] (__tegra_dvfs_set_rate+0xb4/0xf0) from [<c0064bb8>] (tegra_dvfs_set_rate+0x30/0x48)
<4>[ 1237.608624] [<c0064bb8>] (tegra_dvfs_set_rate+0x30/0x48) from [<c0057540>] (clk_enable_locked+0x3c/0xe4)
<4>[ 1237.608692] [<c0057540>] (clk_enable_locked+0x3c/0xe4) from [<c00578b0>] (clk_enable+0x38/0x68)
<4>[ 1237.608759] [<c00578b0>] (clk_enable+0x38/0x68) from [<c02b7130>] (tegra_otg_enable_clk+0x20/0x34)
<4>[ 1237.608823] [<c02b7130>] (tegra_otg_enable_clk+0x20/0x34) from [<c02b71b8>] (tegra_otg_resume_noirq+0x10/0x58)
<4>[ 1237.608897] [<c02b71b8>] (tegra_otg_resume_noirq+0x10/0x58) from [<c02601b0>] (platform_pm_resume_noirq+0x2c/0x40)
<4>[ 1237.608967] [<c02601b0>] (platform_pm_resume_noirq+0x2c/0x40) from [<c0262d4c>] (pm_noirq_op+0xcc/0x14c)
<4>[ 1237.609030] [<c0262d4c>] (pm_noirq_op+0xcc/0x14c) from [<c0262ea0>] (dpm_resume_noirq+0xd4/0x13c)
<4>[ 1237.609094] [<c0262ea0>] (dpm_resume_noirq+0xd4/0x13c) from [<c00af7e4>] (suspend_devices_and_enter+0x1d4/0x2e0)
<4>[ 1237.609160] [<c00af7e4>] (suspend_devices_and_enter+0x1d4/0x2e0) from [<c00af9b8>] (enter_state+0xc8/0x130)
<4>[ 1237.609223] [<c00af9b8>] (enter_state+0xc8/0x130) from [<c00b0860>] (suspend+0x60/0x124)
<4>[ 1237.609283] [<c00b0860>] (suspend+0x60/0x124) from [<c00938bc>] (process_one_work+0x200/0x370)
<4>[ 1237.609343] [<c00938bc>] (process_one_work+0x200/0x370) from [<c0093c4c>] (worker_thread+0x220/0x3c0)
<4>[ 1237.609411] [<c0093c4c>] (worker_thread+0x220/0x3c0) from [<c00976c0>] (kthread+0x7c/0x84)
<4>[ 1237.609485] [<c00976c0>] (kthread+0x7c/0x84) from [<c00471b8>] (kernel_thread_exit+0x0/0x8)
<4>[ 1237.609526] ---[ end trace c5d679c0ae895106 ]---
<3>[ 1237.609565] tegra-i2c tegra-i2c.3: i2c transfer timed out, addr 0x003c, data 0x07
<4>[ 1237.610659] max8907c_i2c_read Fail Error code(0xffffff92) retry cnt=1
When the system trying to enter into suspend mode, it first will tune the frequency to 216MHz, this will cause the dvfs.c try to low down the cpu/core voltage. When lowing down the core voltage, the regulator_check_consumers in regulator return a -EINVAL to dvfs.c set_voltage function. Which will cause the dvfs set voltage abort, so at this time , some part of CPU enter suspend mode, but others not. And this will cause a serious problem when system trying to wakeup.(a lot of I2C communicationn error)
By adding some printk into the regulator core.c, I found that there exist a "ghost consumer" which has a min_uV=0 and max_uV=0. This will cause the regulator_check_consumers always return a -EINVAL.
To workaround this , just add a fix to the drivers/regulator/core.c regulator_check_consumers function:
Code:
list_for_each_entry(regulator, &rdev->consumer_list, list) {
if (!regulator->max_uV && !regulator->min_uV)
{
// Work around for unknown 0,0 consumer bug
continue;
}
if (*max_uV > regulator->max_uV)
*max_uV = regulator->max_uV;
if (*min_uV < regulator->min_uV)
*min_uV = regulator->min_uV;
}
Please note, this bug has been fixed in 3.x kernel.
marsgod said:
When you install the offical V30C 2.6.39 kernel, sometimes there will be a BSOD bug. Espcially when you try to unplug your phone from the USB port, the system sometimes will try to enter suspend mode, tuning it's frequency to 216MHz, this bug will occure. It will take the system a very long time to wakeup, or just crash the system. So if you have a incoming call at this time, maybe the baseband will ring the Android, surely, the Android will not ring you. Then you will miss the incoming call.
To workaround this , just add a fix to the drivers/regulator/core.c regulator_check_consumers function:
Code:
list_for_each_entry(regulator, &rdev->consumer_list, list) {
if (!regulator->max_uV && !regulator->min_uV)
{
// Work around for unknown 0,0 consumer bug
continue;
}
if (*max_uV > regulator->max_uV)
*max_uV = regulator->max_uV;
if (*min_uV < regulator->min_uV)
*min_uV = regulator->min_uV;
}
Please note, this bug has been fixed in 3.x kernel.
Click to expand...
Click to collapse
Hi marsgod, there is a patch in nvidia git about it already. Here is what i cherry picked from there.
https://github.com/bhanvadia/lge-kernel-star/commit/604d675b84aaa905a675109e52b4becebded9cff
this does same as you say, just done by Nvidia already. LG forgot it in their kernel.
EDIT: And to all other xda members this is best example of having commits in GIT.... helps a lot .
Harsh said:
Hi marsgod, there is a patch in nvidia git about it already. Here is what i cherry picked from there.
https://github.com/bhanvadia/lge-kernel-star/commit/604d675b84aaa905a675109e52b4becebded9cff
this does same as you say, just done by Nvidia already. LG forgot it in their kernel.
EDIT: And to all other xda members this is best example of having commits in GIT.... helps a lot .
Click to expand...
Click to collapse
thank you....
And maybe we can revert the board-star-power.c LDO18 fix.
//LGE_CHANGE_S chen.yingchun 20120103 regulator_set_voltage of "vddio_vi" fail
//MAX8907C_REGULATOR_DEVICE(LDO18, 650000, 2225000);
MAX8907C_REGULATOR_APPLYUV_DEVICE(LDO18, 1800000, 1800000);
//LGE_CHANGE_E chen.yingchun 20120103 regulator_set_voltage of "vddio_vi" fail
Guys, why don't you push this fix into official CM kernel repo?
Reading this reminded me that the very same error and solution has been brought up by wkpark around a month ago.
See here...

[Q] Old kernel on new bootloader?

Has anyone else tried?
I backed up ICS boot.img and system.img before upgrading and then restore after flashing V20A.kdz but it doesn't boot. Just stays at the non-animated LG logo.
arararagi said:
Has anyone else tried?
I backed up ICS boot.img and system.img before upgrading and then restore after flashing V20A.kdz but it doesn't boot. Just stays at the non-animated LG logo.
Click to expand...
Click to collapse
Did you tried install Windows7 and after change the "windows" folder for the one from XP?
Doesn't make sense, right?
RuedasLocas said:
Did you tried install Windows7 and after change the "windows" folder for the one from XP?
Doesn't make sense, right?
Click to expand...
Click to collapse
It works if I also restore the MBR from XP.
arararagi said:
It works if I also restore the MBR from XP.
Click to expand...
Click to collapse
Here you don's have that "if"... sorry
Found this in another thread
gordon0001 said:
well, since no one answered i figured out the new kernel (3.1) is the issue. replacing the kernel with the old kernel (2.6) in recovery.img solved the problem, but partitions dont get mounted and couldnt get them mounted, since i barely know the internals of a linux kernel and the kernel ramdisk
Click to expand...
Click to collapse
I tried doing the same thing and just catting the resulting recovery image to boot.
It starts up and adb works, however only external SD on Tegra is accessible.
Code:
~ # find /dev/block/
/dev/block/
/dev/block/loop7
/dev/block/loop6
/dev/block/loop5
/dev/block/loop4
/dev/block/loop3
/dev/block/loop2
/dev/block/loop1
/dev/block/loop0
/dev/block/mmcblk0p1
/dev/block/platform
/dev/block/platform/sdhci-tegra.2
/dev/block/platform/sdhci-tegra.2/mmcblk0p1
/dev/block/platform/sdhci-tegra.2/by-num
/dev/block/platform/sdhci-tegra.2/by-num/p1
/dev/block/platform/sdhci-tegra.2/mmcblk0
/dev/block/mmcblk0
~ # cat /proc/partitions
major minor #blocks name
179 0 15351296 mmcblk0
179 1 15347200 mmcblk0p1
From dmesg:
Code:
<6>[ 3.855253] sdhci: Secure Digital Host Controller Interface driver
<6>[ 3.855433] sdhci: Copyright(c) Pierre Ossman
<4>[ 3.856721] mmc0: Invalid maximum block size, assuming 512 bytes
<6>[ 3.856848] mmc0: no vmmc regulator found
<7>[ 3.858202] Registered led device: mmc0::
<6>[ 3.861711] mmc0: SDHCI controller on platform [sdhci-tegra.3] using ADMA
<4>[ 3.863024] mmc1: Invalid maximum block size, assuming 512 bytes
<6>[ 3.863145] mmc1: no vmmc regulator found
<7>[ 3.864473] Registered led device: mmc1::
<6>[ 3.866846] mmc1: SDHCI controller on platform [sdhci-tegra.0] using ADMA
<4>[ 3.867178] tegra_gpio_irq_set_wake() called
<3>[ 3.867284] sdhci sdhci-tegra.2: SD card wake-up event registrationfailed with eroor: -22
<4>[ 3.868587] mmc2: Invalid maximum block size, assuming 512 bytes
<6>[ 3.868706] mmc2: no vmmc regulator found
<7>[ 3.870035] Registered led device: mmc2::
<6>[ 3.872372] mmc2: SDHCI controller on platform [sdhci-tegra.2] using ADMA
<7>[ 3.872860] Registered led device: button-backlight
<4>[ 3.872961] keypad_led_probe success
<6>[ 3.874563] tegra-se tegra-se: tegra_se_probe: complete
<6>[ 3.875491] usbcore: registered new interface driver usbhid
<6>[ 3.875681] usbhid: USB HID core driver
<6>[ 3.876370] logger: created 256K log 'log_main'
<6>[ 3.876608] logger: created 256K log 'log_events'
<6>[ 3.876939] logger: created 256K log 'log_radio'
<6>[ 3.877259] logger: created 256K log 'log_system'
<4>[ 3.972419] mmc0: switch to bus width 1 ddr 0 failed
<3>[ 3.972635] mmc0: error -110 whilst initialising MMC card
<4>[ 4.085800] mmc0: switch to bus width 1 ddr 0 failed
<3>[ 4.086013] mmc0: error -110 whilst initialising MMC card
<4>[ 4.213528] mmc0: switch to bus width 1 ddr 0 failed
<3>[ 4.213657] mmc0: error -110 whilst initialising MMC card
<4>[ 4.379808] mmc0: switch to bus width 1 ddr 0 failed
<3>[ 4.379939] mmc0: error -110 whilst initialising MMC card
This is how things should look (from the new kernel):
Code:
~ # find /dev/block/
/dev/block/
/dev/block/loop7
/dev/block/loop6
/dev/block/loop5
/dev/block/loop4
/dev/block/loop3
/dev/block/loop2
/dev/block/loop1
/dev/block/loop0
/dev/block/mmcblk1p1
/dev/block/mmcblk1
/dev/block/mmcblk0boot0
/dev/block/mmcblk0boot1
/dev/block/mmcblk0p13
/dev/block/mmcblk0p12
/dev/block/mmcblk0p11
/dev/block/mmcblk0p10
/dev/block/mmcblk0p9
/dev/block/mmcblk0p8
/dev/block/mmcblk0p7
/dev/block/mmcblk0p6
/dev/block/mmcblk0p5
/dev/block/mmcblk0p4
/dev/block/mmcblk0p3
/dev/block/mmcblk0p2
/dev/block/mmcblk0p1
/dev/block/platform
/dev/block/platform/sdhci-tegra.2
/dev/block/platform/sdhci-tegra.2/mmcblk1p1
/dev/block/platform/sdhci-tegra.2/by-num
/dev/block/platform/sdhci-tegra.2/by-num/p1
/dev/block/platform/sdhci-tegra.2/mmcblk1
/dev/block/platform/sdhci-tegra.3
/dev/block/platform/sdhci-tegra.3/mmcblk0boot0
/dev/block/platform/sdhci-tegra.3/mmcblk0boot1
/dev/block/platform/sdhci-tegra.3/mmcblk0p13
/dev/block/platform/sdhci-tegra.3/mmcblk0p12
/dev/block/platform/sdhci-tegra.3/mmcblk0p11
/dev/block/platform/sdhci-tegra.3/mmcblk0p10
/dev/block/platform/sdhci-tegra.3/mmcblk0p9
/dev/block/platform/sdhci-tegra.3/mmcblk0p8
/dev/block/platform/sdhci-tegra.3/mmcblk0p7
/dev/block/platform/sdhci-tegra.3/mmcblk0p6
/dev/block/platform/sdhci-tegra.3/mmcblk0p5
/dev/block/platform/sdhci-tegra.3/mmcblk0p4
/dev/block/platform/sdhci-tegra.3/mmcblk0p3
/dev/block/platform/sdhci-tegra.3/mmcblk0p2
/dev/block/platform/sdhci-tegra.3/mmcblk0p1
/dev/block/platform/sdhci-tegra.3/by-num
/dev/block/platform/sdhci-tegra.3/by-num/p13
/dev/block/platform/sdhci-tegra.3/by-num/p12
/dev/block/platform/sdhci-tegra.3/by-num/p11
/dev/block/platform/sdhci-tegra.3/by-num/p10
/dev/block/platform/sdhci-tegra.3/by-num/p9
/dev/block/platform/sdhci-tegra.3/by-num/p8
/dev/block/platform/sdhci-tegra.3/by-num/p7
/dev/block/platform/sdhci-tegra.3/by-num/p6
/dev/block/platform/sdhci-tegra.3/by-num/p5
/dev/block/platform/sdhci-tegra.3/by-num/p4
/dev/block/platform/sdhci-tegra.3/by-num/p3
/dev/block/platform/sdhci-tegra.3/by-num/p2
/dev/block/platform/sdhci-tegra.3/by-num/p1
/dev/block/platform/sdhci-tegra.3/by-name
/dev/block/platform/sdhci-tegra.3/by-name/UDB
/dev/block/platform/sdhci-tegra.3/by-name/CAL
/dev/block/platform/sdhci-tegra.3/by-name/FOT
/dev/block/platform/sdhci-tegra.3/by-name/MLT
/dev/block/platform/sdhci-tegra.3/by-name/DRM
/dev/block/platform/sdhci-tegra.3/by-name/UDA
/dev/block/platform/sdhci-tegra.3/by-name/NVA
/dev/block/platform/sdhci-tegra.3/by-name/USP
/dev/block/platform/sdhci-tegra.3/by-name/MSC
/dev/block/platform/sdhci-tegra.3/by-name/CAC
/dev/block/platform/sdhci-tegra.3/by-name/APP
/dev/block/platform/sdhci-tegra.3/by-name/LNX
/dev/block/platform/sdhci-tegra.3/by-name/SOS
/dev/block/platform/sdhci-tegra.3/mmcblk0
/dev/block/mmcblk0
~ # cat /proc/partitions
major minor #blocks name
179 0 15267840 mmcblk0
179 1 10240 mmcblk0p1
179 2 10240 mmcblk0p2
179 3 1572864 mmcblk0p3
179 4 393216 mmcblk0p4
179 5 2048 mmcblk0p5
179 6 81920 mmcblk0p6
179 7 2048 mmcblk0p7
179 8 13062144 mmcblk0p8
179 9 16384 mmcblk0p9
179 10 16384 mmcblk0p10
179 11 20480 mmcblk0p11
179 12 16384 mmcblk0p12
179 13 47104 mmcblk0p13
179 32 2048 mmcblk0boot1
179 16 2048 mmcblk0boot0
179 48 15351296 mmcblk1
179 49 15347200 mmcblk1p1
And dmesg:
Code:
<6>[70:01:01 00:00:08.609] sdhci: Secure Digital Host Controller Interface driver
<6>[70:01:01 00:00:08.609] sdhci: Copyright(c) Pierre Ossman
<6>[70:01:01 00:00:08.609] sdhci-pltfm: SDHCI platform and OF driver helper
<4>[70:01:01 00:00:08.609] mmc0: Invalid maximum block size, assuming 512 bytes
<6>[70:01:01 00:00:08.609] mmc0: no vmmc regulator found
<7>[70:01:01 00:00:08.609] Registered led device: mmc0::
<6>[70:01:01 00:00:08.609] mmc0: SDHCI controller on sdhci-tegra.3 [sdhci-tegra.3] using ADMA
<6>[70:01:01 00:00:08.609] sdhci-tegra sdhci-tegra.0: vddio_sd_slot regulator not found: -19. Assuming vddio_sd_slot is not required.
<6>[70:01:01 00:00:08.609] sdhci-tegra sdhci-tegra.0: Error: tegra3 io dpd not supported for sdhci-tegra.0
<4>[70:01:01 00:00:08.609] mmc1: Invalid maximum block size, assuming 512 bytes
<6>[70:01:01 00:00:08.609] mmc1: no vmmc regulator found
<7>[70:01:01 00:00:08.609] Registered led device: mmc1::
<6>[70:01:01 00:00:08.619] mmc1: SDHCI controller on sdhci-tegra.0 [sdhci-tegra.0] using ADMA
<3>[70:01:01 00:00:08.619] Failed gpio lp0 enable for irq=405, error=-22
<3>[70:01:01 00:00:08.619] sdhci-tegra sdhci-tegra.2: SD card wake-up event registrationfailed with eroor: -22
<6>[70:01:01 00:00:08.619] sdhci-tegra sdhci-tegra.2: vddio_sd_slot regulator not found: -19. Assuming vddio_sd_slot is not required.
<4>[70:01:01 00:00:08.619] mmc2: Invalid maximum block size, assuming 512 bytes
<6>[70:01:01 00:00:08.619] mmc2: no vmmc regulator found
<7>[70:01:01 00:00:08.619] Registered led device: mmc2::
<6>[70:01:01 00:00:08.619] mmc2: SDHCI controller on sdhci-tegra.2 [sdhci-tegra.2] using ADMA
RuedasLocas said:
Did you tried install Windows7 and after change the "windows" folder for the one from XP?
Doesn't make sense, right?
Click to expand...
Click to collapse
That comparison doesn't make sense, in fact.
The linux kernel is not linked to the userspace like in windows, you can have the same system running either an early 2.6 version or a very latest 3.x with no changes at all to the rest of the programs.
And use the same version of lilo or grub to boot both kernels, for what the bootloader is concerned.
Not that android can be compared with no "if's" to a standard linux box, but makes more sense than compare it to windows.
And for what it's worth, Sony released an upgrade from Gingerbread to ICS for their 2011 line keeping the same kernel. (and GB to ICS is a way bigger leap than ICS to JB)
ircalf said:
That comparison doesn't make sense, in fact.
The linux kernel is not linked to the userspace like in windows, you can have the same system running either an early 2.6 version or a very latest 3.x with no changes at all to the rest of the programs.
And use the same version of lilo or grub to boot both kernels, for what the bootloader is concerned.
Not that android can be compared with no "if's" to a standard linux box, but makes more sense than compare it to windows.
And for what it's worth, Sony released an upgrade from Gingerbread to ICS for their 2011 line keeping the same kernel. (and GB to ICS is a way bigger leap than ICS to JB)
Click to expand...
Click to collapse
I confess that I was "unhappy" in that expression
ircalf said:
That comparison doesn't make sense, in fact.
The linux kernel is not linked to the userspace like in windows, you can have the same system running either an early 2.6 version or a very latest 3.x with no changes at all to the rest of the programs.
And use the same version of lilo or grub to boot both kernels, for what the bootloader is concerned.
Not that android can be compared with no "if's" to a standard linux box, but makes more sense than compare it to windows.
And for what it's worth, Sony released an upgrade from Gingerbread to ICS for their 2011 line keeping the same kernel. (and GB to ICS is a way bigger leap than ICS to JB)
Click to expand...
Click to collapse
i guess his point was that what the o.p tried to do didnt make sense, so what he said was in the same context, also its obvious that with new bootloader that it would not boot with the previous boot,img otherwise we wouldnt have such problems like not being able to use the v20a bootloader with the previous v10 firmware

Categories

Resources