== Status ==
* Started working on common clock support for Exynos4 platforms.
== Next Week ==
* Complete initial implementation of the common clock support for
Exynos4 platforms.
== Misc ==
* Was on leave from Sept-11 to Sept-14.
=== Highlights ===
* Setup kvm development environment.
1) build Cortex A15x1 fast model simulator
2) Successfully ran A15x1 simulator on ubuntu PC
3) Ran A15 kernel via qemu-system-arm within simulator environment
* Research kvm subsystem and qemu (read doc and code)
* Research big.LITTLE tech, read ARM doc on it and some online
technical articles
on switcher and bit.LITTLE MP scheduler, started to read ARM
reference switcher code from:
http://git.linaro.org/gitweb?p=arm/big.LITTLE/switcher.git;a=summary
== Highlights ==
* Lots of work for KDB FIQ/NMI debugger, sent out v5, v6 and v7.
Switched NMI console driver to tty_port infrastructure, discussed the
ways to handle serial interrupts quiescing, made magic sequence
configurable. TTY patches got Alan Cox's ack.
* Looked into timer slack support for cgroups. While it's indeed
somewhat close to deferrable timers, it's still not exactly what we
need. Timer slack let us group wakeups, but there is still no way to
tell that the timer/poll/select itself should not cause wakeups. As
for deferrable timers, there are still no comments.
* Looked into ideas on early OOM detection from the userland. There are
a lot of inspirational thoughts on measuring memory stress levels,
and I definitely need to perform some tests. I'll prepare a detailed
answer to the ideas, but the most interesting part is that the ideas
are based on vmstat monitoring, which is important: if we're going to
use vmstat, we'll eventually get beaten by vmstat downsides:
slow/expensive updates (so the latency if the pre-OOM detection would
be equal to vmstat_update_time). And for Android low memory killer
use case, pre-OOM condition is important, but not the main problem:
the main "problem" is to monitor memory level when there is no stress
at all (but deferrable timers would solve this).
* Rebased and applied pstore/ftrace debugfs rework, this is now in
linux-next. Also reviewed/fixed FDT support for pstore, by Bryan
Freed @ Chromium.org.
Hi all,
This patch set implements a userland-side API for generic deferrable
timers, per linux/timer.h:
* A deferrable timer will work normally when the system is busy, but
* will not cause a CPU to come out of idle just to service it; instead,
* the timer will be serviced when the CPU eventually wakes up with a
* subsequent non-deferrable timer.
These timers are crucial for power saving, i.e. periodic tasks that want
to work in background when the system is under use, but don't want to
cause wakeups themselves.
The deferred timers are somewhat orthogonal to high-res external timers,
since the deferred timer is tied to the system load, not just to some
external decrementer source.
So, currently, the implementation has a HZ precision, and the maximum
interval is jiffies resolution (i.e. with HZ=1000, on 32 bit that would
be around max 49 days). Of course we can implement longer timeouts by
rearming the timer, although it probably wouldn't make much sense in
real world, so we keep it simple and just return E2BIG if we don't like
the interval.
Note that the code is still using time calculation that is done by the
hrtimer routines, so we pretty much reuse everything except for the
timer events themselves (i.e. we use calculation results of
hrtimer_forward_now() and hrtimer_expires_remaining(), but never start
the hrtimer). So the code path is pretty much the same for both hrtimers
and deferrable timers.
We will use the timers to periodically read /proc/vmstat without
forcibly waking up the system; but let's see, maybe there are other use
cases that might be interesting for PM folks.
Thanks!
Anton.
--
fs/timerfd.c | 87 +++++++++++++++++++++++++++++++++++++++++++------
include/linux/jiffies.h | 3 ++
include/linux/ktime.h | 3 +-
include/linux/timerfd.h | 4 ++-
kernel/time.c | 23 +++++++++++++
5 files changed, 108 insertions(+), 12 deletions(-)
== Linus Walleij linusw ==
=== Highlights ===
* Finally sent out a patch for SPARSE_IRQ on the Nomadik
and ux500. Sadly it seems that to get a kernel that isn't screaming
at you, transitioning to sparse IRQ can not be done unless you
move over to irqdomains, all dynamic IRQ numbers and device
tree at the same time. This puzzled me for a long time.
* Started to drill into a RCU lockup regression that is still in the
v3.6-rc series, but I'm uncertain if it only affects ux500 or if
it's a generic problem. John Stultz has seen the same message.
* Helped Benjamin with pre-review of a patch to genalloc.
* First review of Lee's patch set for HREF/MOP500 device tree
support for the parts that I understand.
* Fixed a smallish regression on the ks8695 watchdog that
came as fallout from the timer patches.
* Reviewed and merged various GPIO patches.
* Reviewed and merged various pinctrl patches. Currently
the Marvell patch set is taking up a lot of bandwidth but
starting to look really nice.
* Attended an internal workshop on kernel architecture that
stole away some three working days or so, but hey, we get
to influence the ST-Ericsson internal kernel.
=== Plans ===
* Ongoing work on sparse IRQ for Nomadik and Ux500.
* Test the PL08x patches on the Ericsson Research
PB11MPCore and submit platform data for using
pl08x DMA on that platform.
* Look into other Ux500 stuff in need of mainlining...
using an internal tracking sheet for this.
* Look into regmap. Try something out, get to know it.
=== Issues ===
* N/A
Thanks,
Linus Walleij
Hi All,
I was trying booting 3.1.5 linaro kernel with wheezy debian filesystem on
pandaboard, but I found ethernet is not working.
On further check I found, there is no net interface under /sys/class/net/
except loopback. Though I have checked kernel config is having scm91x (and
scm911x) enabled.
I am really not sure about net driver details but I could not see these
drivers are getting probed at kernel boot.
Whereas, I have taken 3.2 kernel from kernel.org and it worked perfectly
fine and there is no change in defconfig file from 3.1.5.
I also observed the code structure for ethernet drivers are different
between 3.1.5 and 3.2 but driver files are same except
*ndo_set_rx_mode* has been implemented in 3.2 in place of *
ndo_set_multicast_list.*
any idea, about this problem? is it known???
Or is it something I am missing??
Thanks in advance
--
With Best Regards,
*Tirtha*
[image: Nico Nico animated GIF --]
Hi All,
I was trying booting 3.1.5 linaro kernel with wheezy debian filesystem on
pandaboard, but I found ethernet is not working.
On further check I found, there is no net interface under /sys/class/net/
except loopback. Though I have checked kernel config is having scm91x (and
scm911x) enabled.
I am really not sure about net driver details but I could not see these
drivers are getting probed at kernel boot.
Whereas, I have taken 3.2 kernel from kernel.org and it worked perfectly
fine and there is no change in defconfig file from 3.1.5.
I also observed the code structure for ethernet drivers are different
between 3.1.5 and 3.2 but driver files are same except
*ndo_set_rx_mode* has been implemented in 3.2 in place of *
ndo_set_multicast_list.*
any idea, about this problem? is it known???
Or is it something I am missing??
Thanks in advance
--
With Best Regards,
*Tirtha*
[image: Nico Nico animated GIF --]
Hi all,
Here is a new revision, mostly tty reworks. The new tty_port stuff is a
bliss: no more per-driver mutex, no more counting for open(),
well-separated initialization callbacks (I hope I got them right :-).
But since I now use a lot of new tty_port stuff, I had to rebase the
patch set on top of tty-next, so there's no point in cherry-picking
anymore.
So, in v6:
- Converted the NMI tty driver to use tty_port helpers, per Alan Cox's
suggestions;
- In uart's poll_init callback fixed a race, spotted by Alan;
- Use test_bit instead of touching port->flags directly;
These patches can be found in the following repo (based on tty-next):
git://git.infradead.org/users/cbou/linux-nmi-kdb.git master
Old changelogs and rationale for these patches can be found here:
v1-v5: http://lkml.org/lkml/2012/9/10/2
Thanks,
--
arch/arm/Kconfig | 19 ++
arch/arm/common/vic.c | 28 +++
arch/arm/include/asm/hardware/vic.h | 2 +
arch/arm/include/asm/kgdb.h | 8 +
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/entry-armv.S | 167 +------------
arch/arm/kernel/entry-header.S | 170 +++++++++++++
arch/arm/kernel/kgdb_fiq.c | 99 ++++++++
arch/arm/kernel/kgdb_fiq_entry.S | 87 +++++++
arch/arm/mach-versatile/Makefile | 1 +
arch/arm/mach-versatile/kgdb_fiq.c | 31 +++
drivers/tty/serial/Kconfig | 19 ++
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/amba-pl011.c | 66 ++++-
drivers/tty/serial/kgdb_nmi.c | 391 ++++++++++++++++++++++++++++++
drivers/tty/serial/kgdboc.c | 16 ++
drivers/tty/serial/serial_core.c | 32 +++
include/linux/kdb.h | 29 ++-
include/linux/kgdb.h | 34 +++
include/linux/serial_core.h | 2 +
include/linux/tty_driver.h | 1 +
kernel/debug/debug_core.c | 36 ++-
kernel/debug/kdb/kdb_main.c | 29 +++
23 files changed, 1076 insertions(+), 193 deletions(-)
Hi all,
There wasn't much feedback on v4, the only comment was from Brian
Swetland concerning async console (I explained how we deal with it).
It would be really great if the core functionality could make it into
v3.7. Which raises the question: if the patches are OK, who should take
them? They touch 3 subsystems: KGDB, TTY and ARM.
Taking the patches via -mm or TTY trees would be the easiest way as this
way we'll avoid having to deal with conflicts (see changelog*). But
merging via ARM or KDB will also work.
Russell, Jason, naively presuming that the ARM & KDB patches are OK,
would you be willing to ack ARM/KDB patches? Or, in case if it goes via
KDB or ARM tree, we'll need acks from Greg and Alan on tty patches...
Anyways, here goes the shiny v5:
- *I took two amba-pl1011 patches from Greg's tty tree. This is needed
to ease Stephen Rothwell's life in case if this goes into -next via
non-tty or non-mm tree.
The problem is that we now touch the same lines as tty tree, and
conflicts are not trivial. But by taking the two patches and rebasing
my work on top, we turn the conflicts into trivial ones.
- There were some concerns that '$3#33' might be not lengthy enough
(i.e., it's a bit shorter than '\nreboot\n'). Reading 2GB of
/dev/urandom couldn't find $3#33 sequence, but I made the magic phrase
configurable via kgdb_nmi.magic kernel command line option, just in
case.
These patches can be found in the following repo:
git://git.infradead.org/users/cbou/linux-nmi-kdb.git master
Boilerplate:
These patches introduce KGDB FIQ debugger support. The idea (and some
code, of course) comes from Google's FIQ debugger[2]. There are some
differences (mostly implementation details, feature-wise they're almost
equivalent, or can be made equivalent, if desired).
The FIQ debugger is a facility that can be used to debug situations when
the kernel stuck in uninterruptable sections, e.g. the kernel infinitely
loops or deadlocked in an interrupt or with interrupts disabled. On some
development boards there is even a special NMI button, which is very
useful for debugging weird kernel hangs.
And FIQ is basically an NMI, it has a higher priority than IRQs, and
upon IRQ exception FIQs are not disabled. It is still possible to
disable FIQs (as well as some "NMIs" on other architectures), but via
special means.
So, here FIQs and NMIs are synonyms, but in the code I use NMI term for
arch-independent code, and FIQs for ARM code.
A few years ago KDB wasn't yet ready for production, or even not
well-known, so originally Google implemented its own FIQ debugger that
included its own shell, ring-buffer, commands, dumping, backtracing
logic and whatnot. This is very much like PowerPC's xmon
(arch/powerpc/xmon), except that xmon was there for a decade, so it even
predates KDB.
Anyway, nowadays KGDB/KDB is the cross-platform debugger, and the only
feature that was missing is NMI handling. This is now fixed for ARM.
There are a few differences comparing to the original (Google's) FIQ
debugger:
- Doing stuff in FIQ context is dangerous, as there we are not allowed
to cause aborts or faults. In the original FIQ debugger there was a
"signal" software-induced interrupt, upon exit from FIQ it would fire,
and we would continue to execute "dangerous" commands from there.
In KGDB/KDB we don't use signal interrupts. We can do easier: set up a
breakpoint, continue, and you'll trap into KGDB again in a safe
context.
It works for most cases, but I can imagine cases when you can't set up
a breakpoint. For these cases we'd better introduce a KDB command
"exit_nmi", that will rise the SW IRQ, after which we're allowed to do
anything.
- KGDB/KDB FIQ debugger shell is synchronous. In Google's version you
could have a dedicated shell always running in the FIQ context, so
when you type something on a serial line, you won't actually cause any
debugging actions, FIQ would save the characters in its own buffer and
continue execution normally. But when you hit return key after the
command, then the command is executed.
In KGDB/KDB FIQ debugger it is different. Once you enter KGDB, the
kernel will stop until you instruct it to continue.
This might look as a drastic change, but it is not. There is actually
no difference whether you have sync or async shell, or at least I
couldn't find any use-case where this would matter at all. Anyways, it
is still possible to do async shell in KDB, just don't see any need
for this.
- Original FIQ debugger used a custom FIQ vector handling code, w/ a lot
of logic in it. In this approach I'm using the fact that FIQs are
basically IRQs, except that we there are a bit more registers banked,
and we can actually trap from the IRQ context.
But this all does not prevent us from using a simple jump-table based
approach as used in the generic ARM entry code. So, here I just reuse
the generic approach.
Note that I test the code on a modelled ARM machine (QEMU Versatile), so
there might be some issues on a real HW, but it works in QEMU tho. :-)
Assuming you have QEMU >= 1.1.0, you can easily play with the code using
ARM/versatile defconfig and command like this:
qemu-system-arm -nographic -machine versatilepb -kernel
linux/arch/arm/boot/zImage -append "console=ttyAMA0 kgdboc=ttyAMA0
kgdb_fiq.enable=1"
Thanks,
--
arch/arm/Kconfig | 19 ++
arch/arm/common/vic.c | 28 +++
arch/arm/include/asm/hardware/vic.h | 2 +
arch/arm/include/asm/kgdb.h | 8 +
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/entry-armv.S | 167 +-------------
arch/arm/kernel/entry-header.S | 170 +++++++++++++++
arch/arm/kernel/kgdb_fiq.c | 99 +++++++++
arch/arm/kernel/kgdb_fiq_entry.S | 87 ++++++++
arch/arm/mach-versatile/Makefile | 1 +
arch/arm/mach-versatile/kgdb_fiq.c | 31 +++
drivers/tty/serial/Kconfig | 19 ++
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/amba-pl010.c | 15 +-
drivers/tty/serial/amba-pl011.c | 106 +++++----
drivers/tty/serial/kgdb_nmi.c | 352 ++++++++++++++++++++++++++++++
drivers/tty/serial/kgdboc.c | 16 ++
drivers/tty/serial/serial_core.c | 30 +++
include/linux/kdb.h | 29 +--
include/linux/kgdb.h | 34 +++
include/linux/serial_core.h | 2 +
include/linux/tty_driver.h | 1 +
kernel/debug/debug_core.c | 36 ++-
kernel/debug/kdb/kdb_main.c | 29 +++
24 files changed, 1051 insertions(+), 232 deletions(-)
In v4:
- Implemented kgdb_nmi serial driver, it provides 'nmi_console' KDB
command. With the driver we can use our debugger port as a normal
console, except that we can always get back to the debugger using the
magic sequence. Note that I still somewhat reluctant to introduce
software-raised interrupts, as they're arch-specific and not always
possible. So today the driver uses a tasklet, it should be pretty
cheap: we're checking for the input on timer interrupts, but we don't
cause needless wakeups. The pro of this is that it works everywhere
(but arches still have an option to optimize things, of course);
- Two new patches added to propagate init_poll() callbacks from tty to
uart drivers. As a side-effect, a long-standing bug fixed in
amba-pl1011 driver;
- Dropped patch 'Get rid of .LCcralign local label';
- Some more fixes in SVC return path. Now it seems rock-solid;
In v3:
- Per Colin Cross suggestion, added a way to release a debug console for
normal use. This is done via 'disable_nmi' command (in the original
FIQ debugger it was 'console' command). For this I added a new
callback in the tty ops, and serial drivers have to provide a way to
clear its interrupts. The patch 'tty/serial/kgdboc: Add and wire up
clear_irqs callback' explains the concept in details.
- Made the debug entry prompt more shell-like;
- A new knocking mode '-1'. It disables the feature altogether, and thus
makes it possible to hook KDB entry to a dedicated button.
- The code was rebased on 'v3.5 + kdb kiosk'[1] patches;
In v2:
- Per Colin Cross' suggestion, we should not enter the debugger on any
received byte (this might be a problem when there's a noise on the
serial line). So there is now an additional patch that implements
"knocking" to the KDB (either via $3#33 command or return key, this is
configurable);
- Reworked {enable,select}_fiq/is_fiq callbacks, now multi-mach kernels
should not be a problem;
- For versatile machines there are run-time checks for proper UART port
(kernel will scream aloud if out of range port is specified);
- Added some __init annotations;
- Since not every architecture defines FIQ_START, we can't just blindly
select CONFIG_FIQ symbol. So ARCH_MIGHT_HAVE_FIQ introduced;
- Add !THUMB2_KERNEL dependency for KGDB_FIQ, we don't support Thumb2
kernels;
- New patch that is used to get rid of LCcralign label in alignment_trap
macro.
[1] https://lkml.org/lkml/2012/7/26/260
[2] Original Google's FIQ debugger, fiq_* files:
http://android.git.linaro.org/gitweb?p=kernel/common.git;a=tree;f=arch/arm/…
And board support as an example of using it:
http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=commitdiff;h=461cb80c1…
=== Highlights ===
Get LTP-DDT Test Working in LAVA:
1.Investigation on LTP-DDT, how to build it, run it, configure it :
Completed
2.Get ltp-ddt running successfully on a snowball locally(Limited
Testcases): Completed
3.Create a wrapper for LTP-DDT in lava-test: Started
=== Plans ===
Add ltp-ddt to appropriate kernel and/or daily runs as needed.
Documentation for Driver test cases.
Thanks,
Appala
