From: Chris E. <cem...@ch...> - 2001-05-11 12:52:42
|
I got mmap() working by changing TASK_UNMAPPED_BASE. This is the result: (_images_/root.bin is a Debian/ppc root floppy image). gopher:~/working/umlinux/current/linux$ ./linux ubd0=_images_/root.bin init=/bin/sh tracing thread pid = 29941 Linux version 2.4.4-2um (cme20@gopher) (gcc version 2.95.2 20000220 (Debian GNU/Linux)) #279 Fri May 11 13:32:03 BST 2001 [snip] VFS: Mounted root (ext2 filesystem) readonly. sh: can't access tty; job control turned off # ls dev bin etc floppy initrd instmnt lib mnt proc sbin target tmp usr var release_notes boot_message type.txt # Running without the "init=/bin/sh" causes it to go into a frenzy of activity, opening up several xterms, etc. It then got into a loop somewhere. I should have a revised patch ready soon. Cheers, Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: Chris E. <cem...@ch...> - 2001-08-22 23:08:02
Attachments:
umlppc-20010822.diff
|
Hi, I haven't had a chance to work on UML recently, and Dave Kopper told me it doesn't compile on ppc. He's right; attached is a patch which gets it to compile, and get as far as trying to mount the root filesystem. A few of the changes are things which didn't quite get merged right last time, and a few are new in the last couple of revisions. show_regs ought to move from process_kern.c into a file in sys-$(SUBARCH), I think, but I haven't done that (nor supplied more than a stub implementation) here. Cheers, Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: Jeff D. <jd...@ka...> - 2001-08-23 05:16:42
|
cem...@ch... said: > He's right; attached is a patch which gets it to compile, and get as > far as trying to mount the root filesystem. Thanks, I'll merge this in. > show_regs ought to move from process_kern.c into a file in > sys-$(SUBARCH), I think, but I haven't done that (nor supplied more > than a stub implementation) here. Yup. Sorry about that. One of these days, I'll remember that just because UML builds successfully for me, that doesn't necessarily mean that all is right with the world... Jeff |
From: Chris E. <cem...@ch...> - 2001-08-27 18:14:11
|
On Thursday, 23 Aug 2001, Jeff Dike wrote: > cem...@ch... said: > > He's right; attached is a patch which gets it to compile, and get as > > far as trying to mount the root filesystem. > > Thanks, I'll merge this in. Thanks! Something goes wrong when exec()ing init which I haven't yet managed to track down. Here's a stack trace: #0 0x2000c71c in printk (fmt=0x2014a90c "CME: segv line %d\n") at printk.c:293 #1 0x200cb400 in segv (address=1073820968, ip=1073820968, is_write=1, is_user=1) at trap_kern.c:59 #2 0x200cc7c8 in segv_handler (sig=18, sc=0x5007fd2c, usermode=1) at trap_user.c:305 #3 0x200cc9c0 in sig_handler (sig=11, sc={_unused = {24, 3, 538378240, 0}, signal = 11, handler = 537708824, oldmask = 0, regs = 0x5007fd4c}) at trap_user.c:350 #4 <signal handler called> #5 0x40013528 in ?? () #6 0x200c9c30 in syscall_handler (unused=0x0) at syscall_user.c:67 #7 0xfbffffff in ?? () That address at frame #5 is the faulting address, and isn't mapped; so it's a bit odd that is_write=1. Within segv, the "is_write && !(vma->vm_flags & VM_WRITE)" test is setting ok=0. Any ideas? Has anything obvious changed in the last few releases that I could look more closely at? I skimmed through a diff of arch/um/kernel and didn't notice anything particularly odd. Cheers, Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: Jeff D. <jd...@ka...> - 2001-08-27 19:04:17
|
cem...@ch... said: > That address at frame #5 is the faulting address, and isn't mapped; so > it's a bit odd that is_write=1. Within segv, the "is_write && !(vma-> > vm_flags & VM_WRITE)" test is setting ok=0. Well, if that's code, then nothing should be attempting to modify it. If !(vma->vm_flags & VM_WRITE) then that's a readonly area of virtual memory and UML is correct to segfault writes to it. Are you sure your SC_FAULT_WRITE is correct? It seems to me that it can't be, because if the fault is the result of trying to execute whatever code is there, that's not an attempt to write. That's a read. Jeff |
From: Chris E. <cem...@ch...> - 2001-08-27 21:28:33
Attachments:
scwrite.diff
|
On Monday, 27 Aug 2001, Jeff Dike wrote: > Are you sure your SC_FAULT_WRITE is correct? It seems to me that it > can't be, because if the fault is the result of trying to execute > whatever code is there, that's not an attempt to write. That's a > read. Good guess. It was only correct for data faults. This is another of those "should never have worked before" bugs. I've attached a patch to sysdep/sigcontext.h which gets things working again (except for that annoying signal problem). Cheers, Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: Chris E. <cem...@ch...> - 2001-05-11 13:04:59
|
On Friday, 11 May 2001, Chris Emerson wrote: > I should have a revised patch ready soon. http://www.tartarus.org/~chris/user-mode-linux/umlppc-20010511.diff-3.gz Cheers, Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |