Advent Vega kernel source code now available!

[Guest pershoot]

here is the fix for the green splash on render issue.

need these libs (at a bare minimum) from fards's .39 based build (i believe you have them).

(your egl.cfg should have 0 1 tegra):

lib -

libnvddk_2d_v2.so

libcgdrv.so

libardrv_dynamic.so

libnvmm_vp6_video.so

libnvwsi.so

libnvwinsys.so

libnvos.so

libnvrm.so

libnvrm_graphics.so

lib/egl -

libGLESv2_tegra.so

libGLESv1_CM_tegra.so

libEGL_tegra.so

lib/hw -

hwcomposer.tegra.so

gralloc.tegra.so

my advice is to work with .36, as i believe this is currently stable/developed for your device.

back ported dc/fb/nvmap from .39 (using the new interface calls/allocation, etc.), for 2.6.36:

https://github.com/p...2898db6e153e309

https://github.com/p...99f1c02364caf9a

https://github.com/p...27ebf80724418ae

https://github.com/p...37e4963a1c688fe

youll need to modify some for your specific device. you can bring it under VARIATION_TEGRA and then remove that dependancy.

you could probably also use .39 (i have not backported/tested the nvhost stuff from there though), if you feel you have a stable subsystem to work with. dc/fb must not be modified for the older userspace/libs (you have the libs/userspace to work with them now).

in init.rc, set:

chmod 666 /dev/tegra_dc0

chmod 666 /dev/tegra_dc1

that should do it.

also use:

BoardConfig:

USE_OPENGL_RENDERER := true

just as an fyi,

.39 dc/fb not needed. latest dc/fb in .36 nvidia work as well.

[Guest Cass67]

Alpha 1 of VegaICS released ...

http://t.co/z1AlTaUE

Lets see how it goes ;)

Cheers

Cass

[Guest brucelee666]

Alpha 1 of VegaICS released ...

http://t.co/z1AlTaUE

Lets see how it goes ;)

Cheers

Cass

You may know this but they just pushed 4.0.3 to git (repo sync away) see :-

ICS 4.0.3 news

Also included is the sh file to get nvidia binaries for "stingray" and "wingray" which may be of use for you, not sure if they were released before.

edit:- Forgot to say great work on getting an alpha build out, will have a look when I get a chance, Thanks.

Edited December 17, 2011 by brucelee666

[Guest ejtagle]

Little fixes :D

>Accelerometer working

>Backlight control working

Please, remove sensors.*.so and lights.*.so from /system/lib/hw and copy the ones i supply. Otherwise, they could interfer with our drivers.

I have attached the source of both drivers: They replace the files of the same name in the ICS AOSP patch i provided some time ago. You must be sure to name the resulting compiled drivers as sensors.$(BOARD_NAME).so and lights.$(BOARD_NAME).so. Probably that will require to slightly modify their associated Android,mk files.

BOARD_NAME represents the exact board name used in build.prop. Otherwise, ICS wont load them. I noticed you called it Shuttle ;)

Regards.

Eduardo

hw.rar

[Guest pershoot]

just as an fyi,

.39 dc/fb not needed. latest dc/fb in .36 nvidia work as well.

this was all that was required to work with the new userspace:

https://github.com/p...e771401b724dc91

(along with tiled/inverse display support)

Edited December 17, 2011 by pershoot

[Guest Cass67]

Little fixes :D

>Accelerometer working

>Backlight control working

Please, remove sensors.*.so and lights.*.so from /system/lib/hw and copy the ones i supply. Otherwise, they could interfer with our drivers.

I have attached the source of both drivers: They replace the files of the same name in the ICS AOSP patch i provided some time ago. You must be sure to name the resulting compiled drivers as sensors.$(BOARD_NAME).so and lights.$(BOARD_NAME).so. Probably that will require to slightly modify their associated Android,mk files.

BOARD_NAME represents the exact board name used in build.prop. Otherwise, ICS wont load them. I noticed you called it Shuttle ;)

Regards.

Eduardo

Yup works ... though strangely enough Shuttle should not have been there .. should have been tegra, oversight on my part it seems :)

Looking to compile the Xoom code now to see if that gives us any more stability .. Just pulled it and having a look through..

edit :- the sensors are a bit chatty in the logs .. this is all it spawns ..

D/Sensors ( 138): poll

D/Sensors ( 138): poll

<snip>

Thanks

Cass

Edited December 17, 2011 by Cass67

[Guest Cass67]

Having fun now with squashfs ...

Filesystem Size Used Available Use% Mounted on

/dev/block/mtdblock3 151.4M 123.8M 27.6M 82% /system

/dev/block/loop0 2.3M 2.3M 0 100% /system/fonts

/dev/block/loop1 11.8M 11.8M 0 100% /system/framework

/dev/block/loop2 3.3M 3.3M 0 100% /system/usr

/dev/block/loop3 58.8M 58.8M 0 100% /system/app

/dev/block/loop4 20.6M 20.6M 0 100% /system/lib

# du -sh /system/app

81.1M /system/app

# du -sh /system/lib

49.0M /system/lib

# du -sh /system/fonts

5.2M /system/fonts

# du -sh /system/usr

9.2M /system/usr

We're seeing almost a 60MB gain by doing it this way ...

This is with all apps and all Gapps in place ... had to copy out libc.so to vendor/lib to enjoy the benifits of squashing the lib dir but for those with no need to change things when it all up and good it should really assist with the bad block problem, 27mb free in /system w00t ;)

Ohh and thats from a 4.0.3 ICS image :)

Fun !!

edit .. meant to say .. 38sec boot time from pressing the power button to getting to lockscreen .. not so bad .... performance seems ok in operation too ...

edit 2

/dev/block/mtdblock3 151.4M 120.2M 31.2M 79% /system

actually 30mb free after i remove a few duplicate apps that crept in from the Gapps install ...

edit 3 @eduardo

Had to disable the keyboard repeat to fix the flashy power dialogue on pressing the sleep/power button

# grep rep board-shuttle-keyboard.c

.rep = false, /* auto repeat enabled */

Was disabled in .36 but seems it crept back in to .39 ...

Also

.gpio = SHUTTLE_KEY_POWER,

.active_low = true,

//.debounce_interval =250,

.debounce_interval =50,

to enable proper sleep / shutdown action :)

edit 4 @ eduardo

Seems Google released the latest nvidia libs for 4.0.3 ...

http://code.google.c...rs.html#wingray

they dont boot at all, assuming they need kernel changes ... complains on gralloc that it cant get it ...

https://android.goog...ernel/tegra.git

has code for moto .39 kernel ... may be usefull to pick out whats different :)

# git branch -a

* master

remotes/origin/HEAD -> origin/master

remotes/origin/android-tegra-moto-2.6.36

remotes/origin/android-tegra-moto-2.6.39

remotes/origin/master

Rgds

Cass

Edited December 19, 2011 by Cass67

[Guest ejtagle]

Having fun now with squashfs ...

Filesystem Size Used Available Use% Mounted on

/dev/block/mtdblock3 151.4M 123.8M 27.6M 82% /system

/dev/block/loop0 2.3M 2.3M 0 100% /system/fonts

/dev/block/loop1 11.8M 11.8M 0 100% /system/framework

/dev/block/loop2 3.3M 3.3M 0 100% /system/usr

/dev/block/loop3 58.8M 58.8M 0 100% /system/app

/dev/block/loop4 20.6M 20.6M 0 100% /system/lib

# du -sh /system/app

81.1M /system/app

# du -sh /system/lib

49.0M /system/lib

# du -sh /system/fonts

5.2M /system/fonts

# du -sh /system/usr

9.2M /system/usr

We're seeing almost a 60MB gain by doing it this way ...

This is with all apps and all Gapps in place ... had to copy out libc.so to vendor/lib to enjoy the benifits of squashing the lib dir but for those with no need to change things when it all up and good it should really assist with the bad block problem, 27mb free in /system w00t ;)

Ohh and thats from a 4.0.3 ICS image :)

Fun !!

edit .. meant to say .. 38sec boot time from pressing the power button to getting to lockscreen .. not so bad .... performance seems ok in operation too ...

edit 2

/dev/block/mtdblock3 151.4M 120.2M 31.2M 79% /system

actually 30mb free after i remove a few duplicate apps that crept in from the Gapps install ...

edit 3 @eduardo

Had to disable the keyboard repeat to fix the flashy power dialogue on pressing the sleep/power button

# grep rep board-shuttle-keyboard.c

.rep = false, /* auto repeat enabled */

Was disabled in .36 but seems it crept back in to .39 ...

Also

.gpio = SHUTTLE_KEY_POWER,

.active_low = true,

//.debounce_interval =250,

.debounce_interval =50,

to enable proper sleep / shutdown action :)

edit 4 @ eduardo

Seems Google released the latest nvidia libs for 4.0.3 ...

http://code.google.c...rs.html#wingray

they dont boot at all, assuming they need kernel changes ... complains on gralloc that it cant get it ...

https://android.goog...ernel/tegra.git

has code for moto .39 kernel ... may be usefull to pick out whats different :)

# git branch -a

* master

remotes/origin/HEAD -> origin/master

remotes/origin/android-tegra-moto-2.6.36

remotes/origin/android-tegra-moto-2.6.39

remotes/origin/master

Rgds

Cass

The moto xoom libraries are great news ;) --- I will also check the moto xoom kernel ...

[Guest ejtagle]

Well, patch against 2.6.39 motorola xoom kernel. Completely untested. (ran out of time) ... Tomorrow will continue with it. moto 2.6.39 seems not to be based on our 2.6.39 nvidia kernel base ...

patch2.6.39-moto.rar

Edited December 19, 2011 by ejtagle

[Guest Cass67]

Well, patch against 2.6.39 motorola xoom kernel. Completely untested. (ran out of time) ... Tomorrow will continue with it. moto 2.6.39 seems not to be based on our 2.6.39 nvidia kernel base ...

Compiles fine, just does not boot, great work for just a few hrs ... nice one :)

Cheers

Cass

[Guest ejtagle]

Truth to be said, i don't like the moto 2.6.39 kernel port... Seems to be just an old 2.6.36 nvidia kernel tegra support forward ported to the 2.6.39 kernel... Particularly, the video subsystem seems to be rather old... I will investigate this further... I think that our 2.6.39 nvidia based kernel is a better choice...

[Guest Cass67]

Truth to be said, i don't like the moto 2.6.39 kernel port... Seems to be just an old 2.6.36 nvidia kernel tegra support forward ported to the 2.6.39 kernel... Particularly, the video subsystem seems to be rather old... I will investigate this further... I think that our 2.6.39 nvidia based kernel is a better choice...

Keep ours and steal what we need to make gralloc happy .. i can live with that :)

[Guest ejtagle]

Keep ours and steal what we need to make gralloc happy .. i can live with that :)

The Nvidia gralloc does not load because a library called libpkip.so is missing. That library could be taken from the VC image... Adding it, the libs are recognized but still no graphics display. The libs have internal references to:

/dev/nvhdcp*

/dev/nvrm_daemon

/dev/graphics/fb*

/dev/tegra_sema

/dev/nvmap

/dev/tegra_rpc

/dev/nvhost-ctrl

/dev/nvhost-gr3d

/dev/nvhost-isp

/dev/nvhost-vi

/dev/nvhost-mpe

/dev/nvhost-dsi

/dev/nvhost-display

/dev/nvhost-gr2d

/dev/tegra_avp

So they should be properly created and with the right access. I guess the VC libs had the same requirements ... BTW, i have compared the 2.6.39-moto and the 2.6.36 video subsystem and they seem to share a common base, but are not exactly the same. The 2.6.39-moto has been modified to add something related to overlapped windows, and also the overlay manager has been removed.

I managed to boot the .39-moto once, but, it refused to boot afterwards... Have to figure out why

[Guest Cass67]

I noticed the requirement for the pkip lib last night while trying a few things out to stableize things a bit. I suspect 4.0.3 and beyond is going to need these changes to the kernel as android is very unstable it seems without them. Quite often we revert back to software endering prompting a warm reboot or fc.. not so nice.. could not work around it and the simplest of things cause it like typing on a keyboard..

edit:- appears we have all of those devices created with the exception of

/dev/nvrm_daemon

Thanks

Cass

Edited December 20, 2011 by Cass67

[Guest ejtagle]

I noticed the requirement for the pkip lib last night while trying a few things out to stableize things a bit. I suspect 4.0.3 and beyond is going to need these changes to the kernel as android is very unstable it seems without them. Quite often we revert back to software endering prompting a warm reboot or fc.. not so nice.. could not work around it and the simplest of things cause it like typing on a keyboard..

edit:- appears we have all of those devices created with the exception of

/dev/nvrm_daemon

Thanks

Cass

Just curious... Is there any log entry telling why the framework has reverted to software rendering ? -- Or it just plainly reboots?

I have been reading about this... Seems the AOSP 4.0.3 xoom image has HDMI issues (no output at all) ... Hummm.... And the 2.6.39 moto kernel has some obvious bugs that are not on the 2.6.39 nvidia version ... The boot crashes seem to be related to a race condition ... Honestly, the moto kernel seems to be a quick port of the 2.6.36 drivers to the 2.6.39 kernel... Seems nearly no testing was performed... So, i still have doubts on what to do... I would be interested to find out if the reboots / reverts to sw compositing are actually problems of the gralloc component, or a something else...

Edited December 21, 2011 by ejtagle

[Guest Cass67]

Just curious... Is there any log entry telling why the framework has reverted to software rendering ? -- Or it just plainly reboots?

I have been reading about this... Seems the AOSP 4.0.3 xoom image has HDMI issues (no output at all) ... Hummm.... And the 2.6.39 moto kernel has some obvious bugs that are not on the 2.6.39 nvidia version ... The boot crashes seem to be related to a race condition ... Honestly, the moto kernel seems to be a quick port of the 2.6.36 drivers to the 2.6.39 kernel... Seems nearly no testing was performed... So, i still have doubts on what to do... I would be interested to find out if the reboots / reverts to sw compositing are actually problems of the gralloc component, or a something else...

Ommiting all the crap i have in the log right now due to playing with audio and sensors the message thats always apparent is the following ...

E/SurfaceTexture( 95): [com.android.vending/com.android.vending.AssetBrowserActivity] queueBuffer: slot 0 is current!

E/SurfaceTextureClient(15274): queueBuffer: error queuing buffer to SurfaceTexture, -22

W/nvwsi (15274): queueBuffer failed, error -22

W/HardwareRenderer(15274): EGL error: EGL_BAD_CURRENT_SURFACE

W/HardwareRenderer(15274): Mountain View, we've had a problem here. Switching back to software rendering.

The fc on apps usually occurs when typing so im not sure if we dont just have a bug in LatinIME thus giving us another problem

W/InputManagerService(13670): Starting input on non-focused client com.android.internal.view.IInputMethodClient$Stub$Proxy@412e3fe8 (uid=10044 pid=15274)

D/OpenGLRenderer(13912): Flushing caches (mode 0)

I/LatinIME(13851): InputType.TYPE_NULL is specified

W/LatinIME(13851): Unexpected input class: inputType=0x00000000 imeOptions=0x00000000

W/InputManagerService(13670): Starting input on non-focused client com.android.internal.view.IInputMethodClient$Stub$Proxy@413c5768 (uid=10028 pid=13912)

D/dalvikvm(13738): GC_CONCURRENT freed 414K, 15% free 7679K/9031K, paused 1ms+4ms

D/OpenGLRenderer(13912): Flushing caches (mode 1)

E/SurfaceTexture( 95): [PopupWindow:411af2e8] queueBuffer: slot 1 is current!

E/SurfaceTextureClient(15274): queueBuffer: error queuing buffer to SurfaceTexture, -22

W/nvwsi (15274): queueBuffer failed, error -22

W/HardwareRenderer(15274): EGL error: EGL_BAD_CURRENT_SURFACE

W/HardwareRenderer(15274): Mountain View, we've had a problem here. Switching back to software rendering.

E/SurfaceTexture( 95): [PopupWindow:411af2e8] queueBuffer: slot 0 is current!

E/SurfaceTextureClient(15274): queueBuffer: error queuing buffer to SurfaceTexture, -22

E/SurfaceTextureClient(15274): queueBuffer (handle=0x331018) failed (Invalid argument)

D/AndroidRuntime(15274): Shutting down VM

W/dalvikvm(15274): threadid=1: thread exiting with uncaught exception (group=0x40a481f8)

E/AndroidRuntime(15274): FATAL EXCEPTION: main

E/AndroidRuntime(15274): java.lang.IllegalArgumentException

E/AndroidRuntime(15274): at android.view.Surface.unlockCanvasAndPost(Native Method)

E/AndroidRuntime(15274): at android.view.ViewRootImpl.draw(ViewRootImpl.java:2044)

E/AndroidRuntime(15274): at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1634)

E/AndroidRuntime(15274): at android.view.ViewRootImpl.handleMessage(ViewRootImpl.java:2442)

E/AndroidRuntime(15274): at android.os.Handler.dispatchMessage(Handler.java:99)

E/AndroidRuntime(15274): at android.os.Looper.loop(Looper.java:137)

E/AndroidRuntime(15274): at android.app.ActivityThread.main(ActivityThread.java:4424)

E/AndroidRuntime(15274): at java.lang.reflect.Method.invokeNative(Native Method)

E/AndroidRuntime(15274): at java.lang.reflect.Method.invoke(Method.java:511)

E/AndroidRuntime(15274): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)

E/AndroidRuntime(15274): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)

E/AndroidRuntime(15274): at dalvik.system.NativeStart.main(Native Method)

W/ActivityManager(13670): Force finishing activity com.android.vending/.AssetBrowserActivity

Typically when trying to get logs the settings app i want to crash as it does it every time we switch to sw rendering when its in use wont, ill update in a bit when i get those logs .. i don't have to be typing for that one, just pressing the screen ....

Sleeping is also a similar story,

D/ShutdownThread(16228): Notifying thread to start shutdown longPressBehavior=2

W/InputManagerService(16228): Window already focused, ignoring focus gain of: com.android.internal.view.IInputMethodClient$Stub$Proxy@414da438

D/Lights (16228): set_light_backlight: 95

D/Lights (16228): set_light_backlight: 88

D/Lights (16228): set_light_backlight: 81

D/Lights (16228): set_light_backlight: 74

D/Lights (16228): set_light_backlight: 67

D/Lights (16228): set_light_backlight: 61

D/Lights (16228): set_light_backlight: 54

D/Lights (16228): set_light_backlight: 47

D/Lights (16228): set_light_backlight: 40

D/Lights (16228): set_light_backlight: 33

D/Lights (16228): set_light_backlight: 27

D/Lights (16228): set_light_backlight: 20

D/Lights (16228): set_light_backlight: 13

D/Lights (16228): set_light_backlight: 6

D/Lights (16228): set_light_backlight: 0

I/power (16228): *** set_screen_state 0

V/TransportControlView(16228): Create TCV com.android.internal.widget.TransportControlView@413233c8

D/SurfaceFlinger( 95): About to give-up screen, flinger = 0xf918

D/audio_hw_primary(16193): !!!int adev_set_parameters()

D/audio_hw_primary(16193): !!!select_output_device() adev->devices: 262146

D/dalvikvm(16228): GC_CONCURRENT freed 572K, 17% free 9752K/11655K, paused 2ms+5ms

D/dalvikvm(16228): GC_FOR_ALLOC freed 648K, 20% free 9396K/11655K, paused 32ms

D/dalvikvm(16228): GC_FOR_ALLOC freed 417K, 19% free 9504K/11655K, paused 31ms

D/dalvikvm(16228): GC_FOR_ALLOC freed 367K, 18% free 9596K/11655K, paused 31ms

E/SurfaceTexture( 95): [statusBar] queueBuffer: slot 1 is current!

E/SurfaceTextureClient(17291): queueBuffer: error queuing buffer to SurfaceTexture, -22

E/SurfaceTextureClient(17291): queueBuffer (handle=0x1b2160) failed (Invalid argument)

D/AndroidRuntime(17291): Shutting down VM

W/dalvikvm(17291): threadid=1: thread exiting with uncaught exception (group=0x40a341f8)

E/AndroidRuntime(17291): FATAL EXCEPTION: main

E/AndroidRuntime(17291): java.lang.IllegalArgumentException

E/AndroidRuntime(17291): at android.view.Surface.unlockCanvasAndPost(Native Method)

E/AndroidRuntime(17291): at android.view.ViewRootImpl.draw(ViewRootImpl.java:2044)

E/AndroidRuntime(17291): at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1634)

E/AndroidRuntime(17291): at android.view.ViewRootImpl.handleMessage(ViewRootImpl.java:2442)

E/AndroidRuntime(17291): at android.os.Handler.dispatchMessage(Handler.java:99)

E/AndroidRuntime(17291): at android.os.Looper.loop(Looper.java:137)

E/AndroidRuntime(17291): at android.app.ActivityThread.main(ActivityThread.java:4424)

E/AndroidRuntime(17291): at java.lang.reflect.Method.invokeNative(Native Method)

E/AndroidRuntime(17291): at java.lang.reflect.Method.invoke(Method.java:511)

E/AndroidRuntime(17291): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)

E/AndroidRuntime(17291): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)

E/AndroidRuntime(17291): at dalvik.system.NativeStart.main(Native Method)

W/ActivityManager(16228): Process com.android.systemui has crashed too many times: killing!

I/Process (17291): Sending signal. PID: 17291 SIG: 9

I/ActivityManager(16228): Process com.android.systemui (pid 17291) has died.

I/WindowManager(16228): WIN DEATH: Window{4135cc78 StatusBar paused=false}

W/ActivityManager(16228): Scheduling restart of crashed service com.android.systemui/.SystemUIService in 6250ms

W/InputDispatcher(16228): channel '4141d698 NotificationPanel (server)' ~ Consumer closed input channel or an error occurred. events=0x8

E/InputDispatcher(16228): channel '4141d698 NotificationPanel (server)' ~ Channel is unrecoverably broken and will be disposed!

W/InputDispatcher(16228): Attempted to unregister already unregistered input channel '4141d698 NotificationPanel (server)'

I/WindowManager(16228): WIN DEATH: Window{4141d698 NotificationPanel paused=false}

I/WindowManager(16228): WIN DEATH: Window{41167210 InputMethodsPanel paused=false}

I/WindowManager(16228): WIN DEATH: Window{41167748 CompatModePanel paused=false}

I/WindowManager(16228): WIN DEATH: Window{414277c8 RecentsPanel paused=false}

I/WindowManager(16228): WINDOW DIED Window{4141d698 NotificationPanel paused=false}

I/ActivityManager(16228): Start proc com.android.systemui for restart com.android.systemui: pid=17321 uid=1000 gids={1015, 3002, 3001, 3003, 3007}

E/SurfaceTexture( 95): [Keyguard] queueBuffer: slot 1 is current!

E/SurfaceTextureClient(16228): queueBuffer: error queuing buffer to SurfaceTexture, -22

W/nvwsi (16228): queueBuffer failed, error -22

W/HardwareRenderer(16228): EGL error: EGL_BAD_CURRENT_SURFACE

W/HardwareRenderer(16228): Mountain View, we've had a problem here. Switching back to software rendering.

E/SurfaceTexture( 95): [Keyguard] queueBuffer: slot 0 is current!

E/SurfaceTextureClient(16228): queueBuffer: error queuing buffer to SurfaceTexture, -22

E/SurfaceTextureClient(16228): queueBuffer (handle=0x2f43f8) failed (Invalid argument)

W/dalvikvm(16228): threadid=24: thread exiting with uncaught exception (group=0x40a341f8)

E/AndroidRuntime(16228): *** FATAL EXCEPTION IN SYSTEM PROCESS: WindowManagerPolicy

E/AndroidRuntime(16228): java.lang.IllegalArgumentException

E/AndroidRuntime(16228): at android.view.Surface.unlockCanvasAndPost(Native Method)

E/AndroidRuntime(16228): at android.view.ViewRootImpl.draw(ViewRootImpl.java:2044)

E/AndroidRuntime(16228): at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1634)

E/AndroidRuntime(16228): at android.view.ViewRootImpl.handleMessage(ViewRootImpl.java:2442)

E/AndroidRuntime(16228): at android.os.Handler.dispatchMessage(Handler.java:99)

E/AndroidRuntime(16228): at android.os.Looper.loop(Looper.java:137)

E/AndroidRuntime(16228): at com.android.server.wm.WindowManagerService$PolicyThread.run(WindowManagerService.java:745)

I/Process (16228): Sending signal. PID: 16228 SIG: 9

I/ServiceManager( 90): service 'samplingprofiler' died

W/AudioFlinger(16193): power manager service died !!!

I/ServiceManager( 90): service 'input_method' died

I/ServiceManager( 90): service 'statusbar' died

I/ServiceManager( 90): service 'battery' died

I/ServiceManager( 90): service 'alarm' died

I/ServiceManager( 90): service 'appwidget' died

I/ServiceManager( 90): service 'power' died

I/ServiceManager( 90): service 'diskstats' died

Rgds

Cass

[Guest ejtagle]

I think i found a bug in my patch to the 2.6.39 nvidia kernel that could explain the issues we are having with the 2.6.39 nvidia kernel and gralloc. Based on the logs you supplied, semmes we are getting problems in the SurfaceTexture class. That class represents usually a video surface (Camera/video playback...)... I found that there was a bug in the computation of the U and V planes for YUVsurfaces in the fb.c file of the tegra video subsystem in the kernel.That bug was introduced when i ported the 2.6.36 missing video subsystem apis to the 2.6.39. Seems u and v offsets in the tegra_fb_windowattr are relative to the offset in the window ... At least, that is the way they seem to calculate it in the 2.6.36 kernel... And it was not calculated that way in my previous patch.

Attached the new patch that must be applied above the previous patch to the 2.6.39 nvidia kernel (Not the Motorola kernel!).. I haven't tested it or compiled it. Will do so later, but, just in case someone wants to try it before me ;)

Regards,

Eduardo

PS: I still think that the nvidia 2.6.39 is much better than the 2.6.39 moto zoom kernel ;)

patch2.rar

[Guest Cass67]

I think i found a bug in my patch to the 2.6.39 nvidia kernel that could explain the issues we are having with the 2.6.39 nvidia kernel and gralloc. Based on the logs you supplied, semmes we are getting problems in the SurfaceTexture class. That class represents usually a video surface (Camera/video playback...)... I found that there was a bug in the computation of the U and V planes for YUVsurfaces in the fb.c file of the tegra video subsystem in the kernel.That bug was introduced when i ported the 2.6.36 missing video subsystem apis to the 2.6.39. Seems u and v offsets in the tegra_fb_windowattr are relative to the offset in the window ... At least, that is the way they seem to calculate it in the 2.6.36 kernel... And it was not calculated that way in my previous patch.

Attached the new patch that must be applied above the previous patch to the 2.6.39 nvidia kernel (Not the Motorola kernel!).. I haven't tested it or compiled it. Will do so later, but, just in case someone wants to try it before me ;)

Regards,

Eduardo

PS: I still think that the nvidia 2.6.39 is much better than the 2.6.39 moto zoom kernel ;)

Compiles but still a bit crashy, this ones on sleep, the IOCTL FLIP is new for me ...

D/Lights ( 153): set_light_backlight: 95

D/Lights ( 153): set_light_backlight: 88

D/Lights ( 153): set_light_backlight: 81

D/Lights ( 153): set_light_backlight: 74

D/Lights ( 153): set_light_backlight: 67

D/Lights ( 153): set_light_backlight: 61

D/Lights ( 153): set_light_backlight: 54

D/Lights ( 153): set_light_backlight: 47

D/Lights ( 153): set_light_backlight: 40

D/Lights ( 153): set_light_backlight: 33

D/Lights ( 153): set_light_backlight: 27

D/Lights ( 153): set_light_backlight: 20

D/Lights ( 153): set_light_backlight: 13

D/Lights ( 153): set_light_backlight: 6

D/Lights ( 153): set_light_backlight: 0

I/power ( 153): *** set_screen_state 0

D/SurfaceFlinger( 96): About to give-up screen, flinger = 0xf918

E/gralloc ( 96): NvGrPost: Failed, TEGRA_OVERLAY_IOCTL_FLIP Broken pipe

V/TransportControlView( 153): Create TCV com.android.internal.widget.TransportControlView@414c1970

D/dalvikvm( 153): GC_FOR_ALLOC freed 504K, 16% free 9688K/11527K, paused 34ms

D/dalvikvm( 153): GC_FOR_ALLOC freed 279K, 16% free 9718K/11527K, paused 32ms

D/dalvikvm( 153): GC_FOR_ALLOC freed 435K, 15% free 9835K/11527K, paused 32ms

D/dalvikvm( 153): GC_FOR_ALLOC freed 185K, 13% free 10063K/11527K, paused 32ms

E/SurfaceTexture( 96): [statusBar] queueBuffer: slot 0 is current!

E/SurfaceTextureClient( 240): queueBuffer: error queuing buffer to SurfaceTexture, -22

E/SurfaceTextureClient( 240): queueBuffer (handle=0x18c700) failed (Invalid argument)

D/AndroidRuntime( 240): Shutting down VM

W/dalvikvm( 240): threadid=1: thread exiting with uncaught exception (group=0x40a241f8)

I/Process ( 240): Sending signal. PID: 240 SIG: 9

E/AndroidRuntime( 240): FATAL EXCEPTION: main

E/AndroidRuntime( 240): java.lang.IllegalArgumentException

E/AndroidRuntime( 240): at android.view.Surface.unlockCanvasAndPost(Native Method)

E/AndroidRuntime( 240): at android.view.ViewRootImpl.draw(ViewRootImpl.java:2044)

E/AndroidRuntime( 240): at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1634)

E/AndroidRuntime( 240): at android.view.ViewRootImpl.handleMessage(ViewRootImpl.java:2442)

E/AndroidRuntime( 240): at android.os.Handler.dispatchMessage(Handler.java:99)

E/AndroidRuntime( 240): at android.os.Looper.loop(Looper.java:137)

E/AndroidRuntime( 240): at android.app.ActivityThread.main(ActivityThread.java:4424)

E/AndroidRuntime( 240): at java.lang.reflect.Method.invokeNative(Native Method)

E/AndroidRuntime( 240): at java.lang.reflect.Method.invoke(Method.java:511)

E/AndroidRuntime( 240): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)

E/AndroidRuntime( 240): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)

E/AndroidRuntime( 240): at dalvik.system.NativeStart.main(Native Method)

I/WindowManager( 153): WIN DEATH: Window{41344500 InputMethodsPanel paused=false}

I/ActivityManager( 153): Process com.android.systemui (pid 240) has died.

Got a crash on market too but the error was same as previous one i posted, surface etc ...

edit :- interestingly rolling back to our .36 exhibits the same behaviour ..

E/SurfaceTexture( 1120): [PopupWindow:412a7fe8] queueBuffer: slot 1 is current!

E/SurfaceTextureClient( 2040): queueBuffer: error queuing buffer to SurfaceTexture, -22

W/nvwsi ( 2040): queueBuffer failed, error -22

W/HardwareRenderer( 2040): EGL error: EGL_BAD_CURRENT_SURFACE

W/HardwareRenderer( 2040): Mountain View, we've had a problem here. Switching back to software rendering.

E/SoundPool( 1143): Error creating AudioTrack

E/SurfaceTexture( 1120): [PopupWindow:412a7fe8] queueBuffer: slot 0 is current!

E/SurfaceTextureClient( 2040): queueBuffer: error queuing buffer to SurfaceTexture, -22

E/SurfaceTextureClient( 2040): queueBuffer (handle=0x6f8280) failed (Invalid argument)

D/AndroidRuntime( 2040): Shutting down VM

Cheers

Cass

Edited December 21, 2011 by Cass67

[Guest ejtagle]

Compiles but still a bit crashy, this ones on sleep, the IOCTL FLIP is new for me ...

D/Lights ( 153): set_light_backlight: 95

D/Lights ( 153): set_light_backlight: 88

D/Lights ( 153): set_light_backlight: 81

D/Lights ( 153): set_light_backlight: 74

D/Lights ( 153): set_light_backlight: 67

D/Lights ( 153): set_light_backlight: 61

D/Lights ( 153): set_light_backlight: 54

D/Lights ( 153): set_light_backlight: 47

D/Lights ( 153): set_light_backlight: 40

D/Lights ( 153): set_light_backlight: 33

D/Lights ( 153): set_light_backlight: 27

D/Lights ( 153): set_light_backlight: 20

D/Lights ( 153): set_light_backlight: 13

D/Lights ( 153): set_light_backlight: 6

D/Lights ( 153): set_light_backlight: 0

I/power ( 153): *** set_screen_state 0

D/SurfaceFlinger( 96): About to give-up screen, flinger = 0xf918

E/gralloc ( 96): NvGrPost: Failed, TEGRA_OVERLAY_IOCTL_FLIP Broken pipe

V/TransportControlView( 153): Create TCV com.android.internal.widget.TransportControlView@414c1970

D/dalvikvm( 153): GC_FOR_ALLOC freed 504K, 16% free 9688K/11527K, paused 34ms

D/dalvikvm( 153): GC_FOR_ALLOC freed 279K, 16% free 9718K/11527K, paused 32ms

D/dalvikvm( 153): GC_FOR_ALLOC freed 435K, 15% free 9835K/11527K, paused 32ms

D/dalvikvm( 153): GC_FOR_ALLOC freed 185K, 13% free 10063K/11527K, paused 32ms

E/SurfaceTexture( 96): [statusBar] queueBuffer: slot 0 is current!

E/SurfaceTextureClient( 240): queueBuffer: error queuing buffer to SurfaceTexture, -22

E/SurfaceTextureClient( 240): queueBuffer (handle=0x18c700) failed (Invalid argument)

D/AndroidRuntime( 240): Shutting down VM

W/dalvikvm( 240): threadid=1: thread exiting with uncaught exception (group=0x40a241f8)

I/Process ( 240): Sending signal. PID: 240 SIG: 9

E/AndroidRuntime( 240): FATAL EXCEPTION: main

E/AndroidRuntime( 240): java.lang.IllegalArgumentException

E/AndroidRuntime( 240): at android.view.Surface.unlockCanvasAndPost(Native Method)

E/AndroidRuntime( 240): at android.view.ViewRootImpl.draw(ViewRootImpl.java:2044)

E/AndroidRuntime( 240): at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1634)

E/AndroidRuntime( 240): at android.view.ViewRootImpl.handleMessage(ViewRootImpl.java:2442)

E/AndroidRuntime( 240): at android.os.Handler.dispatchMessage(Handler.java:99)

E/AndroidRuntime( 240): at android.os.Looper.loop(Looper.java:137)

E/AndroidRuntime( 240): at android.app.ActivityThread.main(ActivityThread.java:4424)

E/AndroidRuntime( 240): at java.lang.reflect.Method.invokeNative(Native Method)

E/AndroidRuntime( 240): at java.lang.reflect.Method.invoke(Method.java:511)

E/AndroidRuntime( 240): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)

E/AndroidRuntime( 240): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)

E/AndroidRuntime( 240): at dalvik.system.NativeStart.main(Native Method)

I/WindowManager( 153): WIN DEATH: Window{41344500 InputMethodsPanel paused=false}

I/ActivityManager( 153): Process com.android.systemui (pid 240) has died.

Got a crash on market too but the error was same as previous one i posted, surface etc ...

edit :- interestingly rolling back to our .36 exhibits the same behaviour ..

E/SurfaceTexture( 1120): [PopupWindow:412a7fe8] queueBuffer: slot 1 is current!

E/SurfaceTextureClient( 2040): queueBuffer: error queuing buffer to SurfaceTexture, -22

W/nvwsi ( 2040): queueBuffer failed, error -22

W/HardwareRenderer( 2040): EGL error: EGL_BAD_CURRENT_SURFACE

W/HardwareRenderer( 2040): Mountain View, we've had a problem here. Switching back to software rendering.

E/SoundPool( 1143): Error creating AudioTrack

E/SurfaceTexture( 1120): [PopupWindow:412a7fe8] queueBuffer: slot 0 is current!

E/SurfaceTextureClient( 2040): queueBuffer: error queuing buffer to SurfaceTexture, -22

E/SurfaceTextureClient( 2040): queueBuffer (handle=0x6f8280) failed (Invalid argument)

D/AndroidRuntime( 2040): Shutting down VM

Cheers

Cass

I can't believe what i am going to say, but this seems to be a genuine Android framework bug ... The problematic code lies in base/libs/ui/SurfaceTexture.cpp

The dequeueBuffer method explicitly says that when a buffer is dequeued, it can also be the current buffer. Once this buffer is queued again in the queueBuffer method, there is a check that verifies that the to be queued surface is NOT the current one... And if it is, it fails the function. Failing that function finally leads to reverting to a software renderer ... Perhaps commenting out that verification could be enough ? -- I have to thing a little more about this... I am missing something here?

Regards

Eduardo

[Guest ejtagle]

I can't believe what i am going to say, but this seems to be a genuine Android framework bug ... The problematic code lies in base/libs/ui/SurfaceTexture.cpp

The dequeueBuffer method explicitly says that when a buffer is dequeued, it can also be the current buffer. Once this buffer is queued again in the queueBuffer method, there is a check that verifies that the to be queued surface is NOT the current one... And if it is, it fails the function. Failing that function finally leads to reverting to a software renderer ... Perhaps commenting out that verification could be enough ? -- I have to thing a little more about this... I am missing something here?

Regards

Eduardo

I will do the porting of the 2.6.39 moto video subsystem to ours, in the hope that it will fix this.. Really hope so, as there's not much more to do about that... Do the other tegra2 ports have the same issues ? :S - Are they using the google tegra2 supplied hw acceleration libraries ? ...

[Guest brucelee666]

I can't believe what i am going to say, but this seems to be a genuine Android framework bug ... The problematic code lies in base/libs/ui/SurfaceTexture.cpp

The dequeueBuffer method explicitly says that when a buffer is dequeued, it can also be the current buffer. Once this buffer is queued again in the queueBuffer method, there is a check that verifies that the to be queued surface is NOT the current one... And if it is, it fails the function. Failing that function finally leads to reverting to a software renderer ... Perhaps commenting out that verification could be enough ? -- I have to thing a little more about this... I am missing something here?

Regards

Eduardo

Looking at "frameworks/base/libs/gui" this was added to the android.mk file, not previously in 4.0.1:-

"ifeq ($(TARGET_BOARD_PLATFORM), tegra) LOCAL_CFLAGS += -DALLOW_DEQUEUE_CURRENT_BUFFERendif"

And this was added to the surfacetexture.cpp file:-

"#ifdef ALLOW_DEQUEUE_CURRENT_BUFFER

#define FLAG_ALLOW_DEQUEUE_CURRENT_BUFFER true

#warning "ALLOW_DEQUEUE_CURRENT_BUFFER enabled"

#else

#define FLAG_ALLOW_DEQUEUE_CURRENT_BUFFER false

#endif"

Was previoulsy only set to:-

"#define ALLOW_DEQUEUE_CURRENT_BUFFER false"

You guys know more than me on this but could something not be getting set on build due to "TARGET_BOARD_PLATFORM" or "tegra" flags shown above in android.mk file not being the expected values as you have used different flags to build the source ? (hope that makes sense)

[Guest Cass67]

Looking at "frameworks/base/libs/gui" this was added to the android.mk file, not previously in 4.0.1:-

"ifeq ($(TARGET_BOARD_PLATFORM), tegra) LOCAL_CFLAGS += -DALLOW_DEQUEUE_CURRENT_BUFFERendif"

And this was added to the surfacetexture.cpp file:-

"#ifdef ALLOW_DEQUEUE_CURRENT_BUFFER

#define FLAG_ALLOW_DEQUEUE_CURRENT_BUFFER true

#warning "ALLOW_DEQUEUE_CURRENT_BUFFER enabled"

#else

#define FLAG_ALLOW_DEQUEUE_CURRENT_BUFFER false

#endif"

Was previoulsy only set to:-

"#define ALLOW_DEQUEUE_CURRENT_BUFFER false"

You guys know more than me on this but could something not be getting set on build due to "TARGET_BOARD_PLATFORM" or "tegra" flags shown above in android.mk file not being the expected values as you have used different flags to build the source ? (hope that makes sense)

Thanks for confirming that, I changed it to exaclty that this morning and compiled but not tested yet .. ill update here with results when I get the chance..

Cheers

Cass

[Guest ejtagle]

Well, i've been reading that piece of code... Seems that they are accessing a given opengl texture associated memory buffer from multiple processes at the same time. The only problem with that is that is that OpenGLES does not allow to unbind a memory buffer that is binded to a texture if the buffer or the texture is being read or written and that operation has not completed yet.

If that happens, then OpenGLES returns an error, and the Android framework starts using software layer composition instead of hardware composition. Software composition is much slower than hw composition.

That is exaclly what is happening right now. The message "queueBuffer: slot 0 is current!" ge

The framework implements 3 ways to avoid this problem, the first one makes sure never to return a buffer that is binded to a texture when the user dequeues a buffer. The buffer will be binded to the texture when the user has finished using the buffer and queues it again . That behaviour is selected when ALLOW_DEQUEUE_CURRENT_BUFFER is NOT defined .

The 2nd mode is to use a OpenGLES extension that waits until all pending operations complete before unbinding a memory buffer from the texture. That behaviour is selected when USE_FENCE_SYNC is defined.

And the 3rd method is to trust the OpenGLES to wait by itself for all the operations to complete before unbinding a memory buffer from its texture. That behaviour is selected when neither ALLOW_DEQUEUE_CURRENT_BUFFER nor USE_FENCE_SYNC are defined.

The Nvidia OpenGLES supports all those methods, but, i don't know if it has some kind of bug ... So, we will have to try all the 3 methods to find the one that works for us.

Attached the Android.mk file found in frameworks/base/libs/gui At with some modifications to test the USE_FENCE_SYNC ...

Regarding kernel, until now, every effort to make the 2.6.39-motorolaxoom kernel boot in the Shuttle has failed :S -- And if you are curious about HC versus ICS, well, ICS implements some workarounds that i hope are not interferring with our OpenGLES driver...

Regards,

Eduardo...

Android.rar

Edited December 23, 2011 by ejtagle

[Guest Cass67]

Well, i've been reading that piece of code... Seems that they are accessing a given opengl texture associated memory buffer from multiple processes at the same time. The only problem with that is that is that OpenGLES does not allow to unbind a memory buffer that is binded to a texture if the buffer or the texture is being read or written and that operation has not completed yet.

If that happens, then OpenGLES returns an error, and the Android framework starts using software layer composition instead of hardware composition. Software composition is much slower than hw composition.

That is exaclly what is happening right now. The message "queueBuffer: slot 0 is current!" ge

The framework implements 3 ways to avoid this problem, the first one makes sure never to return a buffer that is binded to a texture when the user dequeues a buffer. The buffer will be binded to the texture when the user has finished using the buffer and queues it again . That behaviour is selected when ALLOW_DEQUEUE_CURRENT_BUFFER is NOT defined .

The 2nd mode is to use a OpenGLES extension that waits until all pending operations complete before unbinding a memory buffer from the texture. That behaviour is selected when USE_FENCE_SYNC is defined.

And the 3rd method is to trust the OpenGLES to wait by itself for all the operations to complete before unbinding a memory buffer from its texture. That behaviour is selected when neither ALLOW_DEQUEUE_CURRENT_BUFFER nor USE_FENCE_SYNC are defined.

The Nvidia OpenGLES supports all those methods, but, i don't know if it has some kind of bug ... So, we will have to try all the 3 methods to find the one that works for us.

Attached the Android.mk file found in frameworks/base/libs/gui At with some modifications to test the USE_FENCE_SYNC ...

Regarding kernel, until now, every effort to make the 2.6.39-motorolaxoom kernel boot in the Shuttle has failed :S -- And if you are curious about HC versus ICS, well, ICS implements some workarounds that i hope are not interferring with our OpenGLES driver...

Regards,

Eduardo...

Good news, flashed yesterdays compile with ALLOW_DEQUEUE_CURRENT_BUFFER=false in place and ive been unable to make it crash again, even returning from sleep.. so seems like on first attempt we hit gold, so nice work there Eduardo looking that one out :)

Seems now all that really is breaking stuff is audio not being in place, dont think we are in bad shape at all .... camera and audio .. cant think of anything else right now ...

Ohh on another note, i disabled dynamic gpu mem allocation as it seems not to be working as id expect, was getting out of memory issues on the youtube app the other day ... changed it to have a static 128mb and ive not seen the errors again ... i may put this back in place now that GL is not giving us static to see what occurs ...

Cheers

Cass

[Guest misterjoji]

sorry but any hope for the gps to be working?