Hi all,
In v4:
- A few cosmetic changes in func_set_flag(), as suggested by Steven
Rostedt. Firstly, in the patch that adds pstore option, I use
'else if' for the new bit (it keeps changes minimal), but then there
is a new separate patch (the last in the series) that converts the
whole thing into a switch construction.
In v3:
- Make traces versioned, as suggested by Steven, Tony and Colin. (The
version tag is stored in the PRZ signature, see the last patch for
the implementation details).
- Add Steven's Ack on the first patch.
In v2:
- Do not introduce a separate 'persistent' tracer, but introduce an
option to the existing 'function' tracer.
Rationale for this patch set:
With this support kernel can save functions call chain log into a
persistent ram buffer that can be decoded and dumped after reboot
through pstore filesystem. It can be used to determine what function
was last called before a hang or an unexpected reset (caused by, for
example, a buggy driver that abuses HW).
Here's a "nano howto", to get the idea:
# mount -t debugfs debugfs /sys/kernel/debug/
# cd /sys/kernel/debug/tracing
# echo function > current_tracer
# echo 1 > options/func_pstore
# reboot -f
[...]
# mount -t pstore pstore /mnt/
# tail /mnt/ftrace-ramoops
0 ffffffff8101ea64 ffffffff8101bcda native_apic_mem_read <- disconnect_bsp_APIC+0x6a/0xc0
0 ffffffff8101ea44 ffffffff8101bcf6 native_apic_mem_write <- disconnect_bsp_APIC+0x86/0xc0
0 ffffffff81020084 ffffffff8101a4b5 hpet_disable <- native_machine_shutdown+0x75/0x90
0 ffffffff81005f94 ffffffff8101a4bb iommu_shutdown_noop <- native_machine_shutdown+0x7b/0x90
0 ffffffff8101a6a1 ffffffff8101a437 native_machine_emergency_restart <- native_machine_restart+0x37/0x40
0 ffffffff811f9876 ffffffff8101a73a acpi_reboot <- native_machine_emergency_restart+0xaa/0x1e0
0 ffffffff8101a514 ffffffff8101a772 mach_reboot_fixups <- native_machine_emergency_restart+0xe2/0x1e0
0 ffffffff811d9c54 ffffffff8101a7a0 __const_udelay <- native_machine_emergency_restart+0x110/0x1e0
0 ffffffff811d9c34 ffffffff811d9c80 __delay <- __const_udelay+0x30/0x40
0 ffffffff811d9d14 ffffffff811d9c3f delay_tsc <- __delay+0xf/0x20
Mostly the code comes from trace_persistent.c driver found in the
Android git tree, written by Colin Cross <ccross(a)android.com>
(according to sign-off history). I reworked the driver a little bit,
and ported it to pstore subsystem.
---
Documentation/ramoops.txt | 25 +++++++++
fs/pstore/Kconfig | 13 +++++
fs/pstore/Makefile | 1 +
fs/pstore/ftrace.c | 35 +++++++++++++
fs/pstore/inode.c | 111 ++++++++++++++++++++++++++++++++++++++--
fs/pstore/internal.h | 43 ++++++++++++++++
fs/pstore/platform.c | 12 ++++-
fs/pstore/ram.c | 65 +++++++++++++++++------
fs/pstore/ram_core.c | 12 +++--
include/linux/pstore.h | 13 +++++
include/linux/pstore_ram.h | 3 +-
kernel/trace/trace.c | 7 +--
kernel/trace/trace_functions.c | 36 +++++++++----
13 files changed, 337 insertions(+), 39 deletions(-)
--
Anton Vorontsov
Email: cbouatmailru(a)gmail.com
Hi all,
I do realize that we're in the middle of the merge window. But maybe
some of you will be bored enough to look into this; and no problem if
you don't feel like it -- I promise to send a brand new shiny v4 after
the merge window, so you won't miss a bit of this new cool stuff. :-)
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; and for
convenience it is now available in the following repo:
git://git.infradead.org/users/cbou/linux-nmi-kdb.git master
Rationale for this patch set:
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 | 169 +------------------------
arch/arm/kernel/entry-header.S | 176 ++++++++++++++++++++++++++-
arch/arm/kernel/kgdb_fiq.c | 159 ++++++++++++++++++++++++
arch/arm/kernel/kgdb_fiq_entry.S | 76 ++++++++++++
arch/arm/mach-versatile/Makefile | 1 +
arch/arm/mach-versatile/include/mach/irqs.h | 1 +
arch/arm/mach-versatile/kgdb_fiq.c | 31 +++++
drivers/tty/serial/amba-pl011.c | 13 ++
drivers/tty/serial/kgdboc.c | 9 ++
drivers/tty/serial/serial_core.c | 15 +++
include/linux/kgdb.h | 14 +++
include/linux/serial_core.h | 1 +
include/linux/tty_driver.h | 1 +
kernel/debug/debug_core.c | 13 +-
kernel/debug/kdb/kdb_debugger.c | 4 +
kernel/debug/kdb/kdb_main.c | 20 +++
21 files changed, 591 insertions(+), 170 deletions(-)
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…
--
Anton Vorontsov
Email: cbouatmailru(a)gmail.com
Hi all,
Here is a patchset that implements "kiosk" mode for KDB debugger. The
mode provides reduced set of features, so that it is no longer possible
to leak sensitive data via the debugger, and not possible to change
program flow in a predefined manner.
The are two use-cases for the mode, one is evil, but another is quite
legitimate.
The evil use case is used by some (ahem) phone manufaturers that want
to have a debuging facilities on a production device, but still don't
want you to use the debugger to gain root access. I don't like locked
phones, and I would not touch this/get my hands dirty by implementing
the feature just for this evil (IMHO) use case.
But there is another non-evil use case: limitting access to public
devices, i.e. "kiosks", ATMs (is that too much?) or just public
computers w/ guest access. I can imagine that an administrator would
want to setup a kernel so that upon an oops (or a sysrq event) the
kernel would enter KDB, but at the same time, he would not want to
leak sensitive data from the PC by means of the debugger.
There are seven patches, the first five of them are just cleanups and
preparations. I believe these five patches are good even if not
considering the kiosk mode. And the rest of patches actually implement
the mode -- it is pretty straightforward.
Note that we might impelement the same mode for KGDB stub, but so far
we don't bother.
Thanks!
--
include/linux/kdb.h | 16 ++--
kernel/debug/kdb/kdb_bp.c | 35 ++++----
kernel/debug/kdb/kdb_main.c | 183 +++++++++++++++++++++-------------------
kernel/debug/kdb/kdb_private.h | 3 +-
kernel/trace/trace_kdb.c | 4 +-
5 files changed, 126 insertions(+), 115 deletions(-)
--
Anton Vorontsov
Email: cbouatmailru(a)gmail.com
==== Activity Summary ====
* Reworked DT bindings for battery type information and its dependents
based on Arnd and lee's suggestion as the earlier DT
bindings was exuberant and ugly w.r.t dtsi file and probe routines.
* Note:battery type information are integrated in the driver, equally
this helps, dependent energy management modules which are
fuel-gauge and charging-algorithm
* Completed Device Tree Coding for Battery-temp and Fuel-Gauge Driver
* Testing in Progress with battery temperature driver as it depends on
fuel-gauge
From testing, it has been observed that fg or btemp interrupts are
not triggered for any ab8500 events
Note: mapping between Hardware IRQ and Linux Virtual IRQ is taken care
* Was on sick leave for 2 days, 2012-07-23/24
==== Plan ====
* Continue to debug interrupt events for btemp and fuel-gauge driver
==== Issues ====
=== Highlights ===
* Got back to the VOLATILE_LRU work, and got a very raw implementation
to seemingly work. Hope to send it out to lkml soon.
* Got my 3.6 time queue merged & sent out a few time items for
tip/timers/core.
* Did some work on generating better test cases for time.
* Did the android upstreaming subteam weekly mail
=== Plans ===
* Send out VOLATILE_LRU work to lkml and get feedback on the approach.
* Try to get the ETM driver up and running on my panda board
=== Issues ===
* None
== Highlights ==
* LTP Driver validation Framework : IN PROGRESS
1. TI LTP-DDT(http://processors.wiki.ti.com/index.php/LTP-DDT) taken as
base.
2. Modified to work on snowball platform.
3. Able to run below list of tests on snowball and those tests are part
of LTP.
1.schedulr.
2. ipc.
3. syscalls.
4. memory management.
5. timers.
4. Today TI LTP-DDT having below list of driver testcases and most of
the tests are depends on platform(EVM).
1.Audio(Capture and playback)
2.Ethernet
3.i2c
4.MMC
5.RTC
6.SPI
7.USB
8.v4l2
Otherthan eathenet none of the above tests are working on snowball.
5. Studying and understanding TI LTP-DDT tests implementation.
== Plans ==
*Preparation of Testspecification for Driver validation .
Thanks
Appala
=== omarrmz ===
=== Highlights ===
* Iommu save and restore patches in preparation for OFF mode support: DONE
- Tested them on omap4 and omap3 (with omap3-isp).
- Need to decide whether to squash them with iommu series.
* Mailbox runtime OFF mode: IN PROGRESS.
* Recieved an email from Paul W, mentioning that he had my patches in
his queue for review. NO UPDATE.
* Completing TI's HR courses: IN PROGRESS.
* Rebased remoteproc for-next branch and placed my patches on top of
this rebase.
Regards,
Omar
== Highlights ==
* Prepared a bunch of patches to fix KDB 'dmesg' command (the
command got broken by a major logbuf rework in early 3.5 development
stage). The fixes are now merged into 3.5;
* Made a few last-minute fixes for the pstore/ftrace versioning code
(noticed by Greg KH);
* Per Steven Rostedt's comments prepared a new patch to make
pstore/tracing more safe in case if we want to implement ramoops
as a removable module. We no longer use tracing front-end. The
patch is not urgent and doesn't bring any new features, and thus
probably 3.7 material.
* The fact that we don't use the tracing front-end revealed a subtle
bug in ramoops module, the fix was sent to the community. Also
another small bug noticed by Dan Carpenter (w/ the help of Smatch
tool), the fix was also prepared and sent out.
== Plans ==
* Finish last bits of KDB kiosk-mode patches, and send the patches out;
* Check if ulmkd is still compilable w/ the recent vmevent tree (there
were some API changes), then send out ulmkd announcement;
* Reevaluate LMK project state, thoughtfully read the previous
discussion about a new LRU list; make a plan for further steps.
--
Anton Vorontsov
Email: cbouatmailru(a)gmail.com
We can dereference 'cxt->cprz' if console and dump logging are disabled
(which is unlikely, but still possible to do). This patch fixes the issue
by changing the code so that we don't dereference przs at all, we can
just calculate bufsize from console_size and record_size values.
Plus, while at it, the patch improves the buffer size calculation.
After Kay's printk rework, we know the optimal buffer size for console
logging -- it is LOG_LINE_MAX (defined privately in printk.c). Previously,
if only console logging was enabled, we would allocate unnecessary large
buffer in pstore, while we only need LOG_LINE_MAX. (Pstore console logging
is still capable of handling buffers > LOG_LINE_MAX, it will just do
multiple calls to psinfo->write).
Note that I don't export the constant, since we will do even a better
thing soon: we will switch console logging to a new write_buf API, which
will eliminate the need for the additional buffer; and so we won't need
the constant.
Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov(a)linaro.org>
---
fs/pstore/ram.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index b86b2b7..c34fccf 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -414,13 +414,14 @@ static int __devinit ramoops_probe(struct platform_device *pdev)
cxt->pstore.data = cxt;
/*
- * Console can handle any buffer size, so prefer dumps buffer
- * size since usually it is smaller.
+ * Console can handle any buffer size, so prefer LOG_LINE_MAX. If we
+ * have to handle dumps, we must have at least record_size buffer. And
+ * for ftrace, bufsize is irrelevant (if bufsize is 0, buf will be
+ * ZERO_SIZE_PTR).
*/
- if (cxt->przs)
- cxt->pstore.bufsize = cxt->przs[0]->buffer_size;
- else
- cxt->pstore.bufsize = cxt->cprz->buffer_size;
+ if (cxt->console_size)
+ cxt->pstore.bufsize = 1024; /* LOG_LINE_MAX */
+ cxt->pstore.bufsize = max(cxt->record_size, cxt->pstore.bufsize);
cxt->pstore.buf = kmalloc(cxt->pstore.bufsize, GFP_KERNEL);
spin_lock_init(&cxt->pstore.buf_lock);
if (!cxt->pstore.buf) {
--
1.7.10.4
From: "hongbo.zhang" <hongbo.zhang(a)linaro.com>
Hi all,
This is the ST-Ericsson db8500 thermal dirver, here are some notes of this patch set:
1.
0001-Remove-un-necessary-variable-checking.patch is a trivial update of the thermal framework.
0002-ST-Ericsson-db8500-thermal-dirver.patch is the ST-Ericsson db8500 thermal dirver.
2.
Since there is no PRCMU interface to read temperature directly, the PRCMU interrupts are used instead,
and a pseudo current temperature is returned, but this works for the thermal management framework.
This can be updated when the corresponding PRCMU interface is available.
3.
As suggested by Vincent Guittot, the cooling device codes are seperated from thermal zone, this makes it
easy to add/remove other cooling devices. CPU frequency limiting is the current cooling device.
4.
The driver isn't added into device tree currently, this can be done soon if needed.
hongbo.zhang (2):
Remove un-necessary variable checking
ST-Ericsson db8500 thermal dirver
arch/arm/configs/u8500_defconfig | 4 +
arch/arm/mach-ux500/board-mop500.c | 69 ++++
drivers/thermal/Kconfig | 20 ++
drivers/thermal/Makefile | 4 +-
drivers/thermal/cpu_cooling.c | 3 +-
drivers/thermal/db8500_cpufreq_cooling.c | 167 +++++++++
drivers/thermal/db8500_thermal.c | 476 ++++++++++++++++++++++++++
include/linux/platform_data/db8500_thermal.h | 39 +++
8 files changed, 779 insertions(+), 3 deletions(-)
create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c
create mode 100644 drivers/thermal/db8500_thermal.c
create mode 100644 include/linux/platform_data/db8500_thermal.h
--
1.7.10
