Hello,
I had this problem before.
I fixed it by implementing the double buffering for frame buffer.
The details of double buffering implementation can be found at
http://www.yuan.se/?p=7
Regards,
Jack
On 2009年11月18日, 下午11時05分, Alexey Roslyakov
alexey.roslya...@gmail.com wrote:
Hello,
I
Hi,
I am also facing the same issue, when i tried to port Eclair. If the
issue is already resolved by anyone, please post the resolution.
Best Regards,
Srinivas Kalbhavi
On Nov 23 2009, 3:27 pm, AchimNohl achim.n...@coware.com wrote:
Hi Alexey,
here is my logcat after removing the locks from
Yes, it's mot safe, we also must add lockunlock before and after
call to gralloc_alloc_buffer in function gralloc_alloc. But I guess
your uncaught exception is essentially another problem, not gralloc-
deadlock-related one.
Can you post logcat?
On 21 ноя, 13:08, AchimNohl achim.n...@coware.com
Hi Alexey,
solution is simple: just remove lockunlock of mutex.
it is locked before (in the same thread), so deadlock occurs.
this does not seem to be safe. I have tried that and got beyond the
point. But now the system crashes later with an uncaught exception in
thread 19 PID 419 in my case.
Hi all,
I have see the same symptom while brining up 2.0 on an ARM926EJS based
(virtual) platform. 1.5 was working fine and my kernel remained
unchanged. In my analysis tools, I see that in my case the boot gets
stuck in a pthread_mutex_lock. After that the CPU is just idle. The
lock is called
On Fri, Nov 20, 2009 at 7:00 AM, AchimNohl achim.n...@coware.com wrote:
Hi all,
I have see the same symptom while brining up 2.0 on an ARM926EJS based
(virtual) platform. 1.5 was working fine and my kernel remained
unchanged. In my analysis tools, I see that in my case the boot gets
stuck
On Fri, Nov 20, 2009 at 12:07 PM, Porting beginner
porting.begin...@gmail.com wrote:
On Fri, Nov 20, 2009 at 7:00 AM, AchimNohl achim.n...@coware.com wrote:
Hi all,
I have see the same symptom while brining up 2.0 on an ARM926EJS based
(virtual) platform. 1.5 was working fine and my
Hi,
Alexey Roslyakov wrote:
Can you share your diff and/or logcat output?
sorry, I will try to send tomorow. I would like to restart and merge the
two patches
Michael
On Nov 20, 12:22 am, Michael Trimarchi trimar...@gandalf.sssup.it
wrote:
Hi,
Alexey Roslyakov wrote:
I added
solution is simple: just remove lockunlock of mutex.
it is locked before (in the same thread), so deadlock occurs.
And probably next problem appears:(
I/gralloc ( 710): refresh rate = 53.04 Hz
I/gralloc ( 710): fb_device_open res: 0
E/gralloc ( 710): couldn't open pmem (Unknown error: -2)
On Fri, Nov 20, 2009 at 2:47 PM, Alexey Roslyakov
alexey.roslya...@gmail.com wrote:
solution is simple: just remove lockunlock of mutex.
it is locked before (in the same thread), so deadlock occurs.
And probably next problem appears:(
I/gralloc ( 710): refresh rate = 53.04 Hz
I/gralloc (
No - BUS is arrived:)
It seems PMEM now is required in kernel.
On 21 ноя, 01:54, Porting beginner porting.begin...@gmail.com wrote:
On Fri, Nov 20, 2009 at 2:47 PM, Alexey Roslyakov
alexey.roslya...@gmail.com wrote:
solution is simple: just remove lockunlock of mutex.
it is locked
On Fri, Nov 20, 2009 at 6:19 PM, Alexey Roslyakov
alexey.roslya...@gmail.com wrote:
No - BUS is arrived:)
It seems PMEM now is required in kernel.
PMEM ? but its already enabled , CONFIG_ANDROID_PMEM=y in my kernel.
I talk to one more developer same here on android-porting, he said he
Is /dev/pmem present on target? Just compiled-in module is not enough.
Take a look on gralloc.cpp. If /dev/pmem is not available buffers
couldn't be allocated, gralloc's functions fails.
On 21 ноя, 05:27, Porting beginner porting.begin...@gmail.com wrote:
On Fri, Nov 20, 2009 at 6:19 PM, Alexey
I added LOGI just before return from fb_device_open.
I/gralloc ( 713): fb_device_open res: 0
fb device initialized successfully. Problem is not here.
But where?
--
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
Hi,
Alexey Roslyakov wrote:
I added LOGI just before return from fb_device_open.
I/gralloc ( 713): fb_device_open res: 0
fb device initialized successfully. Problem is not here.
But where?
maybe we have the same architecture. I'm compiling eclair for openmoko but
the issue that I
Michael, our architectures are almost identical (arm920 s3c244x).
http://www.newsycat.com/android/eclair/eclair_20112009.diff
On 20 ноя, 00:22, Michael Trimarchi trimar...@gandalf.sssup.it
wrote:
Hi,
Alexey Roslyakov wrote:
I added LOGI just before return from fb_device_open.
I/gralloc (
On Thu, Nov 19, 2009 at 2:45 PM, Alexey Roslyakov
alexey.roslya...@gmail.com wrote:
Michael, our architectures are almost identical (arm920 s3c244x).
http://www.newsycat.com/android/eclair/eclair_20112009.diff
On 20 ноя, 00:22, Michael Trimarchi trimar...@gandalf.sssup.it
wrote:
Hi,
Where did you find this file?
~/mydroid$ find . -name '*ramebuffer.cpp'
./hardware/msm7k/libgralloc/framebuffer.cpp
./hardware/msm7k/libgralloc-qsd8k/framebuffer.cpp
./hardware/libhardware/modules/gralloc/framebuffer.cpp
On 20 ноя, 01:54, Porting beginner porting.begin...@gmail.com wrote:
On
On Thu, Nov 19, 2009 at 3:56 PM, Alexey Roslyakov
alexey.roslya...@gmail.com wrote:
Where did you find this file?
~/mydroid$ find . -name '*ramebuffer.cpp'
./hardware/msm7k/libgralloc/framebuffer.cpp
./hardware/msm7k/libgralloc-qsd8k/framebuffer.cpp
Can you share your diff and/or logcat output?
On Nov 20, 12:22 am, Michael Trimarchi trimar...@gandalf.sssup.it
wrote:
Hi,
Alexey Roslyakov wrote:
I added LOGI just before return from fb_device_open.
I/gralloc ( 713): fb_device_open res: 0
fb device initialized successfully. Problem
20 matches
Mail list logo
