Hi Raymond,
I remember you having reported an error with regards
to vmalloc when binder tries to perform mmap. Could you get rid of
this problem? I was able to resolve my board hang issue. The issue was
due to some conflict between the device nodes for "alarm" and "eac"
(audio device). Now I'm able to bring up android without stracing and
also the binder module is functional now. However the Android home
screen pops up a message "com.google.googleapps not responding" and
the android framework stops responding to the HW keyboard events. All
I can see is couple of message for wakeup and sleep from power module.
Sometimes when I press the enter key on the HW keyboard, I do see that
the binder module tries to do mmap and fails with vmalloc error
simliar to what you had observed. The platform on which this is being
tried has got 128MB of RAM and the rootfs is currently mounted from an
NFS server.
"cat /proc/meminfo" command executed before launching Android shows
the following output:
MemTotal: 126680 kB
MemFree: 122616 kB
Buffers: 0 kB
Cached: 1788 kB
SwapCached: 0 kB
Active: 624 kB
Inactive: 1280 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 128 kB
Mapped: 300 kB
Slab: 1224 kB
SReclaimable: 408 kB
SUnreclaim: 816 kB
PageTables: 44 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 63340 kB
Committed_AS: 1504 kB
VmallocTotal: 122880 kB
VmallocUsed: 65864 kB
VmallocChunk: 49148 kB
What may be the reason for this vmalloc failure?????
Warm Regards,
Anil
On Mon, Mar 3, 2008 at 6:42 AM, colorant <colorant@xxxxxxx> wrote:
> >
> > 1. If the /dev/binder device node is missing or having wrong minor
> > number, the android display comes up properly.
> > 2. If the /dev/binder device node is created properly by making use of
> > the information from the "/proc/misc", then the "/system/bin/runtime"
> > spits out the following messages and then hangs for ever.
> > binder_open: 276:276
> > binder_mmap: 276 40000000-40400000 (4096 K) vma 71 pagep 5f
> > binder_open: 278:278
> > binder_mmap: 278 42648000-42a48000 (4096 K) vma 71 pagep 5f
> >
> > In fact the whole system hangs :-(
> >
> > Currently my platform on which this whole activity is being carried
> > out has only 64MB RAM and I presume the mmap calls may be failing due
> > to some memory crunch.
> >
> > It would be great if you could share your thoughts on the above given
> > observations.
> >
> > Warm Regards,
> > Anil
>
> Hi Anil
>
> I guess there still is some thing we don't handle well in the vmalloc
> related functions.
>
> My output messages after the first two binder_mmap is a binder_flush as
> following:
>
> binder_open: 500:500
> binder_mmap: 500 40008000-40408000 (4096 K) vma 71 pagep 5f
> binder_open: 510:510
> binder_mmap: 510 42650000-42a50000 (4096 K) vma 71 pagep 5f
> binder_flush: 510 woke 3 threads
> binder_open: 537:537
> binder_mmap: 537 42650000-42a50000 (4096 K) vma 71 pagep 5f
>
> And three more mmap later, the main screen is shown.
>
> However I also got a mmap fail :
>
> binder_open: 552:552
> binder_mmap: 552 42650000-42a50000 (4096 K) vma 71 pagep 5f
> binder_open: 554:554
> binder_mmap: 554 42650000-42a50000 (4096 K) vma 71 pagep 5f
> binder_open: 498:507
> binder_mmap: 498 40108000-40508000 (4096 K) vma 71 pagep 5f
> allocation failed: out of vmalloc space - use vmalloc=<size> to increase
> size.
> binder_mmap: 498 40108000-40508000 get_vm_area failed -12
>
> And I remember that I had to modify some vmalloc related functions to make
> the binder driver working happy with my 2.6.21 kernel. I think there might
> be something I miss to modify which is changed from 2.6.21 kernel to 2.6.23
> kernel but can be compiled without problem.
>
> However, since I just want to verify the possiblility of porting the android
> to my platform and don't want to really make it perfect for now, So I don't
> want to study further at this point, I will just wait until the whole
> system's src is available so that the problem hunting job is more easy to
> do.
>
> And , Just my guess, It might be helpful to read the emulator's src code ?
> Since the goldfish is base on it, and I can see that some hardware releated
> code, when I trace it down, it finally direct to a register reading or
> writing without any clue of what is going on.
>
> Rayomnd
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
