uml-patch-2.5.39

UML has been updated to 2.5.39.

The build works again.

There were some block driver updates so UML will boot on an unpartitioned disk. I'll be merging changes which fix partitions.

This patch contains UML highmem support.

The patch is available at

	http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.5.39.bz2

For the other UML mirrors and other downloads, see
http://user-mode-linux.sourceforge.net/dl-sf.html

Other links of interest:

The UML project home page : http://user-mode-linux.sourceforge.net
The UML Community site : http://usermodelinux.org

Jeff

not as far as i can tell.

just after typing make

Makefile:363: target `arch/um/os-Linux' given more than once in the same rule.
Makefile:363: target `arch/um/kernel' given more than once in the same rule.
Makefile:363: target `arch/um/drivers' given more than once in the same rule.
Makefile:363: target `arch/um/sys-i386' given more than once in the same rule.
Makefile:533: target `_modinst_arch/um/os-Linux' given more than once in the same rule.
Makefile:533: target `_modinst_arch/um/kernel' given more than once in the same rule.
Makefile:533: target `_modinst_arch/um/drivers' given more than once in the same rule.
Makefile:533: target `_modinst_arch/um/sys-i386' given more than once in the same rule.
Generating include/linux/version.h (unchanged)
make[1]: Entering directory `/home2/james/kernel-build/linux-2.5.39/scripts'
gcc -Wp,-MD,./.fixdep.d -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -o fixdep fixdep.c
gcc -Wp,-MD,./.split-include.d -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -o split-include split-include.c
gcc -Wp,-MD,./.docproc.d -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -o docproc docproc.c
gcc -Wp,-MD,./.conmakehash.d -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -o conmakehash conmakehash.c
make[1]: Leaving directory `/home2/james/kernel-build/linux-2.5.39/scripts'
***
*** You changed .config w/o running make *config?
*** Please run "make oldconfig"
***
make: *** [include/linux/autoconf.h] Error 1

Hello!

Here's what I need to apply before I can build bk-current with UML support. If you use Jeff's patch to 2.5.39, you then only need Makefle part of the patch, I guess.

Jeff: BTW, UML crashes for me on shutdown quite often, if I have CONFIG_DEBUG_SLAB enabled. Just before the crash it warns about winch_interrupt : read failed, errno = 9
fd 57 is losing SIGWINCH support
(this is immediatelly after 'System halted.' message from kernel). And then kernel mode fault at 0x5a5a5a5e

Bye,
Oleg

===== arch/um/Makefile 1.5 vs edited =====

@@ -30,11 +30,6 @@
 LINK_PROFILE = $(PROFILE) -Wl,--wrap,__monstartup
 endif
 
-ARCH_SUBDIRS = $(ARCH_DIR)/drivers $(ARCH_DIR)/kernel \
-	$(ARCH_DIR)/sys-$(SUBARCH) $(ARCH_DIR)/os-$(OS)
-
-SUBDIRS += $(ARCH_SUBDIRS)
-
 core-y			+= $(ARCH_DIR)/kernel/		 \
 			   $(ARCH_DIR)/drivers/          \
 			   $(ARCH_DIR)/sys-$(SUBARCH)/

===== arch/um/drivers/ubd_kern.c 1.5 vs edited =====

@@ -406,7 +406,7 @@
 	ubd_gendisk[n].major = MAJOR_NR;
 	ubd_gendisk[n].first_minor = n << UBD_SHIFT;
 	ubd_gendisk[n].minor_shift = UBD_SHIFT;
-	ubd_gendisk[n].fops = &ubd_fops;
+	ubd_gendisk[n].fops = &ubd_blops;
 	if (fakehd_set)
 		sprintf(ubd_gendisk[n].disk_name, "hd%c", n + 'a');
 	else

@@ -416,7 +416,7 @@
 		fake_gendisk[n].major = fake_major;
 		fake_gendisk[n].first_minor = n << UBD_SHIFT;
 		fake_gendisk[n].minor_shift = UBD_SHIFT;
-		fake_gendisk[n].fops = &ubd_fops;
+		fake_gendisk[n].fops = &ubd_blops;
 		sprintf(fake_gendisk[n].disk_name, "ubd%d", n);
 	}
 

@@ -445,7 +445,7 @@
  	if(real == NULL) return(-1);
  	ubd_dev[n].real = real;
  
-	make_ide_entries(ubd_gendisk[n].name);
+	make_ide_entries(ubd_gendisk[n].disk_name);
 	return(0);
 }
 

@@ -863,6 +863,7 @@
 			return(-EFAULT);
 		return(0);
 	}
+	return -ENOTTY;
 }
 
 static int ubd_revalidate(kdev_t rdev)

Applied, thanks.

Can you get a stack trace from that crash?

This looks different. Is it consistently the same file descriptor? If so, put a breakpoint on close and see who's closing it who isn't supposed to.

Hello!

Well, it can be both ways (EINVAL and ENOTTY). Probably EINVAL is more close in this case, though. I'll send the stacktraces tomorrow, when I'll get to work.

Bye,
Oleg

Hello!

Sure.

#0 panic (fmt=0xa0240900 "Kernel mode fault at addr 0x%lx, ip 0x%lx")

    at panic.c:45
#1  0xa00164e5 in segv (address=1515870814, ip=2684410784, is_write=0, 
    is_user=0, sc=0xaeeb33a0) at trap_kern.c:129
#2  0xa0017466 in segv_handler (sig=11, regs=0xaeea4390) at trap_user.c:437
#3  0xa001751b in sig_handler_common (sig=11, sc=0xaeeb33a0) at trap_user.c:488
#4  0xa0017596 in sig_handler (sig=11, sc=
      {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0, edi = 10, esi = 872415233, ebp = 2934650508, esp = 2934650484, ebx = 1515870810, edx = 0, ecx = 2934650172, eax = 1, trapno = 14, err = 4, eip = 2684410784, cs = 35, __csh = 0, eflags = 66054, esp_at_signal = 2934650484, ss = 43, __ssh = 0, fpstate = 0x0, oldmask = 469827584, cr2 = 1515870814}) at trap_user.c:504
#5  <signal handler called>
#6  handle_IRQ_event (irq=10, regs=0xaeea4390, action=0xa03cc604) at irq.c:153
#7  0xa000dd81 in do_IRQ (irq=10, regs=0xaeea4390) at irq.c:324
#8  0xa000e4ac in sigio_handler (sig=29, regs=0xaeea4390) at irq_user.c:73
#9  0xa001751b in sig_handler_common (sig=29, sc=0xaeeb3788) at trap_user.c:488
#10 0xa0017596 in sig_handler (sig=29, sc=
      {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0, edi = 2934651928, esi = 672274793, ebp = 2934651532, esp = 2934651488, ebx = 66, edx = 2688339692, ecx = 2934651356, eax = 0, trapno = 14, err = 4, eip = 2686504781, cs = 35, __csh = 0, eflags = 643, esp_at_signal = 2934651488, ss = 43, __ssh = 0, fpstate = 0x0, oldmask = 201392128, cr2 = 1074026496})
    at trap_user.c:504

#11 <signal handler called>
#12 0xa020cf4d in __libc_close ()
#13 0xa001fe51 in winch_cleanup () at line.c:441
#14 0xa0011268 in do_uml_exitcalls () at process_kern.c:622 #15 0xa0011feb in machine_power_off () at reboot.c:42 #16 0xa001201b in machine_halt () at reboot.c:50
#17 0xa0035eb5 in sys_reboot (magic1=-18751827, magic2=672274793,

    cmd=3454992675, arg=0x8049644) at sys.c:386

#18 0xa001509d in execute_syscall (r=0xaeea4390) at syscall_kern.c:405 #19 0xa00151e0 in syscall_handler (sig=12, regs=0xaeea4390)
at syscall_user.c:63
#20 0xa001751b in sig_handler_common (sig=12, sc=0xaeeb3d28) at trap_user.c:488 #21 0xa0017596 in sig_handler (sig=12, sc=

      {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0, edi = 4276215469, esi = 134518340, ebp = 2684353868, esp = 2684353840, ebx = 4276215469, edx = 3454992675, ecx = 672274793, eax = 4294967258, trapno = 14, err = 4, eip = 1074697900, cs = 35, __csh = 0, eflags = 534, esp_at_signal = 2684353840, ss = 43, __ssh = 0, fpstate = 0xaeeb3d80, oldmask = 469827584, cr2 = 1074026496}) at trap_user.c:504

#22 <signal handler called>
#23 0x400e96ac in ?? ()
...
(gdb)
#6 handle_IRQ_event (irq=10, regs=0xaeea4390, action=0xa03cc604) at irq.c:153
153 status |= action->flags;
(gdb) p action
$1 = (struct irqaction *) 0x5a5a5a5a
(gdb)

No.
I just tried twice and got 65 for the first time and 53 for the second.

Hm. May be I'll do it later.

Bye,
Oleg