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

[BlaisorBlade <blaisorblade_spam@yahoo.it>]

[-- Attachment #1: Type: text/plain, Size: 2264 bytes --]

Alle 02:52, mercoledì 18 febbraio 2004, roland ha scritto:
> hi !

For Jeff: see at the end why I cc: to you.

>
> 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

Yes but when it's compiled it's linked against host's libs (mainly glibc and 
libpthreads). However, IIRC, the problems with NPTL on the host have been 
fixed time ago, and with NPTL in the guest have currently a temporary fix.

>, 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?)

> 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 !?

The message about "diagnosed and repeatable kernel panic" is IMHO related to 
this: the sigsetjmp change was actually in 2.6.0. And this broke schedule: on 
my system it happens to broke in one point, on your in another point.

If I guessed right, the attached patch will solve everything.

Jeff, do you think this makes sense?
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729

[-- Attachment #2: Panic_schedule_fix.patch --]
[-- Type: text/x-diff, Size: 328 bytes --]

--- 1.9/arch/um/kernel/skas/process_kern.c	Thu Jan  8 07:43:01 2004
+++ edited/arch/um/kernel/skas/process_kern.c	Sun Feb 15 10:42:31 2004
@@ -76,6 +76,7 @@
 
 void new_thread_proc(void *stack, void (*handler)(int sig))
 {
+       local_irq_disable();
 	init_new_thread_stack(stack, handler);
 	os_usr1_process(os_getpid());
 }