== Highlights ==
* Sent v5 of pstore/console patch set, so far it didn't receive any
objections. Perhaps need to ping Greg, as the merge window is now
closed;
* Finished and sent out pstore/ftrace support; it got a preliminary
thumbs up from Steven. Will need to merge the support to the generic
function tracer, turning persistent storage into a flag.
* Discussed various approaches to make continuous console logging in
pstore. And as a part of it tried to make linux_banner printing
somewhat more consistent. But folks did not like it, so in the end
we'll have just one console log buffer, as it was with ram_console;
* Restarted work on vmevents, but got unflattering comments from
KOSAKI, plus Minchan started to doubt about the notifiers in
general. There is some blowing hot and cold started again.
== Plans ==
* Repost pstore/ftrace support with Steven Rostedt comments fixed.
* Move pstore registration earlier, so that we can record early oopses.
Suggested by Colin Cross.
* Make pstore ecc settings configurable, i.e. address Arve Hjønnevåg's
"nice to have" comment on pstore;
* I plan to finish all the major pstore items this week, and thus will
have to pick a new task;
* See how vmevents discussion turns out.
--
Anton Vorontsov
Email: cbouatmailru(a)gmail.com
Hello,
Its been close to a month now that the kernel CI hwpacks built on
ci.linaro.org with default omap2plus defconfigs
(available in the linux-arm-soc, linux-next, linux-linaro, linux) are
failing to boot on the boards.
Here is an example hwpack built using the linux-linaro tree with omap2plus
defconfig on ci.linaro.org which is failing to boot, in case you want to
try to test it.
http://snapshots.linaro.org/kernel-h
wpack/linux-linaro-tracking/linux-linaro-tracking_panda-omap2plus/hwpack_linaro-lt-panda_20120509-0641_b64_armel_supported.tar.gz<http://snapshots.linaro.org/kernel-hwpack/linux-linaro-tracking/linux-linar…>
I was able to fix the above boot problem of the CI kernel hwpacks built
with omap2plus defconfig
by adding the options similar to the ones available in (linux-linaro tree)
default omap4 defconfig on top of the default
omap2plus defconfig options.
Here is the list of the config options which I added
http://paste.ubuntu.com/977642/ along with the omap2plus
defconfig to make it work.
Can someone help me with the basic omap2plus defconfig options that will be
required to boot the hwpack on the board.
Does anyone care of kernel builds for linux-arm-soc, linux-next,
linux-linaro, linux tree using omap2plus defconfigs ?
Apart from this, there are build failures with the linux-next trees failing
since last 20 days.
https://ci.linaro.org/jenkins/view/Linux%20%28next%29/ lists such failing
build jobs.
For example the following job fails
https://ci.linaro.org/jenkins/view/Linux%20%28next%29/job/linux-next_panda-…
.
Can someone look at these linux-next build failures ?
--
Thanks and Regards,
Deepti
Infrastructure Team Member, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
This is in the leaves calendar but thought I'd let folks know that I'm
off Monday (which is mostly over for me) and tomorrow while I explore
Beijing and then off to Linuxcon Japan tue-friday. I'm taking a few
days off and will be back home next Tuesday evening PST, back to work
sometime on Wed. I'll be checking email the whole time between now and
next wed. If you need me for something urgent, email me and then txt
me (+15039578596) so I get to my email ASAP.
Thanks,
~Deepak
=== Highlights ===
* Reworked the fallocate volatile code per feedback and sent out two
iterations.
* Remotely presented Android Upstreaming status at Connect.
* Fixed a leapsecond bug that was reported and sent it in for 3.5
* Spent some time getting my timekeeping queue for 3.6 in order
* Sent out the Android Upstreaming biweekly team email
=== Plans ===
* Continue fallocate volatile discussion and code iterations.
* Hopefully get a fix for the panda HDMI issue that's blocking my
testing of upstreamed Android work that landed in 3.5
* Dig in on some of the items LinusW suggested I look at during the
Connect session.
=== Issues ===
NA
Hi all,
This is another resend of several task->mm fixes, the bugs I found
during LMK code audit. Architectures were traverse the tasklist
in an unsafe manner, plus there are a few cases of unsafe access to
task->mm in general.
There were no objections on the previous resend, and the final words
were somewhere along "the patches are fine" line.
In v3:
- Dropped a controversal 'Make find_lock_task_mm() sparse-aware' patch;
- Reword arm and sh commit messages, per Oleg Nesterov's suggestions;
- Added an optimization trick in clear_tasks_mm_cpumask(): take only
the rcu read lock, no need for the whole tasklist_lock.
Suggested by Peter Zijlstra.
In v2:
- introduced a small helper in cpu.c: most arches duplicate the
same [buggy] code snippet, so it's better to fix it and move the
logic into a common function.
Thanks,
--
Anton Vorontsov
Email: cbouatmailru(a)gmail.com