Re: [ANN] Reminder about recommended Linaro git access procedure

[John Stultz]

On Mon, Sep 8, 2014 at 8:52 AM, Andy Doan  wrote:
> On 08/29/2014 02:57 PM, John Stultz wrote:
>> One more point of concern here. For all the git URLs that I have that
>> use http (kernel.org as well as Google's Android urls), its actually
>> https they're using. Maybe shouldn't we be using https: for these urls
>> as well?
>
> Hey John,
>
> Sorry it took so long, but I've now updated git.linaro.org to advertise
> HTTPS.

Awesome! This makes me feel much better! I'll ping the 0day build
robot to get the URLs updated.

thanks
-john

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

Re: [ANN] Reminder about recommended Linaro git access procedure

[John Stultz]

On Fri, Aug 29, 2014 at 7:57 AM, Andy Doan  wrote:
> On 08/28/2014 11:30 PM, John Stultz wrote:
>> On Thu, Aug 28, 2014 at 2:51 PM, Paul Sokolovsky
>>  wrote:
>
>>> The case we have with git:// is that small number of users can hog
>>> almost all resources of a server. This can happen at release time and
>>> block work of Linaro engineers, something like that happened this time.
>>
>> Do we have a sense of who those users (IPs? which tree they are pulling?) 
>> are?
>
> It appears to have been one IP address for both "attacks". (I use that
> term loosely because they may not have known they were causing this).
>
> Around 5UTC this morning I noticed the same user was causing a small
> resource spike again. They were limiting themselves to about 4-5
> concurrent connections, which the server had no problems with. The 2
> trees being cloned were linux-linaro-tracking.git and your android.git.

Interesting to hear the android.git tree is part of it. Will ping the
few folks I know who pull regularly.


> This makes me think the use has no ill-intentions, they just want to
> clone a bunch of code at the same time.
>
>> Also I think continuing discussion w/ the kernel.org folks to
>> understand their infrastructure would be good. They really started
>> taking things seriously after their compromise, and it would be good
>> for us to learn from their experience and take things similarly
>> seriously before any such problems arise for us.
>
> +1 on that

One more point of concern here. For all the git URLs that I have that
use http (kernel.org as well as Google's Android urls), its actually
https they're using. Maybe shouldn't we be using https: for these urls
as well?

thanks
-john

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

Re: [ANN] Reminder about recommended Linaro git access procedure

[John Stultz]

On Thu, Aug 28, 2014 at 2:51 PM, Paul Sokolovsky
 wrote:
> On Thu, 28 Aug 2014 10:28:06 -0700
> John Stultz  wrote:
>
>> On Thu, Aug 28, 2014 at 10:05 AM, Paul Sokolovsky
>>  wrote:
>> So this is problematic, because there are folks out there in the
>> community who already use the git:// urls for fetching work from the
>> Linaro repos. (The 0day build/test bot, for instance..).
>
> So, it would be nice if they updated to use http://. We actually can be
> proactive and contact them regarding this change (we could use your
> help with that, or just with compiling list of parties who should
> be contacted).

Well, I can try to ping the users I know of, but the problematic spot
is users I am not aware of.


>> We already went through one painful transition where our URLs got
>> scrambled, and I've had a few situations where folks have just
>> recently realized that we still had trees, but the URLs were just
>> different. So its quite frustrating to have to go through that again.
>
> I'm not sure which transition you mean, but the matter of deprecating

So moving from what we had before to gitolite broke the git URLs that
existed previously. I know folks tried to add compatibility urls, but
those URLs were slightly different then what we had previously. So
folks who were pulling regularly from our tree just stopped being able
to connect and get any updates.

> git:// and switching to http:// indeed comes not the first time. And
> previous time there were conservative (or skeptic) responses too, which
> made transition be far complete, and now we need to approach the
> same matter again, instead of having done it once and for all.
>
> But otherwise, the world is dynamic place and changes all the time. For
> example, in the summer 2011 aforementioned kernel.org was down for
> unbelievable 1.5 months, and what, people coped. But we're not going to
> do it like kernel.org and go down, but instead going to start as
> seamless as possible transition (I hope you didn't get any other idea
> from this mail). Just for that, we need some help of the users, first
> of all, internal users, as about their access and its stability we care
> the most.

Ok. I appreciate the transition. I was worried git:// url access was
about to be turned off.


>> If we reduce the
>> git:// url load on the wort users, would that improve things enough?
>> Do you have stats on which trees are hardest hit?
>
> The case we have with git:// is that small number of users can hog
> almost all resources of a server. This can happen at release time and
> block work of Linaro engineers, something like that happened this time.

Do we have a sense of who those users (IPs? which tree they are pulling?) are?

>> > (*1) Unsupported in the current context means that "git://" URLs are
>> > not published in up-to-date information, and there's no warranty
>> > that any 3rd party will be able to complete a clone successfully
>> > using this protocol.
>>
>> So as someone who has sent git pull requests in the past with the git
>> urls, this is terrifying (and makes me hesitant to further use the
>> linaro infrastructure). Do you have a pointer to why the git urls
>> aren't coherent?
>
> Oh, I'm sorry for leaving ambiguity for such interpretation. I just
> meant that we are going to serve git:// to 3rd-party users on "best
> effort" basis, and apply measures to give priority to internal users.
> For example, if there's important build doing fetch, and an external
> user makes 5 (or maybe just 2) git:// connections, they may get
> connection reset. Note that this does not change status quo - for
> example, 2 days ago, *any* user who tried to connect was getting
> connection refused.

Ok. I was worried you were claiming that the git:// url might serve
different (possibly stale) data then the https:// urls. If I was
making a pull request and someone only got half of the commits, that
would be a major infrastructure trust issue.

If its just the connections would be slow or refused, that's enough to
bother folks but not something that would make folks think or worry
our infrastructure was compromised.


> So, kernel.org being down for 1.5 months is terrifying. Myself trying
> to build OABI toolchain and seeing all support being removed from
> everywhere, and finding aligned historical releases of toolchain
> parts almost impossible (while OABI hardware is still in use!) - that's
> terrifying. But I don't see anything terrifying with being frank
> about our git access policies and giving users a choice - either get
> reliable service with http:// or "best effort" with git://.

So yea, kernel.org being down (and some git 

Re: [ANN] Reminder about recommended Linaro git access procedure

[John Stultz]

On Thu, Aug 28, 2014 at 10:05 AM, Paul Sokolovsky
 wrote:
> Recently, we had DoS-like episodes on the main Linaro git server,
> http://git.linaro.org , which affected number of Linaro users,
> including users of Gerrit system, http://review.linaro.org .
>
> These episodes were related to unfriendly usage of native protocol,
> git:// (service port 9418). The implementation of this protocol is known
> to be resource-hungry and not scale to many connections and users. The
> issue itself is not new, it is something which affected us in waves
> over last 3 years, and a resolution for which was established a year
> ago, providing 2 HTTP-based protocols (so called "dump" and "smart"
> protocols) as more scalable replacement.
>
> So, this is a gentle reminder that use of git:// protocol by is
> discouraged for Linaro engineers, and completely unsupported(*1) for
> third parties. Based on the analysis and outcome of the current
> DoS-like activity, we may need to make git:// access more limited and
> strict. So, please kindly:


So why does this affect us but not kernel.org?


> 1. Check URLs you use for cloning and updating your local trees. If you
> use "ssh://" or "http(s)://" protocols, you're ok. If you use git://,
> please switch to using http-based protocol instead. In most cases, this
> requires just replacing "git://" schema with "http://";. If in doubt,
> please visit gitweb page for your repositories, which lists all
> supported URLS to clone a repository, e.g.:
> https://git.linaro.org/arm/arm-trusted-firmware.git
>
> 2. If you set up of oversee CI or automated build jobs, please
> audit and apply similar changes to them.

So this is problematic, because there are folks out there in the
community who already use the git:// urls for fetching work from the
Linaro repos. (The 0day build/test bot, for instance..).

While the git:// urls are now off the gitweb (which is good for future
users), this wasn't the case previously.

We already went through one painful transition where our URLs got
scrambled, and I've had a few situations where folks have just
recently realized that we still had trees, but the URLs were just
different. So its quite frustrating to have to go through that again.

What would be required to just make the git:// urls work properly?

Is this mainly an issue with the Android repos? If we reduce the
git:// url load on the wort users, would that improve things enough?
Do you have stats on which trees are hardest hit?


> (*1) Unsupported in the current context means that "git://" URLs are
> not published in up-to-date information, and there's no warranty that
> any 3rd party will be able to complete a clone successfully using this
> protocol.

So as someone who has sent git pull requests in the past with the git
urls, this is terrifying (and makes me hesitant to further use the
linaro infrastructure). Do you have a pointer to why the git urls
aren't coherent?

thanks
-john

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

Re: embedding html into the wiki

[John Stultz]

On 09/03/2013 04:33 PM, Mike Turquette wrote:
> On Tue, Sep 3, 2013 at 2:29 PM, Fathi Boudra  wrote:
>> Hi Mike,
>>
>> On 4 September 2013 00:09, Mike Turquette  wrote:
>>> Hi all,
>>>
>>> I wanted to create a google doc spreadsheet for tracking some team
>>> activity and then embed in iframe for that spreadsheet into the team
>>> wiki page.
>>>
>>> I tried adding something like the following:
>>>
>>> === Project Status ===
>>> {{{#!html
>>> >> src='https://docs.google.com/spreadsheet/pub?key=0Ajx9x7R7ZLSidGVWcVI5YzhWVER5ZDdVbENKcDh1RUE&output=html&widget=true'>
>>> }}}
>>>
>>> Nothing shows up. I decided to try an easier test:
>>>
>>> === Project Status ===
>>> {{{#!html
>>> Hello, world!
>>> }}}
>>>
>>> I can see the "Hello, world!" string, but the bold tags were ignored.
>>>
>>> So is HTML embedding disabled in MoinMoin? Any idea on the best way to 
>>> proceed?
>> > 800, 600)>>
> Thanks for the quick response Fathi! I'm still unable to get this to
> work after trying several variations. Do you have an example in the
> Linaro wiki of iframe usage? Am I supposed to wrap the
> "<>" part up in some other HTML wrapper?

I'm using it here:
https://wiki.linaro.org/WorkingGroups/Kernel/AndroidUpstreaming

thanks
-john


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

Re: embedding html into the wiki

[John Stultz]

On 09/03/2013 02:29 PM, Fathi Boudra wrote:
> Hi Mike,
>
> On 4 September 2013 00:09, Mike Turquette  wrote:
>> Hi all,
>>
>> I wanted to create a google doc spreadsheet for tracking some team
>> activity and then embed in iframe for that spreadsheet into the team
>> wiki page.
>>
>> I tried adding something like the following:
>>
>> === Project Status ===
>> {{{#!html
>> > src='https://docs.google.com/spreadsheet/pub?key=0Ajx9x7R7ZLSidGVWcVI5YzhWVER5ZDdVbENKcDh1RUE&output=html&widget=true'>
>> }}}
>>
>> Nothing shows up. I decided to try an easier test:
>>
>> === Project Status ===
>> {{{#!html
>> Hello, world!
>> }}}
>>
>> I can see the "Hello, world!" string, but the bold tags were ignored.
>>
>> So is HTML embedding disabled in MoinMoin? Any idea on the best way to 
>> proceed?
>  800, 600)>>
Oh wow! Very cool. I've been wanting to do just this and gave up
earlier. Any link to the documentation on what else you can pass to the
IFrame() function? (like disabling scrolling, etc) Googling around I
can't quite seem to find any details on that.

thanks
-john

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

Re: LSK getting started

[John Stultz]

On 08/05/2013 05:24 PM, Andy Green wrote:


2) warning-elimination: android: binder

This seems to be a problem with a patch already upstream

3) warning-elimination: androidization: mm

Problem coming from Androidization patches

[snip]

5) warning-elimination: ion: use size_t-specific format

Introduced in Androidization


Thanks Andy!

I've applied these three to the linaro-fixes/experimental/android-3.10 
branch.


Are you planning on sending #2 above on to lkml/Greg?

thanks
-john

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

Re: Organizing Config Fragments

[John Stultz]

On 08/01/2013 01:30 AM, Ryan Harkin wrote:

Historically, the main reason for us creating the frags was because of
the platforms (eg, Ubuntu) adding lots of config options that weren't
in the defconfig.  The vexpress defconfig has always been broken.  But
over-riding the defconfig with Ubuntu/Android/whatever options was a
bigger bodge than creating fragments.


Yes. Config fragments just allow for a distribution to have a consistent 
config policy for non-hardware specific configs (ie: cgroups, debug 
options, filesystem support, etc) on an array of different architectures 
and hardware platforms.


thanks
-john


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

Re: [PATCH 00/16] Support for per policy instance of Interactive governor

[John Stultz]

On 05/16/2013 09:18 PM, Viresh Kumar wrote:

On 16 May 2013 22:58, John Stultz  wrote:

Do you have a git branch with the queue you just sent Todd available? It
probably would be easiest to just merge that in.

Yes I do have it. It is android-experimental-3.9 based. Can we merge
that simply with linux-linaro or it is required to be rebased of your
tree first?
No, the linaro.android branch is currently a merge branch (I try to 
merge as long as I can before doing rebases as it makes pulling in other 
work much easier.






I might also suggest Andrey merge that branch in directly, as I try to keep
the linaro.android tree aligned as closely as possible with AOSP, and avoid
mixing other functionality into it.

Andrey if you're overloaded, let me know and I'll do a linaro.android +
Viresh's work merge in a separate branch and send you that git url.

I am happy with both. I can keep that branch with me.


Ok.

thanks
-john


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

Re: [PATCH 00/16] Support for per policy instance of Interactive governor

[John Stultz]

On 05/16/2013 02:47 AM, Viresh Kumar wrote:

On 16 May 2013 14:58, Viresh Kumar  wrote:

Hi Todd and others,

If we have a multi-package system, where we have multiple instances of struct
policy (per package), currently we can't have multiple instances of same
governor. i.e. We can't have multiple instances of Interactive governor for
multiple packages.

This is a bottleneck for multicluster system, where we want different packages
to use Interactive governor, but with different tunables.

-xx-

Recently, I have upstreamed this support in 3.10-rc1 for cpufreq core, Ondemand
and Conservative governor. Now is an attempt for Interactive Governor.

I didn't had any clue on what kernel to rebase my patches over as I couldn't
find a 3.10-rc based branch in your tree and so based it on
experimental/android-3.9.

So, this is what this patchset does:
- Backports some important patches from v3.10-rc1/2 to v3.9: First 8 patches
- Added few more supportive patches which might go in rc3: Next 4 patches
- Finally updated Interactive governor: Last 4 patches

Hi John,

We need to push some part of this patchset to coming release of
linux-linaro too.
And probably you are the best guy for doing this. Right?

So, this is what you need to do:
- Fetch latest Interactive governor patches from AOSP, probably 5 patches only.
- Hopefully you will rebase over 3.10-rc2 ?
- Then you can pick last 8 patches from this patchset..


Do you have a git branch with the queue you just sent Todd available? It 
probably would be easiest to just merge that in.


I might also suggest Andrey merge that branch in directly, as I try to 
keep the linaro.android tree aligned as closely as possible with AOSP, 
and avoid mixing other functionality into it.


Andrey if you're overloaded, let me know and I'll do a linaro.android + 
Viresh's work merge in a separate branch and send you that git url.


thanks
-john



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

Re: Mali-ization

[John Stultz]

On 04/13/2013 03:22 AM, Andy Green wrote:

On 13/04/13 09:07, the mail apparently from Andy Green included:


I'm hoping someone else will write the patches ^^  but if not I'll try
to sort something out.


The attached series gets it building cleanly against current llct with 
ION.


Cool. Although the patches look like they are all against the ump 
driver(which I'm not familiar with), as opposed to changes to the ION 
infrastructure itself. So they won't apply to the AOSP trees, and I 
can't send them upstream.


I assume the ump code is part of the out-of-tree mali driver? Looking at 
llct, I don't see a drivers/base/ump directory.


https://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=tree;f=drivers/base;h=cbad2d664fa248ec366430dbd1724b2959ae43ee;hb=refs/heads/linux-linaro-core-tracking

But I'm guessing this is the point of your original mail in this thread: 
we need a mali tree upon which fixes like these can be applied and then 
pulled into llct.


Or even better, can we get the mali devs to publish a repo of their 
latest work (to which fixes like Andy's can be submitted to) which can 
also be pulled into llct?


thanks
-john


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

Re: Mali-ization

[John Stultz]

On 04/12/2013 05:34 PM, Andy Green wrote:

Hi -

At the moment the Mali T624 OOT module sources I have do not build 
against 3.9-rcX / linux-linaro-core-tracking.  A colleague checked it 
and it does build against 3.4.  The problems I saw are around ION 
compatibility but they didn't look tremendously bad.


Any details on what the ION compatibility issues are?



I could work around the problems myself, but it seems to me this might 
be something that Linaro could solve centrally, dealing with it using 
the Androidization model - sync a Linaro repo against code drops 
coming from "upstream", ie, ARM, but keep it always building against 
llct inbetween.  Perhaps even inside llct.


The idea of having a mali-ization tree sounds like a reasonable approach.

That said, if there are any patches against the ION code needed, I'd be 
interested in seeing them. Right now is a particularly good time for 
getting Android dependent patches into AOSP, as linux-linaro isn't very 
far from the latest AOSP branch, and we've had some good success here 
over the last week or so.


thanks
-john


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

Re: [Linaro-QA-Service] [linux-next] Snowball build broken

[John Stultz]

On 04/11/2013 11:28 AM, Naresh Kamboju wrote:

Hi All,

Greetings from Linaro QA services.
We have setup the process of validating Linux on ARM Kernel builds.
One of those ARM targets is Snowball. Snowball build broken log can be
found here

Build Error:

04:48:08   CC  drivers/mfd/ab8500-debugfs.o
04:48:09
/mnt/ci_build/workspace/linux-next/hwpack/snowball/label/precise_hwpack_cloud/drivers/mfd/ab8500-debugfs.c:95:23:
fatal error: mach/irqs.h: No such file or directory
04:48:09 compilation terminated.
04:48:09 make[3]: *** [drivers/mfd/ab8500-debugfs.o] Error 1
04:48:09 make[2]: *** [drivers/mfd] Error 2
04:48:09 make[1]: *** [drivers] Error 2

Code snippet:
--
drivers/mfd/ab8500-debugfs.c

  89 #ifdef CONFIG_DEBUG_FS
   90 #include 
   91 #include 
   92 #endif
   93
   94 /* TODO: this file should not reference IRQ_DB8500_AB8500! */
   95 #include 
   96
   97 static u32 debug_bank;
   98 static u32 debug_address;
   99


First of all, this is very cool output to see! A few thoughts..


It might also be good to get the maintainers of the affected file on cc.

This can be done automatically via:
$ ./scripts/get_maintainer.pl -f drivers/mfd/ab8500-debugfs.c
Srinidhi Kasagar  (maintainer:ARM/Ux500 
ARM AR)

Linus Walleij  (maintainer:ARM/Ux500 ARM ARC...)
Samuel Ortiz  (supporter:MULTIFUNCTION DEV...)
linux-arm-ker...@lists.infradead.org (moderated list:ARM/Ux500 ARM ARC...)
linux-ker...@vger.kernel.org (open list)


You might also be able to pull recent patch authors into the cc as well 
with something like:


$ git log --pretty=%aE drivers/mfda/ab8500-debugfs.c | head -n 3
linus.wall...@linaro.org
philippe.langl...@linaro.org
asho...@stericsson.com


I am a little curious how these automated messages will be received on 
lkml (I don't think I've seen the kbuild test robot output directly on 
lkml). Would cc'ing the linux-next mailing list be better when testing 
linux-next?


Also, I'm sure you see this error caused two almost identical messages. 
Not sure why the messages were slightly different? Regardless, we'll 
want to avoid sending dups to mailing lists.


Overall, great to see this work moving forward!

thanks
-john





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

Re: Issues with merge_config.sh

[John Stultz]

On 04/04/2013 07:53 PM, Viresh Kumar wrote:

On 5 April 2013 07:58, John Stultz  wrote:

On 04/04/2013 06:34 PM, Viresh Kumar wrote:

Everytime i run merge_config.sh even with O=../ option, i have to run

O=../ ?

Hmm.. when we compile kernel we can give O=../output-folder as an
parameter and so image/binaries will be created in ../output-folder..

I believe the same is true for merge_config.sh also, isn't it?


make mrproper to clean other stuff otherwise compilation doesn't succeed
and complains to run make mrproper.

Make mrproper gave this:

viresh@blr-linut-001:$ make mrproper
CLEAN   scripts/basic
CLEAN   scripts/kconfig
CLEAN   include/config
CLEAN   .config


Sorry, still not sure I understand the problem.

Could you send me the config fragments and commands you're using cause
compilation problems?

Try this:

make mrproper
ARCH=arm O=../btc2 scripts/kconfig/merge_config.sh
linaro/configs/linaro-base.conf linaro/configs/vexpress.conf
linaro/configs/ubuntu-minimal.conf
make mrproper

You will still see some files being cleaned up by last make mrproper.


Try:
$ make mrproper
$ ARCH=arm ./scripts/kconfig/merge_config.sh -O ../btc2 
linaro/configs/linaro-base.conf linaro/configs/vexpress.conf 
linaro/configs/ubuntu-minimal.conf

$ make mrproper

I think the problem is the script takes a "-O " argument and 
doesn't use a "O=" environment prefix.


That said, I see the same behavior you describe with:
$make mrproper
$O=../tmp/ make defconfig
$make mrproper

Where as it seems to work as expected with:
$make mrproper
$make O=../tmp/ defconfig
$make mrproper

Let me know if you are still seeing anything differently from me, and 
we'll try to sort it out.


We do still create a tmp file in the build directory, but we clean that 
up ourselves. So it might be worth moving that tmp file to the output 
directory as well (since one might be building in a ro source directory?).


thanks
-john



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

Re: Issues with merge_config.sh

[John Stultz]

On 04/04/2013 06:34 PM, Viresh Kumar wrote:

On 5 April 2013 00:18, John Stultz  wrote:

Yea, I'll push it upstream and send it to Andrey for Linux Linaro. Thanks
for the testing.

There are more problems than this i believe...

Everytime i run merge_config.sh even with O=../ option, i have to run


O=../ ?



make mrproper to clean other stuff otherwise compilation doesn't succeed
and complains to run make mrproper.

Make mrproper gave this:

viresh@blr-linut-001:$ make mrproper
   CLEAN   scripts/basic
   CLEAN   scripts/kconfig
   CLEAN   include/config
   CLEAN   .config


Sorry, still not sure I understand the problem.

Could you send me the config fragments and commands you're using cause 
compilation problems?


thanks
-john




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

Re: Issues with merge_config.sh

[John Stultz]

On 04/03/2013 09:27 PM, Viresh Kumar wrote:

On 3 April 2013 22:53, John Stultz  wrote:

Huh. I'm totally unfamiliar with this.

Looks like when adding support for the -O option, if its not used, we end up
passing -O=. to make, which generates the unnecessary source softlink.

Does the attached patch fix it for you?

Yes it does.. Thanks. And you will be pushing that upstream and
linux-linaro too?
Yea, I'll push it upstream and send it to Andrey for Linux Linaro. 
Thanks for the testing.


thanks
-john


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

Re: Issues with merge_config.sh

[John Stultz]

On 04/03/2013 10:01 AM, Viresh Kumar wrote:

On 3 April 2013 21:41, John Stultz  wrote:

On 04/02/2013 11:26 PM, Viresh Kumar wrote:

Hi John,

I have been struggling since some time "who creates source directory
in my kernel tree"?
And i thought to clean up the mess today and found running
merge_config.sh creates
it.. And it isn't cleaned up even by running make mrproper...

PS: I am not using O=../ option.


I'm not sure I'm following this at all. Could you explain in more detail
whats going on?

My bad...

So whenever i run merge_config.sh with or without O= option, a link called
"source" is created in kernel directory, which points to the kernel directory.
And git status complains about it every time as new directory.

eg:

lrwxrwxrwx   1 viresh arm 59 Apr  3 22:30 source ->
/home/arm/work/kernel/linaro/linux-linaro-big-LITTLE-MP.git/


Huh. I'm totally unfamiliar with this.

Looks like when adding support for the -O option, if its not used, we 
end up passing -O=. to make, which generates the unnecessary source 
softlink.


Does the attached patch fix it for you?

thanks
-john

diff --git a/scripts/kconfig/merge_config.sh b/scripts/kconfig/merge_config.sh
index 05274fc..81b0c61 100755
--- a/scripts/kconfig/merge_config.sh
+++ b/scripts/kconfig/merge_config.sh
@@ -120,10 +120,18 @@ if [ "$MAKE" = "false" ]; then
 	exit
 fi
 
+# If we have an output dir, setup the O= argument, otherwise leave
+# it blank, since O=. will create an unnecessary ./source softlink
+OUTPUT_ARG=""
+if [ "$OUTPUT" != "." ] ; then
+	OUTPUT_ARG="O=$OUTPUT"
+fi
+
+
 # Use the merged file as the starting point for:
 # alldefconfig: Fills in any missing symbols with Kconfig default
 # allnoconfig: Fills in any missing symbols with # CONFIG_* is not set
-make KCONFIG_ALLCONFIG=$TMP_FILE O=$OUTPUT $ALLTARGET
+make KCONFIG_ALLCONFIG=$TMP_FILE $OUTPUT_ARG $ALLTARGET
 
 
 # Check all specified config values took (might have missed-dependency issues)
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Issues with merge_config.sh

[John Stultz]

On 04/02/2013 11:26 PM, Viresh Kumar wrote:

Hi John,

I have been struggling since some time "who creates source directory
in my kernel tree"?
And i thought to clean up the mess today and found running
merge_config.sh creates
it.. And it isn't cleaned up even by running make mrproper...

PS: I am not using O=../ option.


I'm not sure I'm following this at all. Could you explain in more detail 
whats going on?


thanks
-john


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

Re: arm 0-day kernel builders?

[John Stultz]

On 01/20/2013 06:57 AM, Rob Clark wrote:

Btw, not sure if any of you have seen the 0-day kbuild setup that intel has..

https://lists.01.org/mailman/listinfo/kbuild

runs various builds for different archs on every commit with different
configs, randconfig, etc.   And various checks with sparse, smatch,
etc.  Seems kinda useful, and would be a worthwhile goal to get arm
arch to the point of "it just compiles and boots" like x86 is, vs arm
which has a lot higher tendency to be broken if you don't have the
right kernel config, etc.  I guess on x86, they boot test all the
kernels too on VMs.  Perhaps we could go one better with something
tied in to lava?


+1 on this, Rob.

Just about every time I go to bump kernel revisions for the 
linaro.android tree, and actually try to build and boot on a board, I 
regularly hit compile and boot issues.


Although for the boot issues, there's still the hard problem for 
hardware-simpletons like me in being able to figure out what configs I 
actually need to enable (especially as those options change over time). 
I suspect these sorts of problems are unlikely to be something we can 
test away, and instead need a more critical eye as to how the kconfig 
options are added (so there's less of a random set of options that you 
have to pick the right combination, and more of the existing physical 
dependencies being properly stating in the kconfig - but I realize this 
is more complicated to do then say).


thanks
-john


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

Re: When do we plan to move to Linux 3.8?

[John Stultz]

On 01/07/2013 07:24 AM, Jon Medhurst (Tixy) wrote:

I get this compilation error:

arch/arm/mm/cache-l2x0.c: In function 'l2x0_init':
arch/arm/mm/cache-l2x0.c:376:3: error: 'cache_id' undeclared (first use in this 
function)
arch/arm/mm/cache-l2x0.c:376:3: note: each undeclared identifier is reported 
only once for each function it appears in
arch/arm/mm/cache-l2x0.c: At top level:
arch/arm/mm/cache-l2x0.c:38:21: warning: 'l2x0_sets' defined but not used 
[-Wunused-variable]

If I revert Android's cache-l2x0.c change then it builds and boots fine
on vexpress. I'm not sure how to test the Android patches specifically
but I can confirm the interactive governor was running after boot and
the system generally seemed to work as expected.


Yea, *looks* like the PL310 errata 727915  issue fixed in the Android 
commit id: 74b6cdd9573abba116584c08003ee5e87e96ea14  have been fixed 
upstream already.


Reverted that change and pushed the whole thing out here:
git://git.linaro.org/people/jstultz/android.git 
linaro-android-3.8-jstultz-merge


thanks
-john

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

Re: When do we plan to move to Linux 3.8?

[John Stultz]

On 01/07/2013 07:24 AM, Jon Medhurst (Tixy) wrote:

On Fri, 2013-01-04 at 14:06 -0800, John Stultz wrote:

Instead of doing the full re-base, I just merged the 3.8-rc2+ tree into
the linaro-android-3.7-anton-rebase branch, and the collisions were
seemingly manageable.

I've only compile tested on x86_64, since I don't have my cross-tools
setup yet.

If someone has the time to test merge that branch and make sure it
boots, I'd really appreciate it.

I get this compilation error:

arch/arm/mm/cache-l2x0.c: In function 'l2x0_init':
arch/arm/mm/cache-l2x0.c:376:3: error: 'cache_id' undeclared (first use in this 
function)
arch/arm/mm/cache-l2x0.c:376:3: note: each undeclared identifier is reported 
only once for each function it appears in
arch/arm/mm/cache-l2x0.c: At top level:
arch/arm/mm/cache-l2x0.c:38:21: warning: 'l2x0_sets' defined but not used 
[-Wunused-variable]

If I revert Android's cache-l2x0.c change then it builds and boots fine
on vexpress. I'm not sure how to test the Android patches specifically
but I can confirm the interactive governor was running after boot and
the system generally seemed to work as expected.


Great! Thanks for the testing!  I'll revert the change you pointed out 
and will push it out for merging.


-john



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

Re: When do we plan to move to Linux 3.8?

[John Stultz]

On 01/04/2013 12:19 PM, John Stultz wrote:

On 01/04/2013 06:33 AM, Andrey Konovalov wrote:

On 01/04/2013 02:28 PM, Jon Medhurst (Tixy) wrote:

On Fri, 2013-01-04 at 15:14 +0530, Viresh Kumar wrote:

On 4 January 2013 15:09, Jon Medhurst (Tixy)  wrote:
For my part I have prepared a 3.8 branch for vexpress [1] which 
doesn't

yet contain Android patches or bit.LITTLE MP as their respective
branches aren't on 3.8 yet.


big.LITTLE MP is 3.8 based now :)


I take it as the vexpress topic (for the ll tree) and the big.LITTLE 
topic (for the llct tree) are ready to switch to 3.8, correct?


This leaves the Android topic for llct (John?) and Samsung LT topic 
for ll (Tushar?).


I'll take a swing at rebasing/merging the Android tree. Although my 
build box is ordered, but not shipped, so I'm trying to hobble along 
doing git work from my very slow work VM, so I can't promise it will 
happen quickly.

Ok, I've got a first-pass branch here:
git://git.linaro.org/people/jstultz/android.git 
linaro-android-3.8-jstultz-test


Instead of doing the full re-base, I just merged the 3.8-rc2+ tree into 
the linaro-android-3.7-anton-rebase branch, and the collisions were 
seemingly manageable.


I've only compile tested on x86_64, since I don't have my cross-tools 
setup yet.


If someone has the time to test merge that branch and make sure it 
boots, I'd really appreciate it.


thanks
-john




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

Re: When do we plan to move to Linux 3.8?

[John Stultz]

On 01/04/2013 06:33 AM, Andrey Konovalov wrote:

On 01/04/2013 02:28 PM, Jon Medhurst (Tixy) wrote:

On Fri, 2013-01-04 at 15:14 +0530, Viresh Kumar wrote:

On 4 January 2013 15:09, Jon Medhurst (Tixy)  wrote:
For my part I have prepared a 3.8 branch for vexpress [1] which 
doesn't

yet contain Android patches or bit.LITTLE MP as their respective
branches aren't on 3.8 yet.


big.LITTLE MP is 3.8 based now :)


I take it as the vexpress topic (for the ll tree) and the big.LITTLE 
topic (for the llct tree) are ready to switch to 3.8, correct?


This leaves the Android topic for llct (John?) and Samsung LT topic 
for ll (Tushar?).


I'll take a swing at rebasing/merging the Android tree. Although my 
build box is ordered, but not shipped, so I'm trying to hobble along 
doing git work from my very slow work VM, so I can't promise it will 
happen quickly.


That said, as Tixy noted, most of the critical Android support is 
already upstream (and the 4.2 userland is using it), so some Android 
testing could likely be done without the linaro.android tree merged in, 
but it will be missing items like the interactive cpufreq gov, paranoid 
networking, ion, sync, etc.


thanks
-john




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

Re: [GIT PULL] cpufreq-interactive-gov-master-v1

[John Stultz]

On 12/19/2012 06:05 PM, Viresh Kumar wrote:

On 5 December 2012 09:55, John Stultz  wrote:

So while I can try to update the linaro-android tree more frequently,
maintaining that tree is more of a background task. So when my other
commitments consume my attention, sometimes that update frequency is slower.
Also, given we're already 3 releases beyond the AOSP tree, keeping the two
branches in perfect sync is unlikely to happen (due to the higher chance of
collisions).   So if folks notice there is some critical functionality that
is updated in the AOSP tree, when they let me know, I can be sure to merge
it in (like was done with this case - albeit slower then I'd like).

Hi John,

There are few updates of interactive governor available in AOSP 3.4 branch. Can
you please include them?


Sure thing, just merged them in and pushed them out. Let me know if you 
notice anything missing.


thanks!
-john


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

Re: [ANNOUNCE] linux-linaro kernel schedule for 12.12

[John Stultz]

On 12/13/2012 03:53 AM, Tushar Behera wrote:

* Android kernel doesn't compile because of some change in gpu/ion. Even
after adding fixes for compilation errors there is crash during booting,
so didn't push those fixes.

Hey Tushar,
After looking at the issues you pointed out, I've got some 
alternative patches to try to resolve the ION issues.


Would you mind trying them out? I don't have any ion supported hardware 
around, so I'm not able to actually test if they're ok, but they do build.


See the changes here:
http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=refs/heads/tushar-test

Or fetch them here:
git://git.linaro.org/people/jstultz/android.git tushar-test

If they work for you, I'll push them to the Linaro+Android tree.

thanks
-john


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

Re: [ANNOUNCE] linux-linaro kernel schedule for 12.12

[John Stultz]

On 12/13/2012 03:53 AM, Tushar Behera wrote:

* Android kernel doesn't compile because of some change in gpu/ion. Even
after adding fixes for compilation errors there is crash during booting,
so didn't push those fixes.

Tushar:
Sorry about this.  I'll try to take a look at the compilation 
issues today (mind sending me your config?). I've not yet applied the 
patches you sent as I wanted to double check that AOSP didn't have more 
official fixes. Will try to get this sorted here quickly.


thanks
-john


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

Re: [GIT PULL] cpufreq-interactive-gov-master-v1

[John Stultz]

On 12/04/2012 08:10 PM, Viresh Kumar wrote:

On 5 December 2012 06:32, John Stultz  wrote:

Ok, so I've taken the 3.7 rebase tree Anton did while I was on leave and
cherry-picked a number of newer changes from the AOSP/android-3.4 branch.
This should contain the latest AOSP cpufreq-interactive, ion, and sync
drivers.

You can find it here:
git://git.linaro.org/people/jstultz/android.git
linaro-android-3.7-anton-rebase

I've also included fixes from Tushar and Tixy.

Let me know if you notice any other important commits missing from the AOSP
tree and I'll try to cherry-pick those in as well.

Hi John,

I haven't checked your repo till now, but the bigger question which
this thread had
was, how do we ensure that we always have the latest copy of
interactive governor
in linux-linaro tree?
You would like to pick them yourself from AOSP or us to point to that?
Or you can
also pull from the branch i created (which only had interactive
governor patches)?


So while I can try to update the linaro-android tree more frequently, 
maintaining that tree is more of a background task. So when my other 
commitments consume my attention, sometimes that update frequency is 
slower.  Also, given we're already 3 releases beyond the AOSP tree, 
keeping the two branches in perfect sync is unlikely to happen (due to 
the higher chance of collisions).   So if folks notice there is some 
critical functionality that is updated in the AOSP tree, when they let 
me know, I can be sure to merge it in (like was done with this case - 
albeit slower then I'd like).


However, if you're maintaining your own tree anyway, why not have Andrey 
pull your tree in addition to the current linaro-android-3.x-*rebase branch?


Since they are both contain a common subset, the merge will likely be 
quite easy. That way Andrey's tree will have a better chance of having 
the latest changes.


Does that seem ok?

One other option, if someone has the cycles and interest, is that I 
would be fine with handing over the linaro-android tree maintenance 
responsibilities.  If you or anyone else is interested, please send me 
email and we can work it out.


thanks
-john



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

Re: [GIT PULL] cpufreq-interactive-gov-master-v1

[John Stultz]

On 12/04/2012 10:47 AM, John Stultz wrote:

On 12/04/2012 02:39 AM, Amit Kucheria wrote:

Any conclusion to this discussion? I'd really like the latest version
of interactive governor to be carried in all Linaro releases (Android
and Ubuntu). The one from the Android tree isn't the latest.


Sorry, I've been busy with other items and haven't gotten a chance to 
update the lianro-android tree. I'll spend some time today to try to 
resolve this.


Ok, so I've taken the 3.7 rebase tree Anton did while I was on leave and 
cherry-picked a number of newer changes from the AOSP/android-3.4 
branch.  This should contain the latest AOSP cpufreq-interactive, ion, 
and sync drivers.


You can find it here:
git://git.linaro.org/people/jstultz/android.git 
linaro-android-3.7-anton-rebase


I've also included fixes from Tushar and Tixy.

Let me know if you notice any other important commits missing from the 
AOSP tree and I'll try to cherry-pick those in as well.


thanks
-john


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

Re: [PATCH 3/3] netfilter: xt_quota2: Remove extra parameter from netlink_kernel_create

[John Stultz]

On 11/15/2012 01:17 AM, Tushar Behera wrote:

Required as per commit 9f00d9776bc5 ("netlink: hide struct module
parameter in netlink_kernel_create").

Signed-off-by: Tushar Behera 



Thanks! Merged into linaro-android-3.7-anton-rebase.
-john



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

Re: [PATCH 1/3] usb: gadget: android: Fix build error because of removal of usb_gadget_controller_number

[John Stultz]

On 11/15/2012 01:17 AM, Tushar Behera wrote:

Required as per commit ed9cbda ("usb: gadget: remove
usb_gadget_controller_number()").

Signed-off-by: Tushar Behera 


Thanks! Merged into linaro-android-3.7-anton-rebase.
-john


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

Re: [PATCH 2/3] usb: gadget: android: Fix build error because of change in composite driver framework

[John Stultz]

On 11/15/2012 01:17 AM, Tushar Behera wrote:

Signed-off-by: Tushar Behera 
---

Thanks! Merged into linaro-android-3.7-anton-rebase.
-john



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

Re: [PATCH] gpu: ion: Use RB_CLEAR_NODE instead of rb_init_node

[John Stultz]

On 11/15/2012 02:02 AM, Tushar Behera wrote:

rb_init_node() has been removed from the kernel, use alternate macro.

Signed-off-by: Tushar Behera 
---

This patch also needs to go into android-3.7 tree.



Thanks for this. Sorry it took me so long, but I've just now merged this 
into the linaro-android-3.7-anton-rebase branch


thanks
-john


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

Re: [GIT PULL] cpufreq-interactive-gov-master-v1

[John Stultz]

On 12/04/2012 02:39 AM, Amit Kucheria wrote:

On Sat, Dec 1, 2012 at 8:36 AM, Anton Vorontsov
 wrote:

On Fri, Nov 30, 2012 at 05:30:03PM +0400, Andrey Konovalov wrote:
[...]

How do you suggest to solve these issues?

That you, Andrey and
the 'the guy maintaining the Android topic'

Deepak, is that ^^^ John, Anton, or someone else? :)

Same question. :)

I can easily pull branch into my Android git tree on infradead.org, but I
believe this would be not The Right Thing to do, since it was just a
temporary measure.

Thanks,
Anton.

Hey guys,

Any conclusion to this discussion? I'd really like the latest version
of interactive governor to be carried in all Linaro releases (Android
and Ubuntu). The one from the Android tree isn't the latest.


Sorry, I've been busy with other items and haven't gotten a chance to 
update the lianro-android tree. I'll spend some time today to try to 
resolve this.


thanks
-john


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

Re: [PATCH] merge_config.sh: Add option to specify output dir

[John Stultz]

On 12/02/2012 11:36 PM, Zhangfei Gao wrote:

Provide a -O option to specify dir to put generated .config
Then merge_config.sh does not need to be copied to target dir,
for easy re-usage in other script

Signed-off-by: Zhangfei Gao 
Tested-by: Jon Medhurst (Tixy) 

Acked-by: John Stultz 

thanks
-john


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

Re: [PATCH] merge_config.sh: Add option to specify output dir

[John Stultz]

On 11/29/2012 06:04 PM, Zhangfei Gao wrote:

Provide a -O option to specify dir to put generated .config


This looks ok to me, although you might want to add some extra details 
in the commit log as to why this is useful.


And one minor nit below.

thanks
-john


@@ -100,7 +112,7 @@ for MERGE_FILE in $MERGE_LIST ; do
  done

  if [ "$MAKE" = "false" ]; then
-   cp $TMP_FILE .config
+   cp $TMP_FILE $OUTPUT/.config
echo "#"
echo "# merged configuration written to .config (needs make)"

Should this echo have $output/.config?

thanks
-john


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

Re: CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)

[John Stultz]

On 09/10/2012 11:58 PM, Daniel Lezcano wrote:

Would you mind testing the following patch? It seems to resolve the
issue, but I've not yet run it through my test suite to make sure it
didn't break anything else.

No problem, I will try it this evening.

Is this problem related to all 32bits arch ?
I believe so. Although it didn't appear in my 32bit testing w/ kvm, but 
I suspect that is due to my distro userland setting lots of timers so 
that we don't hit those multi-second idle times, which could overflow 
32bit nanoseconds, or maybe some other kvm quirk.


Anyway, let me know if your testing goes well.

Thanks so much again for noticing and bisecting this down.
-john


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

Re: [PATCH 0/2] Android fixes w.r.t. 3.6 kernel

[John Stultz]

On 09/10/2012 10:22 PM, Tushar Behera wrote:

Ping !!!

On 08/31/2012 09:57 AM, Tushar Behera wrote:

Required for android-3.6 tree.

Tushar Behera (2):
   netfilter: xt_quota2: Move away from NLMSG_PUT()
   netfilter: xt_quota2: Update parameter list in netlink_kernel_create

  net/netfilter/xt_quota2.c |   25 -
  1 files changed, 16 insertions(+), 9 deletions(-)


Without these patches, build of LT kernel based on llct(v3.6-rc5) fails
with following error message.


Thanks for the reminder, the patches landed in my mailbox during Linux 
Plumbers, and got buried under a number of other items.
So my apologies. I've applied them and pushed them out to the 
linaro-android-3.6-jstultz-rebase branch.


thanks
-john


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

Re: CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)

[John Stultz]

On 09/10/2012 12:45 PM, Daniel Lezcano wrote:

On 09/10/2012 07:14 PM, John Stultz wrote:

In the meantime, I'll try to reproduce on my T61. If you could send me
your .config, I'd appreciate it.

http://pastebin.com/qSxqfdDK

The header of the config file shows for a v3.5-rc7 because it is the
result of the git-bisect. If you keep this config file for the latest
kernel that should reproduce the problem.

Let me know if you were able to reproduce the problem.
Great! With this I was able to quickly reproduce the problem and I think 
I have a fix.


Would you mind testing the following patch? It seems to resolve the 
issue, but I've not yet run it through my test suite to make sure it 
didn't break anything else.


If both your and my testing comes back ok, I'll submit it to Thomas.

thanks
-john

From f10a285a5b532a14d3330f6e60e4d7bd5627932a Mon Sep 17 00:00:00 2001
From: John Stultz 
Date: Mon, 10 Sep 2012 20:00:15 -0400
Subject: [PATCH] time: Fix timeekeping_get_ns overflow on 32bit systems

Daniel Lezcano reported seeing multi-second stalls from
keyboard input on his T61 laptop when NOHZ and CPU_IDLE
were enabled on a 32bit kernel.

He bisected the problem down to
1e75fa8be9fb61e1af46b5b3b176347a4c958ca1 (time: Condense
timekeeper.xtime into xtime_sec).

After reproducing this issue, I narrowed the problem down
to the fact that timekeeping_get_ns() returns a 64bit
nsec value that hasn't been accumulated. In some cases
this value was being then stored in timespec.tv_nsec
(which is a long).

On 32bit systems, With idle times larger then 4 seconds
(or less, depending on the value of xtime_nsec), the
returned nsec value would overflow 32bits. This limited
kept time from increasing, causing timers to not expire.

The fix is to make sure we don't directly store the
result of timekeeping_get_ns() into a tv_nsec field,
instead using a 64bit nsec value which can then be
added into the timespec via timespec_add_ns().

With this patch I cannot reproduce the issue.

Cc: Ingo Molnar 
Cc: Richard Cochran 
Cc: Prarit Bhargava 
Cc: Thomas Gleixner 
Cc: Daniel Lezcano 
Reported-and-bisected-by: Daniel Lezcano 
Signed-off-by: John Stultz 
---
 kernel/time/timekeeping.c |   19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 34e5eac..d3b91e7 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -303,10 +303,11 @@ void getnstimeofday(struct timespec *ts)
seq = read_seqbegin(&tk->lock);
 
 		ts->tv_sec = tk->xtime_sec;

-   ts->tv_nsec = timekeeping_get_ns(tk);
+   nsecs = timekeeping_get_ns(tk);
 
 	} while (read_seqretry(&tk->lock, seq));
 
+	ts->tv_nsec = 0;

timespec_add_ns(ts, nsecs);
 }
 EXPORT_SYMBOL(getnstimeofday);
@@ -345,6 +346,7 @@ void ktime_get_ts(struct timespec *ts)
 {
struct timekeeper *tk = &timekeeper;
struct timespec tomono;
+   s64 nsec;
unsigned int seq;
 
 	WARN_ON(timekeeping_suspended);

@@ -352,13 +354,14 @@ void ktime_get_ts(struct timespec *ts)
do {
seq = read_seqbegin(&tk->lock);
ts->tv_sec = tk->xtime_sec;
-   ts->tv_nsec = timekeeping_get_ns(tk);
+   nsec = timekeeping_get_ns(tk);
tomono = tk->wall_to_monotonic;
 
 	} while (read_seqretry(&tk->lock, seq));
 
-	set_normalized_timespec(ts, ts->tv_sec + tomono.tv_sec,

-   ts->tv_nsec + tomono.tv_nsec);
+   ts->tv_sec += tomono.tv_sec;
+   ts->tv_nsec = 0;
+   timespec_add_ns(ts, nsec + tomono.tv_nsec);
 }
 EXPORT_SYMBOL_GPL(ktime_get_ts);
 
@@ -1244,6 +1247,7 @@ void get_monotonic_boottime(struct timespec *ts)

 {
struct timekeeper *tk = &timekeeper;
struct timespec tomono, sleep;
+   s64 nsec;
unsigned int seq;
 
 	WARN_ON(timekeeping_suspended);

@@ -1251,14 +1255,15 @@ void get_monotonic_boottime(struct timespec *ts)
do {
seq = read_seqbegin(&tk->lock);
ts->tv_sec = tk->xtime_sec;
-   ts->tv_nsec = timekeeping_get_ns(tk);
+   nsec = timekeeping_get_ns(tk);
tomono = tk->wall_to_monotonic;
sleep = tk->total_sleep_time;
 
 	} while (read_seqretry(&tk->lock, seq));
 
-	set_normalized_timespec(ts, ts->tv_sec + tomono.tv_sec + sleep.tv_sec,

-   ts->tv_nsec + tomono.tv_nsec + sleep.tv_nsec);
+   ts->tv_sec += tomono.tv_sec + sleep.tv_sec;
+   ts->tv_nsec = 0;
+   timespec_add_ns(ts, nsec + tomono.tv_nsec + sleep.tv_nsec);
 }
 EXPORT_SYMBOL_GPL(get_monotonic_boottime);
 
--

1.7.9.5


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

Re: CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)

[John Stultz]

On 09/07/2012 02:35 PM, Daniel Lezcano wrote:

On 09/07/2012 07:22 PM, John Stultz wrote:

On 09/07/2012 07:20 AM, Daniel Lezcano wrote:

On 09/06/2012 11:18 PM, Rafael J. Wysocki wrote:

On Thursday, September 06, 2012, Daniel Lezcano wrote:

On 09/06/2012 10:04 PM, Rafael J. Wysocki wrote:

On Thursday, September 06, 2012, Daniel Lezcano wrote:

On 09/06/2012 09:54 AM, Daniel Lezcano wrote:
I fall into this issue because NETCONSOLE is set, disabling it
allowed
me to go further.

Unfortunately I am facing to some random freeze on the system which
seems to be related to CONFIG_NO_HZ=y and CONFIG_CPU_IDLE=y.

Disabling one of them, make the freezes to disappear.

Is it a known issue ?

Well, there are systems having problems with this configuration,
but they
should be exceptional.  What system is that?

It is a laptop T61p with a Core 2 Duo T9500. Nothing exceptional I
believe. Maybe someone got the same issue ?

Is it a regression for you?

Yes, I think so. The issue appears between v3.5 and v3.6-rc1.

It is not easy to reproduce but after taking some time to dig, it seems
to appear with this commit:

1e75fa8be9fb61e1af46b5b3b176347a4c958ca1 is the first bad commit
commit 1e75fa8be9fb61e1af46b5b3b176347a4c958ca1
Author: John Stultz 
Date:   Fri Jul 13 01:21:53 2012 -0400

  time: Condense timekeeper.xtime into xtime_sec

  The timekeeper struct has a xtime_nsec, which keeps the
  sub-nanosecond remainder.  This ends up being somewhat
  duplicative of the timekeeper.xtime.tv_nsec value, and we
  have to do extra work to keep them apart, copying the full
  nsec portion out and back in over and over.

  This patch simplifies some of the logic by taking the timekeeper
  xtime value and splitting it into timekeeper.xtime_sec and
  reuses the timekeeper.xtime_nsec for the sub-second portion
  (stored in higher res shifted nanoseconds).

  This simplifies some of the accumulation logic. And will
  allow for more accurate timekeeping once the vsyscall code
  is updated to use the shifted nanosecond remainder.

  Signed-off-by: John Stultz 
  Reviewed-by: Ingo Molnar 
  Cc: Peter Zijlstra 
  Cc: Richard Cochran 
  Cc: Prarit Bhargava 
  Link:
http://lkml.kernel.org/r/1342156917-25092-5-git-send-email-john.stu...@linaro.org

  Signed-off-by: Thomas Gleixner 

:04 04 4d6541ac1f6075d7adee1eef494b31a0cbda0934
dc5708bc738af695f092bf822809b13a1da104b6 Mkernel

How to reproduce: with a laptop T61p, with a Core 2 Duo. I boot the
kernel in busybox and wait some minutes before writing something in the
console. At this moment, nothing appears to the console but the
characters are echo'ed several seconds later (could be 1, 5, or 10 secs
or more).

That happens when CONFIG_CPU_IDLE and CONFIG_NO_HZ are set. Disabling
one of them, the issue does not appear.

Thanks for bisecting this down and the heads up!

Right off I can't see what might be causing this.  Bunch of questions:

Is this a 32 or 64 bit kernel?

It is a 32 bit kernel.


Thanks for your answers! Has this has been seen on 3.6-rc4+ kernels? 
There were a few casting fixes that landed in 3.6-rc4 that would affect 
32bit systems.


In the meantime, I'll try to reproduce on my T61. If you could send me 
your .config, I'd appreciate it.


thanks!
-john


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

Re: CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)

[John Stultz]

On 09/07/2012 07:20 AM, Daniel Lezcano wrote:

On 09/06/2012 11:18 PM, Rafael J. Wysocki wrote:

On Thursday, September 06, 2012, Daniel Lezcano wrote:

On 09/06/2012 10:04 PM, Rafael J. Wysocki wrote:

On Thursday, September 06, 2012, Daniel Lezcano wrote:

On 09/06/2012 09:54 AM, Daniel Lezcano wrote:
I fall into this issue because NETCONSOLE is set, disabling it allowed
me to go further.

Unfortunately I am facing to some random freeze on the system which
seems to be related to CONFIG_NO_HZ=y and CONFIG_CPU_IDLE=y.

Disabling one of them, make the freezes to disappear.

Is it a known issue ?

Well, there are systems having problems with this configuration, but they
should be exceptional.  What system is that?

It is a laptop T61p with a Core 2 Duo T9500. Nothing exceptional I
believe. Maybe someone got the same issue ?

Is it a regression for you?

Yes, I think so. The issue appears between v3.5 and v3.6-rc1.

It is not easy to reproduce but after taking some time to dig, it seems
to appear with this commit:

1e75fa8be9fb61e1af46b5b3b176347a4c958ca1 is the first bad commit
commit 1e75fa8be9fb61e1af46b5b3b176347a4c958ca1
Author: John Stultz 
Date:   Fri Jul 13 01:21:53 2012 -0400

 time: Condense timekeeper.xtime into xtime_sec

 The timekeeper struct has a xtime_nsec, which keeps the
 sub-nanosecond remainder.  This ends up being somewhat
 duplicative of the timekeeper.xtime.tv_nsec value, and we
 have to do extra work to keep them apart, copying the full
 nsec portion out and back in over and over.

 This patch simplifies some of the logic by taking the timekeeper
 xtime value and splitting it into timekeeper.xtime_sec and
 reuses the timekeeper.xtime_nsec for the sub-second portion
 (stored in higher res shifted nanoseconds).

 This simplifies some of the accumulation logic. And will
 allow for more accurate timekeeping once the vsyscall code
 is updated to use the shifted nanosecond remainder.

 Signed-off-by: John Stultz 
 Reviewed-by: Ingo Molnar 
 Cc: Peter Zijlstra 
 Cc: Richard Cochran 
 Cc: Prarit Bhargava 
 Link:
http://lkml.kernel.org/r/1342156917-25092-5-git-send-email-john.stu...@linaro.org
 Signed-off-by: Thomas Gleixner 

:04 04 4d6541ac1f6075d7adee1eef494b31a0cbda0934
dc5708bc738af695f092bf822809b13a1da104b6 M  kernel

How to reproduce: with a laptop T61p, with a Core 2 Duo. I boot the
kernel in busybox and wait some minutes before writing something in the
console. At this moment, nothing appears to the console but the
characters are echo'ed several seconds later (could be 1, 5, or 10 secs
or more).

That happens when CONFIG_CPU_IDLE and CONFIG_NO_HZ are set. Disabling
one of them, the issue does not appear.


Thanks for bisecting this down and the heads up!

Right off I can't see what might be causing this.  Bunch of questions:

Is this a 32 or 64 bit kernel?

By your description above, it sounds like the system is still 
functioning, but there's just a high latency for key-input. Is that right?


Are other things on the system happening slowly?

Does generating interrupts by hitting/holding down the ctrl key make the 
system respond faster?


Is there any dmesg output near when it occurs?

If you don't wait that minute after boot before typing anything, does it 
still trigger later? (or is it tied to early boot?)


On a whim, does the patch below avoid the problem?

thanks
-john

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 34e5eac..2fa0e52 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1179,6 +1179,7 @@ static void update_wall_time(void)
timekeeping_adjust(tk, offset);
 
 
+#if 0

/*
* Store only full nanoseconds into xtime_nsec after rounding
* it up and add the remainder to the error difference.
@@ -1192,6 +1193,7 @@ static void update_wall_time(void)
tk->xtime_nsec -= remainder;
tk->xtime_nsec += 1ULL << tk->shift;
tk->ntp_error += remainder << tk->ntp_error_shift;
+#endif
 
 	/*

 * Finally, make sure that after the rounding


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

Re: Call for topic updates and new topics for linux-linaro-core-tracking tree

[John Stultz]

On 08/10/2012 11:57 AM, Andrey Konovalov wrote:

Greetings,

The linux-linaro-core-tracking tree (llct, see 
http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=summary 
for some more details) is planned to be moved to v3.6-rc1 (or v3.6-rc2 
if it is out) early next week.


There will be more updates to llct as long as new -rc's are out.
And this llct tree will be the base for the 12.08 linux-linaro release.

Most of the current llct topics need updating for that:

[snip]

* topic android_jstultz/linaro-android-3.5-jstultz-rebase
  11 conflicts. This has been already discussed with the topic owner.
  We will both work on moving the current topic to v3.6.

I've pushed out a untested fwd port of the android patches here:
git://git.linaro.org/people/jstultz/android.git 
linaro-android-3.6-jstultz-rebase


FYI, this is just a rebase of the 3.5-jstultz-rebase tree, and is 
missing some changes that has since landed in the android-3.4 branch on 
AOSP.


thanks
-john


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

Mumble server having issues?

[John Stultz]

So I've been having trouble with the mumble server and the behavior is 
odd enough that I don't think its a problem just on my end.


I'm seeing cases where:
* Only one of two members in a room can hear me talk
* One member could hear both parties talking
* I can't hear either of them talk

As well as other cases where neither parties can hear each other.

In all the cases, my talk-indicator (the red lips) has been lighting up 
properly, but the other sides isn't (so its not just an audio playback 
issue on my side, my mumble client isn't getting any input from other 
members).


I know Joey's out, but does anyone else have the ability to check in and 
debug the mumble server?


thanks
-john



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

Re: android-3.4 ... / Audit of OOT android code

[John Stultz]

On 06/10/2012 02:53 AM, Andy Green wrote:

On 05/24/2012 11:06 PM, the mail apparently from Andy Green included:


Putting it another way if Linaro isn't going to take even a modest
amount of care about the OOT Android content making problems in vanilla
case, we probably aren't ready to add this lot to a vanilla basis.
Irritating as that is for me as much as anyone.


Here is an audit I did myself today of OOT Android content needed to 
understand what we're adding to Linaro kernels for vanilla case.  It's 
looking at the changes from POV of someone who does not want the 
additional Android content to build into their kernel or affect 
actions when deconfigured.


Things are "harmless" if they don't unconditionally change the source, 
the CONFIG_ they depend on is not "default y", or by looking at the 
code I determined that it's reasonable or even beneficial.


These are the suspicious things I found from the diff between 
linaro-android-3.4 (from 
http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=refs/heads/linaro-android-3.4 
at HEAD 8674fd7a65aeff35c3879cf0d56e78c93ee62e2c) vs v3.4.  Some are 
clear cut and others change code I don't really understand, but others 
on this list will.




Interesting log, I appreciate the effort you took here.   I don't really 
have too much to add here, but I'll comment on the few items below I 
have a bit of context on.


 1) drivers/input/evdev.c: adds wakelock code not dependent on 
ANDROID *** need discussion ***


I *believe* the evdev/wakelock changes has landed in modified form 
upstream in 3.5 as:

4d7e30d98939a0340022ccd49325a3d70f7e0238
epoll: Add a flag, EPOLLWAKEUP, to prevent suspend while epoll 
events are re


Although for now I'm still carrying the evdev wakelock change in my 
3.5-jstultz-rebase tree (since Android userland will need to be updated 
to use EPOLLWAKEUP).


22) arch/arm/kernel/etm.c: mass changes, no idea *** needs 
discussion ***


I've pinged the etm driver maintainer on the status of these patches as 
part of this blueprint:

https://blueprints.launchpad.net/linux-linaro/+spec/android-etm-upstreaming


And as you noticed we have some fixes pending in the linaro-android-3.4 
branch that I plan to send those up to AOSP when I get a chance.  Feel 
free to send me other changes and I'll queue them as well.


thanks
-john



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

Re: Git repo for kernel config fragments created

[John Stultz]

On 06/11/2012 06:14 AM, Jon Medhurst (Tixy) wrote:

I have created an git repo for the kernel config fragments we produced a
while ago, this is at git://git.linaro.org/kernel/configs.git

The config-core-tracking branch in this repo is intended to be added to
the linux-linaro-core-tracking branch and so be available in all Linaro
kernels. This currently provides three config fragment files:


Thanks so much Tixy, for stepping up and getting this going!
-john


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

Re: Are we going to start using config fragments?

[John Stultz]

On 06/07/2012 12:45 PM, John Stultz wrote:

On 06/06/2012 07:09 AM, Jon Medhurst (Tixy) wrote:


I have attached a couple of patches for the config fragments (3.5
removed the PERF_COUNTERS config).

Thanks, I'll create a new branch for 3.5 and merge your changes, so 
they don't get lost.


I just pushed this out here:
git://git.linaro.org/people/jstultz/android.git linaro-configs-3.5

thanks
-john


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

Re: Are we going to start using config fragments?

[John Stultz]

On 06/06/2012 07:09 AM, Jon Medhurst (Tixy) wrote:

Are we going to start using the config fragments we created a while ago?
(Or did we not reach consensus on that?)
I wouldn't say there was a strong consensus.  But I think we should push 
to make it available at an infrastructure level so those who do want to 
use it can.



If we could get them into a 'final' git location and start using them
for Ubuntu packaging, I can arrange for a mechanism to enable Android
builds to use them.
Andrey,   where would a good "final" git location be so that the base 
config fragments could be included into the linaro-base tree?


I can generate a new git tree, so its not just a branch in 
git://git.linaro.org/people/jstultz/android.git, but if you have other 
suggestions I'd welcome it.


Tixy: My attention on this issue has been somewhat limited. You've been 
by far the most involved in helping deploy config fragments (though, I 
don't want to be punishing good behavior by suggesting this,  so feel 
free to say no! :),  would you be interested in maintaining the branch?



I have attached a couple of patches for the config fragments (3.5
removed the PERF_COUNTERS config).

Thanks, I'll create a new branch for 3.5 and merge your changes, so they 
don't get lost.


thanks
-john


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

Re: Panda HDMI issue w/ 3.5-rc?

[John Stultz]

On 06/01/2012 06:18 PM, S, Venkatraman wrote:

If it helps, I am forwarding Tomi's pull request to Florian for 3.5
merge window.
I haven't checked very closely, but looks like the fixes are in that
pull request.


Thanks so much!
-john


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

Re: Panda HDMI issue w/ 3.5-rc?

[John Stultz]

On 05/25/2012 07:24 AM, Tomi Valkeinen wrote:

On Fri, 2012-05-25 at 19:49 +0530, S, Venkatraman wrote:

On Thu, May 24, 2012 at 10:56 PM, John Stultz  wrote:

Hey Arnd, Rob,
So after Arnd's help sorting a workaround for the mmc driver, I'm now
trying to sort out the following HDMI failure I'm seeing w/ the current
3.5-rc with my Panda Board.

[2.973693] omapdss error: HPD IRQ request failed
[2.978759] omapdss HDMI error: failed to power on device
[2.982391] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at
usb-ehci-omap.09
[2.996459] omapdss error: failed to power on
[3.001037] omapfb omapfb: Failed to enable display 'hdmi'
[3.006805] omapfb omapfb: failed to initialize default display
[3.013183] Console: switching to colour dummy device 80x30
[3.022430] omapfb omapfb: failed to setup omapfb
[3.027374] omapfb: probe of omapfb failed with error -5

Any guesses on this?


( This is just guesswork, as you asked :-) )
Apparently, request_threaded_irq requires that IRQF_ONESHOT be passed as a flag,
when the handler function is NULL.
Many drivers are facing this issue. Russell posted a patch [1] to fix
2 of them (see this patch log). Maybe DSS also requires this change.

[1] http://marc.info/?l=linux-arm-kernel&m=133785047227029&w=2

Yes, I have a fix for this in my pull request. The fbdev maintainer
hasn't responded yet to the request.


Hey Tomi,

Sorry, looks I didn't reply-to-all with my earlier reply.
This issue is still causing me trouble (well, as of yesterday).
Do you have a link to your fix or your git tree so I can do some testing 
while we wait for it to be merged?


thanks
-john


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

Re: Panda HDMI issue w/ 3.5-rc?

[John Stultz]

On 05/25/2012 07:24 AM, Tomi Valkeinen wrote:

On Fri, 2012-05-25 at 19:49 +0530, S, Venkatraman wrote:

On Thu, May 24, 2012 at 10:56 PM, John Stultz  wrote:

Hey Arnd, Rob,
So after Arnd's help sorting a workaround for the mmc driver, I'm now
trying to sort out the following HDMI failure I'm seeing w/ the current
3.5-rc with my Panda Board.

[2.973693] omapdss error: HPD IRQ request failed
[2.978759] omapdss HDMI error: failed to power on device
[2.982391] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at
usb-ehci-omap.09
[2.996459] omapdss error: failed to power on
[3.001037] omapfb omapfb: Failed to enable display 'hdmi'
[3.006805] omapfb omapfb: failed to initialize default display
[3.013183] Console: switching to colour dummy device 80x30
[3.022430] omapfb omapfb: failed to setup omapfb
[3.027374] omapfb: probe of omapfb failed with error -5

Any guesses on this?


( This is just guesswork, as you asked :-) )
Apparently, request_threaded_irq requires that IRQF_ONESHOT be passed as a flag,
when the handler function is NULL.
Many drivers are facing this issue. Russell posted a patch [1] to fix
2 of them (see this patch log). Maybe DSS also requires this change.

[1] http://marc.info/?l=linux-arm-kernel&m=133785047227029&w=2

Yes, I have a fix for this in my pull request. The fbdev maintainer
hasn't responded yet to the request.



Do you have a link to your fix or your git tree so I can do some testing 
while we wait for it to be merged (HDMI still seems to be broken in 
Linus' current git)?


thanks
-john


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

Panda HDMI issue w/ 3.5-rc?

[John Stultz]

Hey Arnd, Rob,
So after Arnd's help sorting a workaround for the mmc driver, I'm 
now trying to sort out the following HDMI failure I'm seeing w/ the 
current 3.5-rc with my Panda Board.


[2.973693] omapdss error: HPD IRQ request failed
[2.978759] omapdss HDMI error: failed to power on device
[2.982391] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at 
usb-ehci-omap.09

[2.996459] omapdss error: failed to power on
[3.001037] omapfb omapfb: Failed to enable display 'hdmi'
[3.006805] omapfb omapfb: failed to initialize default display
[3.013183] Console: switching to colour dummy device 80x30
[3.022430] omapfb omapfb: failed to setup omapfb
[3.027374] omapfb: probe of omapfb failed with error -5

Any guesses on this?

thanks
-john


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

Re: Panda mmc issue w/ Linus' current 3.5-rc tree

[John Stultz]

On 05/24/2012 06:27 AM, Arnd Bergmann wrote:

On Thursday 24 May 2012, John Stultz wrote:

On 05/23/2012 05:05 PM, John Stultz wrote:

Hey Arnd,
 So it looks like something has gone awry in the 3.5 pull with
Panda's mmc functionality.  Trying to boot the current 3.5-rc tree,
the boot fails after not finding the root device.  Looking at the boot
log I'm seeing:

omap_hsmmc: probe of omap_hsmmc.0 failed with error -22

With the same config on 3.4 it boots up fine.  I also tried w/ the
omap2plus_defconfig and see the same behavior.

Before I start bisecting down, I just wanted to raise the issue here
in case there's a known fix.

I went ahead and tried to bisect this down, and it was pretty painful as
there's a omap-usb-host build bug somewhere near the issue that keeps me
from being able to totally isolate it.

Anyway, the bisection finally pointed to this merge:

commit 8dca6010d44cc722a94dc6da96560f9083dac782
Merge: 9bc747b 74c4375
Author: Linus Torvalds
Date:   Tue May 22 09:27:39 2012 -0700

Hmm, so the fixes branch by itself is fine and so is the commit
before merging it.

The only commit that I see that can actually imact this seems
to be 1ee47b0. Can you try reverting that?

Yep. Good call, that's the one!  Reverting it works for me.
Thanks for catching that. After a few hours of bisecting I had gone a 
bit braindead.  :)


Playing around with the patch, it looks like its the irq assignment 
thats causing problems (twl6030_mmc_card_detect_config() is returning 
368). I can work around it with the hack below.


Balaji: Any thoughts on a proper fix here?

thanks
-john

diff --git a/arch/arm/mach-omap2/omap4-common.c 
b/arch/arm/mach-omap2/omap4-common.c
index a8161e5..9bd23a2 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -226,7 +226,7 @@ static int omap4_twl6030_hsmmc_late_init(struct device *dev)
__func__, irq);
return irq;
}
-   pdata->slots[0].card_detect_irq = irq;
+// pdata->slots[0].card_detect_irq = irq;
pdata->slots[0].card_detect = twl6030_mmc_card_detect;
}
return 0;




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

Re: Panda mmc issue w/ Linus' current 3.5-rc tree

[John Stultz]

On 05/23/2012 05:05 PM, John Stultz wrote:

Hey Arnd,
So it looks like something has gone awry in the 3.5 pull with 
Panda's mmc functionality.  Trying to boot the current 3.5-rc tree, 
the boot fails after not finding the root device.  Looking at the boot 
log I'm seeing:


omap_hsmmc: probe of omap_hsmmc.0 failed with error -22

With the same config on 3.4 it boots up fine.  I also tried w/ the 
omap2plus_defconfig and see the same behavior.


Before I start bisecting down, I just wanted to raise the issue here 
in case there's a known fix.


I went ahead and tried to bisect this down, and it was pretty painful as 
there's a omap-usb-host build bug somewhere near the issue that keeps me 
from being able to totally isolate it.


Anyway, the bisection finally pointed to this merge:

commit 8dca6010d44cc722a94dc6da96560f9083dac782
Merge: 9bc747b 74c4375
Author: Linus Torvalds 
Date:   Tue May 22 09:27:39 2012 -0700

Merge tag 'fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-s


Pull non-critical arm-soc bug fixes from Olof Johansson:
 "These bug fixes were not important enough to have them included 
in the

  v3.4 release, mostly because they cover harmless warnings or
  unrealistic configurations.  Instead we queue them up to be picked up
  in the next merge window."

Fixed up trivial conflict in arch/arm/mach-omap2/board-omap4panda.c

* tag 'fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:

  ARM: spear6xx: remove board selection options
  ARM: OMAP: igep0020: Specify the VPLL2 regulator unconditionally
  ARM: OMAP2+: INTC: fix Kconfig option for TI81XX
  ARM: OMAP2+: remove incorrect irq_chip ack field
  ARM: OMAP4: Adding ID for OMAP4460 ES1.1
  ARM: OMAP4: panda: add statics to remove warnings
  ARM: OMAP2+: Incorrect Register Offsets in OMAP Mailbox
  ARM: OMAP: fix trivial warnings for dspbridge
  arm: davinci: use for_each_set_bit_from
  ARM: OMAP4: hsmmc: check for null pointer
  ARM: OMAP1: fix compilation issue in board-sx1.c
  ARM: disable SUSPEND/ARCH_SUSPEND_POSSIBLE for ARCH_TEGRA
  ARM: davinci: da850-evm: fix section mismatch
  ARM: tegra: add pll_x freq table entry for 750MHz
  ARM: davinci: mark spi_board_info arguments as const
  ARM: davinci: fix incorrect pdctl next bit position


But I'm a little skeptical due to the huge number of "git bisect skip"s 
required.


Full bisect log below, in case it helps
thanks
-john

git bisect start

# bad: [1259f6ee15c1603dcae41eb6af5a5f9cf932d4d6] Merge tag 'hwmon-for-linus' 
of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging

git bisect bad 1259f6ee15c1603dcae41eb6af5a5f9cf932d4d6

# good: [76e10d158efb6d4516018846f60c2ab5501900bc] Linux 3.4

git bisect good 76e10d158efb6d4516018846f60c2ab5501900bc

# good: [9bc747bea5fad819e0c0ad96e6a67ea0640dfe2b] Merge tag 'cleanup' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

git bisect good 9bc747bea5fad819e0c0ad96e6a67ea0640dfe2b

# bad: [94b5aff4c6f72fee6b0f49d49e4fa8b204e8ded9] Merge tag 'tty-3.5-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

git bisect bad 94b5aff4c6f72fee6b0f49d49e4fa8b204e8ded9

# good: [cda4db53e9c28061c100400e1a4d273ea61dfba9] Merge tag 
'for-usb-next-2012-05-21' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next

git bisect good cda4db53e9c28061c100400e1a4d273ea61dfba9

# bad: [cdd3a354a05b0c33fe33ab11a0fb0838396cad19] Merge tag 'pm' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

git bisect bad cdd3a354a05b0c33fe33ab11a0fb0838396cad19

# bad: [9f639269ed1522c7d69c54cc8b80ab8ee53fcb10] Merge tag 'soc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

git bisect bad 9f639269ed1522c7d69c54cc8b80ab8ee53fcb10

# skip: [47fad7c6f8d9f64780793cc67d8280259538c31c] Merge tag 'at91-for-next-dt' 
of git://github.com/at91linux/linux-at91 into next/dt

git bisect skip 47fad7c6f8d9f64780793cc67d8280259538c31c

# skip: [70888a4b412abd55c1710e2d36a9a00f4d23f474] Merge branch 
'ux500-devicetree-for-arm-soc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson into 
next/dt

git bisect skip 70888a4b412abd55c1710e2d36a9a00f4d23f474

# good: [15787753d08107f2066b8ed8c9f8046ef3b766bb] ARM: at91: DT: add Calao TNY 
A9263 board support

git bisect good 15787753d08107f2066b8ed8c9f8046ef3b766bb

# good: [73d68d91aa1b9e9cb6c1635143799c0fec484c08] ARM: at91: Add ADC driver to 
at91sam9260/at91sam9g20 dtsi files

git bisect good 73d68d91aa1b9e9cb6c1635143799c0fec484c08

# good: [74c437532b8b5db53509963ec38e8424c56ff6f4] ARM: spear6xx: remove board 
selection options

git bisect good 74c437532b8b5db53509963ec38e8424c56ff6f4

# skip: [e86bde3caea693b2e615e7b3664e6273160bf864] Merg

Re: android-3.4 or android-3.4-compat

[John Stultz]

On 05/23/2012 05:25 PM, Andy Green wrote:

On 24/05/12 06:42, Somebody in the thread at some point said:


Am I right in thinking the issue you're running into here is that your
customer has direct expectations for the tree you're maintaining, which
makes adding unexpected instability on a vanilla build very
undesireable?

(If that's not the case, then generally I don't see a problem with
broadening the group testing the Androidization patches to the vanilla
set -- they will be beta testing, but that's one key part of open source
QA.)


Pretty much, I think they're saying to their customers, "here's an 
enabled vanilla tree" and then nobody wants to see problems coming 
from OOT Androidization series.  Since we already had "funny things" 
in vanilla build from the series, this isn't so paranoid to be 
concerned about.




I think part of the difficulty here has been the classic question of:
A) Is the linaro kernel release a development snapshot of the current 
state of our work - allowing us to get real world testing of our 
not-yet-upstreamed work?

B) Or is it a stable base for others to build upon?

And the answer so far has been "both!" (we're always optimistic! :) but 
this is a good example of a case where the integration testing of 
android code with mainline (which helps resolve issues before pushing 
upstream) is apparently considered too risky for folks wanting that 
stable base to build upon.


Again, I can see both sides,  and what makes most sense depends on our 
priorities.



Personally I like the idea of the Androidization becoming part of
the basis because it puts us in generally converged direction with
mainline.  But then we have a responsibility to make it as
transparent as mainline will insist that it is if we expect members
are seriously going to offer vanilla kernels on this basis.


I like it too. What could we do cheaply that will give us the
transparency or policy that addresses the risk you've outlined?


Someone needs to audit the OOT Androidization stuff and confirm that 
for patches that go "out of their box", ie, reach out of /staging or 
some specific driver:


 - the impact of the patch is negated if CONFIG_ANDROID or some more 
specific config is disabled, or,


 - remove the patch as too invasive, or,

 - conclude the patch is useful and needed in vanilla case too

there's a big variety of "out of the box" patches for stuff like cache 
code, mmc core, network stack and so on in that series last time I 
looked.  We should give some assurance for people using 
linux-linaro-core-tracking that someone at least looked at each of 
those cases and determined its status as above.


Again, this would be great to have.  Although the calls being made here 
also have costs to consider:
* If we remove the patch, we diverge from AOSP, which makes keeping up 
with Google's tree more costly.
* If the patch is needed in vanilla, but might not be acceptable, 
considerable work might be required to get it into shape. So what do we 
do in the meantime?


Further, for the various bits that are not config switched, any such 
review would need to be done by domain experts, as much of the changes 
(especially with regard to arm architecture and mmc tweaks) are well 
beyond my/a novice's ability to audit.  In some cases where I've pushed 
seemingly trivial fixes from the AOSP stack to lkml, Russell and others 
have not been able to come to consensus as to if the fix is correct or 
not, so this definitely isn't a trivial work.


And all of the above suggestions you've made are desired, but given time 
constraints we've been focusing on the more generic functionality first, 
and moving from there to the more specific driver and architecture 
changes (which is where the majority of the un-config switched changes 
are).  Its just taking some time to get there, so I suspect pushing the 
linaro-android tree into a separate merge tree is likely the easiest 
solution at this point to address your concern (assuming the loss of 
integration testing is deemed as ok).


thanks
-john




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

Panda mmc issue w/ Linus' current 3.5-rc tree

[John Stultz]

Hey Arnd,
So it looks like something has gone awry in the 3.5 pull with 
Panda's mmc functionality.  Trying to boot the current 3.5-rc tree, the 
boot fails after not finding the root device.  Looking at the boot log 
I'm seeing:


omap_hsmmc: probe of omap_hsmmc.0 failed with error -22

With the same config on 3.4 it boots up fine.  I also tried w/ the 
omap2plus_defconfig and see the same behavior.


Before I start bisecting down, I just wanted to raise the issue here in 
case there's a known fix.


thanks
-john


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

Re: android-3.4 or android-3.4-compat

[John Stultz]

On 05/21/2012 09:21 PM, Andy Green wrote:

On 22/05/12 01:58, Somebody in the thread at some point said:

On Mon, May 21, 2012 at 10:33:47AM -0700, John Stultz wrote:

like Andy, I am a bit concerned that we merge the android stuff
into the linaro-core and that we get android candies in 'vanilla'
kernel. can't we (shouldn't we) have -android on top of -core and
pull -android only into 'android' kernel? it's true that for most
things, -android is not impacting a 'vanilla' kernel, but clearly

>from the outside (community *and* customers) a kernel 'tainted'

with Android is not a 'vanilla' kernel anymore...


So this re-opens the discussion we've been having since at least
last Oct in moving to a consolidated kernel.

Since Android upstreaming is an very active goal of Linaro,  I think
there's strong technical value in putting the Android patches in
along with all the other Linaro trees, as it allows us to work out
any sort of incompatibilities or issues, so we can resolve them
prior to being pushed upstream.


I'm quite +1 on what John is saying. There was a time when there was
great uncertainty about the future of the Android patches, but since
Linus' comment last year it's become dead certain that the functionality
/will/ be merged upstream. We can pave the way by getting any
integration issues sorted out early -- similarly to what we do for
practically everything else in linux-linaro.


Hm I just said we should audit it for being dependent on CONFIG_ANDROID.

If we KNOW that deconfiguration of CONFIG_ANDROID is equivalent to not 
having Androidization patched in, people will stop wanting to get rid 
of the patches.  But since Google's interest is in the case it is 
configured, I doubt they took care about having it disabled well.


For new or optional functionality, this is usually the case, but not for 
all changes.
Having multiple config based code paths has additional maintainance 
burden, so frequently if a change really should be generic there isn't 
any need for a config.   The simplest example of this are bug fixes, 
which shouldn't be configurable off :)


For other configurable features in the mainline kernel, part of the 
deal of getting in there is that they can be turned off nicely.  
There's even a wholesale CONFIG_PM.  But the remaining (200 or so last 
time I looked) Androidization patches haven't been through that kind 
of scrutiny by anyone.  Again last time I looked they fiddled with a 
fair amount of kernel guts, sometimes with additional config coverage 
but not always.


Initially we added without discrimination that 7 year old patch that 
turns dmesg into junk to llct because it came in with Google's 
Androidization series.  It suggests we're just shovelling them on 
without any plan at the moment.
And I'd say in this case things worked ideally!   Android tree had a 
very old hack that has since become obsolete. You noticed it in the tree 
and requested it be reverted. I've generated a patch to do so, and plan 
to send it to AOSP in my next submission bundle.  Once the Google guys 
rebase, and squish the two patches down,  we're down one more patch.  
This is exactly the type of integration work I think we benefit from.


If this were something that we went in and just configured off, its less 
likely anyone would notice it was unnecessary until we finished 
upstreaming all the larger changes we're focusing on.


Similarly, Andrey and Tushar found early cases during the first few 
integration attempts where parts of the Android patch set didn't align 
with non-Android builds.  They submitted patches that have since been 
pushed back to AOSP.



With regard to your characterization of shovelling the patches in, its 
true we've traditionally taken the patch tree in its entirety, in order 
to produce Android builds that were fully functional. The positive news 
is that as items have been making it upstream, we may soon be able to 
reverse the model, only hand picking specific required changes from the 
AOSP tree.  This possibility has different pros and cons, so it may not 
be the right approach, but its something I'll be looking at in the future.


If we're claiming we are converging these patches to upstream, 
"working out integration issues" then we should be auditing them for 
being properly dependent on CONFIG_ANDROID before adding them to the 
same basis used for vanilla consumers.


So I'd welcome more help in reviewing and auditing the Android patch 
tree with detailed care to accomplish what you're suggesting.  That 
said, I would suggest against blindly be adding #ifdef CONFIG_ANDROID  
all over the code, as there are changes that shouldn't necessarily be 
configurable. Working these out properly will take time and care.


Again, if there is a specific concern, please let me know 

Re: android-3.4 or android-3.4-compat

[John Stultz]

On 05/17/2012 09:00 PM, Andy Green wrote:

On 18/05/12 09:49, Somebody in the thread at some point said:

Hey Andrey, Zach,
So I'm back from my vacation, and have found that the Android team has
released a -compat tree for their 3.4 kernel. Basically this tree
re-adds some items like earlysuspend and classic wakelocks in order to
provide better compatibility with old (and by old, I really mean current
as far as we see - so ICS and earlier) Android userland.

Since we're still shipping ICS, and have no access to whatever the
Android 5.0 userland will be, it seems merging in the -compat tree would
make sense.

However, I know Tixy and others have already tried to address the lack
of earlysuspend in the android-3.3+ kernels, so I wanted to double check
that this wouldn't cause additional pain (since those adjustments might
need to be reverted).

So I just wanted to check first with folks to make sure there are no
objections to merging in the -compat changes, and that the timing of
merging in these changes isn't problematic (I can happily hold off till
this months release is done, so we don't risk any last minute gotchas).


The only worry I can see is that now even vanilla versions of LT 
kernels are basing off llct that includes Androidizaton, even vanilla 
will have possibly invasive wakelock code.


Could you expand a bit more on your concern here? Is the the wakelock 
infrastructure you're concerned about, or the driver changes made by the 
wakelock usage? Or is it just other nebulous changes in the Android tree?


It might be good to briefly audit the changes to confirm they don't 
appear if CONFIG_ANDROID is off.  Google might not take much care 
about that case but I think it might be important for us.


So while wakelocks should turn into a noop if they are disabled, there 
are other changes in the Android tree that aren't necessarily config 
switched.  However, since we are trying to push these patches upstream, 
I think its actually good that we test these changes in non-android 
settings, since its the hope that they will be there eventually, if not 
soon.


Of course, if there are specific issues that pop up, we can either work 
with Google to add needed switches so the code can coexist, or rework 
the changes so the feature is runtime selectable.


thanks
-john


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

Re: android-3.4 or android-3.4-compat

[John Stultz]

On 05/21/2012 03:27 AM, Dechesne, Nicolas wrote:

hi,

On Fri, May 18, 2012 at 6:00 AM, Andy Green > wrote:


So I just wanted to check first with folks to make sure there
are no
objections to merging in the -compat changes, and that the
timing of
merging in these changes isn't problematic (I can happily hold
off till
this months release is done, so we don't risk any last minute
gotchas).


The only worry I can see is that now even vanilla versions of LT
kernels are basing off llct that includes Androidizaton, even
vanilla will have possibly invasive wakelock code.

It might be good to briefly audit the changes to confirm they
don't appear if CONFIG_ANDROID is off.  Google might not take much
care about that case but I think it might be important for us.


like Andy, I am a bit concerned that we merge the android stuff into 
the linaro-core and that we get android candies in 'vanilla' kernel. 
can't we (shouldn't we) have -android on top of -core and pull 
-android only into 'android' kernel? it's true that for most things, 
-android is not impacting a 'vanilla' kernel, but clearly from the 
outside (community *and* customers) a kernel 'tainted' with Android is 
not a 'vanilla' kernel anymore...


So this re-opens the discussion we've been having since at least last 
Oct in moving to a consolidated kernel.


Since Android upstreaming is an very active goal of Linaro,  I think 
there's strong technical value in putting the Android patches in along 
with all the other Linaro trees, as it allows us to work out any sort of 
incompatibilities or issues, so we can resolve them prior to being 
pushed upstream.


That said, if folks really want to have a non-android linaro-core tree, 
we can ask Andrey to just merge it in the same phase as he does the 
Landing team trees.


thanks
-john


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

Re: android-3.4 or android-3.4-compat

[John Stultz]

On 05/18/2012 06:57 AM, Zach Pfeffer wrote:

On 17 May 2012 22:09, Zach Pfeffer  wrote:

On 17 May 2012 20:49, John Stultz  wrote:

Hey Andrey, Zach,
So I'm back from my vacation, and have found that the Android team has
released a -compat tree for their 3.4 kernel. Basically this tree re-adds
some items like earlysuspend and classic wakelocks in order to provide
better compatibility with old (and by old,  I really mean current as far as
we see - so ICS and earlier) Android userland.

Since we're still  shipping ICS, and have no access to whatever the Android
5.0 userland will be, it seems merging in the -compat tree would make sense.

However, I know Tixy and others have already tried to address the lack of
earlysuspend in the android-3.3+ kernels, so I wanted to double check that
this wouldn't cause additional pain (since those adjustments might need to
be reverted).

So I just wanted to check first with folks to make sure there are no
objections to merging in the -compat changes, and that the timing of merging
in these changes isn't problematic (I can happily hold off till this months
release is done, so we don't risk any last minute gotchas).

Yeah, lets hold off. I'll get it on the schedule for next month. Sound
good everyone?

Put a meeting together next week to plan it.
I won't be there, so I'd rather do it over email.  I really don't think 
this will be a huge impact, but really just wanted to give a general 
heads up and get input from Tixy on how badly it might impact his fix 
(or any other userland changes we made to accommodate 3.3+ kernels that 
I'm unaware of) and Andrey on if he had any objections.


thanks
-john


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

android-3.4 or android-3.4-compat

[John Stultz]

Hey Andrey, Zach,
So I'm back from my vacation, and have found that the Android team 
has released a -compat tree for their 3.4 kernel. Basically this tree 
re-adds some items like earlysuspend and classic wakelocks in order to 
provide better compatibility with old (and by old,  I really mean 
current as far as we see - so ICS and earlier) Android userland.


Since we're still  shipping ICS, and have no access to whatever the 
Android 5.0 userland will be, it seems merging in the -compat tree would 
make sense.


However, I know Tixy and others have already tried to address the lack 
of earlysuspend in the android-3.3+ kernels, so I wanted to double check 
that this wouldn't cause additional pain (since those adjustments might 
need to be reverted).


So I just wanted to check first with folks to make sure there are no 
objections to merging in the -compat changes, and that the timing of 
merging in these changes isn't problematic (I can happily hold off till 
this months release is done, so we don't risk any last minute gotchas).


thanks
-john



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

Re: linux-linaro-core-tracking tree created

[John Stultz]

On 05/07/2012 02:09 AM, Andrey Konovalov wrote:

07.05.2012 09:05, Andy Green написал:

Since it's still there in today's llct and making me see double, I
tracked it down to this from Androidization series

109a3af ARM: Make low-level printk work

Author: Tony Lindgren 
Date:   Mon May 9 14:10:26 2005 -0700


I don't think that makes any sense any more and should be removed,
unless there's some case on Android side that really needs it.  Vanilla
has better DEBUG_LL support now since 2005 when that patch was
introduced and the Android kernels will inherit it.  I've reverted it in
my tree since we commonly need DEBUG_LL on (but we don't need printascii
garbling all our logging as if there was an echo in there).


Agreed. A really ancient one.

John,
Are there any reasons for Android to keep this patch?



I don't have any particular insight on that one.  I'll go ahead and 
revert it in our tree and bring it up with the Android folks when I try 
to push some of our changes towards them.


thanks
-john


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

Re: linux-linaro-core-tracking tree created / update frequency

[John Stultz]

On 05/03/2012 09:31 AM, Alexander Sack wrote:

On Thu, May 3, 2012 at 6:10 PM, John Stultz  wrote:

On 05/03/2012 07:15 AM, Alexander Sack wrote:

On Thu, May 3, 2012 at 4:00 PM, Andrey Konovalov
wrote:

Sorry for the delay.

I've updated the linux-linaro-core-tracking, but it currently misses the
linaro-android-3.4 topic. Will put the linaro-android-3.4 topic back
after
resolving the merge conflicts; guess later today.

Is the resolution simple enough? Otherwise, feels that the better
scalable approach is that the topic owner (e.g. John Stultz for the
time being) gets notified and asked to fix the merge conflict on his
side. Your daily merge scripts would then pick it up automatically  as
soon as the merge conflict is resolved.


So Andrey mailed me that there was a conflict between Linus' v3.4-rc5 and
the Android tree, but when I went to updated the tree sort it out,
  v.3.4-rc5 merged in without any issues. I suspect the collision is with
something else in the linaro tree, but haven't yet gotten any feedback as to
what that might be.


OK, feels we could benefit from getting Andreys tools out and enable
you to easily fold linux-linaro with your your own local topic?
I think in this case we've already cleared it up as a slight 
communication issue.



Would this help you to more easily converge, prepare and maintain
topics that coexist in linux-linaro?
Probably not.  I'm unable to dedicate as much time to merging items as 
Andrey, so I'm not likely able to keep pace. As it stands now, I update 
the Android tree at least ~once a week (sometimes more).  So Andrey 
notices collisions before I do. Usually he then pings me and that 
prompts me to try to solve it.


Although I've had a few cases where at Andrey's prodding I spend a few 
hours resolving the collision and testing the resulting tree, only to 
find the Android team did the same in parallel. Usually then I just pick 
up the Android teams' work, but I'm not happy about burning my time that 
way.


This is one of the drawbacks of being always too close to the edge. We 
end up trying to address issues that others in the community also are 
addressing in parallel.  I think its great to be proactive this way 
(especially if you're really the patch-queue owner), but it can keep us 
busy and we miss out on leveraging others work.


thanks
-john



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

Re: linux-linaro-core-tracking tree created / update frequency

[John Stultz]

On 05/03/2012 09:16 AM, Andrey Konovalov wrote:

On 05/03/2012 08:10 PM, John Stultz wrote:


So Andrey mailed me that there was a conflict between Linus' v3.4-rc5
and the Android tree, but when I went to updated the tree sort it out,
v.3.4-rc5 merged in without any issues. I suspect the collision is with
something else in the linaro tree, but haven't yet gotten any feedback
as to what that might be.


I wasn't exact enough. In fact the linux-linaro-core-tracking is 
mainline tip based, and the conflicting commits turned out to be 
post-v3.4-rc5. That's why the confusion.


Ok. I'll watch out for it next time I update my tree.

thanks
-john


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

Re: linux-linaro-core-tracking tree created / update frequency

[John Stultz]

On 05/03/2012 07:15 AM, Alexander Sack wrote:

On Thu, May 3, 2012 at 4:00 PM, Andrey Konovalov
  wrote:

Sorry for the delay.
I've updated the linux-linaro-core-tracking, but it currently misses the
linaro-android-3.4 topic. Will put the linaro-android-3.4 topic back after
resolving the merge conflicts; guess later today.

Is the resolution simple enough? Otherwise, feels that the better
scalable approach is that the topic owner (e.g. John Stultz for the
time being) gets notified and asked to fix the merge conflict on his
side. Your daily merge scripts would then pick it up automatically  as
soon as the merge conflict is resolved.


So Andrey mailed me that there was a conflict between Linus' v3.4-rc5 
and the Android tree, but when I went to updated the tree sort it out,  
v.3.4-rc5 merged in without any issues. I suspect the collision is with 
something else in the linaro tree, but haven't yet gotten any feedback 
as to what that might be.


thanks
-john


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

Re: linux-linaro-core-tracking tree created

[John Stultz]

On 04/24/2012 08:24 PM, Andy Green wrote:

On 04/25/2012 11:12 AM, Somebody in the thread at some point said:


We're still undergoing uplevel on tilt-tracking and didn't get back to
tilt-3.3 functionality yet (OMAP4 boot is busted, although hopefully we
have a fix for that today), so I put off this common config thing.

However now I see it included, aren't most of the patches about board
support redundant?  If LTs base on this, they will add in their own
golden initial defconfig for their board(s) at that point; when they're
combined they'll all be in the combined tree.  It seems like I shouldn't
be seeing a defconfig about Panda coming in with this base tree, but
create it (perhaps after mixing in config fragments that did come in
with the base tree) in my tree.

We could just have the fragments per topic, and then the LT can decide
either to add another fragment, or simply creating an entire different
config to be used by default.

Having everything in config fragments may help automating the builds,
but I understand that having one defconfig might also help people that
are consuming the tree directly.

Yes I'm not really referring to fragment process here, I understand the
idea and as I wrote expect the common one(s) to come in with this base tree.

What I'm talking about is ./configs/panda.conf brought in by this

http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=commitdiff;h=36f22ea6ac55d44026d374669cb55c60bb366d4e

actually, now we don't maintain anything directly equivalent, we only
have omap4plus_defconfig that builds a single kernel that runs with
everything we support, including OMAP543x.

I guess panda.conf is trying to be mainline compatible OMAP44x0 Panda
config.  But what we're going to provide, and what's meaningful and
tested with our tree, will be this omap4plus_defconfig that appears in
our topics.  panda.conf that we are inheriting from this basis branch
may not even build with our tree, it's at least confusing to have it
there and at worst it'll mislead end users, rot as we go on etc.
Yea, it was added mainly for demonstration purposes for how the config 
fragments might work.
(It also is something I use for my panda on android testing, but that 
doesn't warrant it being included).


There may be some need for a config that the (oh the names have changed 
so much I don't know what its called) 
vanilla-upstream-android-builds-for-panda uses.  But I'm happy to locate 
that somewhere else or with a more clear name.


Even so, if you and Andrey have a system that works for the omap config 
fragment, I'm fine dropping the configs/panda.conf


thanks
-john


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

Re: Fix for Ubuntu networking [Re: Preliminary 12.04 linux-linaro kernel tree]

[John Stultz]

On 04/19/2012 04:03 AM, Jon Medhurst (Tixy) wrote:

On Thu, 2012-04-19 at 11:17 +0100, Jon Medhurst (Tixy) wrote:

On Thu, 2012-04-19 at 10:22 +0100, Jon Medhurst (Tixy) wrote:

On Thu, 2012-04-19 at 00:22 +0400, Andrey Konovalov wrote:

Greetings,

I updated (overwrote) the current linux-linaro tree
(git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro
branch).

That builds OK for vexpress and boots Ubuntu. I also kicked off an
Android build [1]


Actually, it has a problem. Firefox can't resolve names or access the
network, though ping from the command-line forks (and can resolve domain
names.)

I also note in syslog that avahi-daemon can't start [1]

I'm pretty certain Firefox worked in the previous version of
linux-linaro I tested a couple of days ago. Perhaps the Android topic
has broken networking on Ubuntu.

This problem is due to CONFIG_ANDROID_PARANOID_NETWORK being enabled in
Ubuntu as it defaults to 'y'. Editing configs/ubuntu.conf to add:

# CONFIG_ANDROID_PARANOID_NETWORK is not set

fixes the networking problem (after also fixing a compile error [1])

I note that some other Android configs default to 'y'...

   CONFIG_HAS_WAKELOCK
   CONFIG_WAKELOCK
   CONFIG_USER_WAKELOCK
   CONFIG_NET_ACTIVITY_STATS

should we play safe and also disable these in Ubuntu?


Yea. All the android configs should be off for ubuntu.


Alternatively, it would be nicer if all of these defaulted 'n' and we
got the Android config to enable them. (But that would mean carrying
patches to AOSP code I guess.)



Yea. But we should be able to push items back to AOSP. I've not done it 
since they changed their gerrit system, so its probably a good exercise 
for me.


I'll try to queue them up, but until then I'd make sure its off in the 
ubuntu config.


thanks
-john


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

Re: Linaro 12.04 3.4-rc1 based androidization branch is available

[John Stultz]

On 04/13/2012 03:22 AM, Jon Medhurst (Tixy) wrote:

Hi John

When using the linaro-android-3.4 branch the mouse buttons don't seem to
work. I've tracked the problem down to something you fixed in
linaro-android-3.4-jstultz-rebase, namely:
http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=commit;h=2d571b539f94918e416971d0d2a7584544906f2c

Can you add this to linaro-android-3.4 and any other fixes you did that might 
be missing?

Just re-added that one. Thanks for pointing it out, sorry for making you 
chase it down.


thanks
-john


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

3.4 based config-fragment tree for 12.04

[John Stultz]

Hey Andrey,
I rebased the config-fragment tree to 3.4-rc2, and you can find it 
here:

git://git.linaro.org/people/jstultz/android.git linaro-configs-3.4

Let me know if you run into any issues.

thanks
-john


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

Re: Linaro 12.04 3.4-rc1 based androidization branch is available

[John Stultz]

On 04/09/2012 03:18 PM, John Stultz wrote:

I went ahead and forward ported the AOSP-3.3 tree to 3.4-rc1.

You can grab it here:
git://git.linaro.org/people/jstultz/android.git 
linaro-android-3.4-jstultz-rebase


Sigh. Looks like the Google devs are following close behind and released 
their own 3.4-rc2 based tree.


Don't get me wrong: Its great to see them keeping up with mainline, but 
I've clearly duplicated their work this cycle.


I've gone ahead and mirrored the AOSP 3.4 tree  here:
git://git.linaro.org/people/jstultz/android.git linaro-android-3.4

Andrey:  Probably you're call on this. If you've already merged in my 
rebase tree it should be fine for 12.04, but if not you might want to 
jump over to the AOSP 3.4 tree.


thanks
-john


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

Linaro 12.04 3.4-rc1 based androidization branch is available

[John Stultz]

I went ahead and forward ported the AOSP-3.3 tree to 3.4-rc1.

You can grab it here:
git://git.linaro.org/people/jstultz/android.git 
linaro-android-3.4-jstultz-rebase



thanks
-john


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

qemu & hardware gfx acceleration

[John Stultz]

So the Google Android team just posted this:
http://feedproxy.google.com/~r/blogspot/hsDu/~3/OCt1AQzfyWI/faster-emulator-with-better-hardware.html

Which shows their device emulator running w/ hardware acceleration.  
Since I know they started with qemu, I was curious if there was any 
details as to if these sorts of changes were making it back upstream to 
qemu, or if qemu had its own plans for hardware acceleration?


Unfortunately there's little technical details in the post above.  The 
video is clearly running on OS X, so I'm not sure if this will also be 
usable w/ Linux hosts, but I could be wrong there.


thanks
-john


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

Re: Config fragment for Versatile Express

[John Stultz]

On 04/02/2012 11:58 AM, Jon Medhurst (Tixy) wrote:

On Mon, 2012-04-02 at 11:18 -0700, John Stultz wrote:

On 04/02/2012 10:29 AM, Jon Medhurst (Tixy) wrote:

On Mon, 2012-04-02 at 08:37 -0700, John Stultz wrote:

On 03/31/2012 02:17 AM, Jon Medhurst (Tixy) wrote:

We almost certainly need board specific android and ubuntu fragments as
well, so I'll add vexpress-android.conf and vexpress-ubuntu.conf as
well. (Unless there is some magic to have conditional config options in
a fragment?)


No, the config fragments are pretty simple, so there's no conditional
logic in them. Your idea for a board-type.conf style split sounds like a
fair idea. Although, I'm curious what would be an example of this?


There's often let's-just-get-it-working hacks produced, and sometimes
you don't want to risk breaking other boards by putting things into a
common config.

My example of this is
http://android.git.linaro.org/gitweb?p=kernel/vexpress-a9.git;a=commit;h=20a2abd40fff4d5942263c09b9852986c47aaa32

Of course, this could be an argument for not enabling such things. ;-)


Ok. Interesting. I can see how this sort of flexibility is useful. So
I'm fine if folks want to add board-distro specific tweaks. Trying to
find some more unified way of building might be necessary, so folks
aren't having to customize things too drastically. Your directory method
seems like would solve this, but I need to spend some more time
understanding Andy's suggestion and understanding how it works with
Andrey's centralized tree.


Possibly if we just had a symlink

 configs/omap_5430evm/base/main.conf -->
 arch/arm/configs/omap_5430evm_defconfig


That could be possible. Although the file location isn't critical for 
the merge_config.sh tool, so the sym link is only necessary if we are 
trying to come with with a more generic config generation script in the 
builder.


In other words, if each build script has to have a custom merge_config 
line (much as it currently has a custom make X_defconfig line), we can 
just add any extra tweaks or hacks there.



but then that defconfig has some non board specific stuff, like EXT
file-systems configured. And Andrey's Android branch would have TI's
Android topics, so that 'base' defconfig file would also gain TI's
Android flavourings. (Neither of these issues might be a problem in
practice.)


Indeed. The non-board specific items in the defconfigs would likely be 
an issue, but I guess we could push the LT's to cleanup where those 
issues were noticed.


thanks
-john



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

Re: Config fragment for Versatile Express

[John Stultz]

On 04/02/2012 06:58 AM, Andy Green wrote:

On 04/02/2012 09:40 PM, Somebody in the thread at some point said:

On Mon, 2012-04-02 at 21:10 +0800, Andy Green wrote:

If you want to do it with this complex directory scheme, please don't so
anything to the definitive sources that makes it mandatory.


Just so I understand properly, are you saying that for the TI kernels
you want to just supply a single fully featured defconfig file and have
that used to produce builds, rather than having one built up from OMAP
bits supplied by you and other android/ubuntu/linaro bits obtained from
another source?


Not at all.

I don't want to sound like a broken record but we have been doing this
layered config stuff for a long time.  It's a very good wheeze and
centralizing some of it will give good results if we can do it in a good
way.

Here's an example from our repo.

Currently our vanilla tree ends at

http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortlog;h=refs/heads/tracking-topic-omapdrm

that's made up of many topics each of which add to the single defconfig
omap_5430evm_defconfig so it builds and configures for the topic
content.  At this end point, it has all the topic patches in and all the
topic config enabled.

An example of what we have been talking about can be found at the
"flavour" branch lat-3.3.

http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortlog;h=refs/heads/lat-3.3

This is based on the vanilla tree from tracking-topic-omapdrm, it
contains the generic androidization patches.

At the end of lat-3.3, I have a patch "config OMAP5 Android" which
adapts the single defconfig that came in from vanilla,
omap_5430evm_defconfig, to have generic Androidization options

http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=commitdiff;h=f4021118f3efe8ad74b24fab682814ff8f6d8869

So when you check out lat-3.3 or one of the tags pointing at it, you get
always up-to-date, androidized, omap4+omap5 defconfig with the same name
as vanilla.

The defconfig you check out at the vanilla tree back at
tracking-topic-omapdrm doesn't have to know or take care or be affected
by any of that.


So, to make sure I'm following properly here, would it be fair to call 
this somewhat of an "additive", or "constructive" style config 
management, where you have your board defconfig, which you add to the 
end of your base tree, then any branches based off of that base tree 
will also contain patches to the board defconfig that enable the new 
features found in that branch?


In this way you have one config, that each branch adds to as needed.



When it's available and we're able to, we'll also start putting out a
new flavour branch which has linux-linaro-tracking "flavoured" on to it,
and just like in lat-3.3 case we will modify the vanilla defconfig
according to what that flavour needs.

All we require is that the flavour tree, be it
linux-androidization-tracking, or linux-linaro-tracking, comes with a
patch containing the defconfig delta that's meaningful for it.

If that makes sense, you can see there's no need for directory
structures, the various flavour and result trees can contain all the
deltas and variant defconfigs.


So part of the config fragment work is motivated by the need to have 
consistent configs across a number of boards.


While the method you described above works well for managing 
board-specific config features enabled by LT branches, the config 
fragment work is trying to find a way to help simplify config management 
for features that are generic.


An example is the SCHED_MC item that I know Amit had to chase a few 
times in order to make sure it was enabled in all the various build 
configs, and that it stayed enabled as folks rebased forward to new 
kernel versions.


Initially I was hoping to provide a basic set of configs split up by 
base/distro/board. Then have folks use the same additive method you 
describe above to enable features per branch (in the appropriate config 
so LT's branches modifying the board config fragment, while 
power-management team's branches can modify the base fragment).


The difficulty is that as Tixy earlier pointed out, are that the LT 
kernel trees are mainline based, and thus aren't based off of something 
that would contain the base/distro/board config fragments.


One approach we might be able to use is if the board defconfigs really 
are minimal, and restricted in scope to only the board options, we could 
switch the merge order (board/distro/base). This way the LT's "additive" 
defconfig can be used (from arch/arm/configs/ ) and we can still also 
get consistent generic options as well.


The only issue with this idea is that it goes specific->generic it 
doesn't allow us to add board-specific hacks like Tixy's IPv6 example, 
since the last fragment wins.


Any other ideas?

thanks
-john




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

Re: Config fragment for Versatile Express

[John Stultz]

On 04/02/2012 10:29 AM, Jon Medhurst (Tixy) wrote:

On Mon, 2012-04-02 at 08:37 -0700, John Stultz wrote:

On 03/31/2012 02:17 AM, Jon Medhurst (Tixy) wrote:

We almost certainly need board specific android and ubuntu fragments as
well, so I'll add vexpress-android.conf and vexpress-ubuntu.conf as
well. (Unless there is some magic to have conditional config options in
a fragment?)


No, the config fragments are pretty simple, so there's no conditional
logic in them. Your idea for a board-type.conf style split sounds like a
fair idea. Although, I'm curious what would be an example of this?


There's often let's-just-get-it-working hacks produced, and sometimes
you don't want to risk breaking other boards by putting things into a
common config.

My example of this is
http://android.git.linaro.org/gitweb?p=kernel/vexpress-a9.git;a=commit;h=20a2abd40fff4d5942263c09b9852986c47aaa32

Of course, this could be an argument for not enabling such things. ;-)


Ok. Interesting. I can see how this sort of flexibility is useful. So 
I'm fine if folks want to add board-distro specific tweaks. Trying to 
find some more unified way of building might be necessary, so folks 
aren't having to customize things too drastically. Your directory method 
seems like would solve this, but I need to spend some more time 
understanding Andy's suggestion and understanding how it works with 
Andrey's centralized tree.


I recognize everyone has a different workflow here, and I do want to 
allow for flexibility. So it might be reasonable to start w/ the config 
dir that Tixy is suggesting, and only convert the build scripts for 
those boards using it. Leaving the others to use their own methods.


Ricardo, Zach: Do either of you have any thoughts feedback here?

thanks
-john


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

Re: Config fragment for Versatile Express

[John Stultz]

On 03/31/2012 02:17 AM, Jon Medhurst (Tixy) wrote:

On Fri, 2012-03-30 at 10:15 -0700, John Stultz wrote:

In that case, just go ahead and push the full config to the config tree.
If we need to do have fullly-enabled vs upstream builds we can deal with
the warnings in the latter case (or maybe further split the board
configs into -upstream and -lt ?).


So this means Landing Teams should host the configs for their boards and
you will host the linaro-base, ubuntu and android fragments?


I guess it depends on whats easiest. I'm fine hosting all the configs, 
if landing teams want to provide them to me. But if landing teams want 
to host them, that's fine too.



We almost certainly need board specific android and ubuntu fragments as
well, so I'll add vexpress-android.conf and vexpress-ubuntu.conf as
well. (Unless there is some magic to have conditional config options in
a fragment?)


No, the config fragments are pretty simple, so there's no conditional 
logic in them. Your idea for a board-type.conf style split sounds like a 
fair idea. Although, I'm curious what would be an example of this?


thanks
-john


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

Re: [RFC] First pass config fragment breakout for linaro kernel

[John Stultz]

On 03/30/2012 12:00 AM, Tushar Behera wrote:


Right, some of the config options should better move to the feature
branches. I have cleaned up origen.conf so that we can now boot
linux-linaro-tracking kernel till the console. Code dropped at [1].

With the help of a couple of patches[2], I was able to get Ubuntu
booting up till home screen.

I haven't tested Android though.

Following is the list of added patches.
0b066ba ARM: EXYNOS: Increase DMA pool allocator size for framebuffer
This patch is not required if CMA patches are added to the kernel.

fb8fa05 ARM: EXYNOS: Add clkdev lookup entry for lcd clock
A rebased version of this patch is queued for 3.4-rc1.

[1] git://git.linaro.org/landing-teams/working/samsung/kernel.git
(topic/linaro_config_3.3)

So I'm merged in your changes.

Although per the discussion with Tixy, you can go ahead and push any 
other configs required by out of tree features.  Having topic branches 
based off of the config tree isn't really the right approach.  Sorry for 
causing extra work here.


thanks
-john


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

Re: Config fragment for Versatile Express

[John Stultz]

On 03/30/2012 10:07 AM, Jon Medhurst (Tixy) wrote:

On Fri, 2012-03-30 at 09:33 -0700, John Stultz wrote:

On 03/30/2012 01:19 AM, Jon Medhurst (Tixy) wrote:

To do that the vexpress config fragment will need to be a topic branch
on the ARM Landing Teams git, and every topic which changes a config
needs to be stacked on top of that. Is that what is expected?

I'm not sure I'm following you here.  I'm hoping to have the base
configs added to the lianro-android tree, then as each topic gets
merged, the topics which require an option, enable them in the fragments
as well.

I'm not sure I follow you either :-)

Our topic branches are based on mainline Linux. If those topics require
config changes, do you suggest they add a separate config fragment? Or
patch an existing one? If the latter, where does this fragment come
from? It will have to exist into our tree and our topics based on top of
it. I was saying that in the case of the vexpress fragment, this would
live in our tree as it's own topic branch and be pulled into
linux-linaro. Which seems to make sense, as our tree exists to provide
enablement for vexpress.

Right right right. I forgot with the new topic branch method, everything 
based on mainline and not a tree Andrey maintains, so you don't have a 
reference to the config tree.


In that case, just go ahead and push the full config to the config tree. 
If we need to do have fullly-enabled vs upstream builds we can deal with 
the warnings in the latter case (or maybe further split the board 
configs into -upstream and -lt ?).


The only hard part is that I have to somewhat blindly trust the configs 
being sent to me, as the tree I'm building/testing with doesn't 
necessarily have all of the features requested.  But I'll try to get the 
build folks to keep me in the loop on what warnings they see.


thanks
-john



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

Re: Config fragment for Versatile Express [ was: [RFC] First pass config fragment breakout for linaro kernel]

[John Stultz]

On 03/30/2012 01:19 AM, Jon Medhurst (Tixy) wrote:

On Thu, 2012-03-29 at 11:00 -0700, John Stultz wrote:

On 03/29/2012 02:22 AM, Jon Medhurst (Tixy) wrote:

John, I've attached a config fragment for Versatile Express.

Great! I've merged that in!  There's a few warnings though:

Value requested for CONFIG_ARCH_VEXPRESS_DT not in final .config
Requested value:  CONFIG_ARCH_VEXPRESS_DT=y
Actual value:

Value requested for CONFIG_FB_ARMHDLCD not in final .config
Requested value:  CONFIG_FB_ARMHDLCD=y
Actual value:

I'm guessing these are features not in the base 3.3 tree? If so you
might want to break those out and re-add them with those patches.

To do that the vexpress config fragment will need to be a topic branch
on the ARM Landing Teams git, and every topic which changes a config
needs to be stacked on top of that. Is that what is expected?
I'm not sure I'm following you here.  I'm hoping to have the base 
configs added to the lianro-android tree, then as each topic gets 
merged, the topics which require an option, enable them in the fragments 
as well.  Then as topic branch features are merged upstream, those 
config enablement patches get merged into the base config tree.


However, if that sort of fine-grained management is too onerous, I'm ok 
with dealing with the warnings.  I realize that managing the patch 
queues can be hard enough work, so I don't mean to add more work if it 
doesn't provide much benefit.




Currently I have two separate topics with monolithic Android and Ubuntu
configs, so if we are moving over to config fragments I can delete
these?
Well, you might hang on to them somewhere, just to make sure no configs 
get moved or dropped and then cause problems later on.


thanks
-john


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

Re: [RFC] First pass config fragment breakout for linaro kernel

[John Stultz]

On 03/29/2012 09:57 PM, Tushar Behera wrote:


The new log messages are because of this config entry.
CONFIG_PROVE_LOCKING=y

But the information is useful, hence better it stays that way.


Yea. The lockdep output is super useful for catching really hard to 
trigger bugs. Take those warnings seriously. :)


-john


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

Re: [RFC] First pass config fragment breakout for linaro kernel

[John Stultz]

On 03/28/2012 09:37 PM, Tushar Behera wrote:

On 03/28/2012 10:17 PM, John Stultz wrote:

On 03/28/2012 05:24 AM, Tushar Behera wrote:


I have not validated the changes in android.conf, but by merging
linaro-base.conf and origen.conf, I was able to boot my kernel the way I
would have expected when using exynos4_defconfig.

One thing I notice is that I find far too many debug messages with this
new config.

You mean the debug output from the merge_config.sh script is a bit
noisy?  Yea. Likely we'll have some extra noise as we settle out what
options needs to be generic vs board specific.  But it should decrease
over time.


I was talking about the console log messages upon booting on a target board.
Ok. Can you send me a "Before" config where you didn't see all the log 
messages?


thanks
-john


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

Re: Config fragment for Versatile Express [ was: [RFC] First pass config fragment breakout for linaro kernel]

[John Stultz]

On 03/29/2012 02:22 AM, Jon Medhurst (Tixy) wrote:

On Mon, 2012-03-26 at 12:20 -0700, John Stultz wrote:

So after talking about it at the last Linaro Connect, I've finally
gotten around to making a first pass at providing config fragments for
the linaro kernel.  I'd like to propose merging this for 12.04, and
doing so early so we can make sure that all the desired config options
are present in the fragments and to allow the vairous linaro build
systems to begin migrating their config generation over.

The current tree is here:

  
http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=refs/heads/linaro-configs-3.3


[...]

I'd ask Landing teams to take a look at this, and report any missing
config options or fragment chunks they'd like to see.

John, I've attached a config fragment for Versatile Express.

Great! I've merged that in!  There's a few warnings though:

Value requested for CONFIG_ARCH_VEXPRESS_DT not in final .config
Requested value:  CONFIG_ARCH_VEXPRESS_DT=y
Actual value:

Value requested for CONFIG_FB_ARMHDLCD not in final .config
Requested value:  CONFIG_FB_ARMHDLCD=y
Actual value:

I'm guessing these are features not in the base 3.3 tree? If so you 
might want to break those out and re-add them with those patches.



This includes loadable module support because one of our topic branches
adds the gator module with a default config of 'm'. I did this because
Linaro kernels are expected to have this module available but I didn't
see any reason for it to be built-in, and as there may be versioning
issues between it and the separate user side daemon, I thought it wise
to keep the door open for loading an alternate module obtained from
elsewhere. That decision does mean that all Linaro kernels would need
loadable module support built in, but I don't think that is a bad idea.

Tushar had similar request, but I don't think the android configs (at 
least the ones I've managed) use modules, so I've added the MODULES=y to 
the common ubuntu.conf file.


If this is still objectionable, it can be changed and we can push it 
down to the linaro-base.conf, but I want to make sure the Android tree 
doesn't run into trouble.


thanks
-john






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

Re: [RFC] First pass config fragment breakout for linaro kernel

[John Stultz]

On 03/28/2012 09:37 PM, Tushar Behera wrote:

On 03/28/2012 10:17 PM, John Stultz wrote:

On 03/28/2012 05:24 AM, Tushar Behera wrote:

On 03/27/2012 12:50 AM, John Stultz wrote:

  So after talking about it at the last Linaro Connect, I've finally
gotten around to making a first pass at providing config fragments for
the linaro kernel.  I'd like to propose merging this for 12.04, and
doing so early so we can make sure that all the desired config options
are present in the fragments and to allow the vairous linaro build
systems to begin migrating their config generation over.

The current tree is here:


http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=refs/heads/linaro-configs-3.3




The most relevant commit being:


http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=commitdiff;h=da8f6d20e1a768cb486005c5ec62582b6f92990d




This includes config fragments for a linaro-base, an android-ization
fragment, and  board configs for panda, origen and imx53.

I suspect we'll need an ubuntu specific fragment as well as all the
other board fragments.

There is likely to be quite a bit of churn as we decide what sort of
configs are really common and which are board specific. But that's ok.

Configs are generated from the config fragments, as follows:

./scripts/kconfig/merge_config.sh ./configs/linaro-base.conf
./configs/android.conf ./configs/panda.conf


You may see warnings, which are not fatal, but should be reported so
they can be properly cleaned up.

I'm asking for Build folks to take a look at the above and consider how
they might merge in fragment assembly into their system replacing their
current config generation.

I'd ask Landing teams to take a look at this, and report any missing
config options or fragment chunks they'd like to see.


I have updated origen.conf and linaro-base.conf for testing Samsung LT
kernel. The results are updated in [1].

I'll take a look at the changes and try to merge them into my tree.

Ok. I've merged most of what you added, but made some tweaks of my own 
to quiet some of the warnings at merge time.


Let me know if you see anything badly missing. Some of the items I 
dropped look like they're from feature branches?


thanks
-john


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

Re: [RFC] First pass config fragment breakout for linaro kernel

[John Stultz]

On 03/28/2012 06:07 AM, Jon Medhurst (Tixy) wrote:
Sorry, there's a bug in the ubuntu config, 
CONFIG_DEFAULT_MMAP_MIN_ADDR should be 32768, not 0. 

Thanks! I'll make sure that gets fixed.
-john


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

Re: [RFC] First pass config fragment breakout for linaro kernel

[John Stultz]

On 03/28/2012 05:24 AM, Tushar Behera wrote:

On 03/27/2012 12:50 AM, John Stultz wrote:

 So after talking about it at the last Linaro Connect, I've finally
gotten around to making a first pass at providing config fragments for
the linaro kernel.  I'd like to propose merging this for 12.04, and
doing so early so we can make sure that all the desired config options
are present in the fragments and to allow the vairous linaro build
systems to begin migrating their config generation over.

The current tree is here:


http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=refs/heads/linaro-configs-3.3



The most relevant commit being:


http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=commitdiff;h=da8f6d20e1a768cb486005c5ec62582b6f92990d



This includes config fragments for a linaro-base, an android-ization
fragment, and  board configs for panda, origen and imx53.

I suspect we'll need an ubuntu specific fragment as well as all the
other board fragments.

There is likely to be quite a bit of churn as we decide what sort of
configs are really common and which are board specific. But that's ok.

Configs are generated from the config fragments, as follows:

./scripts/kconfig/merge_config.sh ./configs/linaro-base.conf
./configs/android.conf ./configs/panda.conf


You may see warnings, which are not fatal, but should be reported so
they can be properly cleaned up.

I'm asking for Build folks to take a look at the above and consider how
they might merge in fragment assembly into their system replacing their
current config generation.

I'd ask Landing teams to take a look at this, and report any missing
config options or fragment chunks they'd like to see.


I have updated origen.conf and linaro-base.conf for testing Samsung LT
kernel. The results are updated in [1].

I'll take a look at the changes and try to merge them into my tree.


I have not validated the changes in android.conf, but by merging
linaro-base.conf and origen.conf, I was able to boot my kernel the way I
would have expected when using exynos4_defconfig.

One thing I notice is that I find far too many debug messages with this
new config.
You mean the debug output from the merge_config.sh script is a bit 
noisy?  Yea. Likely we'll have some extra noise as we settle out what 
options needs to be generic vs board specific.  But it should decrease 
over time.



Going forward, would it be better to have linaro-base.conf, android.conf
and ubuntu.conf managed centrally and each LT managing their board
specific configuration file. That way, we can include the changes in our
board specific configurations in respective topic branches.
So yea, I'd like to delegate/give away as much management of the configs 
as possible.  :)


That said, I do think that we'll need someone looking at the entire 
cross-board fragment picture (since if everyone needs an option, it 
really isn't board specific).   So it might be a good idea to have basic 
board config fragments that work with upstream. Then any board-specific 
feature branches can add their config needs in as a patch on top.


Does that sound reasonable?

thanks
-john







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

Re: [RFC] First pass config fragment breakout for linaro kernel

[John Stultz]

On 03/27/2012 01:48 AM, Ryan Harkin wrote:

Hi John,

On 26 March 2012 20:20, John Stultz <mailto:john.stu...@linaro.org>> wrote:


   So after talking about it at the last Linaro Connect, I've
finally gotten around to making a first pass at providing config
fragments for the linaro kernel.  I'd like to propose merging this
for 12.04, and doing so early so we can make sure that all the
desired config options are present in the fragments and to allow
the vairous linaro build systems to begin migrating their config
generation over.

The current tree is here:


http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=refs/heads/linaro-configs-3.3


The most relevant commit being:


http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=commitdiff;h=da8f6d20e1a768cb486005c5ec62582b6f92990d


This includes config fragments for a linaro-base, an
android-ization fragment, and  board configs for panda, origen and
imx53.

I suspect we'll need an ubuntu specific fragment as well as all
the other board fragments.

There is likely to be quite a bit of churn as we decide what sort
of configs are really common and which are board specific. But
that's ok.

Configs are generated from the config fragments, as follows:

./scripts/kconfig/merge_config.sh ./configs/linaro-base.conf
./configs/android.conf ./configs/panda.conf


You may see warnings, which are not fatal, but should be reported
so they can be properly cleaned up.

I'm asking for Build folks to take a look at the above and
consider how they might merge in fragment assembly into their
system replacing their current config generation.

I'd ask Landing teams to take a look at this, and report any
missing config options or fragment chunks they'd like to see.

thanks
-john


Is there a recommended way of generating a config fragment for a board?


Hey, sorry I missed this email yesterday.

Currently, the vexpress config is quite large and its origin is 
unknown to the LT.  If I remove the linaro-base.conf entries from our 
config, we still end up with a config that is 793 lines long.


In that set, there are things like CONFIG_WLAN=y.  We don't have WLAN 
on vexpress.  That's an easy case, but what about other more obscure 
things like CONFIG_XZ_DEC_BCJ, or CONFIG_FS_POSIX_ACL.  I don't know 
what they are, where they've come from or if we need them.  I know 
that the other platforms don't set them.


Or is it simpler to start from scratch and add in what we know we need?


As Andy already pointed out, savedefconfig is a good starting point. 
That gets rid of the config options that are already "default"


From there, I do something like the following:

$ ./scripts/kconfig/merge_config.sh -r  ./configs/linaro-base.conf 
./configs/ubuntu.conf ./mysaveddefconfig


The -r option will warn on options that are redundantly set. So you can 
then go through and eliminate them from the mysaveddefconfig,  and then 
copy it to the config dir.


There will be some messiness here as we really haven't finalized how the 
generic/distro/board split works out. There will likely be a few special 
cases, but we'll get it sorted.


thanks
-john



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

Re: [RFC] First pass config fragment breakout for linaro kernel

[John Stultz]

On 03/27/2012 06:40 AM, Jon Medhurst (Tixy) wrote:

On Mon, 2012-03-26 at 12:20 -0700, John Stultz wrote:

I suspect we'll need an ubuntu specific fragment as well as all the
other board fragments.

The Ubuntu packaging scripts check that various config options are set,
using these I have created an unbuntu.conf (attached) - I doubt this is
what could be called a final version.

Very cool! Thanks so much for providing this! I'll add it to my tree.


The packaging scripts also have various checks for Linaro config options
which I believe are missing from linaro-base.conf, these are:

   CONFIG_HW_PERF_EVENTS=y
   CONFIG_ENABLE_DEFAULT_TRACERS=y || CONFIG_GENERIC_TRACER=y


I'll add these as well, thanks so much!


Finally, where can I find links to any docs on config fragments? I
started trying to create a fragment for vexpress which just contained:

CONFIG_ARCH_VEXPRESS=y
CONFIG_ARCH_VEXPRESS_CA9X4=y

but merge_config.sh said "Value requested for CONFIG_ARCH_VEXPRESS not
in final .config".

So this is likely due to the ARCH_VEXPRESS option having dependencies 
that aren't met.


They way I usually sort this out is, after building the config.  I call 
make menuconfig and hit "/ARCH_VEXPRESS" and it will show the current 
state of the dependencies for that option. The ones that aren't set, I 
then add to the config fragment.


But as the larger point about documentation, its severely lacking right 
now.  My apologies for that.  I'll see if I can find some time in the 
near future to improve this. If you have any specific documentation 
suggestions, I'd be happy to incorporate them .


thanks
-john


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

[RFC] First pass config fragment breakout for linaro kernel

[John Stultz]

So after talking about it at the last Linaro Connect, I've finally 
gotten around to making a first pass at providing config fragments for 
the linaro kernel.  I'd like to propose merging this for 12.04, and 
doing so early so we can make sure that all the desired config options 
are present in the fragments and to allow the vairous linaro build 
systems to begin migrating their config generation over.


The current tree is here:


http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=refs/heads/linaro-configs-3.3


The most relevant commit being:


http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=commitdiff;h=da8f6d20e1a768cb486005c5ec62582b6f92990d


This includes config fragments for a linaro-base, an android-ization 
fragment, and  board configs for panda, origen and imx53.


I suspect we'll need an ubuntu specific fragment as well as all the 
other board fragments.


There is likely to be quite a bit of churn as we decide what sort of 
configs are really common and which are board specific. But that's ok.


Configs are generated from the config fragments, as follows:

./scripts/kconfig/merge_config.sh ./configs/linaro-base.conf 
./configs/android.conf ./configs/panda.conf


You may see warnings, which are not fatal, but should be reported so 
they can be properly cleaned up.


I'm asking for Build folks to take a look at the above and consider how 
they might merge in fragment assembly into their system replacing their 
current config generation.


I'd ask Landing teams to take a look at this, and report any missing 
config options or fragment chunks they'd like to see.


thanks
-john



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

Re: Call for topics for the 12.03 release of linux-linaro kernel

[john stultz]

On Thu, 2012-03-08 at 00:07 +0400, Andrey Konovalov wrote:
> Greetings,
> 
> I've pushed the baseline for the 12.03 linux-linaro kernel tree to
> git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro branch.
> 
> Currently this is v3.3-rc6 plus:
> - 4 topics from the ARM LT
> - few commits being carried over from linux-linaro-3.1
> 
> This tree is not a history one, it will be rebased fairly often.
> 
> We are moving to a new process (more details will come later).
> That's why the call for topics, not patches. If you have something to be 
> included into the 12.03 and the following linux-linaro kernel releases, 
> please send me a link to the git branch to pull from. This must be a 
> "permanent" location, as this topic branch will be used for all the 
> following releases (until there is a request from the topic owner to 
> stop tracking it). As long as the topic branch merges OK into 
> linux-linaro, it will be present in the linux-linaro releases. The topic 
> branch should be based on recent linux-linaro or mainline Linus tree 
> (like v3.3-rc5 or v3.3-rc6).

Here's the current AOSP 3.3 android queue, with no modifications:
git://git.linaro.org/people/jstultz/android.git linaro-android-3.3

thanks
-john



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

Re: Initial Linaro+Android kernel for 12.02 is available

[john stultz]

On Mon, 2012-02-20 at 17:19 -0600, Zach Pfeffer wrote:
> Paul,
> 
> Would you get Andrey setup to push to android.git.linaro.org?
> 
> We should name it
> 
> kernel/kwg.git
> 
> Sound good with everyone?

Why not reuse the existing kernel/linaro-android.git ?

thanks
-john



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

Re: Initial Linaro+Android kernel for 12.02 is available

[john stultz]

On Sat, 2012-02-18 at 00:16 +0400, Andrey Konovalov wrote:
> Greetings,
> 
> The tree is here:
> git://git.linaro.org/people/ynk/linux-linaro-tracking.git
> branch: linaro-android
> tag: linux-linaro-3.3-rc3-2012.02-1-android-0

Zach, now that Andrey is running the kernel show, you might need to get
him direct git push access to the linaro gerrit trees in order to make
sure his kernels get integrated into the Android build envioronment.

thanks
-john



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

Re: Minimum timing resolution in Ubuntu/Linaro on the PandaBoard ES

[John Stultz]

On Wed, 2012-02-08 at 04:32 -0500, Andrew Richardson wrote:
> Ah, very interesting.

> > dmesg | grep clock
> [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz
> [0.00] sched_clock: 32 bits at 32kHz, resolution
> 30517ns, wraps every 131071999ms

Hrm. So 30us is still much smaller then the 2.5ms you were seeing. So
that doesn't fully explain the behavior.

thanks
-john






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

Re: Minimum timing resolution in Ubuntu/Linaro on the PandaBoard ES

[John Stultz]

On Wed, 2012-02-08 at 04:32 -0500, Andrew Richardson wrote:
> Ah, very interesting.

> > dmesg | grep clock
> [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz
> [0.00] sched_clock: 32 bits at 32kHz, resolution
> 30517ns, wraps every 131071999ms

Hrm. So 30us is still much smaller then the 2.5ms you were seeing. So
that doesn't fully explain the behavior.

thanks
-john





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

Re: Minimum timing resolution in Ubuntu/Linaro on the PandaBoard ES

[John Stultz]

On Tue, 2012-02-07 at 21:21 -0800, Dmitry Antipov wrote:
> BTW, I have no ideas why clock_getres(CLOCK_REALTIME,...) returns {0, 1}
> regardless of underlying clock source. I expect {0, 30517} for 32K timer
> and {0, 26} for MPU timer.

Yea. I had proposed to export the underlying clocksource's resolution
via clock_getres, but it was argued against. The concern is that
applications might not expect clock_getres to change while the
application is running.  Between any clock_getres() call and a time
read, the clocksources could change.

But if someone has a different reading of the posix spec, it might be
good to revisit this.

thanks
-john



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

Re: Minimum timing resolution in Ubuntu/Linaro on the PandaBoard ES

[John Stultz]

On Tue, 2012-02-07 at 20:21 -0500, Andrew Richardson wrote:
> On Feb 7, 2012, at 7:30 PM, John Stultz wrote:
> > On Wed, 2012-02-08 at 00:16 +0100, Zygmunt Krynicki wrote:
> > Hrm. No, that shouldn't be the case. CLOCK_MONOTONIC and
> > CLOCK_REALTIME
> > are driven by the same accumulation, and are only different by an
> > offset.
> > 
> > That said, in the test case you're using CLOCK_MONOTONIC_RAW, which
> > I
> > don't think you really want, as its not NTP freq corrected. In
> > addition
> > it is driven by some slightly different accumulation logic.  But you
> > said CLOCK_REALTIME showed the same issue, so its probably not some
> > CLOCK_MONOTONIC_RAW specific bug.
> > 
> 
> 
> In general, I don't want the time value moving around on me (in case
> something weird is going on and it's changing too much). This seems to
> be what most people advise when it comes to profiling something with
> sub-second execution, but I might be misunderstanding you slightly.

The difference is "hardware constant" vs "software controlled time
constant". And with all things time, its all relative. :)

CLOCK_MONOTONIC_RAW is uncorrected, so a second may not really be a
second and things like thermal changes can cause fluctuations in your
timing intervals. CLOCK_MONOTONIC is NTP corrected, so a second should
be a second and thermal drift should be corrected for, but that depends
on how much you trust ntpd.

That said, CLOCK_MONOTONIC can really only be corrected to 500ppm of
CLOCK_MONOTONIC_RAW, so I suspect the difference won't really matter
that much unless your measuring longer intervals. Its not like
CLOCK_REALTIME, which is more problematic as it may be set back and
forth any amount of time.


> Seems a bit too high, right? I did get some low values, such as a
> 500nanoseconds difference, once. I was expected a harsh lower bound
> (e.g. a few ms), but a measurement of 500ns elapsed makes that theory
> unlikely.

Yea. I suspect something else is at play here.

thanks
-john




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

Re: Minimum timing resolution in Ubuntu/Linaro on the PandaBoard ES

[John Stultz]

On Wed, 2012-02-08 at 00:16 +0100, Zygmunt Krynicki wrote:
> On 02/07/2012 11:43 PM, Andrew Richardson wrote:
> > Greetings,
> >
> > I'm experiencing what appears to be a minimum clock resolution issue in
> > using clock_gettime() on a PandaBoard ES running ubuntu.
> >
> > *> uname -r*
> > 3.1.1-8-linaro-lt-omap
> >
> > *> cat /proc/version*
> > Linux version 3.1.1-8-linaro-lt-omap (buildd@diphda) (gcc version
> > 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) )
> > #8~lt~ci~20120118001257+025756-Ubuntu SMP PREEMPT Thu Jan 19 09:
> >
> > I'm using clock_gettime() (and have tried gettimeofday()) to compute the
> 
> Which clock_t were you using? I think CLOCK_MONOTONIC makes sense for 
> what you are trying to do and perhaps it has different resolution/accuracy.

Hrm. No, that shouldn't be the case. CLOCK_MONOTONIC and CLOCK_REALTIME
are driven by the same accumulation, and are only different by an
offset.

That said, in the test case you're using CLOCK_MONOTONIC_RAW, which I
don't think you really want, as its not NTP freq corrected. In addition
it is driven by some slightly different accumulation logic.  But you
said CLOCK_REALTIME showed the same issue, so its probably not some
CLOCK_MONOTONIC_RAW specific bug.

> > elapsed time around roughly 15ms of computation (image processing).
> > While the computed time is stable on my x86_64 machine, it is not on my
> > PandaBoard ES. I have tried various clocks (e.g. CLOCK_REALTIME), but
> > the issue remains. No error codes are returned by clock_gettime().
> >
> > The result on my x86_64 machine looks like this:
> >
> > *elapsed (s) elapsed (ns) elapsed (us) time (after) time (before)*
> > 0s 532260ns *532us* (t1: 73741s 92573265ns) (t0: 73741s 92041005ns)
> > 0s 544413ns *544us* (t1: 73741s 109390136ns) (t0: 73741s 108845723ns)
> > 0s 529328ns *529us* (t1: 73741s 126024860ns) (t0: 73741s 125495532ns)
> >
> > A: 1.7s in total. *0.536ms* on average.
> >
> >
> > If I move over to my PandaBoard ES, I calculate elapsed times of 0us on
> > some iterations.
> >
> > *elapsed (s) elapsed (ns) elapsed (us) time (after) time (before)*
> > 0s 0ns *0us* (t1: 269529s 192626951ns) (t0: 269529s 192626951ns)
> > 0s 0ns *0us* (t1: 269529s 215606688ns) (t0: 269529s 215606688ns)
> > 0s 2655030ns *2655us* (t1: 269529s 252349852ns) (t0: 269529s
> > 249694822ns)
> > 0s 2593994ns *2593us* (t1: 269529s 286163328ns) (t0: 269529s
> > 283569334ns)
> > 0s 30518ns *30us* (t1: 269529s 317657469ns) (t0: 269529s 317626951ns)
> >
> >
> > If I crank up the amount of work done between the time calls
> > (timetest.c:18: inneriters = 1e7;) such that the timed loop takes around
> > 72ms, the timing results seem accurate and none of the intermediate
> > calculations result in a 0us elapsed time. If I reduce it to around
> > 10-25ms (inneriters=1e6), I get occasional 0us elapsed times. Around 2ms
> > (inneriters=1e5), most results measure an elapsed time of 0us.

Hrm. So I'm not familiar with the clocksource on panda. It may be so
coarse grained as to not allow for better intervals, but 2.5ms intervals
are a little outrageous. In the above you do have a 30us interval, so
clearly there are smaller intervals, so I doubt that is the real issue.

2.5ms is much closer to a tick length when HZ=300. Or a sched out and in
w/ HZ=1000.


> > I'm trying to optimize image processing functions, which take on the
> > order of 2-15ms to process. Am I stuck with this timing resolution? I
> > want to be careful to not omit issues like cache performance when
> > timing, as I might if I repeatedly process an image to average the
> > results. Currently, that seems like the best option.

Might the compiler be out smarting you, and you end up with basically
two calls to clock_gettime() next to each other? Then it would be more
normal to see 0 ns time intervals (if the clocksource is somewhat coarse
grained), with the occasional scheduling blip hitting inbetween the
timings? 

This explanation doesn't match your image timing results though, as I
assume you're doing actual work in that case. 

Hmmm. I'm a little stumped. Can anyone closer to the OMAP hardware
comment?

thanks
-john




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

Re: [PATCH] hrtimers, timers: eliminate some jiffies-backed code

[john stultz]

On Mon, 2012-01-23 at 19:40 +0400, Dmitry Antipov wrote:
> This patch provides an attempt to get away from jiffies in msleep()
> and msleep_interruptible() to hrtimers-backed usleep_range() and
> usleep_range_interruptible(). Both of the latter now returns an amount
> of microseconds really spent in sleep; another rationale for this
> was to convert msleep()-based wait-for-hardware loops to usleep_range(),
> like this:
> 
> unsigned long timeout = jiffies + msecs_to_jiffies(1000);
> while (hw_is_not_ready()) {
>   if (time_after(jiffies, timeout))
>   return -ETIMEDOUT;
>   msleep(1);
> }
> 
> to:
> 
> unsigned long timeout = 0;
> while (hw_is_not_ready()) {
>   if (timeout > USEC_PER_SEC)
> return -ETIMEDOUT;
>   timeout += usleep_range(500, 1500);
> }
> 
> Signed-off-by: Dmitry Antipov 

So I'm still a little foggy on what actual benefit this change brings.

Why do you want to move loops like the above from jiffies based timeouts
to hrtimers?

Is there an actual need for sub-jiffy granularity in these sorts of
timeouts?

Or is this really just a "getting away from using jiffies" cleanup?


> diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
> index fd0dc30..01d782b 100644
> --- a/include/linux/hrtimer.h
> +++ b/include/linux/hrtimer.h
> @@ -126,6 +126,7 @@ struct hrtimer {
>   * task is set to NULL, when the timer expires.
>   */
>  struct hrtimer_sleeper {
> + ktime_t kt;

kt? Please use a better name here, as the function of that value is
opaque on initial reading.

>   struct hrtimer timer;
>   struct task_struct *task;
>  };
> @@ -428,9 +429,10 @@ extern long hrtimer_nanosleep_restart(struct 
> restart_block *restart_block);
>  extern void hrtimer_init_sleeper(struct hrtimer_sleeper *sl,
>struct task_struct *tsk);
> 
> -extern int schedule_hrtimeout_range(ktime_t *expires, unsigned long delta,
> - const enum hrtimer_mode mode);
> -extern int schedule_hrtimeout_range_clock(ktime_t *expires,
> +extern int schedule_hrtimeout_range(ktime_t *expires, ktime_t *elapsed,
> + unsigned long delta,
> + const enum hrtimer_mode mode);

Another silly nit, but is it just me, or does having elapsed as the
second argument in-between the expiration and the slack seem awkward?


> diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
> index ae34bf5..8642c3f 100644
> --- a/kernel/hrtimer.c
> +++ b/kernel/hrtimer.c
> @@ -1475,6 +1475,12 @@ static enum hrtimer_restart hrtimer_wakeup(struct 
> hrtimer *timer)
>   struct hrtimer_sleeper *t =
>   container_of(timer, struct hrtimer_sleeper, timer);
>   struct task_struct *task = t->task;
> + struct hrtimer_clock_base *base;
> + unsigned long flags;
> +
> + base = lock_hrtimer_base(timer, &flags);
> + t->kt = ktime_sub(base->get_time(), t->kt);
> + unlock_hrtimer_base(timer, &flags);


Calling get_time() again on each hrtimer_wakeup isn't free. 

With this we end up when the irq fires, calling hrtimer_interrupt, which
reads the time and goes through the timer list running expired timers,
which then runs the sleeper's timer which then reads the time again!
Additinoally, this extra overhead is done even no one wants the elapsed
time.

Personally, given the above, I'm not sure what the benefit of of your
implementation over just doing something like the following where
necessary:

u64 now = ktime_get();
u64 timeout = ktime_to_ns(now) + NSEC_PER_SEC;
while (hw_is_not_ready()) {
if (now > timeout)
return -ETIMEDOUT;
usleep_range(500, 1500);
now = ktime_get();
}

If you could rework it so you're not calling gettime any additional
times, but still providing the same elapsed sleep time, then it would
atleast have the benefit of an improvement over my example here.

thanks
-john


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

Re: Problems with timers with linux-next on snowball

[john stultz]

On Thu, 2011-12-15 at 14:06 +0100, Linus Walleij wrote:
> On Thu, Dec 15, 2011 at 1:16 PM, Daniel Lezcano
>  wrote:
> > [Me]
> >>> It is easy to reproduce with 'time sleep 1' where the timer expires 1, 2
> >>> or 3 seconds later.
> >>>
> >>> It seems that does not happen with linux-linaro-3.1 but I was able to
> >>> reproduce the problem on a vanilla kernel 3.1.5.
> >>>
> >>> Is it a known problem ?
> >>
> >> Sleeps are only guaranteed at max speed.
> >
> > I am not sure to get the point. Do you mean cpufreq max frequency ?
> 
> It means that the kernel idea of sleep(1) is, sleep atleast 1 second,
> possibly more. When the system scales down frequency, say to half
> the frequency, things start to take twice the time. So sleep(1) may
> result in 2 seconds of sleep or so.

Just a minor clarification: So, while Linus is right that sleep can
validly go longer then the requested time (the only promise is that it
shouldn't return success early), sleep() should be timer based (not
delay based), so even if the frequency drops, you *shouldn't* see freq
proportional delays.

If that were happening, it would seem timekeeping would also be slowed
down, which def shouldn't happen if we're using a sane clocksource
(although broken clocksources - which may change freq with the cpu -
have caused symptoms like the above). 

That said, Linus knows more about the specific issues around the board,
so I'd defer to him in debugging the issue. I just didn't want anyone to
get the impression that sleep length *should* be proportional to cpu
freq.

thanks
-john


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

Initial Linaro+Android kernel for 11.12 is available

[john stultz]

Zach reminded me that this month is compressed, so a linaro+android
kernel would be needed immediately for 11.12.  As Andrey is just ramping
up in taking over for the Linaro Android kernel maintenance, I wanted to
just get a kernel out, using the older kernel workflow, so that we had
something current for 11.12. 

Anyway. This is straight from Andy Green's
linaro-androidization-tracking branch, with a few small build fixes
added on that I found in my testing and the base android_*_defconfig
files.

You can find the tree here:
git://android.git.linaro.org/kernel/linaro-android.git 
linaro-android-3.2-agreen-rebase

The current sha is tagged as: linux-linaro-3.2-2011.12-0-android-0

Known issues:
There seems to be something in the androidization branch that is causing
problems on beagle xm and origen. In my testing beagle xm kernel ends up
hanging in mid-boot(after ~4 seconds).  And the orgien board doesn't
show anything past "Uncompressing Linux... done, booting the kernel". If
I drop the androidization patches and go back to the v3.2-rc4 base, both
kernels boot until the Android userland environment starts and falls
over because the android features are missing. I mucked about for awhile
on both of these tonight, but wasn't able to solve either of them, so
I'd appreciate any help trying to narrow down what is wrong on Origen
(beagle is apparently lower priority).

Andy, one issue with the re-factored android patch tree: Its not very
bisect-able. If I jump back to a topic branch, frequently there are
missing dependencies that keep it from building. Any thoughts on how we
can better chase down these sorts of issues?

thanks
-john





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

Linaro Android Kernel Release for Nov 2011

[John Stultz]

Just following the release of the linux-linaro-3.1-20011.11-0 tag being
made, I've updated the Linaro+Android tree.

I've tagged it as: linux-linaro-3.1-2011.11-0-android-1

>From the branch:
git://android.git.linaro.org/kernel/linaro-android.git 
linaro-android-3.1-agreen-rebase


thanks
-john



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

Initial linaro-android-3.1 kernel for 11.11

[john stultz]

Just wanted to announce that the initial Linaro+Android-3.1 kernel for
11.11 is available.

I've tagged it as: linux-linaro-3.1-2011.11-0-android-0

>From the branch:
git://android.git.linaro.org/kernel/linaro-android.git 
linaro-android-3.1-agreen-rebase

Please remember Nico is freezing the 11.11 linaro kernel on Monday, and
I'll be tagging the 11.11 linaro-android kernel shortly there after.

thanks
-john


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

Re: Linaro Kernel October 2011 Release

[john stultz]

On Thu, 2011-10-20 at 03:11 -0700, Deepak Saxena wrote:
> The Linaro Kernel Working Group (KWG) is excited to announce the
> availability our October 2011 development snapshot:
> 
> linux-linaro-3.1-2011.10-1
> 
> As the word "snapshot" implies, these are meant as development kernels
> and have not been fully validated. You should expect issues and to help
> us deliver a better kernel in the future, please file bugs in Launchpad at
> https://bugs.launchpad.net/linux-linaro.
> 
> The source tarball is available at:
>  
> http://launchpad.net/linux-linaro/3.1/3.1-2011.10/+download/linux-linaro-3.1-2011.10-1.tar.bz2
> 
> The kernel sources can also be accessed using git at:
>  git://git.linaro.org/kernel/linux-linaro-3.1.git
>  tag: linux-linaro-3.1-2011.10-1
> 
> In addition to an update to the 3.1 (-rc10) kernel, this kernel includes
> the following changes that are queued up for 3.2:
> 
...
>   - boot_params to atag_offset transition froma Nicolas Pitre

Looks like the Origen board support missed something here. I'm getting:

arch/arm/mach-exynos4/mach-origen.c:103: error: unknown field
'boot_params' specified in initializer
make[1]: *** [arch/arm/mach-exynos4/mach-origen.o] Error 1

Commenting out the following allows it to build (I've not yet boot
tested).

thanks
-john

diff --git a/arch/arm/mach-exynos4/mach-origen.c 
b/arch/arm/mach-exynos4/mach-origen.c
index ed59f86..32768a5 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -100,7 +100,7 @@ static void __init origen_machine_init(void)
 
 MACHINE_START(ORIGEN, "ORIGEN")
/* Maintainer: JeongHyeon Kim  */
-   .boot_params= S5P_PA_SDRAM + 0x100,
+// .boot_params= S5P_PA_SDRAM + 0x100,
.init_irq   = exynos4_init_irq,
.map_io = origen_map_io,
.init_machine   = origen_machine_init,



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