I think that is related to 3D device - I can reproduce (bug #28 this reliably in Opera Mobile, but that's a complete lockup - the kernel no longer reacts to anything/prints anything. I will try to merge drivers from X10 instead of froyo ones, but I am afraid I am running out of time.
MMC card interface bug (#29), not yet sure where to start.
Oh, this looks like a vold update is needed. Will look into this.
Re: the time is running out. I am starting to work full-time tomorrow and I believe I won't have enough time to devote to these kernels. I wish I had the serial debug cable built 2 months ago :), I would not have wasted a couple of weeks debugging the boot issues alone.
For now I am concerned with Wi-Fi mmc card failure after reload, 3D lockups with .32 kgsl, being able to use 3D acceleration in GB (I guess i should use X10 kgsl sources, am I correct?) and camera module on FroYo.
Sensors and camera module - was the userspace reverse-engineered or acer's libcamera keeps being used on newer ROMs? Were there any known issues with acer rild not starting under GB+ - during my attempts to build a caf/GB ROM I had no luck bringing up rild even after reverting the relevant commits. It links the library but that's pretty much all it does. Is there a canonical source of a CM7 for Liquid?
Hello, no real tests were performed for battery drain. While the kernel is working it is not yet as stable as I would like it to be, so any further optimization will be premature at this stage.
OTOH 2.6.32 builds allow me to get through 14 hours of occasional device usage (no wifi, 3G connection only), which was not that reachable with stock .29. With Wi-Fi enabled the drain is enormous on both .32 and .29.
Built a new version with 2.6.32 kgsl and sensors (updated the links in the first post). The only broken modules are wifi and camera, everything else pretends to be working.
Update: need to forward-port i2c recovery sequence. Either smb380 & ms-3c or isl29018 are breaking the bus so the screen stops responding and the phone appears to hang. Serial console still works but that's not really a solution. Liquid Metal has the gravity sensor/accelerometer replaced with ADXL346 and AK8975 so these are my suspects. Figuring out which one won't really help fixing this, though.
Just a quick heads-up - I got MDP composition working on FroYo with copybit from caf/gingerbread and continue to tackle the remaining issues. It looks like X10 drivers is indeed our only hope. I got Liquid MT OpenGL ES drivers to the point where they crash somewhere within the closed source binary and Nexus libraries are prelinked to 3G/1G VM split.
So now I actually run 2.6.35 on my device - my blog post but having no 3D, camera, WiFi, sensors, and top LEDs (the last one is really easy to fix but not there yet) is not much fun.
Hello, yes, nobody has yet used this kernel to build a ROM so it is only usable with FroYo stock distro. You may also want to check whether the battery is about to die as this may not depend on the ROM.
Another kernel build - acer_a1-kernel-2013-07-03-220.127.116.11-gc8bbbee-update.zip. The only visible change is that all 11 MTD partitions from atag are provided to the kernel.
I've set the default timeout policy to reset the MODEM instead of APPS processor but it works in a weird way. Using reset-modem module I tried to reset modem/reset complete chip and each time APPS processor was restarted as well. I don't have a Qualcomm development board and it does not look like somebody has written anything about these reset options, so it looks like it's not possible to recover properly from the firmware bug acer left us with.
The fact that the CM9+ builds are OK may mean that it is a bug triggered by rild.
Yes, looks like a baseband failure and APPS CPU is perfectly unaware. I guess I need to experiment with various reset switches in the kernel. I remember I've seen the possibility to reboot MODEM CPU only but leave APPS as is. Don't know whether it works but will check this nevertheless.
I've built a serial debug cable so it should be possible to get some more information regarding early kernel failures and hopefully at least some kind of info about the AMSS crash.
Yeah, my device lost the rubber cover for the miniUSB port :(
Welcome to the club - Acer Liquid E Issues (ru). I wonder whether you were experiencing this earlier. I plugged in my life:) SIM yesterday, did some tests and found that I am no longer able to reproduce the crash on incoming call. It looks like that depends on Base Station, and currently I live in a completely different location from where I had this issue regularly (neither Acer nor life:) were helpful). Since the linux kernel is not aware about the reboot, there were no warnings of any kind in the logs, I believe it is a baseband CPU crash, leading to complete system reboot.
Have you ever had such kind of an issue before?
About the apps_boot_reason - now I need to find the reason/description mapping.
I am waiting for the parts to arrive to build a serial connector for these extra 5 pins in the USB port (our Liquid devices have a Nexus One-style debugging facility via its 10-pin mini USB) to debug this kind of baseband failure, but I can't get it to crash at this location, so that's would be a bit hard.
# cat /proc/version
Linux version 18.104.22.168-i2c-g9319eb1-dirty (abuild@biff) (gcc version 4.4.0 (GCC) ) #6 PREEMPT Tue Jun 25 08:10:44 UTC 2013
# mount -t debugfs nodev /sys/kernel/debug
# cd /sys/kernel/debug/acer_smem
# cat bootmode_info
But what's even worse is the kernel not being aware about the reboot happening.
I will fix these in my init version as it looks like persist.radio is not readable/modifiable by rild: - These are uid 10001, which is the second non-privileged app user, not rild.
[ 501.337006] init: sys_prop: permission denied uid:10001 name:persist.radio.mcc.ecclist
[ 501.337827] init: sys_prop: permission denied uid:10001 name:persist.radio.mcc.ecclist.cata
[ 501.350902] init: sys_prop: permission denied uid:10001 name:persist.radio.mcc.ecclist2
[ 501.351303] init: sys_prop: permission denied uid:10001 name:persist.radio.mcc.ecclist2.cata
By any chance, just a stab in the dark, do you happen to be a "life:)" (MCC 255 MNC 06) subscriber?
For now it's just a matter of having less tasks on my plate. In case there are no other issues, switching to freedreno may be an option.
Acer Liquid had 2.6.29 as the only supported kernel version for ages, while FroYo was expected to be on 2.6.32.
During all these years multiple versions of 2.6.29 kernels with imported fixes/changes from newer versions appeared, but they all looked more like Frankenstein-monster types. Backporting new features/fixes from codeaurora was not an easy task.
Bringing relatively stable 2.6.32 version with clearly defined boundaries between codeaurora code and acer devices/hacks was a required condition to continue supporting the device with a newer upstream kernel. It's always easier to have smaller set of changes to maintain and I have already experienced a benefit of running a newer kernel - battery drain of 1% instead of 4-5% an hour when idle was definitely an improvement for me).
There are two versions (2.6.32 and 2.6.39) at once because the issues need to be ironed out first before moving to an unknown land of "2.6.35" for Liquid. FroYo libraries are working fine with 2.6.32 and with 2.6.35 we need a proper Gingerbread build, so that's not a drop-in replacement.