<pfefferz> all right
so welcome to 12.02!
the goal is to mkae snowball work great
and origen
iMX53 is semi blocked
<bero> There's still stuff to try there
<pfefferz> and panda gets a lot of attention
<bero> But it would be really useful to get some more information
<pfefferz> bero, lets hold off on iMX53 until we have more info
<jackh> the three bugs assigned to me, i tried this afternoon, two of them
still there
<pfefferz> can you send the current issue set in?
jackh, cool
<jackh> the gallery one does not there
<pfefferz> did you update the thrid?
that's good
feel free to list the build where you don't see it
in the bug
everyone
we have a new team member
jackh, aka Chenglie
has joined us from IBM
<jackh> it's Chengjie He
<pfefferz> welcome Chengjie
<bero> Welcome jackh
<pabhishek> welcome jackh
<pfefferz> right ;)
<jackh> haha, just call me jacky for short...
<bhoj2> welcom jackh :)
<botao_sun> jackh: I will give you a brief later about compiling the code.
<pfefferz> its great to have you on the Android team Chengjie He
we'll do another welcome round on wednesday ;)
<jackh> pls do it face to face, zach...
haha, joking
<pfefferz> :)
so we're gonna focus on getting our tests all green
its a big job
as usuual
:)
we've had some good pickup by the member companies of our concerns
so we shouldn't be as blocked as we were
we also have connect abs and elc
as a reminder all presentations for elc and abs have to be submitted a
week before the event
also
for everyone doing a session
please have a rough agenda listed
something like
here's where we are
here's where we need to be
I'm going to take a more passive role during other people's sessions this
time
:)
any questions or comments?
<mansson__> Prepare a "lightning talk" version of your session (5 min.)
good to have.
<pfefferz> good point mansson__
<pfefferz> the highest prio thing we have right now
is the demo at connect
most everyone is involoved in getting it to happen
I suspect we'll be spending a bunch of time in the hacking sessions making
it work
I have to get a poster together
so one more thing
people arte really starting to use our builds
1. because they're easy to use
2. they work
3. they can talk to us on irc
this means they're looking at our BPs to see how our work is progressing
so that's all I had
thanks for setting the meeting up Tony
anyone have anything else?
<mansson__> I think everything is pretty clear. We continue to make a
lasting impression on human evolution. Making ARM Linux history.
<pfefferz> exactly!
<mansson__> 15 out of 50 talks at ELC are by Linaro people.
<pfefferz> hehe
not bad for a non-sponser
seriously guys
we're changing the world
every little thing we get working
has a giant impact
okay
<pfefferz> mansson__, would you send this transcript out to everyone?
<mansson__> Yes.
<pfefferz> thanks!
For the architectures with it's own module_alloc(), if module init
size is zero, avoiding module_alloc_update_bounds() and memset()
no-op calls also eliminates warn_alloc_failed() zero-size warning
in __vmalloc_node_range().
Signed-off-by: Dmitry Antipov <dmitry.antipov(a)linaro.org>
---
kernel/module.c | 31 +++++++++++++++++--------------
1 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 2c93276..bbe1c5b 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2644,20 +2644,23 @@ static int move_module(struct module *mod, struct load_info *info)
memset(ptr, 0, mod->core_size);
mod->module_core = ptr;
- ptr = module_alloc_update_bounds(mod->init_size);
- /*
- * The pointer to this block is stored in the module structure
- * which is inside the block. This block doesn't need to be
- * scanned as it contains data and code that will be freed
- * after the module is initialized.
- */
- kmemleak_ignore(ptr);
- if (!ptr && mod->init_size) {
- module_free(mod, mod->module_core);
- return -ENOMEM;
- }
- memset(ptr, 0, mod->init_size);
- mod->module_init = ptr;
+ if (mod->init_size) {
+ ptr = module_alloc_update_bounds(mod->init_size);
+ /*
+ * The pointer to this block is stored in the module structure
+ * which is inside the block. This block doesn't need to be
+ * scanned as it contains data and code that will be freed
+ * after the module is initialized.
+ */
+ kmemleak_ignore(ptr);
+ if (!ptr) {
+ module_free(mod, mod->module_core);
+ return -ENOMEM;
+ }
+ memset(ptr, 0, mod->init_size);
+ mod->module_init = ptr;
+ } else
+ mod->module_init = NULL;
/* Transfer each section which specifies SHF_ALLOC */
pr_debug("final section addresses:\n");
--
1.7.7.5
Hi everyone,
Any chance the linux-linaro-*-lt-samsung kernel trees will get updated
(soon)? By the way, is there a daily/nightly build source for these trees? I
am eager to try them out.
TIA - Vic
Gents,
For some time now I am trying to build android from the linaro repos.
Sofar I never succedded, it always resulted in build failures or it doesn't
boot.
So what did it do:
I tried the 11.12 release staging and tracking. Got the last to build after
switching to the 4.6 toolchain (nowhere documented) and
added an include to the png.c file (it misted a math.h include, weird).
It only didn't boot correctly because the kernel failed to initialise the
GPU.
So I switched to the 12.01 release. First used the "release-12.01" branch,
build failure. Then switched to the "linaro_android_4.0.3" branch
Used the same as mentioned in the build service build overview. Also used
the same setup as mentioned in the build service.
Build fails.
Odd thing is that someone must be able to get a successfull build because
ready available images do exist.
So how did these get build? How do I get a good build?
Cheers,
Hedwin
PS, below the build error in the 12.01 release:
workCoreTests_install_verifier_good_intermediates/package.apk)
com.google.doclava.apicheck.ApiParseException: Error parsing API
at
com.google.doclava.apicheck.XmlApiFile.parseApi(XmlApiFile.java:60)
at com.google.doclava.apicheck.ApiCheck.parseApi(ApiCheck.java:152)
at
com.google.doclava.apicheck.ApiCheck.convertToXml(ApiCheck.java:234)
at com.google.doclava.apicheck.ApiCheck.main(ApiCheck.java:64)
Caused by: org.xml.sax.SAXParseException: Content is not allowed in prolog.
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195)
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:174)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:388)
at
com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1414)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:1039)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at
com.google.doclava.apicheck.XmlApiFile.parseApi(XmlApiFile.java:54)
... 3 more
Error parsing API: frameworks/base/api/current.txt
make: *** [out/target/common/obj/APPS/SignatureTest_intermediates/api.xml]
Error 1
make: *** Waiting for unfinished jobs....
Enclosed please find the link to the Weekly Status report & meeting
minutes
for the Power Management working group for the week ending 2012-01-27
== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2012-01-26
== Meeting Minutes ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2012-01-25
== Summary ==
(For details, see the Weekly Status Report and Meeting Minutes )
* Linaro Connect sessions planning & setup
* http://summit.ubuntu.com/lcq1-12/track/linaro-power/
* Common Clock
* Working on changing the code based on feedback from v2-v4 submission,
quite a bit of code change for v5.
* About 50% done on converting OMAP4 to use the new code.
* Thermal Management
* Working on fine tuning of cpufreq/cpuhotplug based cooling devices to
be now instance based (needed for multi core systems)
* Submitted V4 of imx thermal driver
* hrtimer
* Continue working on implementing core high-res timers feature to
return time spent in usleep_range()
* cpuidle
* Submitted at91 standby functions
* Implemented cpuidle WFI state for ux500 based on common framework
* Working on dynamic init function for the common cpuidle code will add
to the next version
* Sched_mc
* Preparing for the scheduler mini-summit at Connect
* Taking measurement on the new sched_mc patch before submitting it,
will try to summit the
patch before connect and cc the attendees of the mini-summit
* Issue
* Team is not getting fast enough feedback on their patches.
Best regards,
Mounir
--
Mounir Bsaibes
Project Manager
Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106http://twitter.com/#!/linaroorghttp://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>
HI.
I'm building a LAVA service for running fast models. Quite soon (*)
we'll be ready to open an alpha access. Right now you will need to
bring your own root filesystem and kernel image to use it. With that
in mind I wanted to start a discussion about the state of A15 support
in Linaro kernel(s). I need to understand two things:
1) Are we ready to do automatic builds for A15 kernels?
2) If so, which configs and trees should we consider
Thanks
Zygmunt Krynicki
(I'm aware that there is a thread on linaro-dev discussing this exact
topic; this is a request for specific information, so I decided to start
a new thread)
Hello,
As has been pointed out elsewhere, it is very difficult to find
the exact git tree that corresponds to a kernel release. Currently the
problem I am having is that the 11.11 linaro kernel release
(linux-linaro-lt-omap_3.1.0-1402.5~oneiric1) works well on my new board,
but later kernels do not. While I can download the kernel tarball for
3.1.0-1402.5 from launchpad, I would much prefer to use the git tree
that it was produced from. Can anybody tell me exactly which git tree
was used to create that kernel, and which tag/branch I should be looking at?
Thanks,
--
Chris Lalancette