date:20130627

Re: Test Result summary of 13.06 release for Linaro android Jellybean 4.2.2

2013-06-27 Thread Soumya Basak

On 27 June 2013 18:45, Soumya Basak  wrote:
> Linaro-android 13.06 Release (Calendar Week 26 2013):  Here is the
> test result summary for Linaro Android Jellybean 4.2.2 on following
> boards.
>
>
> [1] TI-Panda 4460;
>
> [2] TI-Panda 4430;
>
> [3] ST Ericsson Snowball.
>
> [4]  ARM Versatile Express A9;
>
> [5] Galaxy Nexus;
>
> [6] Samsung Arndale;
>
>
> [1] TI-Panda 4460 with Linaro Linaro Android Jellybean 4.2.2 (Column: AQ)
>
>
> https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadGVWd3pZazdaRUU0MnRnWmgwbVhTR0E#gid=18
>
>
> toolchain version is upgraded to 4.8-2013.06-0~dev.
>
> Please refer to the result spreadsheet for details.
>
>
> [2] TI-Panda 4460 with Linaro Linaro Android Jellybean 4.2.2 (Column: AQ)
>
>
> https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadGVWd3pZazdaRUU0MnRnWmgwbVhTR0E#gid=17
>
>
> [3] ST-Erricsson Snowball with Linaro android Jellybean 4.2.2 (Column: AP)
>
>
> https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadEF1NXVhT3dQWnZsTHBydnpiWVB4Umc#gid=5
>
>
> toolchain version is upgraded to 4.7-2013.06-1 ,
>
> please refer to the result spreadsheet for details.
>
>
> [4] ARM Versatile Express A9 with Linaro android Jellybean 4.2.2 (Column: AQ)
>
>
> https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadExQdHNxTnR5SFZCQzJnN1ZtQ2ZhWkE#gid=5
>
>
> toolchain version is: 4.8-2013.06-0~dev, kernel version:
> 3.10.0-rc6-00192-gb660da8,
>
> Please refer to the result spreadsheet for details.
>
>
> [5] Galaxy_nexus with linaro android Jellybean 4.2.2 (Column: C)
>
>
> https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AuNOCeo15fRHdFhheFZrdk9GNm9RN2FpMHVaSHREX1E#gid=0
>
>
> [6] Samsung Arndale with Linaro android Jellybean 4.2 (Column: C)
>
>
> https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AuNOCeo15fRHdDFaRmJkWHdNVURtemZObnBWb0tleEE#gid=0
>
>
> toolchain version : 4.8-2013.06-0~dev.
>
> please refer to the result spreadsheet for details.


CTS test result on Lava Dashboard For Linaro Android Builds


as monitor from Lava Dashboard daily builds of linux- Linaro-android for Panda

http://validation.linaro.org/lava-server/dashboard/image-reports/linaro-android-member-ti_panda-linaro


the defined test cases CTS test results: 2749/2942 Passes.

from the cts test result bundles observed:

http://validation.linaro.org/lava-server/dashboard/streams/private/team/linaro/android-daily/bundles/d87a105666574cdbf3593a5e86fb98c1addfa3df/c50af0ae-55ce-4bc0-aa6c-425b3b136e50/
>
> Thank You!
>
> Best Regards
> Soumya Basak.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] android-build.linaro.org upgrade to Linaro Login Service - complete

2013-06-27 Thread Paul Sokolovsky

Hello,

After couple of iterations, android-build.linaro.org was updated to
authenticate against Linaro Login system. Please use your
login.linaro.org username (with @linaro.org suffix) and password to
login from now on. Personal jobs were also renamed to have 
firstname.lastname prefix instead of Launchpad username. If you cannot
see your jobs, please contact me to check their state.

Below is interim progress report for completeness.

Thanks,
Paul

Begin forwarded message:

Date: Wed, 26 Jun 2013 22:43:07 +0300
From: Paul Sokolovsky 
To: Paul Sokolovsky 
Cc: linaro-android , Infrastructure
, Linaro Validation
, Philip Colmer
 Subject: Re: [ANN] android-build.linaro.org
upgrade to Linaro Login Service

Hello,

On Wed, 26 Jun 2013 15:46:50 +0300
Paul Sokolovsky  wrote:

> Hello,
> 
> With Android releases out, I'd like to proceed with switchover of
> Android Build frontend authenticaton to Linaro Login. Estimated
> downtime is 2hrs. To minimize impact, I'm scheduling this for later
> evening UTC (around 8pm UTC). Let me know if you need access to a-b
> at that time (otherwise, upgrade is OKed by Vishal).

Upgrade went well, except that now it's not possible to create personal
builds. That's because login username is used to form created job
name, and with Linaro Login, username is first.l...@linaro.org - that's
not valid as part of job name, and besides that, it's too long. Even if
I adhocly remapped it to first-last, it's still too long, and still
would required boring renaming of existing jobs.

Atlassian Crowd supports login aliases, Philip mentioned that it's
possible to create one, but I skipped doing that just for me, hoping
that it would be offered for all folks as part of git migration or
something, but that didn't happen. Well, I guess it's time to raise
that request now - going submit ITS ticket for this.

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Planned maintenance for review.android.git.linaro.org, Saturday 29th June

2013-06-27 Thread Philip Colmer

This is to announce a small maintenance window for
review.android.git.linaro.org where we will remove support for
authentication via Launchpad, and only allow authentication via Linaro
Login. As a result, you will not be required to enter the long OpenID URL
that you have had to use since we migrated the server.

The work will take place during Saturday morning and another email will be
sent when the work has been completed.

Regards

Philip
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Test Result Summary of Linaro openembedded 13.06 release

2013-06-27 Thread Soumya Basak

Linaro 13.06 Release (Calendar Week 26 2013): Here is the test result
summary for 13.06 release Linaro openembedded images.

[1] Linaro openembedded Minimal images (Column: Y)

https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AgB-fT5LL31CdDhwRFBoQ0NZODFFbUsxSHRKUjhBeGc#gid=2

please refer to the result spreadsheet.

[2] Linaro openembedded Lamp images (Column: Y)

https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AgB-fT5LL31CdDhwRFBoQ0NZODFFbUsxSHRKUjhBeGc#gid=1

please refer to the result spreadsheet.

Thank You.

Best Regards
Soumya Basak.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Test Result summary of 13.06 release for Linaro android Jellybean 4.2.2

2013-06-27 Thread Soumya Basak

Linaro-android 13.06 Release (Calendar Week 26 2013):  Here is the
test result summary for Linaro Android Jellybean 4.2.2 on following
boards.


[1] TI-Panda 4460;

[2] TI-Panda 4430;

[3] ST Ericsson Snowball.

[4]  ARM Versatile Express A9;

[5] Galaxy Nexus;

[6] Samsung Arndale;


[1] TI-Panda 4460 with Linaro Linaro Android Jellybean 4.2.2 (Column: AQ)


https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadGVWd3pZazdaRUU0MnRnWmgwbVhTR0E#gid=18


toolchain version is upgraded to 4.8-2013.06-0~dev.

Please refer to the result spreadsheet for details.


[2] TI-Panda 4460 with Linaro Linaro Android Jellybean 4.2.2 (Column: AQ)


https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadGVWd3pZazdaRUU0MnRnWmgwbVhTR0E#gid=17


[3] ST-Erricsson Snowball with Linaro android Jellybean 4.2.2 (Column: AP)


https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadEF1NXVhT3dQWnZsTHBydnpiWVB4Umc#gid=5


toolchain version is upgraded to 4.7-2013.06-1 ,

please refer to the result spreadsheet for details.


[4] ARM Versatile Express A9 with Linaro android Jellybean 4.2.2 (Column: AQ)


https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AkxwyUNxNaAadExQdHNxTnR5SFZCQzJnN1ZtQ2ZhWkE#gid=5


toolchain version is: 4.8-2013.06-0~dev, kernel version:
3.10.0-rc6-00192-gb660da8,

Please refer to the result spreadsheet for details.


[5] Galaxy_nexus with linaro android Jellybean 4.2.2 (Column: C)


https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AuNOCeo15fRHdFhheFZrdk9GNm9RN2FpMHVaSHREX1E#gid=0


[6] Samsung Arndale with Linaro android Jellybean 4.2 (Column: C)


https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AuNOCeo15fRHdDFaRmJkWHdNVURtemZObnBWb0tleEE#gid=0


toolchain version : 4.8-2013.06-0~dev.

please refer to the result spreadsheet for details.

Thank You!

Best Regards
Soumya Basak.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: One HMP issue over TC2

2013-06-27 Thread Lei Wen

After I further disable CONFIG_DISABLE_CPU_SCHED_DOMAIN_BALANCE option,
seems things get better now. And thread now could be distributed
across the cluster.

One more question here, seems it is interesting to see that when A7
and A15 both are
running at same frequency, their calculation capacity seems the same,
which is proved
by this fixed loaded test case.

Is there anyone has any idea why it could happen?
Shouldn't A15's calculation power is stronger than A7? Then why the
fixed load program
would be finished with same time for both CPU?

Thanks,
Lei

On Thu, Jun 27, 2013 at 5:38 PM, Lei Wen  wrote:
> Sorry for inconvenience, as my bad mail editor...
> Change the mail subject to the corrected one
>
> On Thu, Jun 27, 2013 at 5:34 PM, Lei Wen  wrote:
>> Hi Morten and list,
>>
>> I am current investigating HMP related stuff over TC2 platform, and
>> find a strange issue.
>> Here I have two module, both are creating fixed loaded thread, but one
>> module would
>> bound those thread to the cpu, while another don't do the bound operation.
>>
>> [I test with linaro 2013.05 release to get below result]
>> With setting A7/A15 to the same frequency, 1G,
>> The result is:
>> Bounded one:
>> Five thread finished with 137s/137s/137s/138s/138s
>>
>> unbounded one(With HMP related configuration enabled, which is the default 
>> one):
>> Five thread finished with 138s/275s/275s/275s/275s
>>
>> unbounded one(With HMP related configuration disabled):
>> Five thread finished with 228s/229s/229s/229s/231s
>>
>> So it seems to me, that current configuration don't make TC2 to run in
>> its full performance.
>> It worries me for it may downgrade the benchmark for somehow.
>>
>> I haven't see into details, just post the result here to get your
>> guys' feedback.
>> While I get more detailed analysis, I would also post it here.
>>
>> Thanks,
>> Lei

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

One HMP issue over TC2

2013-06-27 Thread Lei Wen

Sorry for inconvenience, as my bad mail editor...
Change the mail subject to the corrected one

On Thu, Jun 27, 2013 at 5:34 PM, Lei Wen  wrote:
> Hi Morten and list,
>
> I am current investigating HMP related stuff over TC2 platform, and
> find a strange issue.
> Here I have two module, both are creating fixed loaded thread, but one
> module would
> bound those thread to the cpu, while another don't do the bound operation.
>
> [I test with linaro 2013.05 release to get below result]
> With setting A7/A15 to the same frequency, 1G,
> The result is:
> Bounded one:
> Five thread finished with 137s/137s/137s/138s/138s
>
> unbounded one(With HMP related configuration enabled, which is the default 
> one):
> Five thread finished with 138s/275s/275s/275s/275s
>
> unbounded one(With HMP related configuration disabled):
> Five thread finished with 228s/229s/229s/229s/231s
>
> So it seems to me, that current configuration don't make TC2 to run in
> its full performance.
> It worries me for it may downgrade the benchmark for somehow.
>
> I haven't see into details, just post the result here to get your
> guys' feedback.
> While I get more detailed analysis, I would also post it here.
>
> Thanks,
> Lei
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define LOOP_NUM	0x100
#define REPEAT_NUM	0x2000
static int busy_loop_test(void *data)
{
	int i, n = (int)data, j;
	struct timeval tv0, tv1;
	long us;
	unsigned long lpj;

	j = 0;
	do_gettimeofday(&tv0);
repeat:
	for (i = 0; i < LOOP_NUM; i ++)
		cpu_relax();
	schedule();
	if (j ++ < REPEAT_NUM)
		goto repeat;

	do_gettimeofday(&tv1);

	us = tv1.tv_usec - tv0.tv_usec;
	us += (tv1.tv_sec - tv0.tv_sec) * 100;
	printk("thread%d(%d) finish with time %d us (%d:%d)\n", n, smp_processor_id(),
			us, tv1.tv_sec - tv0.tv_sec,
			tv1.tv_usec- tv0.tv_usec);

	return 0;
}

#define THREAD_NUM	5
static int __init sched_test_init(void)
{
	struct task_struct *t;
	struct dentry *file;
	struct task_struct *p[THREAD_NUM];
	int i;

	for (i = 0; i < THREAD_NUM; i ++) {
		p[i] = kthread_create_on_node(busy_loop_test,
i,
cpu_to_node(i),
"busy_loop/%d", i);
		get_task_struct(p[i]);
		kthread_bind(p[i], i);
	}

	for (i = 0; i < THREAD_NUM; i ++)
		wake_up_process(p[i]);

	return 0;
}

static void __exit sched_test_exit(void)
{
}

module_init(sched_test_init);
module_exit(sched_test_exit);
MODULE_LICENSE("GPL");

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define LOOP_NUM	0x100
#define REPEAT_NUM	0x2000
static int busy_loop_test(void *data)
{
	int i, n = (int)data, j;
	struct timeval tv0, tv1;
	long us;
	unsigned long lpj;

	j = 0;
	do_gettimeofday(&tv0);
repeat:
	for (i = 0; i < LOOP_NUM; i ++)
		cpu_relax();
	schedule();
	if (j ++ < REPEAT_NUM)
		goto repeat;

	do_gettimeofday(&tv1);

	us = tv1.tv_usec - tv0.tv_usec;
	us += (tv1.tv_sec - tv0.tv_sec) * 100;
	printk("thread%d(%d) finish with time %d us (%d:%d)\n", n, smp_processor_id(),
			us, tv1.tv_sec - tv0.tv_sec,
			tv1.tv_usec- tv0.tv_usec);

	return 0;
}

#define THREAD_NUM	5
static int __init sched_test_init(void)
{
	struct task_struct *t;
	struct dentry *file;
	struct task_struct *p[THREAD_NUM];
	int i;

	for (i = 0; i < THREAD_NUM; i ++) {
		p[i] = kthread_create_on_node(busy_loop_test,
i,
-1,
"busy_loop/%d", i);
		get_task_struct(p[i]);
	}

	for (i = 0; i < THREAD_NUM; i ++)
		wake_up_process(p[i]);

	return 0;
}

static void __exit sched_test_exit(void)
{
}

module_init(sched_test_init);
module_exit(sched_test_exit);
MODULE_LICENSE("GPL");

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

cx...@marvell.com, wwan...@marvell.com, yta...@marvell.com, lei...@marvell.com

2013-06-27 Thread Lei Wen

Hi Morten and list,

I am current investigating HMP related stuff over TC2 platform, and
find a strange issue.
Here I have two module, both are creating fixed loaded thread, but one
module would
bound those thread to the cpu, while another don't do the bound operation.

[I test with linaro 2013.05 release to get below result]
With setting A7/A15 to the same frequency, 1G,
The result is:
Bounded one:
Five thread finished with 137s/137s/137s/138s/138s

unbounded one(With HMP related configuration enabled, which is the default one):
Five thread finished with 138s/275s/275s/275s/275s

unbounded one(With HMP related configuration disabled):
Five thread finished with 228s/229s/229s/229s/231s

So it seems to me, that current configuration don't make TC2 to run in
its full performance.
It worries me for it may downgrade the benchmark for somehow.

I haven't see into details, just post the result here to get your
guys' feedback.
While I get more detailed analysis, I would also post it here.

Thanks,
Lei
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define LOOP_NUM	0x100
#define REPEAT_NUM	0x2000
static int busy_loop_test(void *data)
{
	int i, n = (int)data, j;
	struct timeval tv0, tv1;
	long us;
	unsigned long lpj;

	j = 0;
	do_gettimeofday(&tv0);
repeat:
	for (i = 0; i < LOOP_NUM; i ++)
		cpu_relax();
	schedule();
	if (j ++ < REPEAT_NUM)
		goto repeat;

	do_gettimeofday(&tv1);

	us = tv1.tv_usec - tv0.tv_usec;
	us += (tv1.tv_sec - tv0.tv_sec) * 100;
	printk("thread%d(%d) finish with time %d us (%d:%d)\n", n, smp_processor_id(),
			us, tv1.tv_sec - tv0.tv_sec,
			tv1.tv_usec- tv0.tv_usec);

	return 0;
}

#define THREAD_NUM	5
static int __init sched_test_init(void)
{
	struct task_struct *t;
	struct dentry *file;
	struct task_struct *p[THREAD_NUM];
	int i;

	for (i = 0; i < THREAD_NUM; i ++) {
		p[i] = kthread_create_on_node(busy_loop_test,
i,
cpu_to_node(i),
"busy_loop/%d", i);
		get_task_struct(p[i]);
		kthread_bind(p[i], i);
	}

	for (i = 0; i < THREAD_NUM; i ++)
		wake_up_process(p[i]);

	return 0;
}

static void __exit sched_test_exit(void)
{
}

module_init(sched_test_init);
module_exit(sched_test_exit);
MODULE_LICENSE("GPL");

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define LOOP_NUM	0x100
#define REPEAT_NUM	0x2000
static int busy_loop_test(void *data)
{
	int i, n = (int)data, j;
	struct timeval tv0, tv1;
	long us;
	unsigned long lpj;

	j = 0;
	do_gettimeofday(&tv0);
repeat:
	for (i = 0; i < LOOP_NUM; i ++)
		cpu_relax();
	schedule();
	if (j ++ < REPEAT_NUM)
		goto repeat;

	do_gettimeofday(&tv1);

	us = tv1.tv_usec - tv0.tv_usec;
	us += (tv1.tv_sec - tv0.tv_sec) * 100;
	printk("thread%d(%d) finish with time %d us (%d:%d)\n", n, smp_processor_id(),
			us, tv1.tv_sec - tv0.tv_sec,
			tv1.tv_usec- tv0.tv_usec);

	return 0;
}

#define THREAD_NUM	5
static int __init sched_test_init(void)
{
	struct task_struct *t;
	struct dentry *file;
	struct task_struct *p[THREAD_NUM];
	int i;

	for (i = 0; i < THREAD_NUM; i ++) {
		p[i] = kthread_create_on_node(busy_loop_test,
i,
-1,
"busy_loop/%d", i);
		get_task_struct(p[i]);
	}

	for (i = 0; i < THREAD_NUM; i ++)
		wake_up_process(p[i]);

	return 0;
}

static void __exit sched_test_exit(void)
{
}

module_init(sched_test_init);
module_exit(sched_test_exit);
MODULE_LICENSE("GPL");

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

sched: Load-balancing within HMP domain in the HMP scheduler

2013-06-27 Thread J


Hi.

I have been trying to apply Linaro's HMP scheduler to a big.LITTLE
machine, which has 4 big and 4 LITTLE cores.
However, I could only utilize two cores with the HMP scheduler.

While hmp_select_faster_cpu() always selects the first core in the big
cluster and hmp_select_slower_cpu() always selects the first core in the
LITTLE cluster, I found that my kernel with the HMP scheduler does no
load-balancing at all within each HMP domain(big/LITTLE cluster).

The function rebalance_domains() does almost nothing, because
SD_LOAD_BALANCE flags for the sched_domains are always false.
It's the same in select_task_rq_fair().

I'm wondering if this is normal, although I believe it shouldn't be.
If it's not, how can I get the HMP scheduler to perform load-balancing
within an HMP domain?
What might I be doing wrong here?

Thanks.


- Antonio



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: sched: Load-balancing within HMP domain in the HMP scheduler

2013-06-27 Thread Viresh Kumar

Adding its author in cc.

On 27 June 2013 14:16, J  wrote:
>
> Hi.
>
> I have been trying to apply Linaro's HMP scheduler to a big.LITTLE
> machine, which has 4 big and 4 LITTLE cores.
> However, I could only utilize two cores with the HMP scheduler.
>
> While hmp_select_faster_cpu() always selects the first core in the big
> cluster and hmp_select_slower_cpu() always selects the first core in the
> LITTLE cluster, I found that my kernel with the HMP scheduler does no
> load-balancing at all within each HMP domain(big/LITTLE cluster).
>
> The function rebalance_domains() does almost nothing, because
> SD_LOAD_BALANCE flags for the sched_domains are always false.
> It's the same in select_task_rq_fair().
>
> I'm wondering if this is normal, although I believe it shouldn't be.
> If it's not, how can I get the HMP scheduler to perform load-balancing
> within an HMP domain?
> What might I be doing wrong here?
>
> Thanks.
>
>
> - Antonio
>
>
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Perf test giving strange results

2013-06-27 Thread Milosz Wasilewski

On 26 June 2013 11:42, Andy Green  wrote:
> On 26 June 2013 17:57, Milosz Wasilewski  wrote:
>> On 26 June 2013 09:16, Andy Green  wrote:
>
> Hi Milosz -
>
>>> test 5 (parse event tests) seems to be badly broken.
>>>
>>> Is this just our problem or is it broken for everyone?
>>
>> I'm not sure if the reason is the same but this test was broken in
>> LAVA for some time now. The latest result on 3.10.0-1-linaro-omap
>> kernel looks like this:
>>
>> perf test - parse events tests
>> :Can't open event dir : No such file or directory
>> Can't open event dir : No such file or directory
>> Warning : function scsi_trace_parse_cdb not defined
>> Warning : function scsi_trace_parse_cdb not defined
>> Warning : function scsi_trace_parse_cdb not defined
>> Warning : function scsi_trace_parse_cdb not defined
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : function jiffies_to_msecs not defined
>> Warning : function jiffies_to_msecs not defined
>> Warning : bad op token {
>> Warning : bad op token {
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : Error : expected type 4 but read 0
>> Warning : bad op token {
>> Warning : bad op token {
>> Warning : bad op token {
>> Warning : bad op token {
>> Warning : bad op token {
>> Warning : unknown op '{'
>> Warning : unknown op '{'
>> FAIL
>
> Thanks.
>
> I guess it is simply broken upstream, or we missed a point somewhere.
>
> Llct does have one patch compared to vanilla 3.10-rc6 but that's it
>
> diff --git a/tools/perf/config/utilities.mak b/tools/perf/config/utilities.mak
> index 8ef3bd3..3e89719 100644
> --- a/tools/perf/config/utilities.mak
> +++ b/tools/perf/config/utilities.mak
> @@ -173,7 +173,7 @@ _ge-abspath = $(if $(is-executable),$(1))
>  # Usage: absolute-executable-path-or-empty = $(call
> get-executable-or-default,variable,default)
>  #
>  define get-executable-or-default
> -$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2),$(1)))
> +$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2)))
>  endef
>  _ge_attempt = $(if
> $(get-executable),$(get-executable),$(_gea_warn)$(call _gea_err,$(2)))
>  _gea_warn = $(warning The path '$(1)' is not executable.)
>
>
> What's the plan for tests that are in Lava that are themselves
> partially broken?  We should snip or force the results, patch to turn
> off those tests?

I don't think it is a good idea to disable tests that are broken. I
would rather see them fixed. There are more test cases run in LAVA
that fail due to different reasons.

milosz

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Test Result summary of 13.06 release for Linaro android Jellybean 4.2.2

[ANN] android-build.linaro.org upgrade to Linaro Login Service - complete

Planned maintenance for review.android.git.linaro.org, Saturday 29th June

Test Result Summary of Linaro openembedded 13.06 release

Test Result summary of 13.06 release for Linaro android Jellybean 4.2.2

Re: One HMP issue over TC2

One HMP issue over TC2

cx...@marvell.com, wwan...@marvell.com, yta...@marvell.com, lei...@marvell.com

sched: Load-balancing within HMP domain in the HMP scheduler

Re: sched: Load-balancing within HMP domain in the HMP scheduler

Re: Perf test giving strange results

11 matches

Site Navigation

Mail list logo

Footer information