Add the missing MAINTAINERCLEANFILES to makefile.am.
Signed-off-by: Geoff Levand <geoff(a)infradead.org>
---
Hi Catalin,
Here's a minor fix for the arm64 bootwrapper to make
'make maintainer-clean' work. You can try it with
something this:
autoreconf -i
./configure ...
make maintainer-clean
git ls-files -o
-Geoff
Makefile.am | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Makefile.am b/Makefile.am
index 5791ad1..c911e51 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -88,3 +88,6 @@ fdt.dtb: $(KERNEL_DTB) Makefile gen-cpu-nodes.sh
# The filesystem archive might not exist if INITRD is not being used
.PHONY: all clean $(FILESYSTEM)
+
+MAINTAINERCLEANFILES = aclocal.m4 compile config.* configure install-sh \
+ Makefile.in missing
--
1.9.1
Hi Thomas,
I found this piece of code in tick-oneshot.c:
+int tick_oneshot_mode_active(void)
+{
+ unsigned long flags;
+ int ret;
+
+ local_irq_save(flags);
+ ret = __get_cpu_var(tick_cpu_device).mode == TICKDEV_MODE_ONESHOT;
+ local_irq_restore(flags);
+
+ return ret;
+}
Why do we need local_irq_save/restore() here for just reading value
of this variable? Can these be dropped? If yes, I would do that as
part of my cleanup series around tick stuff.
--
viresh
We need to migrate away all the background kernel activities (Unbound) for
systems requiring isolation of cores (HPC, Real time, networking, etc). After
creating cpusets, you can write 1 or 0 to cpuset.quiesce file.
In our case, we are working on a networking machine which wants to run time
critical data plane threads on some CPUs, i.e. a single thread per CPU. And
these CPUs shouldn't be interrupted at all by background kernel activities, like
timers/hrtimers/workqueues/etc..
Writing '1': on this file would migrate unbound/unpinned timers and hrtimers
away from the CPUs of the cpuset in question. Also it would disallow addition of
any new unpinned timers & hrtimers to isolated CPUs.
Writing '0': will disable isolation of CPUs in current cpuset and unpinned
timers/hrtimers would be allowed in future on these CPUs.
This patchset allow us to do this. In the first few patches it builds basic
infrastructure in timers and hrtimers and then finally use that in cpusets. Also
it updates get_nohz_timer_target() to stop adding new timers/hrtimers to these
isolated CPUs.
V1: https://lkml.org/lkml/2014/3/20/319
Not many comments received.
Based on some other timers/hrtimers cleanup I did:
http://comments.gmane.org/gmane.linux.kernel/1677797
Available here: git://git.linaro.org/people/viresh.kumar/linux.git isolate-cpusets
V1->V2:
- Add support to migrate hrtimers as well (V1 only had timers)
- cpuset.quiesce now supports writing 0 and reading as well
- update get_nohz_timer_target() to stop adding new timers/hrtimers to these
isolated CPUs.
- Minor fixups that I noticed
Known issues:
1. Patch: "timer: track pinned timers with TIMER_PINNED flag", following
reporting by kbuild system (Don't know how to fix this):
config: make ARCH=blackfin allyesconfig
Note: the vireshk/timer-cleanup-for-tglx HEAD
ea63467ac9150cd86f4d960887116f99a2803b56 builds fine. It only hurts
bisectibility.
All error/warnings:
kernel/timer.c: In function 'init_timers':
>> kernel/timer.c:1683:2: error: call to '__compiletime_assert_1683'
>> declared with attribute error: BUILD_BUG_ON failed:
>> __alignof__(struct tvec_base) & TIMER_FLAG_MASK
2. Patch: "timer: don't migrate pinned timers", following reporting by kbuild
system (Not really a problem created due to this patch, but just highlighted
an existing bug. As pinned timers must be removed by owners before CPU goes
down):
smpboot: CPU 1 is now offline
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1935 at kernel/timer.c:1621 migrate_timer_list+0xd6/0xf0()
migrate_timer_list: can't migrate pinned timer: ffffffff81f06a60, deactivating it
Modules linked in:
Viresh Kumar (8):
timer: track pinned timers with TIMER_PINNED flag
timer: don't migrate pinned timers
timer: create timer_quiesce_cpu() to isolate CPU from timers
hrtimer: update timer->state with 'pinned' information
hrtimer: don't migrate pinned timers
hrtimer: create hrtimer_quiesce_cpu() to isolate CPU from hrtimers
cpuset: Create sysfs file: cpusets.quiesce to isolate CPUs
sched: don't queue timers on quiesced CPUs
Documentation/cgroups/cpusets.txt | 19 +++++++-
include/linux/cpuset.h | 8 ++++
include/linux/hrtimer.h | 6 +++
include/linux/timer.h | 13 ++++--
kernel/cpuset.c | 76 ++++++++++++++++++++++++++++++++
kernel/hrtimer.c | 69 ++++++++++++++++++++++++-----
kernel/sched/core.c | 9 ++--
kernel/timer.c | 91 +++++++++++++++++++++++++++++++--------
8 files changed, 253 insertions(+), 38 deletions(-)
--
1.7.12.rc2.18.g61b472e
Hi All,
I am trying to update the kernel of the udoo board 3.10.17.
Original kernel supported by Udoo works fine.
I am able to build the kernel and load the image on the board.
But is stuck at the boot loader... with following message below.
I think this is bootloader problem ?
If not what could be the problem for the booting of the kernel image to stop.
Is it related to device tree file.
Please share some pointer so that I can work on to resolve the problem.
------------------------boot message-------------------------------------------
U-Boot 2013.10-rc3 (Jan 20 2014 - 13:33:34)
CPU:Â Â Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: UDOO
DRAM:Â 1 GiB
MMC:Â Â FSL_SDHC: 0
*** Warning - bad CRC, using default environment
No panel detected: default to LDB-WVGA
Display: LDB-WVGA (800x480)
In:Â Â Â serial
Out:Â Â serial
Err:Â Â serial
Net:Â Â using phy at 6
FEC [PRIME]
Warning: failed to set MAC address
Hit any key to stop autoboot:Â 0
mmc0 is current device
** File not found boot.scr **
5077712 bytes read in 419 ms (11.6 MiB/s)
Booting from mmc ...
** File not found imx6q-udoo.dtb **
## Booting kernel from Legacy Image at 12000000 ...
  Image Name:  Linux-3.10.17-80552-gd6e35d0
  Image Type:  ARM Linux Kernel Image (uncompressed)
  Data Size:   5077648 Bytes = 4.8 MiB
  Load Address: 10800000
  Entry Point: 10800000
  Verifying Checksum ... OK
  Loading Kernel Image ... OK
Starting kernel ...
-------------------------------------------------------------------------
Please share your thought on this.
-Anand Moon