linaro-kernel February 2013

linaro-kernel@lists.linaro.org

38 participants
35 discussions

[RFC] cpufreq: governor: Set MIN_LATENCY_MULTIPLIER to 20

by Viresh Kumar

Currently MIN_LATENCY_MULTIPLIER is set defined as 100 and so on a system with transition latency of 1 ms, the minimum sampling time comes to be around 100 ms. That is quite big if you want to get better performance for your system. Redefine MIN_LATENCY_MULTIPLIER to 20 so that we can support 20ms sampling rate for such platforms. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- Hi Guys, I really don't know how this figure (100) came initially, but we really need to have 20ms support for my platform: ARM TC2. Pushed here: http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/h… drivers/cpufreq/cpufreq_governor.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h index d2ac911..adb8e30 100644 --- a/drivers/cpufreq/cpufreq_governor.h +++ b/drivers/cpufreq/cpufreq_governor.h @@ -34,7 +34,7 @@ */ #define MIN_SAMPLING_RATE_RATIO (2) #define LATENCY_MULTIPLIER (1000) -#define MIN_LATENCY_MULTIPLIER (100) +#define MIN_LATENCY_MULTIPLIER (20) #define TRANSITION_LATENCY_LIMIT (10 * 1000 * 1000) /* Ondemand Sampling types */ -- 1.7.12.rc2.18.g61b472e

11 years, 10 months

[PATCH 1/2] time : pass broadcast device parameter

by Daniel Lezcano

The broadcast timer could be passed as parameter to the function instead of using again tick_broadcast_device.evtdev which was previously used in the caller function. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> --- kernel/time/tick-broadcast.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c index f113755..baf9b0e7 100644 --- a/kernel/time/tick-broadcast.c +++ b/kernel/time/tick-broadcast.c @@ -370,10 +370,9 @@ struct cpumask *tick_get_broadcast_oneshot_mask(void) return to_cpumask(tick_broadcast_oneshot_mask); } -static int tick_broadcast_set_event(ktime_t expires, int force) +static int tick_broadcast_set_event(struct clock_event_device *bc, + ktime_t expires, int force) { - struct clock_event_device *bc = tick_broadcast_device.evtdev; - if (bc->mode != CLOCK_EVT_MODE_ONESHOT) clockevents_set_mode(bc, CLOCK_EVT_MODE_ONESHOT); @@ -443,7 +442,7 @@ again: * Rearm the broadcast device. If event expired, * repeat the above */ - if (tick_broadcast_set_event(next_event, 0)) + if (tick_broadcast_set_event(dev, next_event, 0)) goto again; } raw_spin_unlock(&tick_broadcast_lock); @@ -486,7 +485,7 @@ void tick_broadcast_oneshot_control(unsigned long reason) cpumask_set_cpu(cpu, tick_get_broadcast_oneshot_mask()); clockevents_set_mode(dev, CLOCK_EVT_MODE_SHUTDOWN); if (dev->next_event.tv64 < bc->next_event.tv64) - tick_broadcast_set_event(dev->next_event, 1); + tick_broadcast_set_event(bc, dev->next_event, 1); } } else { if (cpumask_test_cpu(cpu, tick_get_broadcast_oneshot_mask())) { @@ -555,7 +554,7 @@ void tick_broadcast_setup_oneshot(struct clock_event_device *bc) clockevents_set_mode(bc, CLOCK_EVT_MODE_ONESHOT); tick_broadcast_init_next_event(to_cpumask(tmpmask), tick_next_period); - tick_broadcast_set_event(tick_next_period, 1); + tick_broadcast_set_event(bc, tick_next_period, 1); } else bc->next_event.tv64 = KTIME_MAX; } else { -- 1.7.9.5

11 years, 10 months

[PATCH] clocksource : nomadik-mtu : fix missing irq initialization

by Daniel Lezcano

This patch fix the clock device irq field which is not initialized. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> --- drivers/clocksource/nomadik-mtu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clocksource/nomadik-mtu.c b/drivers/clocksource/nomadik-mtu.c index 8914c3c..7cbcaa0 100644 --- a/drivers/clocksource/nomadik-mtu.c +++ b/drivers/clocksource/nomadik-mtu.c @@ -226,5 +226,6 @@ void __init nmdk_timer_init(void __iomem *base, int irq) /* Timer 1 is used for events, register irq and clockevents */ setup_irq(irq, &nmdk_timer_irq); nmdk_clkevt.cpumask = cpumask_of(0); + nmdk_clkevt.irq = irq; clockevents_config_and_register(&nmdk_clkevt, rate, 2, 0xffffffffU); } -- 1.7.9.5

11 years, 10 months

[ACTIVITY] (John Stultz) Feb 18 - 22

by John Stultz

=== Highlights === * Flew to SF and presented at ABS, then flew back home on Monday. Slides are here: http://events.linuxfoundation.org/images/stories/slides/abs2013_stultz.pdf * Spurred by discussion at ABS, worked out how to get ADB running on vanilla linux: https://plus.google.com/u/0/111524780435806926688/posts/AaEccFjKNHE * My discussion proposal for lsf/mm-minisummit on volatile ranges was accepted and I was formally invited to attend * Discussed Serbans' ashmem compat_ioctl patches with Arve and Serban. * Sent out late android upstreaming subteam mail * Synced up with Jakub on Android Upstreaming session at connect * Got my 3.9 timekeeping queue merged upstream, and reviewed and queued a number of timekeeping patches for 3.10 * Discussed some timekeeping changes with tglx, and reviewed some of his patches. * Implemented a first pass at using valid-cycle-ranges with vdso based gettime calls to avoid potential race windows with virtualized kernels. This will allow for reduced lock hold times in the future. === Plans === * Review Serban's binder patches * Look into Androids support of large-files with 32bit applications * Send out sync driver for staging (as I've not heard back from Erik or other folks at Google) * Prep for Connect === Issues === * NA

11 years, 10 months

[ACTIVITY] (David Long) 2013-02-16 - 2013-02-22

by David Long

=== David Long === === Travel/Time Off === * Monday February 18th (U.S. Washington's Birthday, aka President's Day) === Highlights === * I'm dealing with problems getting the uprobe uprobe patch to correctly process the breakpoint. I see the breakpoint being placed but the result when it hits it seems to be corrupted context. * I received email back from Rabin Vincent saying he had no plans to work on this any more and he is happy if I want to take it over. He has volunteered to supply his tests, which I hope to see shortly. === Plans === * Debug the problems I'm experiencing with the patch, then move on to addressing the upstream concerns about its integration. === Issues === -dl

11 years, 10 months

[PATCH 0/2] cpustat: use atomic operations to read/update stats

by Kevin Hilman

On 64-bit platforms, reads/writes of the various cpustat fields are atomic due to native 64-bit loads/stores. However, on non 64-bit platforms, reads/writes of the cpustat fields are not atomic and could lead to inconsistent statistics. This problem was originally reported by Frederic Weisbecker as a 64-bit limitation with the nsec granularity cputime accounting for full dynticks, but then we realized that it's a problem that's been around for awhile and not specific to the new cputime accounting. This series fixes this by first converting all access to the cputime fields to use accessor functions, and then converting the accessor functions to use the atomic64 functions. Implemented based on idea proposed by Frederic Weisbecker. Kevin Hilman (2): cpustat: use accessor functions for get/set/add cpustat: convert to atomic operations arch/s390/appldata/appldata_os.c | 16 +++++++-------- drivers/cpufreq/cpufreq_governor.c | 18 ++++++++--------- drivers/cpufreq/cpufreq_ondemand.c | 2 +- drivers/macintosh/rack-meter.c | 6 +++--- fs/proc/stat.c | 40 +++++++++++++++++++------------------- fs/proc/uptime.c | 2 +- include/linux/kernel_stat.h | 11 ++++++++++- kernel/sched/core.c | 12 +++++------- kernel/sched/cputime.c | 29 +++++++++++++-------------- 9 files changed, 70 insertions(+), 66 deletions(-) -- 1.8.1.2

11 years, 10 months

[ACTIVITY] (Linus Walleij) 2013-02-11 - 2013-02-22

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Finalized a GPIO+pinctrl presentation for the Embedded Linux Conference, and presented on the first day of the conference. Slides will be posted. * Finalized the pinctrl tree before traveling, sent a pull request to Torvalds as soon as the merge window opened and he pulled it in. * AB8500 GPIO patches and all other cleanup has been merged up to the pinctrl and ARM SoC trees and pulled in by Torvalds. MFD is pending but Sam has sent a pull request for this part as well. * Other queued fixes for mach-ux500 and also the PCI regression fix has propagated upstream. * Reviewed misc GPIO, pinctrl and other patches, updated blueprints... === Plans === * Fix regressions popping up in the merge window. There are always such... * Attack the remaining headers in arch/arm/mach-ux500 so we can move forward with multiplatform for v3.9. * Convert the Nomadik to multiplatform. * Convert Nomadik pinctrl driver to register GPIO ranges from the gpiochip side. * 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. * Get hands dirty with regmap. === Issues === * N/A Thanks, Linus Walleij

11 years, 10 months

[PATCH v2] arm: add check for global exclusive monitor

by Vladimir Murzin

Since ARMv6 new atomic instructions have been introduced: ldrex/strex. Several implementation are possible based on (1) global and local exclusive monitors and (2) local exclusive monitor and snoop unit. In case of the 2nd options exclusive store operation on uncached region may be faulty. Check for availability of global monitor to provide some hint about possible issues. Signed-off-by: Vladimir Murzin <murzin.v(a)gmail.com> --- Changes since v1: - Using L_PTE_MT_BUFFERABLE instead of L_PTE_MT_UNCACHABLE Thanks to Russell for ponting this silly error - added comment about how checking is done arch/arm/include/asm/bugs.h | 14 +++++++++-- arch/arm/mm/fault-armv.c | 55 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 67 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/asm/bugs.h b/arch/arm/include/asm/bugs.h index a97f1ea..29d73cd 100644 --- a/arch/arm/include/asm/bugs.h +++ b/arch/arm/include/asm/bugs.h @@ -13,9 +13,19 @@ #ifdef CONFIG_MMU extern void check_writebuffer_bugs(void); -#define check_bugs() check_writebuffer_bugs() +#if __LINUX_ARM_ARCH__ < 6 +static void check_gmonitor_bugs(void) {}; #else -#define check_bugs() do { } while (0) +extern void check_gmonitor_bugs(void); +#endif + +static inline void check_bugs(void) +{ + check_writebuffer_bugs(); + check_gmonitor_bugs(); +} +#else +static inline void check_bugs(void) { } #endif #endif diff --git a/arch/arm/mm/fault-armv.c b/arch/arm/mm/fault-armv.c index 2a5907b..6a1a07e 100644 --- a/arch/arm/mm/fault-armv.c +++ b/arch/arm/mm/fault-armv.c @@ -205,6 +205,61 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned long addr, __flush_icache_all(); } } +#else +/* + * Check for the global exclusive monitor. The global monitor is a external + * transaction monitoring block for tracking exclusive accesses to sharable + * memory regions. LDREX/STREX rely on this monitor when accessing uncached + * shared memory. + * If global monitor is not implemented STREX operation on uncached shared + * memory region always fail, returning 0 in the destination register. + * We rely on this property to check whether global monitor is implemented + * or not. + * NB: The name of L_PTE_MT_BUFFERABLE is not for B bit, but for normal + * non-cacheable memory type (XXCB = 0001). + */ +void __init check_gmonitor_bugs(void) +{ + struct page *page; + const char *reason; + unsigned long res = 1; + + printk(KERN_INFO "CPU: Testing for global monitor: "); + + page = alloc_page(GFP_KERNEL); + if (page) { + unsigned long *p; + pgprot_t prot = __pgprot_modify(PAGE_KERNEL, + L_PTE_MT_MASK, L_PTE_MT_BUFFERABLE); + + p = vmap(&page, 1, VM_IOREMAP, prot); + + if (p) { + int temp, res; + + __asm__ __volatile__( + "ldrex %1, [%2]\n" + "strex %0, %1, [%2]" + : "=&r" (res), "=&r" (temp) + : "r" (p) + : "cc", "memory"); + + reason = "n/a (atomic ops may be faulty)"; + } else { + reason = "unable to map memory\n"; + } + + vunmap(p); + put_page(page); + } else { + reason = "unable to grab page\n"; + } + + if (res) + printk("failed, %s\n", reason); + else + printk("ok\n"); +} #endif /* __LINUX_ARM_ARCH__ < 6 */ /* -- 1.7.10.4

11 years, 10 months

[PATCH] arm: add check for global exclusive monitor

by Vladimir Murzin

Thanks for review Russel! On Mon, Feb 18, 2013 at 04:44:20PM +0000, Russell King - ARM Linux wrote: > On Mon, Feb 18, 2013 at 08:26:50PM +0400, Vladimir Murzin wrote: > > Since ARMv6 new atomic instructions have been introduced: > > ldrex/strex. Several implementation are possible based on (1) global > > and local exclusive monitors and (2) local exclusive monitor and snoop > > unit. > > > > In case of the 2nd option exclusive store operation on uncached > > region may be faulty. > > > > Check for availability of the global monitor to provide some hint about > > possible issues. > > How does this code actually do that? According to DHT0008A_arm_synchronization_primitives.pdf the global monitor is introduce to track exclusive accesses to sharable memory regions. This article also says about some system-wide implication which should be taken into account: (1) for systems with coherency management (2) for systems without coherency management The first one lay on SCU, L1 data cache and local monitor. The second one requires implementation of global monitor if memory regions cannot be cached. It set up the behaviour for store-exclusive operations when global monitor is not available: these operations always fail. Taking all these into account we can guess about availability of global monitor by using store-exclusive operation on uncached memory region. > > > +void __init check_gmonitor_bugs(void) > > +{ > > + struct page *page; > > + const char *reason; > > + unsigned long res = 1; > > + > > + printk(KERN_INFO "CPU: Testing for global monitor: "); > > + > > + page = alloc_page(GFP_KERNEL); > > + if (page) { > > + unsigned long *p; > > + pgprot_t prot = __pgprot_modify(PAGE_KERNEL, > > + L_PTE_MT_MASK, L_PTE_MT_UNCACHED); > > + > > + p = vmap(&page, 1, VM_IOREMAP, prot); > > This is bad practise. Remapping a page of already mapped kernel memory > using different attributes (in this case, strongly ordered) is _definitely_ > a violation of the architecture requirements. The behaviour you will see > from this are in no way guaranteed. DDI0406C_arm_architecture_reference_manual.pdf (A3-131) says: A memory location can be marked as having different cacheability attributes, for example when using aliases in a virtual to physical address mapping: * if the attributes differ only in the cache allocation hint this does not affect the behavior of accesses to that location * for other cases see Mismatched memory attributes on page A3-136. Isn't L_PTE_MT_UNCACHED about cache allocation hint? > > If you want to do this, it must either come from highmem, or not already > be mapped. > > Moreover, this is absolutely silly - the ARM ARM says: > > "LDREX and STREX operations *must* be performed only on memory with the > Normal memory attribute." DDI0406C_arm_architecture_reference_manual.pdf (A3-121) says: It is IMPLEMENTATION DEFINED whether LDREX and STREX operations can be performed to a memory region with the Device or Strongly-ordered memory attribute. Unless the implementation documentation explicitly states that LDREX and STREX operations to a memory region with the Device or Strongly-ordered attribute are permitted, the effect of such operations is UNPREDICTABLE. At least it allows to perform operations on memory region with the Strongly-ordered attribute... but still unpredictable. > > L_PTE_MT_UNCACHED doesn't get you that. As I say above, that gets you > strongly ordered memory, not "normal memory" as required by the > architecture for use with exclusive types. > > > + > > + if (p) { > > + int temp; > > + > > + __asm__ __volatile__( \ > > + "ldrex %1, [%2]\n" \ > > + "strex %0, %1, [%2]" \ > > + : "=&r" (res), "=&r" (temp) \ > > + : "r" (p) \ > > \ character not required for any of the above. Neither is the __ version > of "asm" and "volatile". Thanks. > > > + : "cc", "memory"); > > + > > + reason = "n\\a (atomic ops may be faulty)"; > > "n\\a" ? "not detected"? > So... at the moment this has me wondering - you're testing atomic > operations with a strongly ordered memory region, which ARM already > define this to be outside of the architecture spec. The behaviour you > see is not defined architecturally. > > And if you're trying to use LDREX/STREX to a strongly ordered or device > memory region, then you're quite right that it'll be unreliable. It's > not defined to even work. That's not because they're faulty, it's because > you're abusing them. However, IRL it is not hard to meet this undefined difference. At least I'm able to see it on Tegra2 Harmony and Pandaboard. Moreover, demand on Normal memory attribute breaks up ability to turn caches off. In this case we are not able to boot the system up (seen on Tegra2 harmony). This patch is aimed to highlight the difference in implementation. That's why it has some softering in guessing about faulty. Might be it worth warning about unpredictable effect instead? Best wishes Vladimir

11 years, 10 months

13.1 Versatile Express kernel spewing lock warnings

by Eric Van Hensbergen

I was trying out the new linaro binary image for 13.1 on my TC2 and am getting lock warnings on my console. Should I be worried or is this expected behavior? ----- [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.8.0-1-linaro-vexpress (buildd@wani10) (gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) ) #1ubuntu1~ci+130125174543-Ubuntu SMP Sat Jan 26 00:47:35 UTC 201 ... [ 602.909859] [ 602.909864] ====================================================== [ 602.909868] [ INFO: possible circular locking dependency detected ] [ 602.909877] 3.8.0-1-linaro-vexpress #1ubuntu1~ci+130125174543-Ubuntu Not tainted [ 602.909881] ------------------------------------------------------- [ 602.909887] kworker/0:1/376 is trying to acquire lock: [ 602.909922] ((fb_notifier_list).rwsem){.+.+.+}, at: [<c00385b9>] __blocking_notifier_call_chain+0x1d/0x40 [ 602.909926] [ 602.909926] but task is already holding lock: [ 602.909953] (console_lock){+.+.+.}, at: [<c0285103>] console_callback+0xf/0xe0 [ 602.909957] [ 602.909957] which lock already depends on the new lock. [ 602.909957] [ 602.909960] [ 602.909960] the existing dependency chain (in reverse order) is: [ 602.909976] [ 602.909976] -> #1 (console_lock){+.+.+.}: [ 602.909994] [<c005b041>] __lock_acquire+0x29d/0x858 [ 602.910010] [<c005b93f>] lock_acquire+0x5f/0xbc [ 602.910027] [<c001d2f5>] console_lock+0x31/0x40 [ 602.910041] [<c028350f>] register_con_driver+0x27/0xe8 [ 602.910054] [<c0283ded>] take_over_console+0x19/0x240 [ 602.910071] [<c0269263>] fbcon_takeover+0x3b/0x88 [ 602.910083] [<c00383ed>] notifier_call_chain+0x45/0x54 [ 602.910097] [<c00385cb>] __blocking_notifier_call_chain+0x2f/0x40 [ 602.910110] [<c00385f3>] blocking_notifier_call_chain+0x17/0x1c [ 602.910123] [<c0265d35>] register_framebuffer+0x109/0x1cc [ 602.910135] [<c026fdbb>] hdlcd_probe+0x507/0x5d0 [ 602.910148] [<c02909d3>] platform_drv_probe+0x17/0x18 [ 602.910159] [<c028fd49>] driver_probe_device+0x51/0x170 [ 602.910169] [<c028febf>] __driver_attach+0x57/0x58 [ 602.910185] [<c028ec9b>] bus_for_each_dev+0x2b/0x4c [ 602.910195] [<c028f7dd>] bus_add_driver+0xe5/0x170 [ 602.910206] [<c02901ef>] driver_register+0x43/0xd0 [ 602.910218] [<c0008511>] do_one_initcall+0xc9/0x114 [ 602.910231] [<c03d5ceb>] kernel_init+0xcf/0x1ec [ 602.910245] [<c000ce95>] ret_from_fork+0x11/0x20 [ 602.910261] [ 602.910261] -> #0 ((fb_notifier_list).rwsem){.+.+.+}: [ 602.910274] [<c005a799>] validate_chain.isra.26+0xafd/0xbe4 [ 602.910288] [<c005b041>] __lock_acquire+0x29d/0x858 [ 602.910301] [<c005b93f>] lock_acquire+0x5f/0xbc [ 602.910316] [<c03dfe8d>] down_read+0x25/0x30 [ 602.910329] [<c00385b9>] __blocking_notifier_call_chain+0x1d/0x40 [ 602.910342] [<c00385f3>] blocking_notifier_call_chain+0x17/0x1c [ 602.910354] [<c0264e7d>] fb_blank+0x29/0x64 [ 602.910364] [<c026a859>] fbcon_blank+0x135/0x1ac [ 602.910377] [<c0283471>] do_blank_screen+0x109/0x180 [ 602.910391] [<c028513d>] console_callback+0x49/0xe0 [ 602.910402] [<c00304a1>] process_one_work+0x12d/0x3c4 [ 602.910413] [<c00309a7>] worker_thread+0x117/0x344 [ 602.910426] [<c0033dd3>] kthread+0x77/0x84 [ 602.910439] [<c000ce95>] ret_from_fork+0x11/0x20 [ 602.910443] [ 602.910443] other info that might help us debug this: [ 602.910443] [ 602.910446] Possible unsafe locking scenario: [ 602.910446] [ 602.910450] CPU0 CPU1 [ 602.910453] ---- ---- [ 602.910463] lock(console_lock); [ 602.910472] lock((fb_notifier_list).rwsem); [ 602.910481] lock(console_lock); [ 602.910489] lock((fb_notifier_list).rwsem); [ 602.910493] [ 602.910493] *** DEADLOCK *** [ 602.910493] [ 602.910499] 3 locks held by kworker/0:1/376: [ 602.910523] #0: (events){.+.+.+}, at: [<c003044e>] process_one_work+0xda/0x3c4 [ 602.910546] #1: (console_work){+.+...}, at: [<c003044e>] process_one_work+0xda/0x3c4 [ 602.910572] #2: (console_lock){+.+.+.}, at: [<c0285103>] console_callback+0xf/0xe0 [ 602.910575] [ 602.910575] stack backtrace: [ 602.910596] [<c0011fd1>] (unwind_backtrace+0x1/0x9c) from [<c03da9cb>] (print_circular_bug+0x1a7/0x1f0) [ 602.910614] [<c03da9cb>] (print_circular_bug+0x1a7/0x1f0) from [<c005a799>] (validate_chain.isra.26+0xafd/0xbe4) [ 602.910632] [<c005a799>] (validate_chain.isra.26+0xafd/0xbe4) from [<c005b041>] (__lock_acquire+0x29d/0x858) [ 602.910649] [<c005b041>] (__lock_acquire+0x29d/0x858) from [<c005b93f>] (lock_acquire+0x5f/0xbc) [ 602.910665] [<c005b93f>] (lock_acquire+0x5f/0xbc) from [<c03dfe8d>] (down_read+0x25/0x30) [ 602.910683] [<c03dfe8d>] (down_read+0x25/0x30) from [<c00385b9>] (__blocking_notifier_call_chain+0x1d/0x40) [ 602.910701] [<c00385b9>] (__blocking_notifier_call_chain+0x1d/0x40) from [<c00385f3>] (blocking_notifier_call_chain+0x17/0x1c) [ 602.910718] [<c00385f3>] (blocking_notifier_call_chain+0x17/0x1c) from [<c0264e7d>] (fb_blank+0x29/0x64) [ 602.910732] [<c0264e7d>] (fb_blank+0x29/0x64) from [<c026a859>] (fbcon_blank+0x135/0x1ac) [ 602.910746] [<c026a859>] (fbcon_blank+0x135/0x1ac) from [<c0283471>] (do_blank_screen+0x109/0x180) [ 602.910764] [<c0283471>] (do_blank_screen+0x109/0x180) from [<c028513d>] (console_callback+0x49/0xe0) [ 602.910780] [<c028513d>] (console_callback+0x49/0xe0) from [<c00304a1>] (process_one_work+0x12d/0x3c4) [ 602.910793] [<c00304a1>] (process_one_work+0x12d/0x3c4) from [<c00309a7>] (worker_thread+0x117/0x344) [ 602.910808] [<c00309a7>] (worker_thread+0x117/0x344) from [<c0033dd3>] (kthread+0x77/0x84) [ 602.910825] [<c0033dd3>] (kthread+0x77/0x84) from [<c000ce95>] (ret_from_fork+0x11/0x20)

11 years, 10 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel February 2013