xfs
[Top] [All Lists]

uml with xfs support

To: linux-xfs@xxxxxxxxxxx
Subject: uml with xfs support
From: thomas graichen <list-linux.sgi.xfs@xxxxxxxxxxx>
Date: Thu, 27 Sep 2001 18:17:11 +0200
Distribution: local
Organization: spoiled dot org
References: <news2mail-20010927064448.1BBEC5FC.NOFFLE@xxxxxxxxxxxxxxxxxxx> <news2mail-20010927123441.64BE1C6A.NOFFLE@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Reply-to: thomas graichen <tgr@xxxxxxxxxxx>
Reply-to: thomas graichen <tgr@xxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.10-xfs (i686))
maybe someone here has an idea (but this is low priority - just
tried to get the xfs tree together with uml - user-mode-linux
(.sourceforge.net) running) - this mail originally went to
the uml-devel mailinglist ...

--- snip ---
maybe some more datails about this: 2.4.10-xfs plus uml-2.4.10-3
and when loading the xfs module i get the following backtrace
running in debug (gdb) mode:

(gdb) bt
#0  panic (fmt=0xa01ba1a0 "Kernel mode fault at addr 0x%lx, ip 0x%lx")
    at panic.c:52
#1  0xa011844b in segv (address=12, ip=2684487610, is_write=0,
is_user=0)
    at trap_kern.c:74
#2  0xa0118ffc in segv_handler (sig=11, sc=0xa46ffb78, usermode=0)
    at trap_user.c:309
#3  0xa0119124 in sig_handler (sig=11, sc=
      {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds =
43, __dsh = 0, edi = 3, esi = 0, ebp = 2758803044, esp = 2758803024, ebx
= 2694052000, edx = 0, ecx = 0, eax = 2692755456, trapno = 14, err = 4,
eip = 2684487610, cs = 35, __csh = 0, eflags = 534, esp_at_signal =
2758803024, ss = 43, __ssh = 0, fpstate = 0xa46ffbd0, oldmask =
268435456, cr2 = 12}) at trap_user.c:354
#4  <signal handler called>
#5  kfree (objp=0xa093f8a0) at slab.c:1430
#6  0xa000c76e in sys_init_module (name_user=0x80d9e30 "xfs", 
    mod_user=0x403bf008) at module.c:574
#7  0xa0117445 in execute_syscall (regs=
        {regs = {135110192, 1077669896, 25, 134519728, 135195456,
2684342216, 4294967258, 43, 43, 0, 0, 128, 134765230, 35, 646,
2684342160, 43}})
    at syscall_kern.c:325
#8  0xa011756b in syscall_handler (unused=0x0) at syscall_user.c:82
(gdb)

maybe this helps - also it might be of interest that the xfs.o module
compiled with debugging is 20+ mb in size :-)

t

thomas graichen <list-linux.uml.devel@xxxxxxxxxxx> wrote:
> i just tried to get uml and the xfs tree from sgi to work together
> but it hangs as soon as xfs filesystem gets loaded (either on boot
> if statically compiled in or loaded as a module) ... is there any
> idea where this might come from befroe looking deeper?
>
> so far the uml patch went cleanly into the xfs tree (top of the
> cvs tree) with only one very easy to fix reject ... to get it to
> compile i used the following small patch:
>
> --- ./arch/um/kernel/ksyms.c.org      Wed Sep 26 14:47:01 2001
> +++ ./arch/um/kernel/ksyms.c  Wed Sep 26 14:47:13 2001
> @@ -21,3 +21,4 @@
>  EXPORT_SYMBOL(__do_strncpy_from_user);
>  EXPORT_SYMBOL(flush_tlb_range);
>  EXPORT_SYMBOL(__do_clear_user);
> +EXPORT_SYMBOL(__do_strnlen_user);
> --- ./fs/xfs/linux/xfs_globals.c.org  Wed Sep 26 17:31:15 2001
> +++ ./fs/xfs/linux/xfs_globals.c      Wed Sep 26 17:31:30 2001
> @@ -45,5 +45,5 @@
>  int             restricted_chown = 0;
>  int          scache_linemask = 0x1f;       /* second level cache line size 
> mask */
>  prid_t               dfltprid;
> -unsigned long   physmem;
> +extern unsigned long   physmem;
>  int          ndquot;
> --- ./include/asm-um/uaccess.h.org    Wed Sep 26 14:45:03 2001
> +++ ./include/asm-um/uaccess.h        Wed Sep 26 14:45:19 2001
> @@ -153,6 +153,14 @@
>                              &current->thread.fault_catcher) : len);
>  }
>  
> +static inline int __clear_user(void *mem, int len)
> +{
> +     return(access_ok(VERIFY_WRITE, mem, len) ? 
> +            __do_clear_user(mem, len, 
> +                            &current->thread.fault_addr,
> +                            &current->thread.fault_catcher) : len);
> +}
> +
>  extern int __do_strnlen_user(const char *str, unsigned long n,
>                            void **fault_addr, void **fault_catcher);
>
> maybe something is wrong with it too (but i don't think so) ...
>
> any ideas? - thanks in advance
>
> t

-- 
thomas graichen <tgr@xxxxxxxxxxx> ... perfection is reached, not
when there is no longer anything to add, but when there is no
longer anything to take away. --- antoine de saint-exupery


<Prev in Thread] Current Thread [Next in Thread>
  • uml with xfs support, thomas graichen <=