Re: Announcing the release of BLCR 0.6.0_beta1

From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Wed Jul 25 2007 - 07:35:41 PDT

  • Next message: Neal Becker: "Re: Announcing the release of BLCR 0.6.0_beta1"
    Cedric Le Goater wrote:
    > Paul H. Hargrove wrote:
    >   
    >> I am pleased to announce the release of the first Beta version of BLCR
    >> 0.6.0, now available at
    >>  http://mantis.lbl.gov/blcr-dist/blcr-0.6.0_b1.tar.gz  for a source tarball
    >> or
    >>  http://mantis.lbl.gov/blcr-dist/blcr-0.6.0_b1-1.src.rpm for a source RPM
    >>     
    >
    > You'll need the following patch to compile on a fc7 and on any 2.6.21+ vanilla
    > kernels.
    >   
    
    Thanks for the patch, Cedric.  I'll make sure it gets into the next 
    beta.  I missed that myself because the 2.6.21 and 2.6.22 kernel sources 
    I compile against are not configured for hugetlbfs support.
    
    > I'm still fighting with the insmod which is telling me :
    >
    > 	Running kernel does not match the System.map used to build blcr.o
    >   
    
    Hmm, not 100% sure on that one.  There is code in 
    cr_module/cr_module.c:cr_init_module() that compares the addresses of 
    two symbols as probed from the System.map at configure time against 
    their addresses as resolved by the kernel's module linker/loader.  BLCR 
    refuses to load the module if these don't match, since it will be making 
    function calls to other addresses obtained in the same way (and we 
    really don't want to invoke code at random addresses in kernel context).
    
    So, my best guess is that message means what it says, perhaps due to 
    BLCR's autoconf machinery locating the wrong System.map file.  You 
    should try comparing the output of
      $ grep register_chrdev /proc/kyms
    against that of
      $ grep register_chrdev [MAPFILE]
    where [MAPFILE] is the System.map file being used by BLCR (try "grep 
    LINUX_SYMTAB_FILE Makefile" in your BLCR build directory).  If they 
    match, then it is possible that something is happening with respect to 
    kernel linking/relocation that BLCR is not prepared to deal with.  If 
    they don't match then it might still be a relocation issue, but more 
    likely it means BLCR found the wrong System.map file.  If that is the 
    case, try passing --with-system-map=[WHATEVER] when configuring BLCR.  
    Let us know what you find.
    
    > what about glibc 2.6 ?  
    >   
    
    What about it?  I don't have any systems running glibc 2.6.  If you have 
    specific problems (once past the System.map problem), please let us know 
    and we'll see what we can do to sort them out.
    
    -Paul
    
    > Thanks,
    >
    > C.
    >   
    [patch removed]
    
    -- 
    Paul H. Hargrove                          PHHargrove_at_lbl_dot_gov
    Future Technologies Group                 
    HPC Research Department                   Tel: +1-510-495-2352
    Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900
    

  • Next message: Neal Becker: "Re: Announcing the release of BLCR 0.6.0_beta1"