Re: [patch 1/1] openmosix/openmosix-fix-proc_pid_set_where.patch

Matt Dew wrote:
> I've put the patches together and tested them with a script that applies
> them (sans-quilt).
>
> There are a few changes to the patches:
> openmosix-kcomd-daemon-code_13.patch
>   -- duplicate functions between kcom.c and kcomd.c
>   

Well, it seems to me you were not using the last version I send, I fixed 
that already
> openmosix-kcomd-task-to-kcomd_07.patch
>    -- om.where memory allocation was left out
>   

I submitted a recent patch to fix that out ...  and moreover the printk 
was also removed in another patch (a remove-useless-debug 
something.patch) I the latest patch, I also added a test to check the 
allocation didn't fail, (I think this is cleaner)
> openmosix-remove-useless-debug_17.patch
>    -- extra printk that caused 'chunk failed'
>   
I found in this version of the patch you removed two lines more in 
kcom.c, I remove them also in my patches,
it seems that you don't delete anymore the two lines of right after the 
schedule (migrecv.c):

     schedule();
-    if (task_test_dflags(p, DREMOTE))
-    printk(KERN_DEBUG "[OM] starting remote process(%d)\n", p->pid);
-    else
-    printk(KERN_DEBUG "[OM] starting local process(%d)\n", p->pid);

I my original patch, I delete this, considering it as a debug output, 
unneeded in the source, is that to which you refer by the 'extra printk 
that caused "chunk failed"' ?

finally, there is this printk that is not anymore deleted in task.c 155

-    printk(KERN_DEBUG "leaving FUNCTION: task_local_bring\n");

looking twice at the change, I don't exactly understand why any of these 
change(/nonchange) would cause a 'chunk failed' ...




again, you did not use the lattest version of the initial patches ...
> openmosix-pre-kickstart_22.patch
>    -- extra lines that caused 'chunk failed' error
>   
I could not find the code you changed, actually, but I refreshed a patch 
so that the flush_thread() get  called right before the 
init_arch_kickstart() call (might be the problem)

Since I feel like we are working on two completely different version, I 
resend a version (a .tar.gz) containing all patches (including a git 
patch from the last tab's git) an a similar script to yours that apply 
them all (but this script is using quilt ... so you 'll have to install 
it, under debian : apt-get install quilt)

I refreshed all the patches, just to make sure they will apply cleanly. 
and included the last of your patch in the distribution.

(by default, the openmosix-git patch should be already applied to work 
... but you can apply it manually, it's located in 
patches/openmosix/openmosix-git.patch)

So to install it, basically, uncompress a clean linux-2.6.17 vanilla 
kernel, then, apply the last git modifications,  (or apply the patch 
patches/openmosix/openmosix-git.patch which should give identical 
results). then apply all patches, (you can both use quilt directly, or 
use the script I included).

Matt, can you check with those very patches, to make sure we I am not 
looking for bugs you already found (and corrected) in a part of the 
source I missed.



> original patches are renamed .old.
>
>
> http://osource.org/openmosix/patches/series1/om-series1.tar.bz2
>
> Ian,
> A git diff is included.
>
> On Wed, 2006-09-27 at 20:57 +0000, "Matt Dew"  wrote:
>   
>> Florian,
>>  That's actually what I'm working on right now.  I've found a few
>>     
> small
>   
>> things after that.
>>
>> I'm hoping to put this series of patches up on my site tonight or
>> tomorrow with a little shell script to correctly apply them all in
>> order.
>>
>> If anyone updates the git, could you post a msg to the list just to
>>     
> let
>   
>> everyone know.  
>>
>> thanks,
>> Matt
>>
>>
>> On Wed, 2006-09-27 at 19:54 +0000, Florian Delizy  wrote:
>>     
>>> This patch fix the process migration. It seems some lines got lost
>>>       
>> from 
>>     
>>> Matt's initial patch ... and the om.whereto sockaddr structure
>>>       
> pointer
>   
>>> was left uninitialized ...
>>>
>>> This patch fixes this. There is still a bug that makes the deputy
>>>       
>> kernel 
>>     
>>> crash just after sending the process to the remote. I am
>>>       
> investigating
>   
>>> it at the moment.
>>>
>>> Matt, please can you have a look and check that there are no silly 
>>> omission from your initial patch to mine ? And can you actually try
>>>       
>> out 
>>     
>>> thoses patches over a fresh git to check for the issue I get :
>>>
>>> It seems that the processor jumps at the address 0x0 just after
>>>       
>> sending 
>>     
>>> the process. The remote process runs with no problem (I would say I 
>>> guess just as long as it does not get any signal nor uses syscall
>>>       
> ...)
>   
>>> but the kernel of the deputy machine crashes badly ... I would
>>>       
> really 
>   
>>> appreciate some help on that, guys ...
>>>
>>> Florian
>>>       
>>
>>     
> -------------------------------------------------------------------------
>   
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to
>>     
> share your
>   
>> opinions on IT & business topics through brief surveys -- and earn
>>     
> cash
>   
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>   
>> _______________________________________________
>> openMosix-devel mailing list
>> openMosix-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> https://lists.sourceforge.net/lists/listinfo/openmosix-devel
>>     
>
>
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
openMosix-devel mailing list
openMosix-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/openmosix-devel