Your progress is very similar with me. :)
Clean "/data/cache" directory, and try again.

As I remember, it will fix the problem.

Bye


On 11월13일, 오후8시46분, Markus <[EMAIL PROTECTED]> wrote:
> Hi,
>
> thank you for that advice, the error changed to
>
> D/AndroidRuntime
> ( 1647):
> D/AndroidRuntime( 1647): >>>>>>>>>>>>>> AndroidRuntime START
> <<<<<<<<<<<<<<
> D/AndroidRuntime( 1647): CheckJNI is
> ON
> W/dalvikvm( 1647): DexOpt: incorrect opt magic number (0xff ff ff
> ff)
> D/dalvikvm( 1647): Stale deps in cache file; removing and
> retrying
> D/dalvikvm( 1647): DexOpt: --- BEGIN 'core.jar' (bootstrap=1)
> ---
> D/dalvikvm( 1654): Ignoring duplicate verify attempt on Ljava/lang/
> Object;
> init: untracked pid 1647
> exited
> init: untracked pid 1654 exited
>
> What might cause this error? I changed the whole file system to rwx
> permission for all users (so 777) just to see, if it is some rights
> issue again. It did not help.
>
> bye
> Markus
>
> On 13 Nov., 07:07, "sungjun.lee" <[EMAIL PROTECTED]> wrote:
>
>
>
> > > D/AndroidRuntime( 1690): --- registering native functions ---
> > > I/Zygote  ( 1690): Preloading classes...
> > > E/dalvikvm-gc( 1690): Could not create 176128-byte ashmem mark stack
>
> > Hi, Markus
>
> > I had similar DEBUG messages, and i fix that problem with following.
>
> > 1. Check /dev/ashmem device file's permission. (Change permission in
> > order to make runtime process accessible(rw). )
> > 2. /init.rc script seems to remount / as read only. To deactivate read-
> > only remounting, just comment out the mount command line.
>
> > Hope it helps.
>
> > See this thread more detail
> > - http://www.mail-archive.com/[EMAIL PROTECTED]/msg05631.html
>
> > On 11월12일, 오후10시11분, Markus <[EMAIL PROTECTED]> wrote:
>
> > > 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 andJFFS2running. I know it is possible
> > > > to loop-mount ext3 onJFFS2to 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 isJFFS2, 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 usingJFFS2
> > > > > 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.- 따온 텍스트 숨기기 -
>
> - 따온 텍스트 보기 -...
>
> 추가 정보 >>
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: [EMAIL PROTECTED]
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---

Reply via email to