AOSP master do not parse "/proc/cpuinfo" anymore to set ro.hardware
and other boot related properties [1].
We can still boot by either adding "androidboot.hardware=XXX" bootarg
(where XXX could be juno/hikey/ifc6410 or any other supported hardware
platform) Or by embedding this boot information in the platform device
tree blob as suggested by this AOSP commit [2].
I was wondering if ARMLT would be interested in keeping this Android
boot related information in dts for Juno?
I have never touched anything related to device-trees, but by looking
at [2], it seem the device-tree changes for Android won't be much
complicated. The following device-tree hack worked for me:
--------------------
diff --git a/arch/arm64/boot/dts/juno.dts b/arch/arm64/boot/dts/juno.dts
index 9ad05e4..82471db 100644
--- a/arch/arm64/boot/dts/juno.dts
+++ b/arch/arm64/boot/dts/juno.dts
@@ -26,6 +26,13 @@
stdout-path = &soc_uart0;
};
+ firmware {
+ android {
+ compatible = "android,firmware";
+ hardware = "juno";
+ };
+ };
+
psci {
compatible = "arm,psci-0.2";
method = "smc";
--------------------
Regards,
Amit Pundir
[1] https://android.googlesource.com/platform/system/core/+/74b34f3cb79aa8f2c5b…
[2] https://android.googlesource.com/platform/system/core.git/+/6a52443d31d4de5…
Hi,
I'm submitting a multi-node job to try the hacking session on Juno Android,
but the host boot failed there:
<LAVA_DISPATCHER>2015-04-14 06:14:29 AM INFO: launching qemu with command
u'qemu-system-x86_64 -machine accel=kvm:tcg -m 512 -nographic -net
nic,macaddr=DE:AD:BE:EF:26:10,model=virtio -net tap -hda
/var/lib/lava/dispatcher/tmp/tmp3WXvi4/ubuntu-14-04-server-base.img'
<LAVA_DISPATCHER>2015-04-14 06:16:29 AM ERROR: Kernel Error: did not start
booting.
https://validation.linaro.org/scheduler/job/309110.0
Although in log it says:
<LAVA_DISPATCHER>2015-04-14 06:20:30 AM CRITICAL: Could not get the Android
test image booted properly
But on the target side it says:
06:26:24 AM INFO: [ACTION-E] boot_linaro_android_image is finished
successfully.
https://validation.linaro.org/scheduler/job/309110.1
By making a closer look at log the target side did boot up successfully:
root@linaro# ifconfig eth0
eth0: ip 10.7.0.20 mask 255.0.0.0 flags [up broadcast running multicast]
Is there anyone know how to walk around this issue, or knowing a successful
example for multi-node Juno Android hacking session in LAVA? Then I may can
use that test definition file as a reference.
Another error is worth to mention here, on target side:
root@linaro# echo 0>/sys/class/android_usb/android0/enable
sh: can't create /sys/class/android_usb/android0/enable: No such file or
directory
Thanks.
Botao
send it to Linaro Android Mailing list, so that others who care can comment
as well.
On 31 March 2015 at 23:20, YongQin Liu <yongqin.liu(a)linaro.org> wrote:
>
>
> On 31 March 2015 at 23:00, Milosz Wasilewski <milosz.wasilewski(a)linaro.org
> > wrote:
>
>> On 31 March 2015 at 15:57, Jon Medhurst (Tixy) <tixy(a)linaro.org> wrote:
>> > On Tue, 2015-03-31 at 13:35 +0100, Milosz Wasilewski wrote:
>> >> We noticed Vellamo 1 hangs on Network Loader test. It happens almost
>> >> always with 15.03 release build.
>> >
>> > That's what I'm seeing too.
>> >
>> > I don't get the audio error seen in LAVA, presumably because I have a
>> > monitor with audio support.
>> >
>> > I do get the mali errors when running test 4 - 'Pixel Blender'...
>> >
>> > [ 239.339919] mali 2d000000.gpu: JS: Job Hard-Stopped (took more than
>> 4 ticks at 50 ms/tick)
>> > [ 239.798175] mali 2d000000.gpu: JS: Job Hard-Stopped (took more than
>> 4 ticks at 50 ms/tick)
>> > [ 239.806397] mali 2d000000.gpu: error detected from slot 0, job
>> status 0x00000004 (TERMINATED)
>> > [ 239.814839] mali 2d000000.gpu: GPU fault 0x04 from job slot 0
>> > [ 239.820817] mali 2d000000.gpu: Replaying jobs retry=0
>> >
>> > I'll take a bit of a look to see if I can get a clue as to what's going
>> > on.
>> >
>> > Does this test work on the HiKey?
>>
>> do we have HiKey build?
>>
> No test on HiKey.
>
> Thanks,
> Yongqin Liu
>
>
>
> --
> Best Regards,
> Yongqin Liu
> ---------------------------------------------------------------
> #mailing list
> linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org>
> http://lists.linaro.org/mailman/listinfo/linaro-android
>
--
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/linaro-android
Hi, Antutu Team
When I ran the Antutu5.7 benchmark on my Nexus9(Build from AOSP 5.1.0_r3),
it got crashed during the execution of 32bit test.
The crash in the logcat is something like following, could you please help
to check on that.
--------- beginning of crash
04-14 16:08:37.354 F/libc (12271): Fatal signal 11 (SIGSEGV), code 1,
fault addr 0x0 in tid 13151 (GLThread 662)
04-14 16:08:37.356 I/art (12271): Explicit concurrent mark sweep GC
freed 3218(239KB) AllocSpace objects, 3(48KB) LOS objects, 39% free,
16MB/27MB, paused 4.890ms total 58.692ms
04-14 16:08:37.455 I/DEBUG ( 514): *** *** *** *** *** *** *** *** ***
*** *** *** *** *** *** ***
04-14 16:08:37.456 I/DEBUG ( 514): Build fingerprint:
'Android/aosp_flounder/flounder:5.1/LMY47I/liuyq04131145:userdebug/test-keys'
04-14 16:08:37.456 I/DEBUG ( 514): Revision: '0'
04-14 16:08:37.456 I/DEBUG ( 514): ABI: 'arm'
04-14 16:08:37.456 I/DEBUG ( 514): pid: 12271, tid: 13151, name:
GLThread 662 >>> com.antutu.ABenchMark <<<
04-14 16:08:37.456 I/DEBUG ( 514): signal 11 (SIGSEGV), code 1
(SEGV_MAPERR), fault addr 0x0
04-14 16:08:37.463 I/DEBUG ( 514): r0 00000000 r1 e25d7aac r2
00000000 r3 e2ed7c7c
04-14 16:08:37.463 I/DEBUG ( 514): r4 00000026 r5 73d9e368 r6
73d9be98 r7 32ed0750
04-14 16:08:37.463 I/DEBUG ( 514): r8 70289440 r9 ab59a778 sl
00000000 fp 32ed0750
04-14 16:08:37.463 I/DEBUG ( 514): ip e2dbc9f1 sp e25d7a98 lr
e2dbc9f7 pc e2dbc9f6 cpsr 600d0030
04-14 16:08:37.464 I/DEBUG ( 514):
04-14 16:08:37.464 I/DEBUG ( 514): backtrace:
04-14 16:08:37.464 I/DEBUG ( 514): #00 pc 000e49f6
/data/app/com.antutu.ABenchMark-1/lib/arm/libabenchmark.so
(Java_org_cocos2dx_lib_Cocos2dxRenderer_nativeOnPause+5)
04-14 16:08:37.464 I/DEBUG ( 514): #01 pc 0005b9b5
/data/dalvik-cache/arm/data@app@com.antutu.ABenchMark-1@base.apk
@classes.dex
04-14 16:08:37.756 I/DEBUG ( 514):
04-14 16:08:37.756 I/DEBUG ( 514): Tombstone written to:
/data/tombstones/tombstone_09
You can check the logcat and tombstone in the attached file.
BTW, we can see similar crash on our own 64bit platform with Antutu5.6.2 as
well.
And in the logcat attached, there are also crashes seems on the 3d related
test for 32bit.
If possible please help to check on that as well.
--
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/linaro-android
Hi guys,
Re. caffinemark Stuart did some investigation and found the following. Not
sure if it applies to your builds too.
* Investigated why CaffeineMark wasn't working. For Juno, we use a small
heapsize (48MB), which wasn't sufficient for
caffeinemark to run successfully against. Looks like the allocator is
subject to fragmentation issues. Using flounder's
configuration (a 2GB 10inch tablet, apparently) works fine
Regards,
Steve
On 20/03/2015 14:16, "linaro-android-request(a)lists.linaro.org"
<linaro-android-request(a)lists.linaro.org> wrote:
>Send linaro-android mailing list submissions to
> linaro-android(a)lists.linaro.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.linaro.org/mailman/listinfo/linaro-android
>or, via email, send a message with subject or body 'help' to
> linaro-android-request(a)lists.linaro.org
>
>You can reach the person managing the list at
> linaro-android-owner(a)lists.linaro.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of linaro-android digest..."
>
>
>Today's Topics:
>
> 1. Re: Update v1 : Jobs for build#335 (Mahanth Gouda)
> 2. Re: Update v1 : Jobs for build#335 (Botao Sun)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Thu, 19 Mar 2015 16:28:44 +0000
>From: Mahanth Gouda <mahanth.gouda(a)linaro.org>
>To: YongQin Liu <yongqin.liu(a)linaro.org>
>Cc: Linaro Android Mailman List <linaro-android(a)lists.linaro.org>,
> Jakub Pavelek <jakub.pavelek(a)linaro.org>
>Subject: Re: Update v1 : Jobs for build#335
>Message-ID:
> <CAKhO2P9rPYOf+Z8GNNrYMfoCqsJats=kJr0ZJO2Ug_BP=mBTbQ(a)mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>Pleas find my observations in line:
>
> - nbench - Looks ok.
>
>
> - GFXBench3 - CRASH - (I get this msg on the display - Your version of
> the GFXBench is outdated, please refresh the app and start again. Let
>me
> know if you need to the log cat msg for this ?)
>
>
> - gearses2eclair - Looks good to me. Tried a couple of times and it
> looks OK.
>
>
>Thanks,
>
>Mahanth
>
>On 19 March 2015 at 16:10, YongQin Liu <yongqin.liu(a)linaro.org> wrote:
>
>> Hi, Mahanth
>>
>> Another 3 apks:
>>
>> - nbench
>> - GFXBench3
>> - gearses2eclair, not finished yet, seems to be timed out
>>
>> Could you please help to check these 3 apks as well?
>> They are failed to get the result at my jobs.
>>
>>
>> Thanks,
>> Yongqin Liu
>> On 19 March 2015 at 23:49, Mahanth Gouda <mahanth.gouda(a)linaro.org>
>>wrote:
>>
>>> Hi all,
>>> Just wanted to let you know that I've picked up the build 335 and
>>>started
>>> manual testing this morning on Juno.
>>> I'm half the way running these tests so far, hoping to finish the rest
>>>in
>>> next few hours time.
>>> So, thought of giving you a quick results update:
>>>
>>> I'm testing only those benchmarks that've been marked by Yongqin as
>>> failed.
>>> Please let me know if I've missed something?
>>>
>>> Benchmark job 1:
>>> ---------------
>>> 1. antutu 5 - *HUNG/CRASH *(No log as the test didn't complete )
>>> 2. caffeinemark - *CRASH *- (Every other time this test fails) - logcat
>>> & snapshot attached
>>> 3. cfbench - *PASS*
>>>
>>> Benchmark job 2:
>>> ---------------
>>> 4. smartbench2014 - *PASS*
>>> 5. gearsES1eclair - *CRASH* (There's no log for this because the script
>>> does not complete, it's hung in between) It took long time
>>>investigating
>>> this, but could not get to the root cause of this issue. So, I've left
>>>it
>>> open for now.
>>>
>>> Benchmark job 3:
>>> ---------------
>>> 6. vellamo - testing in progress (currently the benchmark sounds like
>>> it's paused on Networking Loader, since a while)
>>>
>>>
>>> Benchmark job 4:
>>> ---------------
>>> 7. andebench2014 -
>>> 8. javawhetstone -
>>> 9. jbench -
>>> 10. linpackjava -
>>> 11. scimark -
>>>
>>> Please note - I've repeated all these tests at least 5 times in order
>>>to
>>> check the consistency.
>>>
>>>
>>> Thanks & regards,
>>> Mahanth
>>>
>>>
>>>
>>>
>>> On 19 March 2015 at 10:59, Mahanth Gouda <mahanth.gouda(a)linaro.org>
>>> wrote:
>>>
>>>> Hi Jakub,
>>>> Thanks for the help offer, I've started with this, will surely seek
>>>>your
>>>> help when required.
>>>>
>>>>
>>>> Thanks,
>>>> Mahanth
>>>>
>>>> On 19 March 2015 at 09:19, Jakub Pavelek <jakub.pavelek(a)linaro.org>
>>>> wrote:
>>>>
>>>>> Hi Botao and Mananth,
>>>>>
>>>>> if you need anything from us ping me or YongQin. We would like to
>>>>> investigate the failing benchmark automation ASAP, otherwise we need
>>>>>QAS to
>>>>> run those benchmarks manually and we will lose trends tracking in
>>>>> ImageReports.
>>>>>
>>>>>
>>>>>
>>>>> On 18 March 2015 at 19:01, Milosz Wasilewski <
>>>>> milosz.wasilewski(a)linaro.org> wrote:
>>>>>
>>>>>> Botao and Mahanth can help. Mahanth has access to the hw. As far as
>>>>>>I
>>>>>> remember:
>>>>>> - antutu 5 crashes (was crashing before) before it finishes
>>>>>> - caffeinemark crashes 4 out of 5 attempts
>>>>>> - nbench produces empty results for some reason (only zeros)
>>>>>> - GFXBench takes very long to run, we might have too short timeout
>>>>>> - GearsES1 crashes always and should be abandoned
>>>>>>
>>>>>> I don't know about the others. This is what was happening before
>>>>>> moving to 5.1. Mahanth, please take this as high priority to
>>>>>> investigate. Botao migh help you with Gears as he did the
>>>>>>automation.
>>>>>>
>>>>>> milosz
>>>>>>
>>>>>>
>>>>>> On 18 March 2015 at 15:56, Jakub Pavelek <jakub.pavelek(a)linaro.org>
>>>>>> wrote:
>>>>>> > Milosz is out of office all this week. We need to find another way
>>>>>> to check
>>>>>> > things out :-/
>>>>>> >
>>>>>> > On 18 March 2015 at 10:14, YongQin Liu <yongqin.liu(a)linaro.org>
>>>>>> wrote:
>>>>>> >>
>>>>>> >> Hi, Misolz
>>>>>> >>
>>>>>> >> Could you please help to check if the benchmark tests mentioned
>>>>>> below
>>>>>> >> can work on the Juno with the 5.1 build#335?
>>>>>> >>
>>>>>> >> Thanks,
>>>>>> >> Yongqin Liu
>>>>>> >>
>>>>>> >> On 18 March 2015 at 17:11, YongQin Liu <yongqin.liu(a)linaro.org>
>>>>>> wrote:
>>>>>> >>>
>>>>>> >>> Hi, All
>>>>>> >>>
>>>>>> >>> The job for the benchmarks failed again.
>>>>>> >>> Seems there is a problem to run the vellamo on Juno, the test
>>>>>> timed out
>>>>>> >>> and caused the sync problem.
>>>>>> >>> So I split the job into 3 small jobs:
>>>>>> >>>
>>>>>> >>> Benchmark Job#1
>>>>>> >>> https://validation.linaro.org/scheduler/job/287238.0 finished.
>>>>>> >>> but there is no benchmark result for benchmarks application of
>>>>>> antutu5,
>>>>>> >>> Caffeinemark, and CF-Bench.
>>>>>> >>> And also all the benchmark result for nbench are zero.
>>>>>> >>>
>>>>>> >>> Benchmark Job#2
>>>>>> >>> https://validation.linaro.org/scheduler/job/287240.0
>>>>>> >>> Smartbench2012 seems not started correctly.
>>>>>> >>> And the gearses1eclair test was timed out, and caused the sync
>>>>>> problem.
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> Benchmark Job#3: vellamo job, timed out again.
>>>>>> >>> https://validation.linaro.org/scheduler/job/287242.0
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> Benchmark Job#4: tests for andebench2014, Javawhetstone, JBench,
>>>>>> >>> LinpackJava, and Scimark
>>>>>> >>> https://validation.linaro.org/scheduler/job/287503.0
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> Thanks,
>>>>>> >>> Yongqin Liu
>>>>>> >>> On 17 March 2015 at 21:30, YongQin Liu <yongqin.liu(a)linaro.org>
>>>>>> wrote:
>>>>>> >>>>
>>>>>> >>>> Hi, Jakub
>>>>>> >>>>
>>>>>> >>>> The 2 cts jobs finished.
>>>>>> >>>>
>>>>>> >>>> Thanks,
>>>>>> >>>> Yongqin Liu
>>>>>> >>>> On 17 March 2015 at 15:47, YongQin Liu <yongqin.liu(a)linaro.org>
>>>>>> wrote:
>>>>>> >>>>>
>>>>>> >>>>> Hi, All
>>>>>> >>>>>
>>>>>> >>>>> Following are job status for Juno build #335 on LAVA:
>>>>>> >>>>> The 3 resubmitted jobs are running on LAVA now.
>>>>>> >>>>>
>>>>>> >>>>> Normal Job:
>>>>>> >>>>> https://validation.linaro.org/scheduler/job/282224 finished
>>>>>> >>>>>
>>>>>> >>>>> benchmark-lite:
>>>>>> >>>>> https://validation.linaro.org/scheduler/job/282229.0 finished
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>> linaro-android_armv8-android-juno-lsk-benchmark-application
>>>>>> >>>>> https://validation.linaro.org/scheduler/job/282231.0 finished
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>> linaro-android_armv8-android-juno-lsk_cts_32bit:
>>>>>> >>>>> https://validation.linaro.org/scheduler/job/282225.1 Canceled
>>>>>> >>>>> https://validation.linaro.org/scheduler/job/284313.0
>>>>>>Incomplete
>>>>>> >>>>> https://validation.linaro.org/scheduler/job/286312.0
>>>>>>resubmitted
>>>>>> >>>>
>>>>>> >>>> Finished
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>> linaro-android_armv8-android-juno-lsk_cts_64bit:
>>>>>> >>>>> https://validation.linaro.org/scheduler/job/282227.0 Canceled
>>>>>> >>>>> https://validation.linaro.org/scheduler/job/284315.0
>>>>>>Incomplete
>>>>>> >>>>> https://validation.linaro.org/scheduler/job/286310.0
>>>>>> resubmitted
>>>>>> >>>>
>>>>>> >>>> Finished.
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>> Benchmarks:
>>>>>> >>>>> https://validation.linaro.org/scheduler/job/282233.0 Canceled
>>>>>> >>>>> https://validation.linaro.org/scheduler/job/284317.0
>>>>>>Incomplete
>>>>>> >>>>> https://validation.linaro.org/scheduler/job/286314.0
>>>>>>resubmitted
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>> --
>>>>>> >>>>> Best Regards,
>>>>>> >>>>> Yongqin Liu
>>>>>> >>>>>
>>>>>>---------------------------------------------------------------
>>>>>> >>>>> #mailing list
>>>>>> >>>>> linaro-android(a)lists.linaro.org
>>>>>> >>>>> http://lists.linaro.org/mailman/listinfo/linaro-android
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> --
>>>>>> >>>> Best Regards,
>>>>>> >>>> Yongqin Liu
>>>>>> >>>> ---------------------------------------------------------------
>>>>>> >>>> #mailing list
>>>>>> >>>> linaro-android(a)lists.linaro.org
>>>>>> >>>> http://lists.linaro.org/mailman/listinfo/linaro-android
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> --
>>>>>> >>> Best Regards,
>>>>>> >>> Yongqin Liu
>>>>>> >>> ---------------------------------------------------------------
>>>>>> >>> #mailing list
>>>>>> >>> linaro-android(a)lists.linaro.org
>>>>>> >>> http://lists.linaro.org/mailman/listinfo/linaro-android
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> Best Regards,
>>>>>> >> Yongqin Liu
>>>>>> >> ---------------------------------------------------------------
>>>>>> >> #mailing list
>>>>>> >> linaro-android(a)lists.linaro.org
>>>>>> >> http://lists.linaro.org/mailman/listinfo/linaro-android
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > With best regards,
>>>>>> >
>>>>>> > Jakub Pavelek
>>>>>> >
>>>>>> > Linaro Mobile Group project manager
>>>>>> > Linaro.org?Open source software for ARM SoCs
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> With best regards,
>>>>>
>>>>> Jakub Pavelek
>>>>>
>>>>> Linaro Mobile Group project manager
>>>>> Linaro.org?Open source software for ARM SoCs
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> Best Regards,
>> Yongqin Liu
>> ---------------------------------------------------------------
>> #mailing list
>> linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org>
>> http://lists.linaro.org/mailman/listinfo/linaro-android
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><http://lists.linaro.org/pipermail/linaro-android/attachments/20150319/2ac
>ebd8e/attachment-0001.html>
>
>------------------------------
>
>Message: 2
>Date: Fri, 20 Mar 2015 17:16:38 +1100
>From: Botao Sun <botao.sun(a)linaro.org>
>To: Mahanth Gouda <mahanth.gouda(a)linaro.org>
>Cc: Linaro Android Mailman List <linaro-android(a)lists.linaro.org>,
> Jakub Pavelek <jakub.pavelek(a)linaro.org>
>Subject: Re: Update v1 : Jobs for build#335
>Message-ID:
> <CAMGVPmUryFQoPs+RF4M4P+nFm524HdTm=g7Y1GP6Ed3yOHyMaw(a)mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>Hi Mahanth,
>
>Glad to hear that you managed to run gearses2eclair successfully, I'm
>afraid there is nothing more I can do on my side - I only have a TI Panda
>4430 which the latest available image is 14.10, and obviously it works
>well
>on that build as I wrote the code based on it.
>
>Thanks goodness you have the access to Juno board in Cambridge. ;)
>
>Let me know if you need any extra explanation about the code.
>
>
>Botao
>
>On 20 March 2015 at 03:28, Mahanth Gouda <mahanth.gouda(a)linaro.org> wrote:
>
>> Pleas find my observations in line:
>>
>> - nbench - Looks ok.
>>
>>
>> - GFXBench3 - CRASH - (I get this msg on the display - Your version
>>of
>> the GFXBench is outdated, please refresh the app and start again.
>>Let me
>> know if you need to the log cat msg for this ?)
>>
>>
>> - gearses2eclair - Looks good to me. Tried a couple of times and it
>> looks OK.
>>
>>
>> Thanks,
>>
>> Mahanth
>>
>> On 19 March 2015 at 16:10, YongQin Liu <yongqin.liu(a)linaro.org> wrote:
>>
>>> Hi, Mahanth
>>>
>>> Another 3 apks:
>>>
>>> - nbench
>>> - GFXBench3
>>> - gearses2eclair, not finished yet, seems to be timed out
>>>
>>> Could you please help to check these 3 apks as well?
>>> They are failed to get the result at my jobs.
>>>
>>>
>>> Thanks,
>>> Yongqin Liu
>>> On 19 March 2015 at 23:49, Mahanth Gouda <mahanth.gouda(a)linaro.org>
>>> wrote:
>>>
>>>> Hi all,
>>>> Just wanted to let you know that I've picked up the build 335 and
>>>> started manual testing this morning on Juno.
>>>> I'm half the way running these tests so far, hoping to finish the rest
>>>> in next few hours time.
>>>> So, thought of giving you a quick results update:
>>>>
>>>> I'm testing only those benchmarks that've been marked by Yongqin as
>>>> failed.
>>>> Please let me know if I've missed something?
>>>>
>>>> Benchmark job 1:
>>>> ---------------
>>>> 1. antutu 5 - *HUNG/CRASH *(No log as the test didn't complete )
>>>> 2. caffeinemark - *CRASH *- (Every other time this test fails) -
>>>>logcat
>>>> & snapshot attached
>>>> 3. cfbench - *PASS*
>>>>
>>>> Benchmark job 2:
>>>> ---------------
>>>> 4. smartbench2014 - *PASS*
>>>> 5. gearsES1eclair - *CRASH* (There's no log for this because the
>>>>script
>>>> does not complete, it's hung in between) It took long time
>>>>investigating
>>>> this, but could not get to the root cause of this issue. So, I've
>>>>left it
>>>> open for now.
>>>>
>>>> Benchmark job 3:
>>>> ---------------
>>>> 6. vellamo - testing in progress (currently the benchmark sounds like
>>>> it's paused on Networking Loader, since a while)
>>>>
>>>>
>>>> Benchmark job 4:
>>>> ---------------
>>>> 7. andebench2014 -
>>>> 8. javawhetstone -
>>>> 9. jbench -
>>>> 10. linpackjava -
>>>> 11. scimark -
>>>>
>>>> Please note - I've repeated all these tests at least 5 times in order
>>>>to
>>>> check the consistency.
>>>>
>>>>
>>>> Thanks & regards,
>>>> Mahanth
>>>>
>>>>
>>>>
>>>>
>>>> On 19 March 2015 at 10:59, Mahanth Gouda <mahanth.gouda(a)linaro.org>
>>>> wrote:
>>>>
>>>>> Hi Jakub,
>>>>> Thanks for the help offer, I've started with this, will surely seek
>>>>> your help when required.
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Mahanth
>>>>>
>>>>> On 19 March 2015 at 09:19, Jakub Pavelek <jakub.pavelek(a)linaro.org>
>>>>> wrote:
>>>>>
>>>>>> Hi Botao and Mananth,
>>>>>>
>>>>>> if you need anything from us ping me or YongQin. We would like to
>>>>>> investigate the failing benchmark automation ASAP, otherwise we
>>>>>>need QAS to
>>>>>> run those benchmarks manually and we will lose trends tracking in
>>>>>> ImageReports.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 18 March 2015 at 19:01, Milosz Wasilewski <
>>>>>> milosz.wasilewski(a)linaro.org> wrote:
>>>>>>
>>>>>>> Botao and Mahanth can help. Mahanth has access to the hw. As far
>>>>>>>as I
>>>>>>> remember:
>>>>>>> - antutu 5 crashes (was crashing before) before it finishes
>>>>>>> - caffeinemark crashes 4 out of 5 attempts
>>>>>>> - nbench produces empty results for some reason (only zeros)
>>>>>>> - GFXBench takes very long to run, we might have too short timeout
>>>>>>> - GearsES1 crashes always and should be abandoned
>>>>>>>
>>>>>>> I don't know about the others. This is what was happening before
>>>>>>> moving to 5.1. Mahanth, please take this as high priority to
>>>>>>> investigate. Botao migh help you with Gears as he did the
>>>>>>>automation.
>>>>>>>
>>>>>>> milosz
>>>>>>>
>>>>>>>
>>>>>>> On 18 March 2015 at 15:56, Jakub Pavelek <jakub.pavelek(a)linaro.org>
>>>>>>> wrote:
>>>>>>> > Milosz is out of office all this week. We need to find another
>>>>>>>way
>>>>>>> to check
>>>>>>> > things out :-/
>>>>>>> >
>>>>>>> > On 18 March 2015 at 10:14, YongQin Liu <yongqin.liu(a)linaro.org>
>>>>>>> wrote:
>>>>>>> >>
>>>>>>> >> Hi, Misolz
>>>>>>> >>
>>>>>>> >> Could you please help to check if the benchmark tests mentioned
>>>>>>> below
>>>>>>> >> can work on the Juno with the 5.1 build#335?
>>>>>>> >>
>>>>>>> >> Thanks,
>>>>>>> >> Yongqin Liu
>>>>>>> >>
>>>>>>> >> On 18 March 2015 at 17:11, YongQin Liu <yongqin.liu(a)linaro.org>
>>>>>>> wrote:
>>>>>>> >>>
>>>>>>> >>> Hi, All
>>>>>>> >>>
>>>>>>> >>> The job for the benchmarks failed again.
>>>>>>> >>> Seems there is a problem to run the vellamo on Juno, the test
>>>>>>> timed out
>>>>>>> >>> and caused the sync problem.
>>>>>>> >>> So I split the job into 3 small jobs:
>>>>>>> >>>
>>>>>>> >>> Benchmark Job#1
>>>>>>> >>> https://validation.linaro.org/scheduler/job/287238.0 finished.
>>>>>>> >>> but there is no benchmark result for benchmarks application of
>>>>>>> antutu5,
>>>>>>> >>> Caffeinemark, and CF-Bench.
>>>>>>> >>> And also all the benchmark result for nbench are zero.
>>>>>>> >>>
>>>>>>> >>> Benchmark Job#2
>>>>>>> >>> https://validation.linaro.org/scheduler/job/287240.0
>>>>>>> >>> Smartbench2012 seems not started correctly.
>>>>>>> >>> And the gearses1eclair test was timed out, and caused the sync
>>>>>>> problem.
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> Benchmark Job#3: vellamo job, timed out again.
>>>>>>> >>> https://validation.linaro.org/scheduler/job/287242.0
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> Benchmark Job#4: tests for andebench2014, Javawhetstone,
>>>>>>>JBench,
>>>>>>> >>> LinpackJava, and Scimark
>>>>>>> >>> https://validation.linaro.org/scheduler/job/287503.0
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> Thanks,
>>>>>>> >>> Yongqin Liu
>>>>>>> >>> On 17 March 2015 at 21:30, YongQin Liu <yongqin.liu(a)linaro.org>
>>>>>>> wrote:
>>>>>>> >>>>
>>>>>>> >>>> Hi, Jakub
>>>>>>> >>>>
>>>>>>> >>>> The 2 cts jobs finished.
>>>>>>> >>>>
>>>>>>> >>>> Thanks,
>>>>>>> >>>> Yongqin Liu
>>>>>>> >>>> On 17 March 2015 at 15:47, YongQin Liu
>>>>>>><yongqin.liu(a)linaro.org>
>>>>>>> wrote:
>>>>>>> >>>>>
>>>>>>> >>>>> Hi, All
>>>>>>> >>>>>
>>>>>>> >>>>> Following are job status for Juno build #335 on LAVA:
>>>>>>> >>>>> The 3 resubmitted jobs are running on LAVA now.
>>>>>>> >>>>>
>>>>>>> >>>>> Normal Job:
>>>>>>> >>>>> https://validation.linaro.org/scheduler/job/282224 finished
>>>>>>> >>>>>
>>>>>>> >>>>> benchmark-lite:
>>>>>>> >>>>> https://validation.linaro.org/scheduler/job/282229.0 finished
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>> linaro-android_armv8-android-juno-lsk-benchmark-application
>>>>>>> >>>>> https://validation.linaro.org/scheduler/job/282231.0 finished
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>> linaro-android_armv8-android-juno-lsk_cts_32bit:
>>>>>>> >>>>> https://validation.linaro.org/scheduler/job/282225.1 Canceled
>>>>>>> >>>>> https://validation.linaro.org/scheduler/job/284313.0
>>>>>>>Incomplete
>>>>>>> >>>>> https://validation.linaro.org/scheduler/job/286312.0
>>>>>>> resubmitted
>>>>>>> >>>>
>>>>>>> >>>> Finished
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>> linaro-android_armv8-android-juno-lsk_cts_64bit:
>>>>>>> >>>>> https://validation.linaro.org/scheduler/job/282227.0 Canceled
>>>>>>> >>>>> https://validation.linaro.org/scheduler/job/284315.0
>>>>>>> Incomplete
>>>>>>> >>>>> https://validation.linaro.org/scheduler/job/286310.0
>>>>>>> resubmitted
>>>>>>> >>>>
>>>>>>> >>>> Finished.
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>> Benchmarks:
>>>>>>> >>>>> https://validation.linaro.org/scheduler/job/282233.0 Canceled
>>>>>>> >>>>> https://validation.linaro.org/scheduler/job/284317.0
>>>>>>>Incomplete
>>>>>>> >>>>> https://validation.linaro.org/scheduler/job/286314.0
>>>>>>> resubmitted
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>> --
>>>>>>> >>>>> Best Regards,
>>>>>>> >>>>> Yongqin Liu
>>>>>>> >>>>>
>>>>>>>---------------------------------------------------------------
>>>>>>> >>>>> #mailing list
>>>>>>> >>>>> linaro-android(a)lists.linaro.org
>>>>>>> >>>>> http://lists.linaro.org/mailman/listinfo/linaro-android
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> --
>>>>>>> >>>> Best Regards,
>>>>>>> >>>> Yongqin Liu
>>>>>>> >>>>
>>>>>>>---------------------------------------------------------------
>>>>>>> >>>> #mailing list
>>>>>>> >>>> linaro-android(a)lists.linaro.org
>>>>>>> >>>> http://lists.linaro.org/mailman/listinfo/linaro-android
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> --
>>>>>>> >>> Best Regards,
>>>>>>> >>> Yongqin Liu
>>>>>>> >>> ---------------------------------------------------------------
>>>>>>> >>> #mailing list
>>>>>>> >>> linaro-android(a)lists.linaro.org
>>>>>>> >>> http://lists.linaro.org/mailman/listinfo/linaro-android
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> --
>>>>>>> >> Best Regards,
>>>>>>> >> Yongqin Liu
>>>>>>> >> ---------------------------------------------------------------
>>>>>>> >> #mailing list
>>>>>>> >> linaro-android(a)lists.linaro.org
>>>>>>> >> http://lists.linaro.org/mailman/listinfo/linaro-android
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > --
>>>>>>> > With best regards,
>>>>>>> >
>>>>>>> > Jakub Pavelek
>>>>>>> >
>>>>>>> > Linaro Mobile Group project manager
>>>>>>> > Linaro.org?Open source software for ARM SoCs
>>>>>>> >
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> With best regards,
>>>>>>
>>>>>> Jakub Pavelek
>>>>>>
>>>>>> Linaro Mobile Group project manager
>>>>>> Linaro.org?Open source software for ARM SoCs
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Yongqin Liu
>>> ---------------------------------------------------------------
>>> #mailing list
>>> linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org>
>>> http://lists.linaro.org/mailman/listinfo/linaro-android
>>>
>>
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><http://lists.linaro.org/pipermail/linaro-android/attachments/20150320/989
>687c9/attachment.html>
>
>------------------------------
>
>_______________________________________________
>linaro-android mailing list
>linaro-android(a)lists.linaro.org
>http://lists.linaro.org/mailman/listinfo/linaro-android
>
>
>End of linaro-android Digest, Vol 40, Issue 13
>**********************************************
>
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Hello all,
I am working on a android tablet using TI OMAP 4470 ES1 Soc which has 2xArm
Cortex A9. The system is running Android 4.2.2 with Linux Kernel 3.4.48.
My kernel configuration with these debugging:
CONFIG_CC_STACKPROTECTOR=y
> CONFIG_DEBUG_SPINLOCK=y
> CONFIG_DEBUG_MUTEXES=y
> # CONFIG_DEBUG_LOCK_ALLOC is not set
> CONFIG_TRACE_IRQFLAGS=y
> CONFIG_DEBUG_ATOMIC_SLEEP=y
> CONFIG_DEBUG_LOCK_ALLOC=y
> CONFIG_PROVE_LOCKING=y
> CONFIG_LOCKDEP=y
> CONFIG_DEBUG_SLAB=y
> CONFIG_DEBUG_SLAB_LEAK=y
> #and FTRACE
> CONFIG_FUNCTION_TRACER=y
> CONFIG_FUNCTION_GRAPH_TRACER=y
> CONFIG_STACK_TRACER=y
> CONFIG_DYNAMIC_FTRACE=y
The system randomly got reset due to memory corruption and one of them
seems the the stack is restored incorrectly. One of the crashing is as
following:
[484677.808807] Unable to handle kernel paging request at virtual address
> 0040049c
> [484677.817077] pgd = d5ee8000
> [484677.820220] [0040049c] *pgd=00000000
> [484677.824615] Process UEventObserver (pid: 764, stack limit = 0xd5b2c2f8)
> [484677.832000] Internal error: Oops: 805 [#1] PREEMPT SMP ARM
> [484677.838287] Modules linked in: wlcore_sdio(O) wl18xx(O) wlcore(O)
> mac80211(O) cfg80211(O) compat(O) pvrsrvkm_sgx544_112(O)
> [484677.851806] CPU: 0 Tainted: G W O (3.4.48-dirty #1)
> [484677.858459] PC is at lock_release+0x9c/0x134
> [484677.863433] LR is at _raw_spin_lock_irqsave+0x64/0x70
> [484677.869140] pc : [<c00a48f0>] lr : [<c06b7850>] psr: 60000193
> [484677.869140] sp : d5b2db20 ip : d5b2daf0 fp : d5b2db54
> [484677.882141] r10: 00000000 r9 : d5b2dbf4 r8 : 00000000
> [484677.888122] r7 : d5a8bec0 r6 : d5b2c000 r5 : d58a8040 r4 : c00a3710
> [484677.895416] r3 : 00400040 r2 : 00000000 r1 : 5bbd5bbc r0 : 60000113
Decode the stack dump:
> [484678.126312] SP: 0xd5b2daa0:
> [484678.131408] daa0 00000080 00000000 c0070cf8 00000000 c06b6cb4
> c06b64c8 c00a48f0 60000193
> [484678.141998] dac0 ffffffff d5b2db0c d5b2db54 d5b2dad8
> c06b85d8(lr=__dabt_svc) c000839c(pc=do_DataAbort())
> 60000113(r0) 5bbd5bbc(r1)
> [484678.152587] dae0 00000000(r2) 00400040(r3) c00a3710(pc=__lock_acquire)
> push {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr, pc}
> d58a8040(4) d5b2c000(5) d5a8bec0(6) 00000000(7) d5b2dbf4(8)
> [484678.163055] db00 00000000(9) d5b2db54(sl) d5b2daf0(fp) d5b2db20(ip)
> c06b7850(lr=_raw_spin_lock_irqsave) c00a48f0(pc=lock_release)
> 60000193 ffffffff
> push {r3, r4, r5, r6, fp, ip, lr, pc}
> [484678.173522] db20 d5b2dd10(r3) d5b2dcf4(r4) d5a86338(r5) 00000000(r6)
> d5b2db5c(fp) d5b2db40(ip) c0144974(lr=__pollwait)
> c0070cd4(pc=add_wait_queue)
> [484678.184082] db40 d5abb400 d5b2dbfc d5a86338 d5b2dc04 d5b2db74
> d5b2db60 c050e470 c01448f0(pc=pollwake)
> [484678.194702] db60 d5b2dcf4 d5b2dbfc d5b2db84 d5b2db78 c0500d84
> c050e440 d5b2dbe4 d5b2db88
> [484678.205200] db80 c0144cc4 c0500d64 d5b2dbac d5b2c000 00000000
> 00000000 00000000 d5b2dbf4
I found that the UEventObserver userspace process is calling select()
system call then the kernel code path is:
__pollwait()
--> add_wait_queue()
------> _raw_spin_lock_irqsave()
---------> lock_release()
1. The first issue is I do not understand why the _raw_spin_lock_irqsave()
call lock_release right after. It should call lock_acquire().
2. It look likes the register is pop from stack is not correct:
It look likes the stack frame for add_wait_queue() function is correct:
> 60000193(cpsr) ffffffff
> push {r3, r4, r5, r6, fp, ip, lr, pc}
> [484678.173522] db20 d5b2dd10(r3) d5b2dcf4(r4) d5a86338(r5) 00000000(r6)
> d5b2db5c(fp) d5b2db40(ip) c0144974(lr=__pollwait)
> c0070cd4(pc=add_wait_queue)
The cpsr=600000193 means interrupt is disabled so that scheduler is also
off mean no other task in the same core can affect the current execution
thread.
The stack frame for calling lock_release() seems correct too
> push {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr, pc}
> d58a8040(4) d5b2c000(5) d5a8bec0(6) 00000000(7) d5b2dbf4(8)
> [484678.163055] db00 00000000(9) d5b2db54(sl) d5b2daf0(fp) d5b2db20(ip)
> c06b7850(lr=_raw_spin_lock_irqsave) c00a48f0(pc=lock_release)
I found that:
> R5=d5b2c000 point to the thread_info
> R4=d58a8040 point to the current task_struct
But it look like poping from stack got issue then the system crashed:
> r6 : d5b2c000 r5 : d58a8040 r4 : c00a3710
Now R6=d5b2c000 (which is R5 in stack) and R5=d58a8040 (which is R4 in
stack) R4=c00a3710(seem this is the LR of other stack frame).
Have anyone faced this issue ?
I suspect that enabling Profiling when building kernel cause this issue
because I found the generated code for add_wait_queue():
> void add_wait_queue(wait_queue_head_t *q, wait_queue_t *wait)
> {
> c0070cc8: e1a0c00d mov ip, sp
> c0070ccc: e92dd878 push {r3, r4, r5, r6, fp, ip, lr, pc}
> c0070cd0: e24cb004 sub fp, ip, #4
> c0070cd4: e92d4000 push {lr}
> c0070cd8: ebfe8c62 *bl c0013e68 <__gnu_mcount_nc>*
The jump to __gnu_mcount_nc() is generated by GCC when the option -pg is
enabled. Is there any how that cause issue for stack setup ?
Many thanks for reading this long mail. Any sharing idea is very
appriciated.
Thanks again.
--
Quan Cao
0976574864
Hi list,
I don't know whether this is correct list for my questions. If it's not,
please let me know and sorry for the noise.
We have a premium member who is trying to create member build based on
LCR. Here is the first questions they asked:
What's the difference between AOSP and LCR?
I downloaded the android source (I suppose it's LCR) by following the
link here:
https://wiki.linaro.org/Platform/Android/GetSource#Platform_Code_Get_source…
and got couple of questions regarding this source:
1. Is this source code for LCR?
2. I suppose the source code could be divided to two parts:
- base android src defined by MANIFEST_BRANCH. Which match the same
tag on Google AOSP exactly even they are from Linaro android git
server.
- Addon projects from Linaro defined by local manifest.
Let me know if I have wrong assumption.
This is important because the member is from PRC. It's very easy
to hit network issue when we download the source from Linaro android
git server.
If my understanding is correct, we could suggest a temporary
workaround to member that they download the base android src from
Google AOSP server. And download addon projects from Linaro server.
3. I noticed there is a directory named "android-patchset" which
includeds some additional patches. But it looks like LCR doesn't
apply them. I checked two place:
- linaro_android_build_cmds.sh. It exports PATCHSETS. But doesn't
use it.
- bionic revision in pinned-manifest.xml and the snapshot of AOSP.
They are exactly same. So no additional patch applied on bionic
when android-patchset has bionic patch
Did I miss something here?
Regards
Yin, Fengwei
hi all,
i'm porting the mali driver on the latest linux kernel. but it cannot work.
firstly, i thought maybe i should check that the preprocessor output be the same under different linux kernel verison.
as gcc could use the -E options to get the preprocess output.
after reading in the Document/kbuild/kbuild.txt, modules.txt.
KCPPFLAGS=-E was set in the KDIR/Makefile, but the preprocessors output couldn't get in the *.o.
is that right?
or is there any quick way to get the preprocessor output.
thanks a lot.
