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 @@
> ¤t->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,
> + ¤t->thread.fault_addr,
> + ¤t->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
|