Re: [Pacemaker] [Openais] Linux HA on debian sparc

2013-06-24 Thread Simon Platten 

  
  
Hello, I read a post on corosync 1.3.1:

http://oss.clusterlabs.org/pipermail/pacemaker/2011-May/010517.html

"We have recently
with corosync 1.3.1 gone through an alignment fixing process for ARM
arches"

Is this avaiable as a download, as I have downloaded corosync and am
trying to build it on an ARM processor but also getting lots of
warnings:

"warning: cast increases required alignment of target type
[-Wcast-align]"

Thank you,

-- 
   Kind Regards,
Simon A. Platten
  
   
   About Me... 

  

___
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [Pacemaker] [Openais] Linux HA on debian sparc

2011-06-07 Thread Steven Dake 
On 06/07/2011 04:44 AM, william felipe_welter wrote:
> More two questions.. The patch for mmap calls will be on the mainly
> development for all archs ?
> Any problems if i send this patch's for Debian project ?
> 

These patches will go into the maintenance branches

You can send them to whoever you like ;)

Regards
-steve

> 2011/6/3 Steven Dake :
>> On 06/02/2011 08:16 PM, william felipe_welter wrote:
>>> Well,
>>>
>>> Now with this patch, the pacemakerd process starts and up his other
>>> process ( crmd, lrmd, pengine) but after the process pacemakerd do
>>> a fork, the forked  process pacemakerd dies due to "signal 10, Bus
>>> error".. And  on the log, the process of pacemark ( crmd, lrmd,
>>> pengine) cant connect to open ais plugin (possible because the
>>> "death" of the pacemakerd process).
>>> But this time when the forked pacemakerd dies, he generates a coredump.
>>>
>>> gdb  -c "/usr/var/lib/heartbeat/cores/root/ pacemakerd 7986"  -se
>>> /usr/sbin/pacemakerd :
>>> GNU gdb (GDB) 7.0.1-debian
>>> Copyright (C) 2009 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later 
>>> 
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "sparc-linux-gnu".
>>> For bug reporting instructions, please see:
>>> ...
>>> Reading symbols from /usr/sbin/pacemakerd...done.
>>> Reading symbols from /usr/lib64/libuuid.so.1...(no debugging symbols
>>> found)...done.
>>> Loaded symbols for /usr/lib64/libuuid.so.1
>>> Reading symbols from /usr/lib/libcoroipcc.so.4...done.
>>> Loaded symbols for /usr/lib/libcoroipcc.so.4
>>> Reading symbols from /usr/lib/libcpg.so.4...done.
>>> Loaded symbols for /usr/lib/libcpg.so.4
>>> Reading symbols from /usr/lib/libquorum.so.4...done.
>>> Loaded symbols for /usr/lib/libquorum.so.4
>>> Reading symbols from /usr/lib64/libcrmcommon.so.2...done.
>>> Loaded symbols for /usr/lib64/libcrmcommon.so.2
>>> Reading symbols from /usr/lib/libcfg.so.4...done.
>>> Loaded symbols for /usr/lib/libcfg.so.4
>>> Reading symbols from /usr/lib/libconfdb.so.4...done.
>>> Loaded symbols for /usr/lib/libconfdb.so.4
>>> Reading symbols from /usr/lib64/libplumb.so.2...done.
>>> Loaded symbols for /usr/lib64/libplumb.so.2
>>> Reading symbols from /usr/lib64/libpils.so.2...done.
>>> Loaded symbols for /usr/lib64/libpils.so.2
>>> Reading symbols from /lib/libbz2.so.1.0...(no debugging symbols 
>>> found)...done.
>>> Loaded symbols for /lib/libbz2.so.1.0
>>> Reading symbols from /usr/lib/libxslt.so.1...(no debugging symbols
>>> found)...done.
>>> Loaded symbols for /usr/lib/libxslt.so.1
>>> Reading symbols from /usr/lib/libxml2.so.2...(no debugging symbols
>>> found)...done.
>>> Loaded symbols for /usr/lib/libxml2.so.2
>>> Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
>>> Loaded symbols for /lib/libc.so.6
>>> Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
>>> Loaded symbols for /lib/librt.so.1
>>> Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
>>> Loaded symbols for /lib/libdl.so.2
>>> Reading symbols from /lib/libglib-2.0.so.0...(no debugging symbols
>>> found)...done.
>>> Loaded symbols for /lib/libglib-2.0.so.0
>>> Reading symbols from /usr/lib/libltdl.so.7...(no debugging symbols
>>> found)...done.
>>> Loaded symbols for /usr/lib/libltdl.so.7
>>> Reading symbols from /lib/ld-linux.so.2...(no debugging symbols 
>>> found)...done.
>>> Loaded symbols for /lib/ld-linux.so.2
>>> Reading symbols from /lib/libpthread.so.0...(no debugging symbols 
>>> found)...done.
>>> Loaded symbols for /lib/libpthread.so.0
>>> Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
>>> Loaded symbols for /lib/libm.so.6
>>> Reading symbols from /usr/lib/libz.so.1...(no debugging symbols 
>>> found)...done.
>>> Loaded symbols for /usr/lib/libz.so.1
>>> Reading symbols from /lib/libpcre.so.3...(no debugging symbols 
>>> found)...done.
>>> Loaded symbols for /lib/libpcre.so.3
>>> Reading symbols from /lib/libnss_compat.so.2...(no debugging symbols
>>> found)...done.
>>> Loaded symbols for /lib/libnss_compat.so.2
>>> Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
>>> Loaded symbols for /lib/libnsl.so.1
>>> Reading symbols from /lib/libnss_nis.so.2...(no debugging symbols 
>>> found)...done.
>>> Loaded symbols for /lib/libnss_nis.so.2
>>> Reading symbols from /lib/libnss_files.so.2...(no debugging symbols
>>> found)...done.
>>> Loaded symbols for /lib/libnss_files.so.2
>>> Core was generated by `pacemakerd'.
>>> Program terminated with signal 10, Bus error.
>>> #0  cpg_dispatch (handle=17861288972693536769, dispatch_types=7986) at 
>>> cpg.c:339
>>> 339   switch (dispatch_data->id) {
>>> (gdb) bt
>>> #0  cpg_dispatch (handl

Re: [Pacemaker] [Openais] Linux HA on debian sparc

2011-06-07 Thread william felipe_welter 
More two questions.. The patch for mmap calls will be on the mainly
development for all archs ?
Any problems if i send this patch's for Debian project ?

2011/6/3 Steven Dake :
> On 06/02/2011 08:16 PM, william felipe_welter wrote:
>> Well,
>>
>> Now with this patch, the pacemakerd process starts and up his other
>> process ( crmd, lrmd, pengine) but after the process pacemakerd do
>> a fork, the forked  process pacemakerd dies due to "signal 10, Bus
>> error".. And  on the log, the process of pacemark ( crmd, lrmd,
>> pengine) cant connect to open ais plugin (possible because the
>> "death" of the pacemakerd process).
>> But this time when the forked pacemakerd dies, he generates a coredump.
>>
>> gdb  -c "/usr/var/lib/heartbeat/cores/root/ pacemakerd 7986"  -se
>> /usr/sbin/pacemakerd :
>> GNU gdb (GDB) 7.0.1-debian
>> Copyright (C) 2009 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later 
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "sparc-linux-gnu".
>> For bug reporting instructions, please see:
>> ...
>> Reading symbols from /usr/sbin/pacemakerd...done.
>> Reading symbols from /usr/lib64/libuuid.so.1...(no debugging symbols
>> found)...done.
>> Loaded symbols for /usr/lib64/libuuid.so.1
>> Reading symbols from /usr/lib/libcoroipcc.so.4...done.
>> Loaded symbols for /usr/lib/libcoroipcc.so.4
>> Reading symbols from /usr/lib/libcpg.so.4...done.
>> Loaded symbols for /usr/lib/libcpg.so.4
>> Reading symbols from /usr/lib/libquorum.so.4...done.
>> Loaded symbols for /usr/lib/libquorum.so.4
>> Reading symbols from /usr/lib64/libcrmcommon.so.2...done.
>> Loaded symbols for /usr/lib64/libcrmcommon.so.2
>> Reading symbols from /usr/lib/libcfg.so.4...done.
>> Loaded symbols for /usr/lib/libcfg.so.4
>> Reading symbols from /usr/lib/libconfdb.so.4...done.
>> Loaded symbols for /usr/lib/libconfdb.so.4
>> Reading symbols from /usr/lib64/libplumb.so.2...done.
>> Loaded symbols for /usr/lib64/libplumb.so.2
>> Reading symbols from /usr/lib64/libpils.so.2...done.
>> Loaded symbols for /usr/lib64/libpils.so.2
>> Reading symbols from /lib/libbz2.so.1.0...(no debugging symbols 
>> found)...done.
>> Loaded symbols for /lib/libbz2.so.1.0
>> Reading symbols from /usr/lib/libxslt.so.1...(no debugging symbols
>> found)...done.
>> Loaded symbols for /usr/lib/libxslt.so.1
>> Reading symbols from /usr/lib/libxml2.so.2...(no debugging symbols
>> found)...done.
>> Loaded symbols for /usr/lib/libxml2.so.2
>> Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
>> Loaded symbols for /lib/libc.so.6
>> Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
>> Loaded symbols for /lib/librt.so.1
>> Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
>> Loaded symbols for /lib/libdl.so.2
>> Reading symbols from /lib/libglib-2.0.so.0...(no debugging symbols
>> found)...done.
>> Loaded symbols for /lib/libglib-2.0.so.0
>> Reading symbols from /usr/lib/libltdl.so.7...(no debugging symbols
>> found)...done.
>> Loaded symbols for /usr/lib/libltdl.so.7
>> Reading symbols from /lib/ld-linux.so.2...(no debugging symbols 
>> found)...done.
>> Loaded symbols for /lib/ld-linux.so.2
>> Reading symbols from /lib/libpthread.so.0...(no debugging symbols 
>> found)...done.
>> Loaded symbols for /lib/libpthread.so.0
>> Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
>> Loaded symbols for /lib/libm.so.6
>> Reading symbols from /usr/lib/libz.so.1...(no debugging symbols 
>> found)...done.
>> Loaded symbols for /usr/lib/libz.so.1
>> Reading symbols from /lib/libpcre.so.3...(no debugging symbols found)...done.
>> Loaded symbols for /lib/libpcre.so.3
>> Reading symbols from /lib/libnss_compat.so.2...(no debugging symbols
>> found)...done.
>> Loaded symbols for /lib/libnss_compat.so.2
>> Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
>> Loaded symbols for /lib/libnsl.so.1
>> Reading symbols from /lib/libnss_nis.so.2...(no debugging symbols 
>> found)...done.
>> Loaded symbols for /lib/libnss_nis.so.2
>> Reading symbols from /lib/libnss_files.so.2...(no debugging symbols
>> found)...done.
>> Loaded symbols for /lib/libnss_files.so.2
>> Core was generated by `pacemakerd'.
>> Program terminated with signal 10, Bus error.
>> #0  cpg_dispatch (handle=17861288972693536769, dispatch_types=7986) at 
>> cpg.c:339
>> 339                   switch (dispatch_data->id) {
>> (gdb) bt
>> #0  cpg_dispatch (handle=17861288972693536769, dispatch_types=7986) at 
>> cpg.c:339
>> #1  0xf6f100f0 in ?? ()
>> #2  0xf6f100f4 in ?? ()
>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>>
>>
>>
>> I take a look at the cpg.c and see that the dispatch_data was aquired
>>

Re: [Pacemaker] [Openais] Linux HA on debian sparc

2011-06-03 Thread Steven Dake 
On 06/02/2011 08:16 PM, william felipe_welter wrote:
> Well,
> 
> Now with this patch, the pacemakerd process starts and up his other
> process ( crmd, lrmd, pengine) but after the process pacemakerd do
> a fork, the forked  process pacemakerd dies due to "signal 10, Bus
> error".. And  on the log, the process of pacemark ( crmd, lrmd,
> pengine) cant connect to open ais plugin (possible because the
> "death" of the pacemakerd process).
> But this time when the forked pacemakerd dies, he generates a coredump.
> 
> gdb  -c "/usr/var/lib/heartbeat/cores/root/ pacemakerd 7986"  -se
> /usr/sbin/pacemakerd :
> GNU gdb (GDB) 7.0.1-debian
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "sparc-linux-gnu".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /usr/sbin/pacemakerd...done.
> Reading symbols from /usr/lib64/libuuid.so.1...(no debugging symbols
> found)...done.
> Loaded symbols for /usr/lib64/libuuid.so.1
> Reading symbols from /usr/lib/libcoroipcc.so.4...done.
> Loaded symbols for /usr/lib/libcoroipcc.so.4
> Reading symbols from /usr/lib/libcpg.so.4...done.
> Loaded symbols for /usr/lib/libcpg.so.4
> Reading symbols from /usr/lib/libquorum.so.4...done.
> Loaded symbols for /usr/lib/libquorum.so.4
> Reading symbols from /usr/lib64/libcrmcommon.so.2...done.
> Loaded symbols for /usr/lib64/libcrmcommon.so.2
> Reading symbols from /usr/lib/libcfg.so.4...done.
> Loaded symbols for /usr/lib/libcfg.so.4
> Reading symbols from /usr/lib/libconfdb.so.4...done.
> Loaded symbols for /usr/lib/libconfdb.so.4
> Reading symbols from /usr/lib64/libplumb.so.2...done.
> Loaded symbols for /usr/lib64/libplumb.so.2
> Reading symbols from /usr/lib64/libpils.so.2...done.
> Loaded symbols for /usr/lib64/libpils.so.2
> Reading symbols from /lib/libbz2.so.1.0...(no debugging symbols found)...done.
> Loaded symbols for /lib/libbz2.so.1.0
> Reading symbols from /usr/lib/libxslt.so.1...(no debugging symbols
> found)...done.
> Loaded symbols for /usr/lib/libxslt.so.1
> Reading symbols from /usr/lib/libxml2.so.2...(no debugging symbols
> found)...done.
> Loaded symbols for /usr/lib/libxml2.so.2
> Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
> Loaded symbols for /lib/libc.so.6
> Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
> Loaded symbols for /lib/librt.so.1
> Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
> Loaded symbols for /lib/libdl.so.2
> Reading symbols from /lib/libglib-2.0.so.0...(no debugging symbols
> found)...done.
> Loaded symbols for /lib/libglib-2.0.so.0
> Reading symbols from /usr/lib/libltdl.so.7...(no debugging symbols
> found)...done.
> Loaded symbols for /usr/lib/libltdl.so.7
> Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
> Loaded symbols for /lib/ld-linux.so.2
> Reading symbols from /lib/libpthread.so.0...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib/libpthread.so.0
> Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
> Loaded symbols for /lib/libm.so.6
> Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
> Loaded symbols for /usr/lib/libz.so.1
> Reading symbols from /lib/libpcre.so.3...(no debugging symbols found)...done.
> Loaded symbols for /lib/libpcre.so.3
> Reading symbols from /lib/libnss_compat.so.2...(no debugging symbols
> found)...done.
> Loaded symbols for /lib/libnss_compat.so.2
> Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
> Loaded symbols for /lib/libnsl.so.1
> Reading symbols from /lib/libnss_nis.so.2...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib/libnss_nis.so.2
> Reading symbols from /lib/libnss_files.so.2...(no debugging symbols
> found)...done.
> Loaded symbols for /lib/libnss_files.so.2
> Core was generated by `pacemakerd'.
> Program terminated with signal 10, Bus error.
> #0  cpg_dispatch (handle=17861288972693536769, dispatch_types=7986) at 
> cpg.c:339
> 339   switch (dispatch_data->id) {
> (gdb) bt
> #0  cpg_dispatch (handle=17861288972693536769, dispatch_types=7986) at 
> cpg.c:339
> #1  0xf6f100f0 in ?? ()
> #2  0xf6f100f4 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> 
> 
> I take a look at the cpg.c and see that the dispatch_data was aquired
> by coroipcc_dispatch_get (that was defined on lib/coroipcc.c)
> function:
> 
>do {
> error = coroipcc_dispatch_get (
> cpg_inst->handle,
> (void **)&dispatch_data,
> timeout);
> 
> 
> 

Try

Re: [Pacemaker] [Openais] Linux HA on debian sparc

2011-06-02 Thread william felipe_welter 
Well,

Now with this patch, the pacemakerd process starts and up his other
process ( crmd, lrmd, pengine) but after the process pacemakerd do
a fork, the forked  process pacemakerd dies due to "signal 10, Bus
error".. And  on the log, the process of pacemark ( crmd, lrmd,
pengine) cant connect to open ais plugin (possible because the
"death" of the pacemakerd process).
But this time when the forked pacemakerd dies, he generates a coredump.

gdb  -c "/usr/var/lib/heartbeat/cores/root/ pacemakerd 7986"  -se
/usr/sbin/pacemakerd :
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/sbin/pacemakerd...done.
Reading symbols from /usr/lib64/libuuid.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib64/libuuid.so.1
Reading symbols from /usr/lib/libcoroipcc.so.4...done.
Loaded symbols for /usr/lib/libcoroipcc.so.4
Reading symbols from /usr/lib/libcpg.so.4...done.
Loaded symbols for /usr/lib/libcpg.so.4
Reading symbols from /usr/lib/libquorum.so.4...done.
Loaded symbols for /usr/lib/libquorum.so.4
Reading symbols from /usr/lib64/libcrmcommon.so.2...done.
Loaded symbols for /usr/lib64/libcrmcommon.so.2
Reading symbols from /usr/lib/libcfg.so.4...done.
Loaded symbols for /usr/lib/libcfg.so.4
Reading symbols from /usr/lib/libconfdb.so.4...done.
Loaded symbols for /usr/lib/libconfdb.so.4
Reading symbols from /usr/lib64/libplumb.so.2...done.
Loaded symbols for /usr/lib64/libplumb.so.2
Reading symbols from /usr/lib64/libpils.so.2...done.
Loaded symbols for /usr/lib64/libpils.so.2
Reading symbols from /lib/libbz2.so.1.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libbz2.so.1.0
Reading symbols from /usr/lib/libxslt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libxslt.so.1
Reading symbols from /usr/lib/libxml2.so.2...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libglib-2.0.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib/libglib-2.0.so.0
Reading symbols from /usr/lib/libltdl.so.7...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libltdl.so.7
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libpcre.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib/libpcre.so.3
Reading symbols from /lib/libnss_compat.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/libnss_files.so.2
Core was generated by `pacemakerd'.
Program terminated with signal 10, Bus error.
#0  cpg_dispatch (handle=17861288972693536769, dispatch_types=7986) at cpg.c:339
339 switch (dispatch_data->id) {
(gdb) bt
#0  cpg_dispatch (handle=17861288972693536769, dispatch_types=7986) at cpg.c:339
#1  0xf6f100f0 in ?? ()
#2  0xf6f100f4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)



I take a look at the cpg.c and see that the dispatch_data was aquired
by coroipcc_dispatch_get (that was defined on lib/coroipcc.c)
function:

   do {
error = coroipcc_dispatch_get (
cpg_inst->handle,
(void **)&dispatch_data,
timeout);




Resumed log:
...
un 02 23:12:20 corosync [CPG   ] got mcast request on 0x62500
Jun 02 23:12:20 corosync [TOTEM ] mcasted message added to pending queue
Jun 02 23:12:20 corosync [TOTEM ] Delivering f to 10
Jun 02 23:12:20 corosync [TOTEM ] Delivering MCAST message with seq 10

Re: [Pacemaker] [Openais] Linux HA on debian sparc

2011-06-02 Thread Steven Dake 
On 06/01/2011 11:05 PM, william felipe_welter wrote:
> I recompile my kernel without hugetlb .. and the result are the same..
> 
> My test program still resulting:
> PATH=/dev/shm/teste123XX
> page size=2
> fd=3
> ADDR_ORIG:0xe000a000  ADDR:0x
> Erro
> 
> And Pacemaker still resulting because the mmap error:
> Could not initialize Cluster Configuration Database API instance error 2
> 

Give the patch I posted recently a spin - corosync WFM with this patch
on sparc64 with hugetlb set.  Please report back results.

Regards
-steve

> For make sure that i have disable the hugetlb there is my /proc/meminfo:
> MemTotal:   33093488 kB
> MemFree:32855616 kB
> Buffers:5600 kB
> Cached:53480 kB
> SwapCached:0 kB
> Active:45768 kB
> Inactive:  28104 kB
> Active(anon):  18024 kB
> Inactive(anon): 1560 kB
> Active(file):  27744 kB
> Inactive(file):26544 kB
> Unevictable:   0 kB
> Mlocked:   0 kB
> SwapTotal:   6104680 kB
> SwapFree:6104680 kB
> Dirty: 0 kB
> Writeback: 0 kB
> AnonPages: 14936 kB
> Mapped: 7736 kB
> Shmem:  4624 kB
> Slab:  39184 kB
> SReclaimable:  10088 kB
> SUnreclaim:29096 kB
> KernelStack:7088 kB
> PageTables: 1160 kB
> Quicklists:17664 kB
> NFS_Unstable:  0 kB
> Bounce:0 kB
> WritebackTmp:  0 kB
> CommitLimit:22651424 kB
> Committed_AS: 519368 kB
> VmallocTotal:   1069547520 kB
> VmallocUsed:   11064 kB
> VmallocChunk:   1069529616 kB
> 
> 
> 2011/6/1 Steven Dake :
>> On 06/01/2011 07:42 AM, william felipe_welter wrote:
>>> Steven,
>>>
>>> cat /proc/meminfo
>>> ...
>>> HugePages_Total:   0
>>> HugePages_Free:0
>>> HugePages_Rsvd:0
>>> HugePages_Surp:0
>>> Hugepagesize:   4096 kB
>>> ...
>>>
>>
>> It definitely requires a kernel compile and setting the config option to
>> off.  I don't know the debian way of doing this.
>>
>> The only reason you may need this option is if you have very large
>> memory sizes, such as 48GB or more.
>>
>> Regards
>> -steve
>>
>>> Its 4MB..
>>>
>>> How can i disable hugetlb ? ( passing CONFIG_HUGETLBFS=n at boot to
>>> kernel ?)
>>>
>>> 2011/6/1 Steven Dake mailto:sd...@redhat.com>>
>>>
>>> On 06/01/2011 01:05 AM, Steven Dake wrote:
>>> > On 05/31/2011 09:44 PM, Angus Salkeld wrote:
>>> >> On Tue, May 31, 2011 at 11:52:48PM -0300, william felipe_welter
>>> wrote:
>>> >>> Angus,
>>> >>>
>>> >>> I make some test program (based on the code coreipcc.c) and i
>>> now i sure
>>> >>> that are problems with the mmap systems call on sparc..
>>> >>>
>>> >>> Source code of my test program:
>>> >>>
>>> >>> #include 
>>> >>> #include 
>>> >>> #include 
>>> >>>
>>> >>> #define PATH_MAX  36
>>> >>>
>>> >>> int main()
>>> >>> {
>>> >>>
>>> >>> int32_t fd;
>>> >>> void *addr_orig;
>>> >>> void *addr;
>>> >>> char path[PATH_MAX];
>>> >>> const char *file = "teste123XX";
>>> >>> size_t bytes=10024;
>>> >>>
>>> >>> snprintf (path, PATH_MAX, "/dev/shm/%s", file);
>>> >>> printf("PATH=%s\n",path);
>>> >>>
>>> >>> fd = mkstemp (path);
>>> >>> printf("fd=%d \n",fd);
>>> >>>
>>> >>>
>>> >>> addr_orig = mmap (NULL, bytes, PROT_NONE,
>>> >>>   MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
>>> >>>
>>> >>>
>>> >>> addr = mmap (addr_orig, bytes, PROT_READ | PROT_WRITE,
>>> >>>   MAP_FIXED | MAP_SHARED, fd, 0);
>>> >>>
>>> >>> printf("ADDR_ORIG:%p  ADDR:%p\n",addr_orig,addr);
>>> >>>
>>> >>>
>>> >>>   if (addr != addr_orig) {
>>> >>>printf("Erro");
>>> >>> }
>>> >>> }
>>> >>>
>>> >>> Results on x86:
>>> >>> PATH=/dev/shm/teste123XX
>>> >>> fd=3
>>> >>> ADDR_ORIG:0x7f867d8e6000  ADDR:0x7f867d8e6000
>>> >>>
>>> >>> Results on sparc:
>>> >>> PATH=/dev/shm/teste123XX
>>> >>> fd=3
>>> >>> ADDR_ORIG:0xf7f72000  ADDR:0x
>>> >>
>>> >> Note: 0x == MAP_FAILED
>>> >>
>>> >> (from man mmap)
>>> >> RETURN VALUE
>>> >>On success, mmap() returns a pointer to the mapped area.  On
>>> >>error, the value MAP_FAILED (that is, (void *) -1) is
>>> returned,
>>> >>and errno is  set appropriately.
>>> >>
>>> >>>
>>> >>>
>>> >>> But im wondering if is really needed to call mmap 2 times ?
>>>  What are the
>>> >>> reason to call the mmap 2 times, on the second time using the
>>> address of the
>>> >>> first?
>>> >>>
>>> >>>
>>> >> Well there are 3 calls to mmap()
>>> >> 1) one to allocate 2 * what you need (in pages)
>>> >> 2) maps the first half of the mem to a real file
>>> >> 3) maps the second half

Re: [Pacemaker] [Openais] Linux HA on debian sparc

2011-06-01 Thread william felipe_welter 
I recompile my kernel without hugetlb .. and the result are the same..

My test program still resulting:
PATH=/dev/shm/teste123XX
page size=2
fd=3
ADDR_ORIG:0xe000a000  ADDR:0x
Erro

And Pacemaker still resulting because the mmap error:
Could not initialize Cluster Configuration Database API instance error 2

For make sure that i have disable the hugetlb there is my /proc/meminfo:
MemTotal:   33093488 kB
MemFree:32855616 kB
Buffers:5600 kB
Cached:53480 kB
SwapCached:0 kB
Active:45768 kB
Inactive:  28104 kB
Active(anon):  18024 kB
Inactive(anon): 1560 kB
Active(file):  27744 kB
Inactive(file):26544 kB
Unevictable:   0 kB
Mlocked:   0 kB
SwapTotal:   6104680 kB
SwapFree:6104680 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 14936 kB
Mapped: 7736 kB
Shmem:  4624 kB
Slab:  39184 kB
SReclaimable:  10088 kB
SUnreclaim:29096 kB
KernelStack:7088 kB
PageTables: 1160 kB
Quicklists:17664 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit:22651424 kB
Committed_AS: 519368 kB
VmallocTotal:   1069547520 kB
VmallocUsed:   11064 kB
VmallocChunk:   1069529616 kB


2011/6/1 Steven Dake :
> On 06/01/2011 07:42 AM, william felipe_welter wrote:
>> Steven,
>>
>> cat /proc/meminfo
>> ...
>> HugePages_Total:       0
>> HugePages_Free:        0
>> HugePages_Rsvd:        0
>> HugePages_Surp:        0
>> Hugepagesize:       4096 kB
>> ...
>>
>
> It definitely requires a kernel compile and setting the config option to
> off.  I don't know the debian way of doing this.
>
> The only reason you may need this option is if you have very large
> memory sizes, such as 48GB or more.
>
> Regards
> -steve
>
>> Its 4MB..
>>
>> How can i disable hugetlb ? ( passing CONFIG_HUGETLBFS=n at boot to
>> kernel ?)
>>
>> 2011/6/1 Steven Dake mailto:sd...@redhat.com>>
>>
>>     On 06/01/2011 01:05 AM, Steven Dake wrote:
>>     > On 05/31/2011 09:44 PM, Angus Salkeld wrote:
>>     >> On Tue, May 31, 2011 at 11:52:48PM -0300, william felipe_welter
>>     wrote:
>>     >>> Angus,
>>     >>>
>>     >>> I make some test program (based on the code coreipcc.c) and i
>>     now i sure
>>     >>> that are problems with the mmap systems call on sparc..
>>     >>>
>>     >>> Source code of my test program:
>>     >>>
>>     >>> #include 
>>     >>> #include 
>>     >>> #include 
>>     >>>
>>     >>> #define PATH_MAX  36
>>     >>>
>>     >>> int main()
>>     >>> {
>>     >>>
>>     >>> int32_t fd;
>>     >>> void *addr_orig;
>>     >>> void *addr;
>>     >>> char path[PATH_MAX];
>>     >>> const char *file = "teste123XX";
>>     >>> size_t bytes=10024;
>>     >>>
>>     >>> snprintf (path, PATH_MAX, "/dev/shm/%s", file);
>>     >>> printf("PATH=%s\n",path);
>>     >>>
>>     >>> fd = mkstemp (path);
>>     >>> printf("fd=%d \n",fd);
>>     >>>
>>     >>>
>>     >>> addr_orig = mmap (NULL, bytes, PROT_NONE,
>>     >>>               MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
>>     >>>
>>     >>>
>>     >>> addr = mmap (addr_orig, bytes, PROT_READ | PROT_WRITE,
>>     >>>               MAP_FIXED | MAP_SHARED, fd, 0);
>>     >>>
>>     >>> printf("ADDR_ORIG:%p  ADDR:%p\n",addr_orig,addr);
>>     >>>
>>     >>>
>>     >>>   if (addr != addr_orig) {
>>     >>>                printf("Erro");
>>     >>>         }
>>     >>> }
>>     >>>
>>     >>> Results on x86:
>>     >>> PATH=/dev/shm/teste123XX
>>     >>> fd=3
>>     >>> ADDR_ORIG:0x7f867d8e6000  ADDR:0x7f867d8e6000
>>     >>>
>>     >>> Results on sparc:
>>     >>> PATH=/dev/shm/teste123XX
>>     >>> fd=3
>>     >>> ADDR_ORIG:0xf7f72000  ADDR:0x
>>     >>
>>     >> Note: 0x == MAP_FAILED
>>     >>
>>     >> (from man mmap)
>>     >> RETURN VALUE
>>     >>        On success, mmap() returns a pointer to the mapped area.  On
>>     >>        error, the value MAP_FAILED (that is, (void *) -1) is
>>     returned,
>>     >>        and errno is  set appropriately.
>>     >>
>>     >>>
>>     >>>
>>     >>> But im wondering if is really needed to call mmap 2 times ?
>>      What are the
>>     >>> reason to call the mmap 2 times, on the second time using the
>>     address of the
>>     >>> first?
>>     >>>
>>     >>>
>>     >> Well there are 3 calls to mmap()
>>     >> 1) one to allocate 2 * what you need (in pages)
>>     >> 2) maps the first half of the mem to a real file
>>     >> 3) maps the second half of the mem to the same file
>>     >>
>>     >> The point is when you write to an address over the end of the
>>     >> first half of memory it is taken care of the the third mmap which
>>     maps
>>     >> the address back to the top of the file for you. This means you
>>     >> don't have to worry about ringbuffer wrapping which can be a
>>     headache.
>>     >>
>>     >> -Angus
>>     >>
>>     >
>>  

Re: [Pacemaker] [Openais] Linux HA on debian sparc

2011-06-01 Thread Steven Dake 
On 06/01/2011 07:42 AM, william felipe_welter wrote:
> Steven,
> 
> cat /proc/meminfo
> ...
> HugePages_Total:   0
> HugePages_Free:0
> HugePages_Rsvd:0
> HugePages_Surp:0
> Hugepagesize:   4096 kB
> ...
> 

It definitely requires a kernel compile and setting the config option to
off.  I don't know the debian way of doing this.

The only reason you may need this option is if you have very large
memory sizes, such as 48GB or more.

Regards
-steve

> Its 4MB..
> 
> How can i disable hugetlb ? ( passing CONFIG_HUGETLBFS=n at boot to
> kernel ?)
> 
> 2011/6/1 Steven Dake mailto:sd...@redhat.com>>
> 
> On 06/01/2011 01:05 AM, Steven Dake wrote:
> > On 05/31/2011 09:44 PM, Angus Salkeld wrote:
> >> On Tue, May 31, 2011 at 11:52:48PM -0300, william felipe_welter
> wrote:
> >>> Angus,
> >>>
> >>> I make some test program (based on the code coreipcc.c) and i
> now i sure
> >>> that are problems with the mmap systems call on sparc..
> >>>
> >>> Source code of my test program:
> >>>
> >>> #include 
> >>> #include 
> >>> #include 
> >>>
> >>> #define PATH_MAX  36
> >>>
> >>> int main()
> >>> {
> >>>
> >>> int32_t fd;
> >>> void *addr_orig;
> >>> void *addr;
> >>> char path[PATH_MAX];
> >>> const char *file = "teste123XX";
> >>> size_t bytes=10024;
> >>>
> >>> snprintf (path, PATH_MAX, "/dev/shm/%s", file);
> >>> printf("PATH=%s\n",path);
> >>>
> >>> fd = mkstemp (path);
> >>> printf("fd=%d \n",fd);
> >>>
> >>>
> >>> addr_orig = mmap (NULL, bytes, PROT_NONE,
> >>>   MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
> >>>
> >>>
> >>> addr = mmap (addr_orig, bytes, PROT_READ | PROT_WRITE,
> >>>   MAP_FIXED | MAP_SHARED, fd, 0);
> >>>
> >>> printf("ADDR_ORIG:%p  ADDR:%p\n",addr_orig,addr);
> >>>
> >>>
> >>>   if (addr != addr_orig) {
> >>>printf("Erro");
> >>> }
> >>> }
> >>>
> >>> Results on x86:
> >>> PATH=/dev/shm/teste123XX
> >>> fd=3
> >>> ADDR_ORIG:0x7f867d8e6000  ADDR:0x7f867d8e6000
> >>>
> >>> Results on sparc:
> >>> PATH=/dev/shm/teste123XX
> >>> fd=3
> >>> ADDR_ORIG:0xf7f72000  ADDR:0x
> >>
> >> Note: 0x == MAP_FAILED
> >>
> >> (from man mmap)
> >> RETURN VALUE
> >>On success, mmap() returns a pointer to the mapped area.  On
> >>error, the value MAP_FAILED (that is, (void *) -1) is
> returned,
> >>and errno is  set appropriately.
> >>
> >>>
> >>>
> >>> But im wondering if is really needed to call mmap 2 times ?
>  What are the
> >>> reason to call the mmap 2 times, on the second time using the
> address of the
> >>> first?
> >>>
> >>>
> >> Well there are 3 calls to mmap()
> >> 1) one to allocate 2 * what you need (in pages)
> >> 2) maps the first half of the mem to a real file
> >> 3) maps the second half of the mem to the same file
> >>
> >> The point is when you write to an address over the end of the
> >> first half of memory it is taken care of the the third mmap which
> maps
> >> the address back to the top of the file for you. This means you
> >> don't have to worry about ringbuffer wrapping which can be a
> headache.
> >>
> >> -Angus
> >>
> >
> > interesting this mmap operation doesn't work on sparc linux.
> >
> > Not sure how I can help here - Next step would be a follow up with the
> > sparc linux mailing list.  I'll do that and cc you on the message
> - see
> > if we get any response.
> >
> > http://vger.kernel.org/vger-lists.html
> >
> >>>
> >>>
> >>>
> >>>
> >>> 2011/5/31 Angus Salkeld  >
> >>>
>  On Tue, May 31, 2011 at 06:25:56PM -0300, william felipe_welter
> wrote:
> > Thanks Steven,
> >
> > Now im try to run on the MCP:
> > - Uninstall the pacemaker 1.0
> > - Compile and install 1.1
> >
> > But now i have problems to initialize the pacemakerd: Could not
>  initialize
> > Cluster Configuration Database API instance error 2
> > Debbuging with gdb i see that the error are on the confdb.. most
>  specificaly
> > the errors start on coreipcc.c  at line:
> >
> >
> > 448if (addr != addr_orig) {
> > 449goto error_close_unlink;  <- enter here
> > 450   }
> >
> > Some ideia about  what can cause this  ?
> >
> 
>  I tried porting a ringbuffer (www.libqb.org
> ) to sparc and had the same
>  failure.
>  There are 3 mmap() calls and on sparc the third one keeps failing.
> 
>

Re: [Pacemaker] [Openais] Linux HA on debian sparc

2011-06-01 Thread william felipe_welter 
Steven,

cat /proc/meminfo
...
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   4096 kB
...

Its 4MB..

How can i disable hugetlb ? ( passing CONFIG_HUGETLBFS=n at boot to kernel
?)

2011/6/1 Steven Dake 

> On 06/01/2011 01:05 AM, Steven Dake wrote:
> > On 05/31/2011 09:44 PM, Angus Salkeld wrote:
> >> On Tue, May 31, 2011 at 11:52:48PM -0300, william felipe_welter wrote:
> >>> Angus,
> >>>
> >>> I make some test program (based on the code coreipcc.c) and i now i
> sure
> >>> that are problems with the mmap systems call on sparc..
> >>>
> >>> Source code of my test program:
> >>>
> >>> #include 
> >>> #include 
> >>> #include 
> >>>
> >>> #define PATH_MAX  36
> >>>
> >>> int main()
> >>> {
> >>>
> >>> int32_t fd;
> >>> void *addr_orig;
> >>> void *addr;
> >>> char path[PATH_MAX];
> >>> const char *file = "teste123XX";
> >>> size_t bytes=10024;
> >>>
> >>> snprintf (path, PATH_MAX, "/dev/shm/%s", file);
> >>> printf("PATH=%s\n",path);
> >>>
> >>> fd = mkstemp (path);
> >>> printf("fd=%d \n",fd);
> >>>
> >>>
> >>> addr_orig = mmap (NULL, bytes, PROT_NONE,
> >>>   MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
> >>>
> >>>
> >>> addr = mmap (addr_orig, bytes, PROT_READ | PROT_WRITE,
> >>>   MAP_FIXED | MAP_SHARED, fd, 0);
> >>>
> >>> printf("ADDR_ORIG:%p  ADDR:%p\n",addr_orig,addr);
> >>>
> >>>
> >>>   if (addr != addr_orig) {
> >>>printf("Erro");
> >>> }
> >>> }
> >>>
> >>> Results on x86:
> >>> PATH=/dev/shm/teste123XX
> >>> fd=3
> >>> ADDR_ORIG:0x7f867d8e6000  ADDR:0x7f867d8e6000
> >>>
> >>> Results on sparc:
> >>> PATH=/dev/shm/teste123XX
> >>> fd=3
> >>> ADDR_ORIG:0xf7f72000  ADDR:0x
> >>
> >> Note: 0x == MAP_FAILED
> >>
> >> (from man mmap)
> >> RETURN VALUE
> >>On success, mmap() returns a pointer to the mapped area.  On
> >>error, the value MAP_FAILED (that is, (void *) -1) is returned,
> >>and errno is  set appropriately.
> >>
> >>>
> >>>
> >>> But im wondering if is really needed to call mmap 2 times ?  What are
> the
> >>> reason to call the mmap 2 times, on the second time using the address
> of the
> >>> first?
> >>>
> >>>
> >> Well there are 3 calls to mmap()
> >> 1) one to allocate 2 * what you need (in pages)
> >> 2) maps the first half of the mem to a real file
> >> 3) maps the second half of the mem to the same file
> >>
> >> The point is when you write to an address over the end of the
> >> first half of memory it is taken care of the the third mmap which maps
> >> the address back to the top of the file for you. This means you
> >> don't have to worry about ringbuffer wrapping which can be a headache.
> >>
> >> -Angus
> >>
> >
> > interesting this mmap operation doesn't work on sparc linux.
> >
> > Not sure how I can help here - Next step would be a follow up with the
> > sparc linux mailing list.  I'll do that and cc you on the message - see
> > if we get any response.
> >
> > http://vger.kernel.org/vger-lists.html
> >
> >>>
> >>>
> >>>
> >>>
> >>> 2011/5/31 Angus Salkeld 
> >>>
>  On Tue, May 31, 2011 at 06:25:56PM -0300, william felipe_welter wrote:
> > Thanks Steven,
> >
> > Now im try to run on the MCP:
> > - Uninstall the pacemaker 1.0
> > - Compile and install 1.1
> >
> > But now i have problems to initialize the pacemakerd: Could not
>  initialize
> > Cluster Configuration Database API instance error 2
> > Debbuging with gdb i see that the error are on the confdb.. most
>  specificaly
> > the errors start on coreipcc.c  at line:
> >
> >
> > 448if (addr != addr_orig) {
> > 449goto error_close_unlink;  <- enter here
> > 450   }
> >
> > Some ideia about  what can cause this  ?
> >
> 
>  I tried porting a ringbuffer (www.libqb.org) to sparc and had the
> same
>  failure.
>  There are 3 mmap() calls and on sparc the third one keeps failing.
> 
>  This is a common way of creating a ring buffer, see:
> 
> http://en.wikipedia.org/wiki/Circular_buffer#Exemplary_POSIX_Implementation
> 
>  I couldn't get it working in the short time I tried. It's probably
>  worth looking at the clib implementation to see why it's failing
>  (I didn't get to that).
> 
>  -Angus
> 
>
> Note, we sorted this out we believe.  Your kernel has hugetlb enabled,
> probably with 4MB pages.  This requires corosync to allocate 4MB pages.
>
> Can you verify your hugetlb settings?
>
> If you can turn this option off, you should have atleast a working
> corosync.
>
> Regards
> -steve
> 
>  ___
>  Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
>  http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
>  Project Home: http://www.clusterlabs.org
>  Getting started:
> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>

Re: [Pacemaker] [Openais] Linux HA on debian sparc

2011-06-01 Thread Steven Dake 
On 06/01/2011 01:05 AM, Steven Dake wrote:
> On 05/31/2011 09:44 PM, Angus Salkeld wrote:
>> On Tue, May 31, 2011 at 11:52:48PM -0300, william felipe_welter wrote:
>>> Angus,
>>>
>>> I make some test program (based on the code coreipcc.c) and i now i sure
>>> that are problems with the mmap systems call on sparc..
>>>
>>> Source code of my test program:
>>>
>>> #include 
>>> #include 
>>> #include 
>>>
>>> #define PATH_MAX  36
>>>
>>> int main()
>>> {
>>>
>>> int32_t fd;
>>> void *addr_orig;
>>> void *addr;
>>> char path[PATH_MAX];
>>> const char *file = "teste123XX";
>>> size_t bytes=10024;
>>>
>>> snprintf (path, PATH_MAX, "/dev/shm/%s", file);
>>> printf("PATH=%s\n",path);
>>>
>>> fd = mkstemp (path);
>>> printf("fd=%d \n",fd);
>>>
>>>
>>> addr_orig = mmap (NULL, bytes, PROT_NONE,
>>>   MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
>>>
>>>
>>> addr = mmap (addr_orig, bytes, PROT_READ | PROT_WRITE,
>>>   MAP_FIXED | MAP_SHARED, fd, 0);
>>>
>>> printf("ADDR_ORIG:%p  ADDR:%p\n",addr_orig,addr);
>>>
>>>
>>>   if (addr != addr_orig) {
>>>printf("Erro");
>>> }
>>> }
>>>
>>> Results on x86:
>>> PATH=/dev/shm/teste123XX
>>> fd=3
>>> ADDR_ORIG:0x7f867d8e6000  ADDR:0x7f867d8e6000
>>>
>>> Results on sparc:
>>> PATH=/dev/shm/teste123XX
>>> fd=3
>>> ADDR_ORIG:0xf7f72000  ADDR:0x
>>
>> Note: 0x == MAP_FAILED
>>
>> (from man mmap)
>> RETURN VALUE
>>On success, mmap() returns a pointer to the mapped area.  On
>>error, the value MAP_FAILED (that is, (void *) -1) is returned,
>>and errno is  set appropriately.
>>
>>>
>>>
>>> But im wondering if is really needed to call mmap 2 times ?  What are the
>>> reason to call the mmap 2 times, on the second time using the address of the
>>> first?
>>>
>>>
>> Well there are 3 calls to mmap()
>> 1) one to allocate 2 * what you need (in pages)
>> 2) maps the first half of the mem to a real file
>> 3) maps the second half of the mem to the same file
>>
>> The point is when you write to an address over the end of the
>> first half of memory it is taken care of the the third mmap which maps
>> the address back to the top of the file for you. This means you
>> don't have to worry about ringbuffer wrapping which can be a headache.
>>
>> -Angus
>>
> 
> interesting this mmap operation doesn't work on sparc linux.
> 
> Not sure how I can help here - Next step would be a follow up with the
> sparc linux mailing list.  I'll do that and cc you on the message - see
> if we get any response.
> 
> http://vger.kernel.org/vger-lists.html
> 
>>>
>>>
>>>
>>>
>>> 2011/5/31 Angus Salkeld 
>>>
 On Tue, May 31, 2011 at 06:25:56PM -0300, william felipe_welter wrote:
> Thanks Steven,
>
> Now im try to run on the MCP:
> - Uninstall the pacemaker 1.0
> - Compile and install 1.1
>
> But now i have problems to initialize the pacemakerd: Could not
 initialize
> Cluster Configuration Database API instance error 2
> Debbuging with gdb i see that the error are on the confdb.. most
 specificaly
> the errors start on coreipcc.c  at line:
>
>
> 448if (addr != addr_orig) {
> 449goto error_close_unlink;  <- enter here
> 450   }
>
> Some ideia about  what can cause this  ?
>

 I tried porting a ringbuffer (www.libqb.org) to sparc and had the same
 failure.
 There are 3 mmap() calls and on sparc the third one keeps failing.

 This is a common way of creating a ring buffer, see:
 http://en.wikipedia.org/wiki/Circular_buffer#Exemplary_POSIX_Implementation

 I couldn't get it working in the short time I tried. It's probably
 worth looking at the clib implementation to see why it's failing
 (I didn't get to that).

 -Angus


Note, we sorted this out we believe.  Your kernel has hugetlb enabled,
probably with 4MB pages.  This requires corosync to allocate 4MB pages.

Can you verify your hugetlb settings?

If you can turn this option off, you should have atleast a working corosync.

Regards
-steve

 ___
 Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
 http://oss.clusterlabs.org/mailman/listinfo/pacemaker

 Project Home: http://www.clusterlabs.org
 Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
 Bugs:
 http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker

>>>
>>>
>>>
>>> -- 
>>> William Felipe Welter
>>> --
>>> Consultor em Tecnologias Livres
>>> william.wel...@4linux.com.br
>>> www.4linux.com.br
>>
>>> ___
>>> Openais mailing list
>>> open...@lists.linux-foundation.org
>>> https://lists.linux-foundation.org/mailman/listinfo/openais
>>
>>
>> ___
>> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
>> http://oss.clusterlab

Re: [Pacemaker] [Openais] Linux HA on debian sparc

2011-06-01 Thread Steven Dake 
On 05/31/2011 09:44 PM, Angus Salkeld wrote:
> On Tue, May 31, 2011 at 11:52:48PM -0300, william felipe_welter wrote:
>> Angus,
>>
>> I make some test program (based on the code coreipcc.c) and i now i sure
>> that are problems with the mmap systems call on sparc..
>>
>> Source code of my test program:
>>
>> #include 
>> #include 
>> #include 
>>
>> #define PATH_MAX  36
>>
>> int main()
>> {
>>
>> int32_t fd;
>> void *addr_orig;
>> void *addr;
>> char path[PATH_MAX];
>> const char *file = "teste123XX";
>> size_t bytes=10024;
>>
>> snprintf (path, PATH_MAX, "/dev/shm/%s", file);
>> printf("PATH=%s\n",path);
>>
>> fd = mkstemp (path);
>> printf("fd=%d \n",fd);
>>
>>
>> addr_orig = mmap (NULL, bytes, PROT_NONE,
>>   MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
>>
>>
>> addr = mmap (addr_orig, bytes, PROT_READ | PROT_WRITE,
>>   MAP_FIXED | MAP_SHARED, fd, 0);
>>
>> printf("ADDR_ORIG:%p  ADDR:%p\n",addr_orig,addr);
>>
>>
>>   if (addr != addr_orig) {
>>printf("Erro");
>> }
>> }
>>
>> Results on x86:
>> PATH=/dev/shm/teste123XX
>> fd=3
>> ADDR_ORIG:0x7f867d8e6000  ADDR:0x7f867d8e6000
>>
>> Results on sparc:
>> PATH=/dev/shm/teste123XX
>> fd=3
>> ADDR_ORIG:0xf7f72000  ADDR:0x
> 
> Note: 0x == MAP_FAILED
> 
> (from man mmap)
> RETURN VALUE
>On success, mmap() returns a pointer to the mapped area.  On
>error, the value MAP_FAILED (that is, (void *) -1) is returned,
>and errno is  set appropriately.
> 
>>
>>
>> But im wondering if is really needed to call mmap 2 times ?  What are the
>> reason to call the mmap 2 times, on the second time using the address of the
>> first?
>>
>>
> Well there are 3 calls to mmap()
> 1) one to allocate 2 * what you need (in pages)
> 2) maps the first half of the mem to a real file
> 3) maps the second half of the mem to the same file
> 
> The point is when you write to an address over the end of the
> first half of memory it is taken care of the the third mmap which maps
> the address back to the top of the file for you. This means you
> don't have to worry about ringbuffer wrapping which can be a headache.
> 
> -Angus
> 

interesting this mmap operation doesn't work on sparc linux.

Not sure how I can help here - Next step would be a follow up with the
sparc linux mailing list.  I'll do that and cc you on the message - see
if we get any response.

http://vger.kernel.org/vger-lists.html

>>
>>
>>
>>
>> 2011/5/31 Angus Salkeld 
>>
>>> On Tue, May 31, 2011 at 06:25:56PM -0300, william felipe_welter wrote:
 Thanks Steven,

 Now im try to run on the MCP:
 - Uninstall the pacemaker 1.0
 - Compile and install 1.1

 But now i have problems to initialize the pacemakerd: Could not
>>> initialize
 Cluster Configuration Database API instance error 2
 Debbuging with gdb i see that the error are on the confdb.. most
>>> specificaly
 the errors start on coreipcc.c  at line:


 448if (addr != addr_orig) {
 449goto error_close_unlink;  <- enter here
 450   }

 Some ideia about  what can cause this  ?

>>>
>>> I tried porting a ringbuffer (www.libqb.org) to sparc and had the same
>>> failure.
>>> There are 3 mmap() calls and on sparc the third one keeps failing.
>>>
>>> This is a common way of creating a ring buffer, see:
>>> http://en.wikipedia.org/wiki/Circular_buffer#Exemplary_POSIX_Implementation
>>>
>>> I couldn't get it working in the short time I tried. It's probably
>>> worth looking at the clib implementation to see why it's failing
>>> (I didn't get to that).
>>>
>>> -Angus
>>>
>>>
>>> ___
>>> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>>>
>>> Project Home: http://www.clusterlabs.org
>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>> Bugs:
>>> http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>>>
>>
>>
>>
>> -- 
>> William Felipe Welter
>> --
>> Consultor em Tecnologias Livres
>> william.wel...@4linux.com.br
>> www.4linux.com.br
> 
>> ___
>> Openais mailing list
>> open...@lists.linux-foundation.org
>> https://lists.linux-foundation.org/mailman/listinfo/openais
> 
> 
> ___
> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: 
> http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker


___
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/d

Re: [Pacemaker] [Openais] Linux HA on debian sparc

2011-05-31 Thread Angus Salkeld 
On Tue, May 31, 2011 at 11:52:48PM -0300, william felipe_welter wrote:
> Angus,
> 
> I make some test program (based on the code coreipcc.c) and i now i sure
> that are problems with the mmap systems call on sparc..
> 
> Source code of my test program:
> 
> #include 
> #include 
> #include 
> 
> #define PATH_MAX  36
> 
> int main()
> {
> 
> int32_t fd;
> void *addr_orig;
> void *addr;
> char path[PATH_MAX];
> const char *file = "teste123XX";
> size_t bytes=10024;
> 
> snprintf (path, PATH_MAX, "/dev/shm/%s", file);
> printf("PATH=%s\n",path);
> 
> fd = mkstemp (path);
> printf("fd=%d \n",fd);
> 
> 
> addr_orig = mmap (NULL, bytes, PROT_NONE,
>   MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
> 
> 
> addr = mmap (addr_orig, bytes, PROT_READ | PROT_WRITE,
>   MAP_FIXED | MAP_SHARED, fd, 0);
> 
> printf("ADDR_ORIG:%p  ADDR:%p\n",addr_orig,addr);
> 
> 
>   if (addr != addr_orig) {
>printf("Erro");
> }
> }
> 
> Results on x86:
> PATH=/dev/shm/teste123XX
> fd=3
> ADDR_ORIG:0x7f867d8e6000  ADDR:0x7f867d8e6000
> 
> Results on sparc:
> PATH=/dev/shm/teste123XX
> fd=3
> ADDR_ORIG:0xf7f72000  ADDR:0x

Note: 0x == MAP_FAILED

(from man mmap)
RETURN VALUE
   On success, mmap() returns a pointer to the mapped area.  On
   error, the value MAP_FAILED (that is, (void *) -1) is returned,
   and errno is  set appropriately.

> 
> 
> But im wondering if is really needed to call mmap 2 times ?  What are the
> reason to call the mmap 2 times, on the second time using the address of the
> first?
> 
> 
Well there are 3 calls to mmap()
1) one to allocate 2 * what you need (in pages)
2) maps the first half of the mem to a real file
3) maps the second half of the mem to the same file

The point is when you write to an address over the end of the
first half of memory it is taken care of the the third mmap which maps
the address back to the top of the file for you. This means you
don't have to worry about ringbuffer wrapping which can be a headache.

-Angus

> 
> 
> 
> 
> 2011/5/31 Angus Salkeld 
> 
> > On Tue, May 31, 2011 at 06:25:56PM -0300, william felipe_welter wrote:
> > > Thanks Steven,
> > >
> > > Now im try to run on the MCP:
> > > - Uninstall the pacemaker 1.0
> > > - Compile and install 1.1
> > >
> > > But now i have problems to initialize the pacemakerd: Could not
> > initialize
> > > Cluster Configuration Database API instance error 2
> > > Debbuging with gdb i see that the error are on the confdb.. most
> > specificaly
> > > the errors start on coreipcc.c  at line:
> > >
> > >
> > > 448if (addr != addr_orig) {
> > > 449goto error_close_unlink;  <- enter here
> > > 450   }
> > >
> > > Some ideia about  what can cause this  ?
> > >
> >
> > I tried porting a ringbuffer (www.libqb.org) to sparc and had the same
> > failure.
> > There are 3 mmap() calls and on sparc the third one keeps failing.
> >
> > This is a common way of creating a ring buffer, see:
> > http://en.wikipedia.org/wiki/Circular_buffer#Exemplary_POSIX_Implementation
> >
> > I couldn't get it working in the short time I tried. It's probably
> > worth looking at the clib implementation to see why it's failing
> > (I didn't get to that).
> >
> > -Angus
> >
> >
> > ___
> > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
> > http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> >
> > Project Home: http://www.clusterlabs.org
> > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> > Bugs:
> > http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
> >
> 
> 
> 
> -- 
> William Felipe Welter
> --
> Consultor em Tecnologias Livres
> william.wel...@4linux.com.br
> www.4linux.com.br

> ___
> Openais mailing list
> open...@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/openais


___
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker

Re: [Pacemaker] [Openais] Linux HA on debian sparc

2011-05-31 Thread william felipe_welter 
Angus,

I make some test program (based on the code coreipcc.c) and i now i sure
that are problems with the mmap systems call on sparc..

Source code of my test program:

#include 
#include 
#include 

#define PATH_MAX  36

int main()
{

int32_t fd;
void *addr_orig;
void *addr;
char path[PATH_MAX];
const char *file = "teste123XX";
size_t bytes=10024;

snprintf (path, PATH_MAX, "/dev/shm/%s", file);
printf("PATH=%s\n",path);

fd = mkstemp (path);
printf("fd=%d \n",fd);


addr_orig = mmap (NULL, bytes, PROT_NONE,
  MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);


addr = mmap (addr_orig, bytes, PROT_READ | PROT_WRITE,
  MAP_FIXED | MAP_SHARED, fd, 0);

printf("ADDR_ORIG:%p  ADDR:%p\n",addr_orig,addr);


  if (addr != addr_orig) {
   printf("Erro");
}
}

Results on x86:
PATH=/dev/shm/teste123XX
fd=3
ADDR_ORIG:0x7f867d8e6000  ADDR:0x7f867d8e6000

Results on sparc:
PATH=/dev/shm/teste123XX
fd=3
ADDR_ORIG:0xf7f72000  ADDR:0x


But im wondering if is really needed to call mmap 2 times ?  What are the
reason to call the mmap 2 times, on the second time using the address of the
first?






2011/5/31 Angus Salkeld 

> On Tue, May 31, 2011 at 06:25:56PM -0300, william felipe_welter wrote:
> > Thanks Steven,
> >
> > Now im try to run on the MCP:
> > - Uninstall the pacemaker 1.0
> > - Compile and install 1.1
> >
> > But now i have problems to initialize the pacemakerd: Could not
> initialize
> > Cluster Configuration Database API instance error 2
> > Debbuging with gdb i see that the error are on the confdb.. most
> specificaly
> > the errors start on coreipcc.c  at line:
> >
> >
> > 448if (addr != addr_orig) {
> > 449goto error_close_unlink;  <- enter here
> > 450   }
> >
> > Some ideia about  what can cause this  ?
> >
>
> I tried porting a ringbuffer (www.libqb.org) to sparc and had the same
> failure.
> There are 3 mmap() calls and on sparc the third one keeps failing.
>
> This is a common way of creating a ring buffer, see:
> http://en.wikipedia.org/wiki/Circular_buffer#Exemplary_POSIX_Implementation
>
> I couldn't get it working in the short time I tried. It's probably
> worth looking at the clib implementation to see why it's failing
> (I didn't get to that).
>
> -Angus
>
>
> ___
> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs:
> http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>



-- 
William Felipe Welter
--
Consultor em Tecnologias Livres
william.wel...@4linux.com.br
www.4linux.com.br
___
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker

Re: [Pacemaker] [Openais] Linux HA on debian sparc

2011-05-31 Thread Angus Salkeld 
On Tue, May 31, 2011 at 06:25:56PM -0300, william felipe_welter wrote:
> Thanks Steven,
> 
> Now im try to run on the MCP:
> - Uninstall the pacemaker 1.0
> - Compile and install 1.1
> 
> But now i have problems to initialize the pacemakerd: Could not initialize
> Cluster Configuration Database API instance error 2
> Debbuging with gdb i see that the error are on the confdb.. most specificaly
> the errors start on coreipcc.c  at line:
> 
> 
> 448if (addr != addr_orig) {
> 449goto error_close_unlink;  <- enter here
> 450   }
> 
> Some ideia about  what can cause this  ?
> 

I tried porting a ringbuffer (www.libqb.org) to sparc and had the same failure.
There are 3 mmap() calls and on sparc the third one keeps failing.

This is a common way of creating a ring buffer, see:
http://en.wikipedia.org/wiki/Circular_buffer#Exemplary_POSIX_Implementation

I couldn't get it working in the short time I tried. It's probably
worth looking at the clib implementation to see why it's failing
(I didn't get to that).

-Angus


___
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker

Re: [Pacemaker] [Openais] Linux HA on debian sparc

2011-05-31 Thread william felipe_welter 
Thanks Steven,

Now im try to run on the MCP:
- Uninstall the pacemaker 1.0
- Compile and install 1.1

But now i have problems to initialize the pacemakerd: Could not initialize
Cluster Configuration Database API instance error 2
Debbuging with gdb i see that the error are on the confdb.. most specificaly
the errors start on coreipcc.c  at line:


448if (addr != addr_orig) {
449goto error_close_unlink;  <- enter here
450   }

Some ideia about  what can cause this  ?




2011/5/31 Steven Dake 

> Try running paceamaker using the MCP.  The plugin mode of pacemaker
> never really worked very well because of complexities of posix mmap and
> fork.  Not having sparc hardware personally, YMMV.  We have recently
> with corosync 1.3.1 gone through an alignment fixing process for ARM
> arches - hope that solves your alignment problems on sparc as well.
>
> Regards
> -steve
>
> On 05/31/2011 08:38 AM, william felipe_welter wrote:
> > Im trying to setup HA with corosync and pacemaker using the debian
> > packages on SPARC Architecture. Using Debian package corosync  process
> > dies after initializate pacemaker process. I make some tests with ltrace
> > and strace and this tools tell me that corosync died because a
> > segmentation fault. I try a lot of thing to solve this problem, but
> > nothing made corosync works.
> >
> > My second try is to compile from scratch (using this
> > docs:http://www.clusterlabs.org/wiki/Install#From_Source)
> >  . This way
> > corosync process startup perfectly! but some process of pacemaker don't
> > start.. Analyzing log i see the probably reason:
> >
> > attrd: [2283]: info: init_ais_connection_once: Connection to our AIS
> > plugin (9) failed: Library error (2)
> > 
> > stonithd: [2280]: info: init_ais_connection_once: Connection to our AIS
> > plugin (9) failed: Library error (2)
> > .
> > cib: [2281]: info: init_ais_connection_once: Connection to our AIS
> > plugin (9) failed: Library error (2)
> > .
> > crmd: [3320]: debug: init_client_ipc_comms_
> > nodispatch: Attempting to talk on: /usr/var/run/crm/cib_rw
> > crmd: [3320]: debug: init_client_ipc_comms_nodispatch: Could not init
> > comms on: /usr/var/run/crm/cib_rw
> > crmd: [3320]: debug: cib_native_signon_raw: Connection to command
> > channel failed
> > crmd: [3320]: debug: init_client_ipc_comms_nodispatch: Attempting to
> > talk on: /usr/var/run/crm/cib_callback
> > crmd: [3320]: debug: init_client_ipc_comms_nodispatch: Could not init
> > comms on: /usr/var/run/crm/cib_callback
> > crmd: [3320]: debug: cib_native_signon_raw: Connection to callback
> > channel failed
> > crmd: [3320]: debug: cib_native_signon_raw: Connection to CIB failed:
> > connection failed
> > crmd: [3320]: debug: cib_native_signoff: Signing out of the CIB Service
> > crmd: [3320]: debug: init_client_ipc_comms_nodispatch: Attempting to
> > talk on: /usr/var/run/crm/cib_rw
> > crmd: [3320]: debug: init_client_ipc_comms_nodispatch: Could not init
> > comms on: /usr/var/run/crm/cib_rw
> > crmd: [3320]: debug: cib_native_signon_raw: Connection to command
> > channel failed
> > crmd: [3320]: debug: init_client_ipc_comms_nodispatch: Attempting to
> > talk on: /usr/var/run/crm/cib_callback
> > crmd: [3320]: debug: init_client_ipc_comms_nodispatch: Could not init
> > comms on: /usr/var/run/crm/cib_callback
> > crmd: [3320]: debug: cib_native_signon_raw: Connection to callback
> > channel failed
> > crmd: [3320]: debug: cib_native_signon_raw: Connection to CIB failed:
> > connection failed
> > crmd: [3320]: debug: cib_native_signoff: Signing out of the CIB Service
> > crmd: [3320]: info: do_cib_control: Could not connect to the CIB
> > service: connection failed
> > 
> >
> >
> >
> >
> >
> > My conf:
> > # Please read the corosync.conf.5 manual page
> > compatibility: whitetank
> >
> > totem {
> > version: 2
> > join: 60
> > token: 3000
> > token_retransmits_before_loss_const: 10
> > secauth: off
> > threads: 0
> > consensus: 8601
> > vsftype: none
> > threads: 0
> > rrp_mode: none
> > clear_node_high_bit: yes
> > max_messages: 20
> > interface {
> > ringnumber: 0
> > bindnetaddr: 10.10.23.0
> > mcastaddr: 226.94.1.1
> > mcastport: 5405
> > }
> > }
> >
> > logging {
> > fileline: off
> > to_stderr: no
> > to_logfile: yes
> > to_syslog: yes
> > logfile: /var/log/cluster/corosync.log
> > debug: on
> > timestamp: on
> > logger_subsys {
> > subsys: AMF
> > debug: on
> > }
> > }
> >
> > amf {
> > mode: disabled
> > }
> >
> > service {
> > # Load the Pacemaker Cluster Resource Manager
> > ver:   0
> > name:  pacemaker
> > }
> >
> > aisexec {
> > user:   root
> > group:  root
> > }
> >
> >
> > My Question is: why attrd, cib ... can't connect to  AIS Plugin?  What
> > could be the r

Re: [Pacemaker] [Openais] Linux HA on debian sparc

2011-05-31 Thread Steven Dake 
Try running paceamaker using the MCP.  The plugin mode of pacemaker
never really worked very well because of complexities of posix mmap and
fork.  Not having sparc hardware personally, YMMV.  We have recently
with corosync 1.3.1 gone through an alignment fixing process for ARM
arches - hope that solves your alignment problems on sparc as well.

Regards
-steve

On 05/31/2011 08:38 AM, william felipe_welter wrote:
> Im trying to setup HA with corosync and pacemaker using the debian
> packages on SPARC Architecture. Using Debian package corosync  process
> dies after initializate pacemaker process. I make some tests with ltrace
> and strace and this tools tell me that corosync died because a
> segmentation fault. I try a lot of thing to solve this problem, but
> nothing made corosync works.
> 
> My second try is to compile from scratch (using this
> docs:http://www.clusterlabs.org/wiki/Install#From_Source)
>  . This way
> corosync process startup perfectly! but some process of pacemaker don't
> start.. Analyzing log i see the probably reason:
> 
> attrd: [2283]: info: init_ais_connection_once: Connection to our AIS
> plugin (9) failed: Library error (2)
> 
> stonithd: [2280]: info: init_ais_connection_once: Connection to our AIS
> plugin (9) failed: Library error (2)
> .
> cib: [2281]: info: init_ais_connection_once: Connection to our AIS
> plugin (9) failed: Library error (2)
> .
> crmd: [3320]: debug: init_client_ipc_comms_
> nodispatch: Attempting to talk on: /usr/var/run/crm/cib_rw
> crmd: [3320]: debug: init_client_ipc_comms_nodispatch: Could not init
> comms on: /usr/var/run/crm/cib_rw
> crmd: [3320]: debug: cib_native_signon_raw: Connection to command
> channel failed
> crmd: [3320]: debug: init_client_ipc_comms_nodispatch: Attempting to
> talk on: /usr/var/run/crm/cib_callback
> crmd: [3320]: debug: init_client_ipc_comms_nodispatch: Could not init
> comms on: /usr/var/run/crm/cib_callback
> crmd: [3320]: debug: cib_native_signon_raw: Connection to callback
> channel failed
> crmd: [3320]: debug: cib_native_signon_raw: Connection to CIB failed:
> connection failed
> crmd: [3320]: debug: cib_native_signoff: Signing out of the CIB Service
> crmd: [3320]: debug: init_client_ipc_comms_nodispatch: Attempting to
> talk on: /usr/var/run/crm/cib_rw
> crmd: [3320]: debug: init_client_ipc_comms_nodispatch: Could not init
> comms on: /usr/var/run/crm/cib_rw
> crmd: [3320]: debug: cib_native_signon_raw: Connection to command
> channel failed
> crmd: [3320]: debug: init_client_ipc_comms_nodispatch: Attempting to
> talk on: /usr/var/run/crm/cib_callback
> crmd: [3320]: debug: init_client_ipc_comms_nodispatch: Could not init
> comms on: /usr/var/run/crm/cib_callback
> crmd: [3320]: debug: cib_native_signon_raw: Connection to callback
> channel failed
> crmd: [3320]: debug: cib_native_signon_raw: Connection to CIB failed:
> connection failed
> crmd: [3320]: debug: cib_native_signoff: Signing out of the CIB Service
> crmd: [3320]: info: do_cib_control: Could not connect to the CIB
> service: connection failed
> 
> 
> 
> 
> 
> 
> My conf:
> # Please read the corosync.conf.5 manual page
> compatibility: whitetank
> 
> totem {
> version: 2
> join: 60
> token: 3000
> token_retransmits_before_loss_const: 10
> secauth: off
> threads: 0
> consensus: 8601
> vsftype: none
> threads: 0
> rrp_mode: none
> clear_node_high_bit: yes
> max_messages: 20
> interface {
> ringnumber: 0
> bindnetaddr: 10.10.23.0
> mcastaddr: 226.94.1.1
> mcastport: 5405
> }
> }
> 
> logging {
> fileline: off
> to_stderr: no
> to_logfile: yes
> to_syslog: yes
> logfile: /var/log/cluster/corosync.log
> debug: on
> timestamp: on
> logger_subsys {
> subsys: AMF
> debug: on
> }
> }
> 
> amf {
> mode: disabled
> }
> 
> service {
> # Load the Pacemaker Cluster Resource Manager
> ver:   0
> name:  pacemaker
> }
> 
> aisexec {
> user:   root
> group:  root
> }
> 
> 
> My Question is: why attrd, cib ... can't connect to  AIS Plugin?  What
> could be the reasons for the connection failed ?
> (Yes, my /dev/shm are tmpfs)
> 
> 
> 
> -- 
> William Felipe Welter
> --
> Consultor em Tecnologias Livres
> william.wel...@4linux.com.br 
> www.4linux.com.br 
> 
> 
> 
> ___
> Openais mailing list
> open...@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/openais


___
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://developerb