linux-toradex.git/init, branch T20_LinuxImageV2.0Beta1_20121218

init: check printed flag to skip printing message

2012-03-09T19:48:49+00:00

Otherwise the 'Calibration skipped' message gets printed everytime a CPU is
hotplugged in, cluttering console for systems that frequently hotplug CPUs.

Change-Id: Ie0b4dc92a11d7518cfe6eb2100d8edadca4efb3e
Signed-off-by: Diwakar Tundlam 
Reviewed-on: http://git-master/r/88921
Reviewed-by: Satya Popuri 
Reviewed-by: Aleksandr Frid 
Reviewed-by: Peter Boonstoppel

Merge branch 'linux-3.1.y' into android-tegra-nv-3.1

2012-01-24T11:35:20+00:00

Linux 3.1.10

Change-Id: I465d184c492e8041dd0cd90f2cb70fde17ba7118
Signed-off-by: Varun Wadekar

NFS: Retry mounting NFSROOT

2012-01-18T15:31:54+00:00

commit 43717c7daebf10b43f12e68512484b3095bb1ba5 upstream.

Lukas Razik  reports that on his SPARC system,
booting with an NFS root file system stopped working after commit
56463e50 "NFS: Use super.c for NFSROOT mount option parsing."

We found that the network switch to which Lukas' client was attached
was delaying access to the LAN after the client's NIC driver reported
that its link was up.  The delay was longer than the timeouts used in
the NFS client during mounting.

NFSROOT worked for Lukas before commit 56463e50 because in those
kernels, the client's first operation was an rpcbind request to
determine which port the NFS server was listening on.  When that
request failed after a long timeout, the client simply selected the
default NFS port (2049).  By that time the switch was allowing access
to the LAN, and the mount succeeded.

Neither of these client behaviors is desirable, so reverting 56463e50
is really not a choice.  Instead, introduce a mechanism that retries
the NFSROOT mount request several times.  This is the same tactic that
normal user space NFS mounts employ to overcome server and network
delays.

Signed-off-by: Lukas Razik 
[ cel: match kernel coding style, add proper patch description ]
[ cel: add exponential back-off ]
Signed-off-by: Chuck Lever 
Tested-by: Lukas Razik 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

ashmem for 2.6.27.

2011-12-01T05:37:55+00:00

Forward port of ashmem to 2.6.27.

Signed-off-by: Robert Love 

ashmem: Don't install fault handler for private mmaps.

Ashmem is used to create named private heaps. If this heap is backed
by a tmpfs file it will allocate two pages for every page touched.
In 2.6.27, the extra page would later be freed, but 2.6.29 does not
scan anonymous pages when running without swap so the memory is not
freed while the file is referenced. This change changes the behavior
of private ashmem mmaps to match /dev/zero instead tmpfs.

Signed-off-by: Arve Hjønnevåg 

ashmem: Add common prefix to name reported in /proc/pid/maps

Signed-off-by: Arve Hjønnevåg 

ashmem: don't require a page aligned size

This makes ashmem more similar to shmem and mmap, by
not requiring the specified size to be page aligned,
instead rounding it internally as needed.

Signed-off-by: Marco Nelissen

Add build option to to set the default panic timeout.

2011-12-01T05:37:51+00:00

bootup: move 'usermodehelper_enable()' a little earlier

2011-09-30T02:21:01+00:00

Commit d5767c53535a ("bootup: move 'usermodehelper_enable()' to the end
of do_basic_setup()") moved 'usermodehelper_enable()' to end of
do_basic_setup() to after the initcalls.  But then I get failed to let
uvesafb work on my computer, and lose the splash boot.

So maybe we could start usermodehelper_enable a little early to make
some task work that need eary init with the help of user mode.

[ I would *really* prefer that initcalls not call into user space - even
  the real 'init' hasn't been execve'd yet, after all! But for uvesafb
  it really does look like we don't have much choice.

  I considered doing this when we mount the root filesystem, but
  depending on config options that is in multiple places.  We could do
  the usermode helper enable as a rootfs_initcall()..

  So I'm just using wang yanqing's trivial patch.  It's not wonderful,
  but it's simple and should work.  We should revisit this some day,
  though.      - Linus ]

Signed-off-by: Linus Torvalds

bootup: move 'usermodehelper_enable()' to the end of do_basic_setup()

2011-09-28T17:23:44+00:00

Doing it just before starting to call into cpu_idle() made a sick kind
of sense only because the original bug we fixed (see commit
288d5abec831: "Boot up with usermodehelper disabled") was about problems
with some scheduler data structures not being initialized, and they had
better be initialized at that point.

But it really didn't make any other conceptual sense, and doing it after
the initial "schedule()" call for the idle thread actually opened up a
race: what if the main initialization thread did everything without
needing to sleep, and got all the way into user land too? Without
actually having scheduled back to the idle thread?

Now, in normal circumstances that doesn't ever happen, but it looks like
Richard Cochran triggered exactly that on his ARM IXP4xx machines:

  "I have some ARM IXP4xx based machines that use the two on chip MAC
   ports (aka NPEs).  The NPE needs a firmware in order to function.
   Ever since the following commit [that 288d5abec831 one], it is no
   longer possible to bring up the interfaces during the init scripts."

with a call trace showing an ioctl coming from user space. Richard says:

  "The init is busybox, and the startup script does mount, syslogd, and
   then ifup, so that all can go by quickly."

The fix is to move the usermodehelper_enable() into the main 'init'
thread, and just put it after we've done all our initcalls.  By then,
everything really should be up, but we've obviously not actually started
the user-mode portion of init yet.

Reported-and-tested-by: Richard Cochran 
Signed-off-by: Linus Torvalds

init: carefully handle loglevel option on kernel cmdline.

2011-09-21T20:18:52+00:00

When a malformed loglevel value (for example "${abc}") is passed on the
kernel cmdline, the loglevel itself is being set to 0.

That then suppresses all following messages, including all the errors
and crashes caused by other malformed cmdline options.  This could make
debugging process quite tricky.

This patch leaves the previous value of loglevel if the new value is
incorrect and reports an error code in this case.

Signed-off-by: Alexander Sverdlin 
Signed-off-by: Linus Torvalds

Boot up with usermodehelper disabled

2011-08-04T08:03:29+00:00

The core device layer sends tons of uevent notifications for each device
it finds, and if the kernel has been built with a non-empty
CONFIG_UEVENT_HELPER_PATH that will make us try to execute the usermode
helper binary for all these events very early in the boot.

Not only won't the root filesystem even be mounted at that point, we
literally won't have necessarily even initialized all the process
handling data structures at that point, which causes no end of silly
problems even when the usermode helper doesn't actually succeed in
executing.

So just use our existing infrastructure to disable the usermodehelpers
to make the kernel start out with them disabled.  We enable them when
we've at least initialized stuff a bit.

Problems related to an uninitialized

	init_ipc_ns.ids[IPC_SHM_IDS].rw_mutex

reported by various people.

Reported-by: Manuel Lauss 
Reported-by: Richard Weinberger 
Reported-by: Marc Zyngier 
Acked-by: Kay Sievers 
Cc: Andrew Morton 
Cc: Vasiliy Kulikov 
Cc: Greg KH 
Signed-off-by: Linus Torvalds

tmpfs: miscellaneous trivial cleanups

2011-08-04T00:25:23+00:00

While it's at its least, make a number of boring nitpicky cleanups to
shmem.c, mostly for consistency of variable naming.  Things like "swap"
instead of "entry", "pgoff_t index" instead of "unsigned long idx".

And since everything else here is prefixed "shmem_", better change
init_tmpfs() to shmem_init().

Signed-off-by: Hugh Dickins 
Acked-by: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds