Hi, we managed to get the kernel panic located. It is caused by PackageManagerService.java, line 477. Just by commenting it //mAppInstallObserver.startWatching(); Android is able to do Filechanges in /data/app without crashing our system. We investigated deaper into this problem and got to the inotify-driver in the kernel as a top candidate for our kernel panic. Does anybody know, if this inotify-driver needs anything, that is not supported in yaffs2?
We also reinvestigated to use a yaffs2 only file system. We have a partition with /data, everything else is in a second partition. We tried to mount this second partition read-only, giving all permissions, but nothing helps. Android tries to start 4 times, and dies with this log: D/AndroidRuntime( 1690): >>>>>>>>>>>>>> AndroidRuntime START <<<<<<<<<<<<<< D/AndroidRuntime( 1690): CheckJNI is ON D/AndroidRuntime( 1690): --- registering native functions --- I/Zygote ( 1690): Preloading classes... E/dalvikvm-gc( 1690): Could not create 176128-byte ashmem mark stack I/DEBUG ( 1635): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG ( 1635): Build fingerprint: 'generic/generic/generic/:1.0/ TC3/eng.mvill.20081029.135723:eng/test-keys' I/DEBUG ( 1635): pid: 1690, tid: 1690 >>> zygote <<< I/DEBUG ( 1635): signal 11 (SIGSEGV), fault addr fffffffc I/DEBUG ( 1635): r0 00000000 r1 400117f8 r2 00000000 r3 fffffffc I/DEBUG ( 1635): r4 ad07fa78 r5 400091e8 r6 00072430 r7 00059aa0 I/DEBUG ( 1635): r8 00000000 r9 00059a60 10 00072470 fp beec26d0 I/DEBUG ( 1635): ip 400091e8 sp beec26c0 lr ad07edf8 pc ad0161b8 cpsr 00000010 I/DEBUG ( 1635): #00 pc ad0161b8 /system/lib/libdvm.so I/DEBUG ( 1635): #01 pc ad01482c /system/lib/libdvm.so I/DEBUG ( 1635): #02 pc ad0481ac /system/lib/libdvm.so I/DEBUG ( 1635): #03 pc ad03bc00 /system/lib/libdvm.so I/DEBUG ( 1635): #04 pc ad0434b8 /system/lib/libdvm.so I/DEBUG ( 1635): #05 pc ad012748 /system/lib/libdvm.so I/DEBUG ( 1635): #06 pc ad02a92c /system/lib/libdvm.so I/DEBUG ( 1635): #07 pc ad0169d0 /system/lib/libdvm.so I/DEBUG ( 1635): #08 pc ad051f40 /system/lib/libdvm.so I/DEBUG ( 1635): #09 pc ad03f8aa /system/lib/libdvm.so I/DEBUG ( 1635): #10 pc ad030b96 /system/lib/libdvm.so I/DEBUG ( 1635): #11 pc ad326500 /system/lib/ libandroid_runtime.so I/DEBUG ( 1635): #12 pc ad326f90 /system/lib/ libandroid_runtime.so I/DEBUG ( 1635): #13 pc 00008bf2 /system/bin/app_process I/DEBUG ( 1635): #14 pc afe1e042 /system/lib/libc.so I/DEBUG ( 1635): #15 pc afe0b010 /system/lib/libc.so I/DEBUG ( 1635): #16 pc b0000d70 /system/bin/linker I/DEBUG ( 1635): stack: I/DEBUG ( 1635): beec2680 afe35d78 I/DEBUG ( 1635): beec2684 00002040 I/DEBUG ( 1635): beec2688 00002bb4 I/DEBUG ( 1635): beec268c beec26d0 [stack] I/DEBUG ( 1635): beec2690 ad07edf8 I/DEBUG ( 1635): beec2694 40009200 I/DEBUG ( 1635): beec2698 00059aa0 [heap] I/DEBUG ( 1635): beec269c ad049839 /system/lib/libdvm.so I/DEBUG ( 1635): beec26a0 beec26d0 [stack] I/DEBUG ( 1635): beec26a4 ad049851 /system/lib/libdvm.so I/DEBUG ( 1635): beec26a8 400091e8 I/DEBUG ( 1635): beec26ac ad07fa78 I/DEBUG ( 1635): beec26b0 400091e8 I/DEBUG ( 1635): beec26b4 00000320 I/DEBUG ( 1635): beec26b8 df002777 I/DEBUG ( 1635): beec26bc e3a070ad I/DEBUG ( 1635): #00 beec26c0 00000320 I/DEBUG ( 1635): beec26c4 ad07edf8 I/DEBUG ( 1635): beec26c8 00000010 I/DEBUG ( 1635): beec26cc 00000320 I/DEBUG ( 1635): beec26d0 00072430 [heap] I/DEBUG ( 1635): beec26d4 00072470 [heap] I/DEBUG ( 1635): beec26d8 00000080 I/DEBUG ( 1635): beec26dc 7fffffff I/DEBUG ( 1635): beec26e0 00000320 I/DEBUG ( 1635): beec26e4 00000000 I/DEBUG ( 1635): beec26e8 00000000 I/DEBUG ( 1635): beec26ec 400091e8 I/DEBUG ( 1635): beec26f0 00000000 I/DEBUG ( 1635): beec26f4 ad07edf8 I/DEBUG ( 1635): beec26f8 00000320 I/DEBUG ( 1635): beec26fc 00002710 I/DEBUG ( 1635): beec2700 00000001 I/DEBUG ( 1635): beec2704 ad014830 /system/lib/libdvm.so I/DEBUG ( 1635): #01 beec2708 00000001 I/DEBUG ( 1635): beec270c afe0df4c /system/lib/libc.so I/DEBUG ( 1635): beec2710 4108e230 I/DEBUG ( 1635): beec2714 00000001 I/DEBUG ( 1635): beec2718 ad07fd54 I/DEBUG ( 1635): beec271c 00000001 I/DEBUG ( 1635): beec2720 ad03bbf9 /system/lib/libdvm.so I/DEBUG ( 1635): beec2724 4001f080 I/DEBUG ( 1635): beec2728 ad07edf8 I/DEBUG ( 1635): beec272c 000010f8 I/DEBUG ( 1635): beec2730 0000bb00 [heap] I/DEBUG ( 1635): beec2734 4104af40 I/DEBUG ( 1635): beec2738 00000000 I/DEBUG ( 1635): beec273c ad0481af /system/lib/libdvm.so init: critical process 'servicemanager' exited 4 times in 4 minutes; rebooting into recovery mode any idea, what might cause this problem? bye Markus On 12 Nov., 08:49, mvniekerk <[EMAIL PROTECTED]> wrote: > Cool. I couldn't get Android and JFFS2 running. I know it is possible > to loop-mount ext3 on JFFS2 to bridge the mmap problem with the data > partition. UBIFS is an all-inclusive solution for me at the moment and > is quite simple and as oppose to ext3 knows how to handle flash with > all its gotchas. As far as I know it is JFFS2, YAFFS2 and UBIFS that > is tailored for flash devices. > > Well, the options are legio it seems but do yourself a favour and look > into UBIFS. I'll be sitting in the corner and eat my humble pie... > > On Nov 11, 2:56 pm, Sean McNeil <[EMAIL PROTECTED]> wrote: > > > mvniekerk wrote: > > > Well, I can help you with this much - jffs2 + Android = No Go. It will > > > Not true. Android runs perfectly on the Openmoko Freerunner using JFFS2 > > for root and system. You need to qualify your statement as the only real > > partition that needs mmap is the /data partition. What I did for that is > > to split the sdcard into 2 partitions: fat for user data like music, > > videos, etc, and ext3 for the /data partition. > > > > run a few apps until the actual zygote stuff needs to run. mmap is the > > > thing that will screw you over - you only get mmap with read only > > > jffs2. > > > yaffs2 + NOR = No Go. It will fall over and flop. > > > UBIFS + NOR + Android = Works well actually. Got it running on our > > > iMX31 board with NOR. I'll post some instructions to get UBIFS working > > > if you need it. UBIFS = JFFS3. It has compression and a lot of other > > > cool stuff. It also scales well. > > > > On Nov 10, 4:10 pm, Markus <[EMAIL PROTECTED]> wrote: > > > >> Hi, > > > >> yes, we might change to a different file system, but actually, Android > > >> uses yaffs2 as main file system or at least it seems like this if you > > >> hack into its configuration files. To be honest, we do not know, if > > >> this problem is caused by the file system or something else as we are > > >> able to do file operations in /data/app during the booting process. > > >> The kernel panic occurs after Android finished the booting process. So > > >> our guess is that Android starts something, that watches the file > > >> system (especially /data/app) and that this service is causing our > > >> problem. Unfortunately, we could not yet locate, which tool is > > >> responsible... any guess, what is started in the end of the booting > > >> process, that might cause our problem? > > > >> Below, a log of the kernel panic. > > > >> Bye > > >> Markus > > > >> busybox cp ApiDemos.apk test > > >> Unable to handle kernel paging request at virtual address 00100104 > > >> pgd = c70a4000 > > >> [00100104] *pgd=870a2031, *pte=857180dd, *ppte=8571880e > > >> Internal error: Oops: 81f [#1] PREEMPT > > >> Modules linked in: > > >> CPU: 0 Not tainted (2.6.24-140-g68eb4b4 #77) > > >> PC is at android_unlock_suspend+0x60/0x170 > > >> LR is at android_unlock_suspend+0x34/0x170 > > >> pc : [<c01ff8b4>] lr : [<c01ff888>] psr: 60000193 > > >> sp : c711bea8 ip : c039bac4 fp : c711bee4 > > >> r10: c711a000 r9 : 000001e0 r8 : 60000113 > > >> r7 : c7de20a0 r6 : c039babc r5 : c039babc r4 : c7de20e0 > > >> r3 : c7c35da8 r2 : 00100100 r1 : 00200200 r0 : c7de20e0 > > >> Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user > > >> Control: 00e5387f Table: 870a4000 DAC: 00000015 > > >> Process FileObserver (pid: 1675, stack limit = 0xc711a260) > > >> Stack: (0xc711bea8 to 0xc711c000) > > >> bea0: c710401c c7cfac40 c711bed4 c711bec0 c00603cc > > >> c006035c > > >> bec0: c73dc3c0 00000000 c73dc3d0 c7de20a0 c73dc3c0 c711a000 c711befc > > >> c711bee8 > > >> bee0: c00c4f90 c01ff860 c73dc3c0 46a2cba4 c711bf4c c711bf00 c00c57d0 > > >> c00c4f30 > > >> bf00: c003f92c 46a2cb84 c7cfac70 00000000 c7cfac40 c005b298 c711bf18 > > >> c711bf18 > > >> bf20: c02bfa58 c7043ea0 46a2cb84 c711bf78 00000200 c0025004 c711a000 > > >> 41046fc0 > > >> bf40: c711bf74 c711bf50 c00961a4 c00c5634 c711bf74 c711bf60 c7043ea0 > > >> fffffff7 > > >> bf60: 00000000 00000000 c711bfa4 c711bf78 c00965ec c00960fc 00000000 > > >> 00000000 > > >> bf80: 001ce0b0 00000001 00000f4c ad352cd8 001cf5b8 00000003 00000000 > > >> c711bfa8 > > >> bfa0: c0024e80 c00965b4 00000f4c ad352cd8 0000001e 46a2cb84 00000200 > > >> fd1fafed > > >> bfc0: 00000f4c ad352cd8 001cf5b8 00000003 46a2cda0 41046fd4 41046fc0 > > >> 00000001 > > >> bfe0: ad353458 46a2cb48 ad3414c9 afe0b50c 00000010 0000001e 00ff00ff > > >> 00ff00ff > > >> Backtrace: > > >> [<c01ff854>] (android_unlock_suspend+0x0/0x170) from [<c00c4f90>] > > >> (remove_kevent+0x6c/0x94) > > >> [<c00c4f24>] (remove_kevent+0x0/0x94) from [<c00c57d0>] (inotify_read > > >> +0x1a8/0x1e4) > > >> r4:46a2cba4 > > >> [<c00c5628>] (inotify_read+0x0/0x1e4) from [<c00961a4>] (vfs_read > > >> +0xb4/0x144) > > >> [<c00960f0>] (vfs_read+0x0/0x144) from [<c00965ec>] (sys_read > > >> +0x44/0x70) > > >> r7:00000000 r6:00000000 r5:fffffff7 r4:c7043ea0 > > >> [<c00965a8>] (sys_read+0x0/0x70) from [<c0024e80>] (ret_fast_syscall > > >> +0x0/0x2c) > > >> r7:00000003 r6:001cf5b8 r5:ad352cd8 r4:00000f4c > > >> Code: e5965000 e5812000 e5843000 e59c3000 (e5821004) > > >> Kernel panic - not syncing: Fatal exception > > > >> On 9 Nov., 10:16, mvniekerk <[EMAIL PROTECTED]> wrote: > > > >>> Your answer lies in UBIFS. There is a port for kernel 2.6.24 up to > > >>> 2.6.27. UBIFS is JFFS3 if you like - and it does support mmap. If your > > >>> flash chip is of the NOR-type then YAFFS2 will not work - that is what > > >>> makes UBIFS so sweet! > > >>> To set up a UBI volume for UBIFS is bit of a schlep, but once done it > > >>> is a cool piece of equipment. > > > >>> On Nov 6, 11:39 pm, Markus <[EMAIL PROTECTED]> wrote: > > > >>>> Hi, > > > >>>> it is the init process, that cannot start. The kernel is always > > >>>> booting fine and only the Android init process is not able to do its > > >>>> job. For yaffs2, the booting process stops like > > >>>> inhttp://groups.google.com/group/android-porting/browse_thread/thread/d... > > >>>> - I'm sorry, that I can't post my own message at the moment, but I do > > >>>> not have access to the hardware right now to flash everything... > > > >>>> Like in the link above, we get the same problem about the magic > > >>>> number, while Android tries to load the core.jar file. After 4 tries, > > >>>> Android resigns and reboots. > > > >>>> bye > > >>>> Markus > > > >>>> On 6 Nov., 17:22, "Gergely Kis" <[EMAIL PROTECTED]> wrote: > > > >>>>> Hi, > > > >>>>> Could you give more information regarding "Android was not able to > > >>>>> boot onyaffs2". What were the actual error messages? Did the kernel > > >>>>> hang, or the init process? > > > >>>>> Best Regards, > > >>>>> Gergely > > > >>>>> On Thu, Nov 6, 2008 at 4:18 PM, Markus <[EMAIL PROTECTED]> wrote: > > > >>>>>> Hi, > > > >>>>>> as I wrote in Android Internals, we ported Android to an i.MX31. > > >>>>>> Unfortunately, we have some issues with the file system. > > >>>>>> If I use NFS as file system with a modified init.rc config, > > >>>>>> everything > > >>>>>> seems to work well, but this is no option for us as permanent file > > >>>>>> system, so we decided to useyaffs2as file system. As this did not > > >>>>>> work (Android was not able to boot), we changed to jffs2. jffs2 boots > > >>>>>> fine as long as we use a read-only file system. After booting, we can > > >>>>>> start many applications, but it seems that those requiring file write > > >>>>>> operations fail to start, e.g. the webbrowser. If we change init.rc > > >>>>>> config to give file-write permissions, Android is not able to boot > > >>>>>> anymore. > > > >>>>>> So we have decided to use a mixture ofyaffs2and jffs2, after we saw > > >>>>>> this idea at the armv4 port. The basic idea is, that all mmap > > >>>>>> operations are done onyaffs2, as jffs2 does not support them. At the > > >>>>>> moment, we split the file system to two parts: /data is located on > > >>>>>> our > > >>>>>> yaffs2partition, everything else on our jffs2 partition. The system > > >>>>>> boots fine and we can run every application. But now, it is getting > > >>>>>> confusing: As soon as Android has finished booting, it is impossible > > >>>>>> to write/delete files in /data/app - if we do, we get a kernel panic, > > >>>>>> which reports FileObserver to fail. This does not happen, if we do > > >>>>>> file accesses before Android has finished its booting process. > > > >>>>>> Remembering that we had some cases, in which it was necessary to > > >>>>>> start > > >>>>>> the system with strace running in the background (and discarding the > > >>>>>> log), I booted theyaffs2/jffs2 system with strace in the background. > > >>>>>> Now, I am able to access files in /data/app, I just get "syscall: > > >>>>>> unknown syscall trap 0xe1a00000" reported to my debug console. In > > >>>>>> this > > >>>>>> mode, it is also possible to run applications directly from Eclipse > > >>>>>> on > > >>>>>> the target device. > > > >>>>>> So can anybody tell me what is going wrong, if I use ayaffs2only > > >>>>>> file system? And why does strace heal those problems with ayaffs2/ > > >>>>>> jffs2 system? It just makes the system slower... > > > >>>>>> bye > > >>>>>> Markus --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [EMAIL PROTECTED] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
