Re: 2.6.3-rc2 failure - was: Re: [uml-devel] Kernel idles in loop after loading IPv4

["roland" <for_spam@gmx.de>]

hi !

> You should try using, as skas patch,
> http://www.user-mode-linux.org/~blaisorblade/patches/2.6.2-v1-host-skas2/00-2.6.2-v1-host-SKAS2.patch.bz2,
> which comes from the latest one from Ingo Molnar. I have not been very

the bug ("hang after NET: Registered protocol family 2":) doesn`t seem to have a relation to SKAS, because it also happens in TT
mode.
when i run the binary with "./linux mode=tt" the hang occurs, too.
furthermore - it doesn`t seem to be a compiler issue, because i compiled 2.6.3-rc2 on 2 completely different systems (suse9 and
rh7.2).
i also read about guesses, that this could have to do with "newer" hosts running NPTL.
could someone explain? i thought uml is a static binary, so how can this have a relation to a thread >LIBRARY<??
somewhere i read about "kernel threads". is ntpl related to the kernel itself? (sorry if this sounds stupid - but i remember
switching between different thread-libraries on solaris via envvars. is this just the same with ntpl?)

if someone wants to test - the rh7.2 compiled (and for me also failing) binary is at: http://www.my-vserver.de/uml-2.6.3-rc2.gz

update:
after adding a lot if printk`s to the uml-patched 2.6.3-rc2 source, i found the following(maybe interesting):

in ./kernel/sched.c
in function wait_for_completion(struct completion *x)
the call to "schedule()" never returns and this seems to be the reason for the hanging ipv4 initialisation.
i have no clue about kernel internals and i think it`s nonsense, if i dig further into this....

but as i already said:
2.6.0-test9 with uml-patch-2.6.0-test9-1  _WORKS_ (at least for me)
2.6.0 with uml-patch-2.6.0-1 and following kernel/uml-patch versions seem to have the ipv4 hang-at-init bug.

so maybe the bug has been introduced with uml-patch-2.6.0-1 !?
regards
roland



----- Original Message ----- 
From: "BlaisorBlade" <blaisorblade_spam@yahoo.it>
To: <user-mode-linux-devel@lists.sourceforge.net>
Cc: "roland" <for_spam@gmx.de>
Sent: Sunday, February 15, 2004 8:45 PM
Subject: Re: 2.6.3-rc2 failure - was: Re: [uml-devel] Kernel idles in loop after loading IPv4


> Alle 18:47, domenica 15 febbraio 2004, roland ha scritto:
> > hi !
> > concerning the uml "hang" after  "NET: Registered protocol family 2":
> >
> > after some investigation i found, that the problem seems to have been
> > introduced with uml-patch-2.6.0-1 (at
> > http://prdownloads.sourceforge.net/user-mode-linux/uml-patch-2.6.0-1.bz2)
> >
> > uml-patch-2.6.0-test9-1 (at
> > http://prdownloads.sourceforge.net/user-mode-linux/uml-patch-2.6.0-test9-1.
> >bz2?download), in conjunction with minor compile-fix
> > http://people.0x63.nu/~andersg/uml-minor-fixes.diff works nicely for me.
>
> On what guest kernel do you apply the patch? uml-patch-2.6.0-1 gave strange
> problems with 2.6.1 vanilla kernel.
>
> > seems there has been a major change (lots of merges?) in uml-patch-2.6.0-1
> > because it`s much more bigger (around 2x) than uml-patch-2.6.0-test9-1
> >
> > btw:
> > i use Bryan O'Sullivan`s skas patch on my host kernel. see:
> > http://sourceforge.net/mailarchive/message.php?msg_id=5840691 since this
> > patch isn`t based on steven james patch (which stephen williams patch is
> > based of), it isn`t a skas issue, but a compiler or host-fs issue !? i`m on
> > suse9 host.
> You should try using, as skas patch,
> http://www.user-mode-linux.org/~blaisorblade/patches/2.6.2-v1-host-skas2/00-2.6.2-v1-host-SKAS2.patch.bz2,
> which comes from the latest one from Ingo Molnar. I have not been very
> careful, but when I gave a look to the Bryan's patch, it seemed likely to
> have similar problems as the other one. At least, both do only this change to
> write_ldt (i.e. don't use current->mm but let the caller specify which mm
> use):
>
> -static int write_ldt(void __user * ptr, unsigned long bytecount, int oldmode)
> +static int write_ldt(struct task_struct *task, void __user * ptr, unsigned
> long bytecount, int oldmode)
>  {
> -       struct mm_struct * mm = current->mm;
> +       struct mm_struct * mm = task->mm;
>         __u32 entry_1, entry_2, *lp;
>         int error;
>         struct user_desc ldt_info;
>
> While Ingo Molnar's one does also this:
>
> @@ -195,7 +197,7 @@
>
>         down(&mm->context.sem);
>         if (ldt_info.entry_number >= mm->context.size) {
> -               error = alloc_ldt(&current->mm->context,
> ldt_info.entry_number+1, 1);
> +               error = alloc_ldt(&mm->context, ldt_info.entry_number+1, 1);
>                 if (error < 0)
>                         goto out_unlock;
>         }
>
> This second change is *needed*, whichever patch do you use: without it part of
> write_ldt uses current->mm instead of mm. That also means that alloc_ldt is
> not called on mm->context, so that probably it remains null and so we get
> Oopses.
>
> Bye
> -- 
> Paolo Giarrusso, aka Blaisorblade
> Linux registered user n. 292729
>



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel