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
> The build works again.
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!
On Mon, Sep 30, 2002 at 09:26:21PM +0100, James Stevenson wrote:
> > The build works again.
> 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.
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 =====
--- 1.5/arch/um/Makefile Tue Oct 1 10:42:18 2002
+++ edited/arch/um/Makefile Tue Oct 1 11:20:00 2002
@@ -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 =====
--- 1.5/arch/um/drivers/ubd_kern.c Tue Oct 1 10:56:09 2002
+++ edited/arch/um/drivers/ubd_kern.c Tue Oct 1 11:33:18 2002
@@ -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)
[email protected] said:
> Here's what I need to apply before I can build bk-current with UML
> support.
Applied, thanks.
> And then kernel mode fault at 0x5a5a5a5e
Can you get a stack trace from that crash?
> Just before the crash it warns about winch_interrupt : read failed,
> errno = 9 fd 57 is losing SIGWINCH support
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.
> @@ -863,6 +863,7 @@
> return(-EFAULT);
> return(0);
> }
> + return -ENOTTY;
> }
I did a check of some of the other block drivers, and they mostly seem to
do -EINVAL rather than -ENOTTY. There was an oddball -ENOSYS, but I guess
I'll stick with -EINVAL.
Jeff
Hello!
On Tue, Oct 01, 2002 at 01:19:36PM -0500, Jeff Dike wrote:
> > @@ -863,6 +863,7 @@
> > return(-EFAULT);
> > return(0);
> > }
> > + return -ENOTTY;
> > }
> I did a check of some of the other block drivers, and they mostly seem to
> do -EINVAL rather than -ENOTTY. There was an oddball -ENOSYS, but I guess
> I'll stick with -EINVAL.
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!
On Tue, Oct 01, 2002 at 01:19:36PM -0500, Jeff Dike wrote:
> > And then kernel mode fault at 0x5a5a5a5e
> Can you get a stack trace from that crash?
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)
> > Just before the crash it warns about winch_interrupt : read failed,
> > errno = 9 fd 57 is losing SIGWINCH support
> This looks different. Is it consistently the same file descriptor? If so,
No.
I just tried twice and got 65 for the first time and 53 for the second.
> put a breakpoint on close and see who's closing it who isn't supposed to.
Hm. May be I'll do it later.
Bye,
Oleg