headers
Vincent Perrier | 10 Jun 2009 22:13
Picon

Fedora core 11 and UML kernel compile

Hello,
I think I am not the first to have this problem, but just
to remind people of this problem:
Fedora 11 cannot compile uml kernels (2.6.29.4 and 2.6.30),
here is the error:
   . . .
   . . .
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
/usr/bin/ld:arch/um/kernel/vmlinux.lds:1: ignoring invalid character `#'
in expression
/usr/bin/ld:arch/um/kernel/vmlinux.lds:1: syntax error
collect2: ld returned 1 exit status
  KSYM    .tmp_kallsyms1.S
nm: '.tmp_vmlinux1': No such file
No valid symbol.
make: *** [.tmp_kallsyms1.S] Error 1

I have no knowledge at all of kernel compilation, so I have no idea
how to get it compiled.

Note with no link to the above problem:
I have made a virtual network creation software using UML at
http://clownix.net and with it you can mix UML and KVM machines
and on this emulated network UML is MUCH faster as far as
emulated ethernet interfaces are concerned.

On both machines, a socket is used to get into the machine ethernet
emulated interface, and as the KVM emulates real hardware (interrupts
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Menage | 11 Jun 2009 21:02
Picon
Favicon

Building/runing UML in SMP mode

For a while now (since tt mode was dropped and skas mode became the
only option?)  it looks as though UML has been UP-only on x86-64. And
even though the configs appear to allow building SMP on x86-32, there
are things like the panic() call in kernel/smp.c:idle_thread() which
imply that it won't work too well in 32-bit mode either.

For testing cgroups/cpusets changes we'd find it useful to be able to
run UML in SMP mode. Is anyone working on this, or can point us at a
list of the major things that need to be done to make SMP UML
practical?

Thanks,

Paul

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
Permalink | Reply | 3 comments |
headers
Paul Menage | 16 Jun 2009 02:17
Picon
Favicon

[PATCH 1/5] UML: Fix some apparent bitrot

UML: Fix some apparent bitrot

- migration of net_device methods into net_device_ops
- address space layout changes
- dma_sync_single() changes

Signed-off-by: Paul Menage <menage <at> google.com>

---

 arch/um/drivers/slip_kern.c        |    1 -
 arch/um/drivers/slirp_kern.c       |    1 -
 arch/um/include/asm/dma-mapping.h  |    4 ++--
 arch/um/include/shared/as-layout.h |    4 +---
 4 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/arch/um/drivers/slip_kern.c b/arch/um/drivers/slip_kern.c
index 5ec1756..dd2aadc 100644
--- a/arch/um/drivers/slip_kern.c
+++ b/arch/um/drivers/slip_kern.c
 <at>  <at>  -30,7 +30,6  <at>  <at>  static void slip_init(struct net_device *dev, void *data)

 	slip_proto_init(&spri->slip);

-	dev->init = NULL;
 	dev->hard_header_len = 0;
 	dev->header_ops = NULL;
 	dev->addr_len = 0;
diff --git a/arch/um/drivers/slirp_kern.c b/arch/um/drivers/slirp_kern.c
index f15a6e7..e376284 100644
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Menage | 16 Jun 2009 02:17
Picon
Favicon

[PATCH 4/5] UML: Avoid lockdep issues during initialization

UML: Avoid lockdep issues during initialization

UML calls atomic_notifier_chain_register() very early during
initialization. When lockdep is in use, the spinlock operations thus
invoked make use of current_thread_info(), which isn't valid in UML
until start_kernel_proc() is reached (running on the init_thread_union
stack rather than the default stack at the top of the address space).

This patch moves the call to the beginning of start_kernel_proc(), and
additionally disables lock debugging for the duration of the call,
since lockdep_init() doesn't occur until start_kernel() is called.

Signed-off-by: Paul Menage <menage <at> google.com>

---

 arch/um/kernel/skas/process.c |   26 ++++++++++++++++++++++++++
 arch/um/kernel/um_arch.c      |   20 --------------------
 2 files changed, 26 insertions(+), 20 deletions(-)

diff --git a/arch/um/kernel/skas/process.c b/arch/um/kernel/skas/process.c
index 4a21c5c..2b62a72 100644
--- a/arch/um/kernel/skas/process.c
+++ b/arch/um/kernel/skas/process.c
 <at>  <at>  -5,7 +5,9  <at>  <at> 

 #include "linux/init.h"
 #include "linux/sched.h"
+#include "linux/debug_locks.h"
 #include "as-layout.h"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Dike | 16 Jun 2009 03:03

Re: Building/runing UML in SMP mode

On Thu, Jun 11, 2009 at 12:02:56PM -0700, Paul Menage wrote:
> For a while now (since tt mode was dropped and skas mode became the
> only option?)  it looks as though UML has been UP-only on x86-64. And
> even though the configs appear to allow building SMP on x86-32, there
> are things like the panic() call in kernel/smp.c:idle_thread() which
> imply that it won't work too well in 32-bit mode either.
> 
> For testing cgroups/cpusets changes we'd find it useful to be able to
> run UML in SMP mode. Is anyone working on this, or can point us at a
> list of the major things that need to be done to make SMP UML
> practical?

SMP has been problematic because of ptrace.  Ironically, despite the
horridness of tt mode, that was where SMP was easiest to do.

The problem with SMP on skas0 is the need to detach a userspace
process from one virtual CPU process and attach it to another whenever
the associated UML process is migrated from one CPU to another.

I actually had this somewhat working, but the code was a horror show,
with much nastiness about ignoring the signals that are needed in
order to prevent a detached process from running.

				Jeff

--

-- 
Work email - jdike at linux dot intel dot com

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul Menage | 16 Jun 2009 02:17
Picon
Favicon

[PATCH 2/5] UML: Enable CONFIG_TRACE_IRQFLAGS_SUPPORT

UML: Enable CONFIG_TRACE_IRQFLAGS_SUPPORT

Signed-off-by: Paul Menage <menage <at> google.com>

---

 arch/um/Kconfig.common        |    2 +-
 arch/um/include/asm/system.h  |   39 ++++++++++++++++++++++-----------------
 arch/um/kernel/irq.c          |    1 +
 arch/um/kernel/process.c      |    1 -
 arch/um/kernel/skas/process.c |    2 +-
 5 files changed, 25 insertions(+), 20 deletions(-)

diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index 0d207e7..8a54ae4 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
 <at>  <at>  -36,7 +36,7  <at>  <at>  config PCMCIA
 # Yet to do!
 config TRACE_IRQFLAGS_SUPPORT
 	bool
-	default n
+	default y

 config LOCKDEP_SUPPORT
 	bool
diff --git a/arch/um/include/asm/system.h b/arch/um/include/asm/system.h
index 753346e..dd76c29 100644
--- a/arch/um/include/asm/system.h
+++ b/arch/um/include/asm/system.h
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Menage | 16 Jun 2009 02:17
Picon
Favicon

[PATCH 3/5] UML: Enable CONFIG_STACKTRACE_SUPPORT

UML: Enable CONFIG_STACKTRACE_SUPPORT

Adds a simple stacktrace function, only tested/enabled on X86

Signed-off-by: Paul Menage <menage <at> google.com>

---

 arch/um/Kconfig.common      |    2 +
 arch/um/kernel/Makefile     |    1 +
 arch/um/kernel/stacktrace.c |   68 +++++++++++++++++++++++++++++++++++++++++++
 arch/um/kernel/sysrq.c      |   20 +++++++++++++
 4 files changed, 90 insertions(+), 1 deletions(-)
 create mode 100644 arch/um/kernel/stacktrace.c

diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index 8a54ae4..b757c36 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
 <at>  <at>  -44,7 +44,7  <at>  <at>  config LOCKDEP_SUPPORT

 config STACKTRACE_SUPPORT
 	bool
-	default n
+	default UML_X86

 config GENERIC_CALIBRATE_DELAY
 	bool
diff --git a/arch/um/kernel/Makefile b/arch/um/kernel/Makefile
index 388ec0a..b1867a0 100644
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Menage | 16 Jun 2009 02:17
Picon
Favicon

[PATCH 5/5] UML: Remove sigio_lock()/sigio_unlock() lockdep warnings

UML: Remove sigio_lock()/sigio_unlock() lockdep warnings

When lockdep is enabled on UML, calls to sigio_lock() and
sigio_unlock() trigger a lockdep warning since this function is called
both from interrupt context and process context. This patch allows a
"flags" argument to be passed to sigio_lock() and sigio_unlock() to
allow them to use spin_lock_irqsave() and spin_unlock_irqrestore().

Signed-off-by: Paul Menage <menage <at> google.com>

---

 arch/um/include/shared/sigio.h |    4 +--
 arch/um/kernel/sigio.c         |    8 +++---
 arch/um/os-Linux/sigio.c       |   55 +++++++++++++++++++++-------------------
 3 files changed, 35 insertions(+), 32 deletions(-)

diff --git a/arch/um/include/shared/sigio.h b/arch/um/include/shared/sigio.h
index 434f1a9..5b16047 100644
--- a/arch/um/include/shared/sigio.h
+++ b/arch/um/include/shared/sigio.h
 <at>  <at>  -8,7 +8,7  <at>  <at> 

 extern int write_sigio_irq(int fd);
 extern int register_sigio_fd(int fd);
-extern void sigio_lock(void);
-extern void sigio_unlock(void);
+extern void sigio_lock(unsigned long *flags);
+extern void sigio_unlock(unsigned long flags);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Menage | 16 Jun 2009 03:22
Picon
Favicon

Re: Building/runing UML in SMP mode

On Mon, Jun 15, 2009 at 6:03 PM, Jeff Dike<jdike <at> addtoit.com> wrote:
>
> The problem with SMP on skas0

Does that mean that it works more easily on skas3?

> I actually had this somewhat working, but the code was a horror show,
> with much nastiness about ignoring the signals that are needed in
> order to prevent a detached process from running.
>

So it's probably not on the horizon any time soon then?

Thanks,

Paul

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
Permalink | Reply | 1 comment |
headers
Paul Menage | 16 Jun 2009 02:17
Picon
Favicon

[RFC][PATCH 0/5] UML: Support lockdep on x86-64 UML

The following series provides the basic support for lockdep on UML
running on x86-64, and fixes a few lockdep-generated warnings.

It's not yet sufficient to properly use lockdep yet - currently
lockdep disables itself with the stacktrace/warning below; presumably
there's a point in the UML code where an unblock_signals() call needs
to be accompanied by a trace_hardirqs_off(), but I'm not familiar
enough with the UML code to figure out which one(s). Any suggestions
from those more familiar with either lockdep or UML would be welcome.

 [<0000000060025e3d>] show_trace+0x61/0x78
 [<0000000060025f64>] dump_stack+0x22/0x2e
 [<0000000060043192>] warn_slowpath_common+0x66/0x90
 [<00000000600431ce>] warn_slowpath_null+0x12/0x14
 [<00000000600648c3>] check_flags+0xbb/0x1c0
 [<0000000060069dcc>] lock_acquire+0x61/0xd9
 [<0000000060082236>] find_get_page+0x47/0xb1
 [<0000000060082539>] find_lock_page+0x25/0x77
 [<0000000060082ed9>] find_or_create_page+0x3c/0xa8
 [<00000000600cdca3>] __getblk+0x144/0x25e
 [<0000000060119025>] jread+0x13c/0x24c
 [<00000000601191a8>] do_one_pass+0x73/0x4b9
 [<00000000601196c3>] journal_recover+0x54/0xf1
 [<000000006011c159>] journal_load+0x59/0xa5
 [<0000000060109eec>] ext3_fill_super+0x10c7/0x1884
 [<00000000600ad64a>] get_sb_bdev+0x123/0x175
 [<00000000601068f2>] ext3_get_sb+0x12/0x14
 [<00000000600ac475>] vfs_kern_mount+0x5d/0xae
 [<00000000600ac52e>] do_kern_mount+0x52/0x103
 [<00000000600c476e>] do_mount+0x7ca/0x861
(Continue reading)

Permalink | Reply | 5 comments |

Gmane