Advent Vega kernel source code now available!

[Guest ejtagle]

I have e153. I seem to remember Cass had a similar problem. He had a e220 i think. If you need more info, or you need me to send an AT string to the modem, let me know.

I also have an e169 on the p10an10. Unfortunately, Huawei seems to like changing the meaning and implementation of some specific AT commands related to GPRS. Most of them work on all huawei models, but there are a few that do not. I am specifically referring to 2 of them: The one used to detect if a sim card is present , and the one used to enable 3G ... Both are very critical for a successful data connection. For example, the e169 does not accept the AT^RFSWITCH command, that EM770W requires to enable 3G... Probably, there is an equivalent command ... Unfortunately, i have no source code for the huawei supplied ril, and decompiling it is hard (i am using IDA pro): It is unable to resolve strings... Otherwise, it would be relatively easy to check what AT commands and when to send them.

If you look at the radio log, you will notice the "card not present" java exception... I think that fixing the card detection routine to fall back to other commands if the RFSWITCH / card detect command fails, and fixing the 3G enable routine to also fall back to an older command sequence if the used commands fails should be enough to make the RIL work for those older models...

(if you want to check for unsupported commands, look for the ERROR response to the AT commands sent...

[Guest the_corvus]

I also have an e169 on the p10an10. Unfortunately, Huawei seems to like changing the meaning and implementation of some specific AT commands related to GPRS. Most of them work on all huawei models, but there are a few that do not. I am specifically referring to 2 of them: The one used to detect if a sim card is present , and the one used to enable 3G ... Both are very critical for a successful data connection. For example, the e169 does not accept the AT^RFSWITCH command, that EM770W requires to enable 3G... Probably, there is an equivalent command ... Unfortunately, i have no source code for the huawei supplied ril, and decompiling it is hard (i am using IDA pro): It is unable to resolve strings... Otherwise, it would be relatively easy to check what AT commands and when to send them.

If you look at the radio log, you will notice the "card not present" java exception... I think that fixing the card detection routine to fall back to other commands if the RFSWITCH / card detect command fails, and fixing the 3G enable routine to also fall back to an older command sequence if the used commands fails should be enough to make the RIL work for those older models...

(if you want to check for unsupported commands, look for the ERROR response to the AT commands sent...

I'm not sure, but the at command needed was AT +CFUN=1

Corvus.

PS: https://github.com/rbraken/wetab-ICS-device-tree/blob/master/huawei-generic/huaweigeneric-ril.c line 1061

[Guest plastikman187]

for linking cache we are doing this in init.rc

# creates Cache on Internal SD

    mkdir /data/cache 0771 system system

    chown system system /data/cache

    chmod 0771 /data/cache


    mkdir /data/cache/dalvik-cache 0771 system system

    chown system system /data/cache/dalvik-cache

    chmod 0771 /data/cache/dalvik-cache

    symlink /data/cache/dalvik-cache /cache/dalvik-cache

    chown system system /cache/dalvik-cache

    chmod 0771 /cache/dalvik-cache


# Gives proper permissions to the symlink for cache

    chown system cache /cache

    chmod 0551 /cache

We have lots of people with bad blocks so some times 10MB might be a little tight I am running at 350MB /system with no issues.

[Guest ejtagle]

I'm not sure, but the at command needed was AT +CFUN=1

Corvus.

PS: https://github.com/r...eigeneric-ril.c line 1061

Yes, i remember that ;) .. The problem here is that EM770W needs CFUN=1, but e168/e220/e170 seems to require a different value... I have the at command manuals for one of those modems (can't recall the exact model, I am not at my development machine right now) and, if you compare it against the EM770W manual, there is difference in the meaning of the CFUN values... Right now, as it is, the ril works beautifully with EM770W , including 3G ;)

[Guest kipper641]

Any use ?

3.20.2 Description

This command switches the on-off of radio by software and writes the corresponding value to NV .

The function of querying includes the state of W_DISABLE# pi n (GPIO#30). The W_DISABLE# pi n

decides the on-off of radio section’s hardware.The TE may decide if prompt the Msg1 by the return

value of the command. The ^RFSWITCH command equals the combinati on function of +CFUN(7+1)

and writes the corresponding value to NV .

AT^RFSWITCH=0 equal s AT+CFUN=7 and writes NV.

AT^RFSWITCH=1 equal s AT+CFUN=1 and writes NV.

Keith

[Guest ejtagle]

Any use ?

3.20.2 Description

This command switches the on-off of radio by software and writes the corresponding value to NV .

The function of querying includes the state of W_DISABLE# pi n (GPIO#30). The W_DISABLE# pi n

decides the on-off of radio section’s hardware.The TE may decide if prompt the Msg1 by the return

value of the command. The ^RFSWITCH command equals the combinati on function of +CFUN(7+1)

and writes the corresponding value to NV .

AT^RFSWITCH=0 equal s AT+CFUN=7 and writes NV.

AT^RFSWITCH=1 equal s AT+CFUN=1 and writes NV.

Keith

Exactly, and I can tell you that for Huawei EM770W , the RFSWITCH is required, rather than optional. Without it, the module refuses to log into the cell network. So we are already using it. But, for the Huawei E169 / E220 and many others, the command is not implemented at all in the 3g modem firmware.

As our current implementation of the RIL is depending on this (RFSWITCH) command to be properly handled by the 3g module, that is the cause of the other modules/3g dongles that are not the EM770W one that refuse to work.

My idea is to detect the RFSWITCH command failure, and fall back to the AT+CFUN=0 or AT+CFUN=1 to get the same result, but on previous Huawei modules/firmwares. If anyone has more info on those modules (E169/E220/Exxx) on the right way to enable/disable radio , let us know. I think the CFUN command is the way to go. I will try it and let everyone know if it worked.

The problem is that we are trying to write a generic Huawei RIL that works not only with the internal EM770W, but also with external 3G Huawei dongles ... :o

Edited August 7, 2012 by ejtagle

[Guest ejtagle]

The following attached ril implements the workarounds mentioned above. Seems it goes further in the initialization process, but, at least on my device (huawei e169), i sometimes have random ttyUSB crashes... Means the modem stops responding. I think the problem is not in the RIL itself, rather than, in the linux kernel.

Lately , i have read that we need, instead of enabling,the USB generic serial driver, we need to disable it and enable the USB driver for GSM and CDMA devices. I ran out of time, but, just in case, i am posting the RIL... Maybe it is working for the Exxx huawei modems...

huawei-generic-7aug.rar

[Guest Oldbarzo]

Hi

Already posted on Tabletroms, but just for info. 3G intermittent signal, seems to be OK near transmission

masts but get no signal further afield although the status icon always shows 2 bars. Also unable to enable

GPS, cannot get a fix. Built_in module supplied by DivXDemon. 3G gave full BRS on status in RC2 and worked

everywhere.

Stransky

[Guest plastikman187]

Turns out that the cause of the kernel not being able to suspend, is a wakelock.. To find exactly what wakelock is the culprit, you can do:

echo 15 > /sys/module/wakelock/parameters/debug_mask

And, when trying to suspend, the kernel will print out the problematic wakelock ...

I am at it right now

Update: The wakelock called "event3-143" is the one preventing the kernel to enter suspend ... Tracing what kernel component is using it...

Update2: Found the culprit. It is a "race" condition between the suspend process and the accelerometer driver... Everytime the accelerometer driver sends an event, a wakelock is locked with timeout of 5 seconds (this happens in /drivers/input/evdev.c) ... So, as the accelerometer is posting 25 events per second, then, we can assume this wakelock called "event3-143" is being held all the time... effectively preventing the kernel to enter suspend mode. Even, if the accelerometer is disabled at suspend time (as it is right now), there is still 5 seconds remaining of locked wakelock. So, the suspend fails. As soon as the kernel fails to suspend, the accelerometer is reenabled and relocks the wakelock...

I will have to patch evdev.c, as with some input devices, it makes no sense to hold a wakelock for such a huge amount of time... This is probably a bug of the android kernel itself, but it does not show in any HC3.x as there, the used accelerometers are being exposed as files, and not as input devices, as it should be... Now, i have to figure out a way to fix this...

hello ejtagle,

i know that this is an old post but i am having a similar issue with AOSP JB and the wake lock is coming form system_server but i cant figure out what component it causing the issue. how did you determine that it was an issue in evdev.c in this particular issue?

<6>[  191.571300] expire_wake_locks: start

<6>[  191.571692] wake lock wlan_ctrl_wake, expired

<6>[  191.572320] expired wake lock wlan_ctrl_wake

<6>[  191.572682] expire_wake_locks: done, has_lock 0

<6>[  191.617966] suspend: enter suspend

<6>[  191.618613] PM: Syncing filesystems ... done.

<6>[  191.634464] Tegra cpufreq suspend: setting frequency to 216000 kHz

<4>[  191.646783] Freezing user space processes ... (elapsed 0.03 seconds) done.

<4>[  191.678110] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.

<4>[  191.698346] Suspending console(s) (use no_console_suspend to debug)

<6>[  191.710595] Wake24 for irq=362

<6>[  191.710650] Enabling wake24

<6>[  191.717654] tegradc tegradc.1: suspend

<6>[  191.717783] tegradc tegradc.0: suspend

<6>[  191.717887] tegra_avp_suspend()+

<4>[  191.718040] tegra_pwm tegra_pwm.0: pwm_disable called on disabled PWM

<6>[  191.718152] tegra_grhost tegra_grhost: suspending

<6>[  191.719195] tegra_grhost tegra_grhost: suspend status: 0

<6>[  191.877603] PM: suspend of devices complete after 176.510 msecs

<6>[  191.879229] power_suspend_late return 0

<6>[  191.879342] PM: late suspend of devices complete after 1.621 msecs

<4>[  191.879415] Disabling non-boot CPUs ...

<5>[  192.008128] CPU1: shutdown

<7>[  192.010530] vfp_pm_suspend: saving vfp state

<6>[  192.030110] Wake[31-0] level=0x800210

<6>[  192.030178] Wake[31-0] enable=0x1800080

<6>[  192.030243] Entering suspend state LP1

<4>[  192.030307] partition ve is left on before suspend

<4>[  192.030307] partition vde is left on before suspend

<6>[  192.030474] Exited suspend state LP1

<6>[  192.030542]  legacy wake status=0x0

<6>[  192.053725] Suspended for 0.068 seconds

<6>[  192.053925] Enabling non-boot CPUs ...

<4>[  192.082324] CPU1: Booted secondary processor

<6>[  192.088857] Switched to NOHz mode on CPU #1

<6>[  192.251776] CPU1 is up

<6>[  192.256918] PM: early resume of devices complete after 5.020 msecs

<6>[  192.280770] tegra_grhost tegra_grhost: resuming

<4>[  192.280911] tegra_pwm tegra_pwm.0: pwm_disable called on disabled PWM

<6>[  192.280987] tegra_avp_resume()+

<6>[  192.281061] tegradc tegradc.0: resume

<6>[  192.281131] tegradc tegradc.1: resume

<3>[  192.281554] tegra-snd-alc5623 tegra-snd-alc5623.0: resume work item may be lost

<6>[  192.281713] Wake24 for irq=362

<6>[  192.281765] Disabling wake24

<6>[  192.281855] wakeup wake lock: event1-266

<6>[  192.281951] wake_lock: event1-266, start expire timer, 500

<6>[  192.282066] wake_lock: event1-266, start expire timer, 500

<6>[  192.321136] wake_lock: event1-266, start expire timer, 500

<6>[  192.321284] wake_lock: event1-266, start expire timer, 500

<6>[  192.321450] wake_lock: event2-266, start expire timer, 500

<6>[  192.381370] PM: resume of devices complete after 123.666 msecs

<4>[  192.523187] Restarting tasks ... done.

<6>[  192.540457] Tegra cpufreq resume: restoring frequency to 216000 kHz

<6>[  192.543920] wake_lock: KeyEvents, stop expire timer

<6>[  192.552366] wake_unlock: KeyEvents, start expire timer, 477

<6>[  192.553483] wake_lock: KeyEvents, stop expire timer

<6>[  192.554651] suspend: exit suspend, ret = 0 (2012-08-07 15:18:21.731934999 UTC)

<6>[  192.557240] request_suspend_state: wakeup (3->0) at 192500293002 (2012-08-07 15:18:21.734483999 UTC)

<4>[  192.647574] tegra_pwm tegra_pwm.0: pwm_disable called on disabled PWM

<4>[  192.737480] tegra_dock_late_resume

this same kernel works in ICS so it seems like it is not kernel related but possibly android related is this the culprit?

<6>[  192.543920] wake_lock: KeyEvents, stop expire timer

<6>[  192.552366] wake_unlock: KeyEvents, start expire timer, 477

<6>[  192.553483] wake_lock: KeyEvents, stop expire timer

<6>[  192.554651] suspend: exit suspend, ret = 0 (2012-08-07 15:18:21.731934999 UTC)

-plastikman

[Guest ejtagle]

hello ejtagle,

i know that this is an old post but i am having a similar issue with AOSP JB and the wake lock is coming form system_server but i cant figure out what component it causing the issue. how did you determine that it was an issue in evdev.c in this particular issue?

<6>[  191.571300] expire_wake_locks: start

<6>[  191.571692] wake lock wlan_ctrl_wake, expired

<6>[  191.572320] expired wake lock wlan_ctrl_wake

<6>[  191.572682] expire_wake_locks: done, has_lock 0

<6>[  191.617966] suspend: enter suspend

<6>[  191.618613] PM: Syncing filesystems ... done.

<6>[  191.634464] Tegra cpufreq suspend: setting frequency to 216000 kHz

<4>[  191.646783] Freezing user space processes ... (elapsed 0.03 seconds) done.

<4>[  191.678110] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.

<4>[  191.698346] Suspending console(s) (use no_console_suspend to debug)

<6>[  191.710595] Wake24 for irq=362

<6>[  191.710650] Enabling wake24

<6>[  191.717654] tegradc tegradc.1: suspend

<6>[  191.717783] tegradc tegradc.0: suspend

<6>[  191.717887] tegra_avp_suspend()+

<4>[  191.718040] tegra_pwm tegra_pwm.0: pwm_disable called on disabled PWM

<6>[  191.718152] tegra_grhost tegra_grhost: suspending

<6>[  191.719195] tegra_grhost tegra_grhost: suspend status: 0

<6>[  191.877603] PM: suspend of devices complete after 176.510 msecs

<6>[  191.879229] power_suspend_late return 0

<6>[  191.879342] PM: late suspend of devices complete after 1.621 msecs

<4>[  191.879415] Disabling non-boot CPUs ...

<5>[  192.008128] CPU1: shutdown

<7>[  192.010530] vfp_pm_suspend: saving vfp state

<6>[  192.030110] Wake[31-0] level=0x800210

<6>[  192.030178] Wake[31-0] enable=0x1800080

<6>[  192.030243] Entering suspend state LP1

<4>[  192.030307] partition ve is left on before suspend

<4>[  192.030307] partition vde is left on before suspend

<6>[  192.030474] Exited suspend state LP1

<6>[  192.030542]  legacy wake status=0x0

<6>[  192.053725] Suspended for 0.068 seconds

<6>[  192.053925] Enabling non-boot CPUs ...

<4>[  192.082324] CPU1: Booted secondary processor

<6>[  192.088857] Switched to NOHz mode on CPU #1

<6>[  192.251776] CPU1 is up

<6>[  192.256918] PM: early resume of devices complete after 5.020 msecs

<6>[  192.280770] tegra_grhost tegra_grhost: resuming

<4>[  192.280911] tegra_pwm tegra_pwm.0: pwm_disable called on disabled PWM

<6>[  192.280987] tegra_avp_resume()+

<6>[  192.281061] tegradc tegradc.0: resume

<6>[  192.281131] tegradc tegradc.1: resume

<3>[  192.281554] tegra-snd-alc5623 tegra-snd-alc5623.0: resume work item may be lost

<6>[  192.281713] Wake24 for irq=362

<6>[  192.281765] Disabling wake24

<6>[  192.281855] wakeup wake lock: event1-266

<6>[  192.281951] wake_lock: event1-266, start expire timer, 500

<6>[  192.282066] wake_lock: event1-266, start expire timer, 500

<6>[  192.321136] wake_lock: event1-266, start expire timer, 500

<6>[  192.321284] wake_lock: event1-266, start expire timer, 500

<6>[  192.321450] wake_lock: event2-266, start expire timer, 500

<6>[  192.381370] PM: resume of devices complete after 123.666 msecs

<4>[  192.523187] Restarting tasks ... done.

<6>[  192.540457] Tegra cpufreq resume: restoring frequency to 216000 kHz

<6>[  192.543920] wake_lock: KeyEvents, stop expire timer

<6>[  192.552366] wake_unlock: KeyEvents, start expire timer, 477

<6>[  192.553483] wake_lock: KeyEvents, stop expire timer

<6>[  192.554651] suspend: exit suspend, ret = 0 (2012-08-07 15:18:21.731934999 UTC)

<6>[  192.557240] request_suspend_state: wakeup (3->0) at 192500293002 (2012-08-07 15:18:21.734483999 UTC)

<4>[  192.647574] tegra_pwm tegra_pwm.0: pwm_disable called on disabled PWM

<4>[  192.737480] tegra_dock_late_resume

this same kernel works in ICS so it seems like it is not kernel related but possibly android related is this the culprit?

<6>[  192.543920] wake_lock: KeyEvents, stop expire timer

<6>[  192.552366] wake_unlock: KeyEvents, start expire timer, 477

<6>[  192.553483] wake_lock: KeyEvents, stop expire timer

<6>[  192.554651] suspend: exit suspend, ret = 0 (2012-08-07 15:18:21.731934999 UTC)

-plastikman

There is no wakelock preventing your device to enter LP1. In fact, it enters LP1.. But sleeps for less than 100ms. Something is waking up afterwards. Probably a hw interrupt... ...

[Guest plastikman187]

There is no wakelock preventing your device to enter LP1. In fact, it enters LP1.. But sleeps for less than 100ms. Something is waking up afterwards. Probably a hw interrupt... ...

The same kernel enters and stays in LP1 in ICS just fine. it seems like a JB issue to me. Do you have any insight that can help me to debug the issue?

Edited August 7, 2012 by plastikman187

[Guest ejtagle]

The same kernel enters and stays in LP1 in ICS just fine. it seems like a JB issue to me. Do you have any insight that can help me to debug the issue?

Could be a JB application... But i suspect it is not

http://stackoverflow.com/questions/5780280/how-can-i-see-which-wakelocks-are-active

You can always add to the kernel command line the following and check for yourself:

ignore_loglevel earlyprintk initcall_debug

[Guest fosser2]

ejtagle,

I'm trying to figure out where most of the power button function takes place in your 3.1 kernel. In our .39 kernel we had a hacked function in tps6586x that allowed function of the android power menu. Right now on 3.1 when we push power button, the tablet just shuts off. Obviously this is not good for the tablet. In 3.1 is there a better way to implament the proper function of the power button gpio or should we just use the hacked code from .36/.39? Our old code can be found here.

https://github.com/T...smba1002-wake.c

Thanks

Edited August 8, 2012 by fosser2

[Guest Scanno]

@Eduardo,

Here is a logcat from stransky regarding HDMI audio

http://db.tt/EF96iBDF

[Guest ejtagle]

ejtagle,

I'm trying to figure out where most of the power button function takes place in your 3.1 kernel. In our .39 kernel we had a hacked function in tps6586x that allowed function of the android power menu. Right now on 3.1 when we push power button, the tablet just shuts off. Obviously this is not good for the tablet. In 3.1 is there a better way to implament the proper function of the power button gpio or should we just use the hacked code from .36/.39? Our old code can be found here.

https://github.com/T...smba1002-wake.c

Thanks

On shuttle, the way (hardware implemented) power button works is the following: A short press just sets the associated GPIO to 0. The gpio_keys driver gets that event and sends the keycode to the linux input layer. And then, Android reads it and processes it.

If you keep it pressed for a long time, the tablet just shuts down. But, that behaviour is implemented in hw, and not in the linux kernel. In fact, i do suspect that behaviour is implemented in a complementary microcontroller called NVEC... That, among other things, does the power management of the system.

Maybe you are missing sending a command to the NVEC that tells it to cancel the processing of the button ? ... I find quite strange that you explicitly need to cancel sleep mode in the tps6586x...

[Guest ejtagle]

@Eduardo,

Here is a logcat from stransky regarding HDMI audio

http://db.tt/EF96iBDF

The problem with hdmi audio is that we are missing an entry in the audio_policy.xml file for it. As the entry is missing, audio is never routed to hdmi. Attached an audio_policy.xml file that should work ;)

Look at this section of the log:

08-08 20:17:58.600 V/WiredAccessoryObserver( 285): Headset UEVENT: {SUBSYSTEM=switch, SWITCH_STATE=1, DEVPATH=/devices/virtual/switch/hdmi, SEQNUM=1149, ACTION=change, SWITCH_NAME=hdmi}

08-08 20:17:58.600 V/WiredAccessoryObserver( 285): newState = 16, headsetState = 16,mHeadsetState = 0

08-08 20:17:58.600 V/WiredAccessoryObserver( 285): device hdmi connected

08-08 20:17:58.780 W/AudioWatchdog( 110): Insufficient CPU for load: expected=50.0 actual=142.7 ms; underruns=1 logs=1

08-08 20:17:58.810 D/dalvikvm( 285): GC_EXPLICIT freed 105K, 17% free 11137K/13319K, paused 15ms+5ms, total 268ms

08-08 20:17:58.820 W/AudioPolicyManagerBase( 110): checkOutputsForDevice(): No output available for device 0400

First line tells that the hdmi output is engaged and working... BUT, no call to audio_hw.c is made to actually switch audio... And the cause is the last line: AudioPolicyManager says there is no output device for hdmi audio... A quick check on audio_policy.xml tells that we are missing that section :) . I compared the tuna audio_policy.xml to the one we are using, and tuna has it, so i added it. I think that now with that new audio_policy.xml, there will be a declared hdmi audio output and Android will use it :)

audio_policy.rar

[Guest fosser2]

Maybe you are missing sending a command to the NVEC that tells it to cancel the processing of the button ? ... I find quite strange that you explicitly need to cancel sleep mode in the tps6586x...

We don't have the NVEC controller on our tablet. This is what's making the implamentation harder...

[Guest ejtagle]

We don't have the NVEC controller on our tablet. This is what's making the implamentation harder...

Is there any extra controller in your tablet ? ... I have already reverse engineered the shmcu used in p10an10 by Shuttle... ;) ...

[Guest fosser2]

Is there any extra controller in your tablet ? ... I have already reverse engineered the shmcu used in p10an10 by Shuttle... ;) ...

As far as I know TPS6586X handles all of our power code including the shutdown.

[Guest Scanno]

The problem with hdmi audio is that we are missing an entry in the audio_policy.xml file for it. As the entry is missing, audio is never routed to hdmi. Attached an audio_policy.xml file that should work ;)

Look at this section of the log:

08-08 20:17:58.600 V/WiredAccessoryObserver( 285): Headset UEVENT: {SUBSYSTEM=switch, SWITCH_STATE=1, DEVPATH=/devices/virtual/switch/hdmi, SEQNUM=1149, ACTION=change, SWITCH_NAME=hdmi}

08-08 20:17:58.600 V/WiredAccessoryObserver( 285): newState = 16, headsetState = 16,mHeadsetState = 0

08-08 20:17:58.600 V/WiredAccessoryObserver( 285): device hdmi connected

08-08 20:17:58.780 W/AudioWatchdog( 110): Insufficient CPU for load: expected=50.0 actual=142.7 ms; underruns=1 logs=1

08-08 20:17:58.810 D/dalvikvm( 285): GC_EXPLICIT freed 105K, 17% free 11137K/13319K, paused 15ms+5ms, total 268ms

08-08 20:17:58.820 W/AudioPolicyManagerBase( 110): checkOutputsForDevice(): No output available for device 0400

First line tells that the hdmi output is engaged and working... BUT, no call to audio_hw.c is made to actually switch audio... And the cause is the last line: AudioPolicyManager says there is no output device for hdmi audio... A quick check on audio_policy.xml tells that we are missing that section :) . I compared the tuna audio_policy.xml to the one we are using, and tuna has it, so i added it. I think that now with that new audio_policy.xml, there will be a declared hdmi audio output and Android will use it :)

Eduardo,

Finally was able to make a build with the changed audio policy.... The audio system gets instable and crashes.

See attached logs.

dmesg0814.txt

logcat0814.txt

[Guest ejtagle]

Eduardo,

Finally was able to make a build with the changed audio policy.... The audio system gets instable and crashes.

See attached logs.

Well, something still missing... Believe it or not, the crashes are caused by the audio_policy.xml file... A null pointer exception.. Will check it a bit later..

edit1: Try the attached one... ;) .. I removed some devices the audio_hw.c we are using does not support. Save yourself recompiling the rom. Just push it to /system/etc and reboot :)

.

audio_policy.rar

Edited August 15, 2012 by ejtagle

[Guest plastikman187]

Do you guys get GFX corruption in JB? Our lock screen gets corrupt, and some times the graphics just completely freak out. http://i.imgur.com/HHRsv.jpg

Edited August 16, 2012 by plastikman187

[Guest MikhailM]

Do you guys get GFX corruption in JB? Our lock screen gets corrupt, and some times the graphics just completely freak out. http://i.imgur.com/HHRsv.jpg

No, lock screen is stable in Vegabean Beta 1. Earlier on Scanno had problems with the image shifting down in portrait orientation, but this has been sorted out now.

[Guest plastikman187]

No, lock screen is stable in Vegabean Beta 1. Earlier on Scanno had problems with the image shifting down in portrait orientation, but this has been sorted out now.

Thanks!

[Guest Scanno]

Well, something still missing... Believe it or not, the crashes are caused by the audio_policy.xml file... A null pointer exception.. Will check it a bit later..

edit1: Try the attached one... ;) .. I removed some devices the audio_hw.c we are using does not support. Save yourself recompiling the rom. Just push it to /system/etc and reboot :)

.

Sadly still the same problem

logcat0816.txt