On Fri, 2005-11-04 at 04:19 +0100, Blaisorblade wrote: > On Thursday 03 November 2005 08:19, Hayim Shaul wrote: > > I saw the problem recurring. > > Wait a moment, just noticed after all the rest - you are another user (we > discussed the rmmod crash, I've finished and maybe posted a patch for it) and > getting the same problem? You talk like being the same... > > Anyway, I'm answering assuming this is the same problem. > > Surprisingly when I changed the location of the linux exceutable it ran as > > expected. > > > > under /bin/linux it froze, but under /usr/bin/linux it ran OK. > > > > Also when I tried to `strace -f /usr/bin/linux` it froze as well. > I don't think "strace -f" is supposed to let UML run - both strace and UML > would try to call ptrace() on UML childs, and if GDB succeeds UML won't work > anymore. > > Try "strace -f gdb", give "run" at the gdb prompt and see it going nuts > (never > tested)... > > > I checked the starce output. > > > From what I gathered, I see that the process is spawning a child. As the > > child exists SIGCHLD is called. It seems that the last lines of the > > strace are printed from the SIGCHLD handler. So maybe something is > > wrong in the signal handle. > > I'd guess some sort of race condition - likely, execution on different paths > (or on different partitions) has different speeds. > > However, the lines you posted are uninformative as they come likely from some > interrupt handler (possibly the timer handler?). > > So, the last _interesting_ lines of strace output could be useful; don't ask > me a definition, I can only say "not so boring". Or from the SIGCHLD to when > it starts looping. > > > Perhaps it tries to run/open something and due to the different path it > > runs/opens the worng thing? > > I would be surprised, I've run it from any path. And you'd see an "open" or > "access" or such failing, which you don't. > > > I tried to look at the code but lost my way. > > > As a workaroud try placing linux in a different location > > (/usr/bin/linux?). > Just until we debug the problem. > > Any help/guide to fix the problem? > Suggestions (sorry I didn't mention these first): > > *) pass mode=tt. It's slower but more tested. It should be a workaround for > you (make sure you enable TT mode first). > > *) Try using a different UML version - there is my -bs tree, on my homepage > (see signature), which is more up-to-date than -stable kernels (applies on > them though). It has fixes for -skas0 mode (it's a recent introduction so > still to be perfected a bit). > > *) Try with disabling/enabling on the host: > > exec_shield > /proc/sys/kernel/randomize_va_space > > and see if there's any difference.
Hayim is referring to the same problem I was trying to solve in this thread. Indeed changing the path of executing the uml is a workaround the problem. sorry if there was some kind of a misunderstanding. Thanks all. ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
