linux-um archives
 help / color / mirror / Atom feed
From: Dennis Muhlestein <devel@muhlesteins.com>
To: user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] Patch for 2.6.6
Date: Tue, 11 May 2004 14:28:21 -0600	[thread overview]
Message-ID: <40A13765.5010002@muhlesteins.com> (raw)
In-Reply-To: <200405112032.13202.blaisorblade_spam@yahoo.it>

I got this:

Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 19.
2 out of 2 hunks FAILED -- saving rejects to file include/asm-um/irq.h.rej

when applying the first patch.  I tried also with not applying that 
part, and get a compile failure pretty early in the build process.

-Dennis


BlaisorBlade wrote:

>I'm working on the 2.6.6 patch, and you'll find attached what you need on top 
>of the vanilla kernel. I changed a bit his 2.6.6-0 patch, so I attach the 
>2.6.6-01 patch. The changes just avoid the "fuzz" messages from patch.
>
>So, what to do:
>
>-create a 2.6.6 vanilla kernel tree
>-apply the attached uml-patch-2.6.6-01.bz2
>-apply the attached patch-2.6.6-v2
>
>you need no other patches!! The one for 2.6.5 is included!
>
>-build as usual.
>
>I've built one UML this way, I just have a problem with tty pairs with the 
>root_fs_tomsbrt: maybe it comes from the work done in the kernel in this area 
>and from the particularities of that FS; with my normal slack9.0 FS, it 
>started well and is now working and running some little stress tests.
>
>Or better, it stopped at a certain point, did a lot of work, 
>restarted the boot process from the first message and then went just fine. I 
>typed "reboot" and it worked perfectly; then I shut it down, and restarted 
>it: it worked perfectly.
>
>However, before it started, the same binary gave:
>- a segmentation fault (not repeatable, sometimes it happened even before)
>- a panic from tcsetattr with EINTR (it's known, has a XXX in the sources and 
>I sent a working patch time ago)
>
From here onwards there are the technical details about the patches:
>
>Most of the kludges Jeff Chua did are just workaround, which can be replaced 
>with this patch:
>
>--- Makefile.saved      2004-05-11 19:20:02.000000000 +0200
>+++ Makefile    2004-05-11 19:20:59.000000000 +0200
>@@ -449,6 +449,10 @@
>
> include $(srctree)/arch/$(ARCH)/Makefile
>
>+# Let architecture Makefiles change CPPFLAGS if needed
>+CFLAGS := $(CPPFLAGS) $(CFLAGS)
>+AFLAGS := $(CPPFLAGS) $(AFLAGS)
>+
> ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
> CFLAGS         += -Os
> else
>
>(apply with patch -l). This undoes a change from the 2.6.6 patch, done for I 
>do not know which reason. They probably thought it didn't hurt; it does, 
>indeed. For us it is VERY important (actually, for some kludges we do).
>
>This second change, instead, comes straight from his patch. I've not tested 
>it, however I know where it could come from. If he got a running UML with 
>this change, then it means it works, however it needs some more analisys 
>IMHO.
>
>--- ./arch/um/kernel/physmem.c.saved    2004-05-11 19:24:53.000000000 +0200
>+++ ./arch/um/kernel/physmem.c  2004-05-11 19:25:16.000000000 +0200
>@@ -285,7 +285,7 @@
>                p = &map[i];
>                set_page_count(p, 0);
>                SetPageReserved(p);
>-               INIT_LIST_HEAD(&p->list);
>+               INIT_LIST_HEAD(&p->lru);
>        }
>
>        mem_map = map;
>
>Then, inside patch-2.6.6-v1 there is the content of the 2nd version of the 
>2.6.5 fix.
>
>Finally, I had to fix the linker script, to avoid the problem with these lines 
>addressed:
>
>--- uml.org/kernel/sched.c      Fri Apr 16 21:23:00 2004
>+++ uml/kernel/sched.c  Fri Apr 16 12:19:34 2004
>@@ -225,12 +225,14 @@
> #define task_rq(p)             cpu_rq(task_cpu(p))
> #define cpu_curr(cpu)          (cpu_rq(cpu)->curr)
>
>+/*
> extern unsigned long __scheduling_functions_start_here;
> extern unsigned long __scheduling_functions_end_here;
> const unsigned long scheduling_functions_start_here =
>                        (unsigned long)&__scheduling_functions_start_here;
> const unsigned long scheduling_functions_end_here =
>                        (unsigned long)&__scheduling_functions_end_here;
>+*/
>
>I had to use SCHED_TEXT inside the linker script as the other linking scripts 
>do from 2.6.6; this provides the definition for __scheduling_functions_*.
>
>And finally this:
>
> void show_stack(struct task_struct *task, unsigned long *sp)
> {
>-       if(task)
>-               show_trace_task(task);
>-       else
>-               show_trace(sp);
>+       show_trace(sp);
> }
>
>because 2.6.6 deletes show_trace_task from each arch. However the other archs 
>did never actually use it, while UML does - maybe the proper solution is to 
>restore the show_trace_task definition. But why was it unused? Maybe the bug 
>is the fact we use it.
>
>However, I hope it helps.
>  
>
>------------------------------------------------------------------------
>
>--- linux-2.6.6/arch/um/kernel/physmem.c.saved	2004-05-11 19:24:53.000000000 +0200
>+++ linux-2.6.6/arch/um/kernel/physmem.c	2004-05-11 19:25:16.000000000 +0200
>@@ -285,7 +285,7 @@
> 		p = &map[i];
> 		set_page_count(p, 0);
> 		SetPageReserved(p);
>-		INIT_LIST_HEAD(&p->list);
>+		INIT_LIST_HEAD(&p->lru);
> 	}
> 
> 	mem_map = map;
>--- linux-2.6.6/arch/um/kernel/sysrq.c.saved	2004-05-11 17:52:41.000000000 +0200
>+++ linux-2.6.6/arch/um/kernel/sysrq.c	2004-05-11 19:55:36.000000000 +0200
>@@ -46,10 +46,7 @@
> 
> void show_stack(struct task_struct *task, unsigned long *sp)
> {
>-	if(task)
>-		show_trace_task(task);
>-	else
>-		show_trace(sp);
>+	show_trace(sp);
> }
> 
> /*
>--- linux-2.6.6/arch/um/dyn.lds.S.saved	2004-05-11 17:52:40.000000000 +0200
>+++ linux-2.6.6/arch/um/dyn.lds.S	2004-05-11 20:18:36.000000000 +0200
>@@ -1,3 +1,5 @@
>+#include <asm-generic/vmlinux.lds.h>
>+
> OUTPUT_FORMAT(ELF_FORMAT)
> OUTPUT_ARCH(ELF_ARCH)
> ENTRY(_start)
>@@ -58,7 +60,9 @@
>   } =0x90909090
>   .plt            : { *(.plt) }
>   .text           : {
>-    *(.text .stub .text.* .gnu.linkonce.t.*)
>+    *(.text)
>+    SCHED_TEXT
>+    *(.stub .text.* .gnu.linkonce.t.*)
>     /* .gnu.warning sections are handled specially by elf32.em.  */
>     *(.gnu.warning)
>   } =0x90909090
>--- linux-2.6.6/arch/um/uml.lds.S.saved	2004-05-11 17:52:42.000000000 +0200
>+++ linux-2.6.6/arch/um/uml.lds.S	2004-05-11 20:03:10.000000000 +0200
>@@ -34,6 +34,7 @@
>   .text      :
>   {
>     *(.text)
>+    SCHED_TEXT
>     /* .gnu.warning sections are handled specially by elf32.em.  */
>     *(.gnu.warning)
>     *(.gnu.linkonce.t*)
>--- linux-2.6.6/Makefile.saved	2004-05-11 19:20:02.000000000 +0200
>+++ linux-2.6.6/Makefile	2004-05-11 19:20:59.000000000 +0200
>@@ -449,6 +449,10 @@
> 
> include $(srctree)/arch/$(ARCH)/Makefile
> 
>+# Let architecture Makefiles change CPPFLAGS if needed
>+CFLAGS := $(CPPFLAGS) $(CFLAGS)
>+AFLAGS := $(CPPFLAGS) $(AFLAGS)
>+
> ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
> CFLAGS		+= -Os
> else
>--- linux/include/asm-um/system-i386.h	2004-02-04 04:43:42.000000000 +0100
>+++ uml/linux/include/asm-um/system-i386.h	2004-04-08 00:18:09.621333000 +0200
>@@ -2,36 +2,5 @@
> #define __UM_SYSTEM_I386_H
> 
> #include "asm/system-generic.h"
>-
>-static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
>-				      unsigned long new, int size)
>-{
>-	unsigned long prev;
>-	switch (size) {
>-	case 1:
>-		__asm__ __volatile__(LOCK_PREFIX "cmpxchgb %b1,%2"
>-				     : "=a"(prev)
>-				     : "q"(new), "m"(*__xg(ptr)), "0"(old)
>-				     : "memory");
>-		return prev;
>-	case 2:
>-		__asm__ __volatile__(LOCK_PREFIX "cmpxchgw %w1,%2"
>-				     : "=a"(prev)
>-				     : "q"(new), "m"(*__xg(ptr)), "0"(old)
>-				     : "memory");
>-		return prev;
>-	case 4:
>-		__asm__ __volatile__(LOCK_PREFIX "cmpxchgl %1,%2"
>-				     : "=a"(prev)
>-				     : "q"(new), "m"(*__xg(ptr)), "0"(old)
>-				     : "memory");
>-		return prev;
>-	}
>-	return old;
>-}
>-
>-#define cmpxchg(ptr,o,n)\
>-	((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o),\
>-					(unsigned long)(n),sizeof(*(ptr))))
>     
> #endif
>--- linux/arch/um/Makefile-i386	2004-04-08 00:27:50.031333000 +0200
>+++ uml/linux/arch/um/Makefile-i386	2004-04-07 23:22:31.000000000 +0200
>@@ -30,7 +30,7 @@
> $(SYS_DIR)/thread.h: $(SYS_UTIL_DIR)/mk_thread 
> 	$(call filechk,$@)
> 
>-$(SYS_UTIL_DIR)/mk_sc: scripts/fixdep include/config/MARKER FORCE ; 
>+$(SYS_UTIL_DIR)/mk_sc: scripts/basic/fixdep include/config/MARKER FORCE ; 
> 	$(Q)$(MAKE) $(build)=$(SYS_UTIL_DIR) $@
> 
> $(SYS_UTIL_DIR)/mk_thread: $(ARCH_SYMLINKS) $(GEN_HEADERS) sys_prepare FORCE ; 
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

  reply	other threads:[~2004-05-11 20:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-11 18:37 [uml-devel] Patch for 2.6.6 BlaisorBlade
2004-05-11 20:28 ` Dennis Muhlestein [this message]
2004-05-11 23:22   ` roland
2004-05-12 18:24   ` BlaisorBlade
2004-05-12 21:20     ` roland
2004-05-12 13:39 ` Rik van Riel
2004-05-15 15:03 ` /dev/rob0
  -- strict thread matches above, loose matches on Subject: below --
2004-05-11 19:01 BlaisorBlade

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40A13765.5010002@muhlesteins.com \
    --to=devel@muhlesteins.com \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox