[fedora-arm] FC18 on sheevaplug corosync and gdb segfaults

[Jochen De Smet]

On 7/7/2013 18:57, Gordan Bobic wrote:
> That implies the code quality deteriorated since F13. Disappointing, if unsurprising. :-(
>
> I suggest you try rawhide package versions (rebuild src.rpm from source). If they also break, please file a bug against rawhide on RH bugzilla.
>
> I suspect it's more likely the armv5tel build will get dropped before the alignment bugs get fixed, though.  :-(
I finally had some time to try this with the rawhide gdb src rpm from a 
few days ago, and it's
still hitting the traps.  I've read 
http://www.rt-embedded.com/blog/archives/resolving-alignment-traps/
but if anyone has a more extensive tutorial on how to debug and fix 
these, I'd love to read it.

J.

>
> Jochen De Smet <jochen.arm at leahnim.org> wrote:
>
>> That seems to have some effect.  It was set to 0, and I changed
>> it to 3 as indicated in an old gcc forum thread.
>>
>> It fixed the gdb of ls (and shows lots of alignment traps); corosync
>> now appears to start fine as well.
>>
>> Thanks!
>>
>> J.
>>
>> On 7/7/2013 17:10, Gordan Bobic wrote:
>>> IIRC,
>>> # cat /proc/cpu/alignment
>>>
>>>
>>> Jochen De Smet <jochen.arm at leahnim.org> wrote:
>>>
>>>> Is that a kernel option or a system config setting?
>>>>
>>>> Kernel-wise, a grep for align shows:
>>>>
>>>> [root at flea ~]# zcat /proc/config.gz | grep -i align
>>>> # CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
>>>> CONFIG_ALIGNMENT_TRAP=y
>>>>
>>>> Looking at arch/arm/mm/alignment.c, it seems like the TRAP one
>>>> might be the one you meant?
>>>>
>>>> J.
>>>>
>>>>
>>>> On 7/7/2013 16:45, Gordan Bobic wrote:
>>>>> Do you have alignment fixup enabled? Is that on by default these days?
>>>>>
>>>>> Jochen De Smet <jochen.arm at leahnim.org> wrote:
>>>>>
>>>>>> Now that my Mirabox is up and running FC18, I thought it'd be a good
>>>>>> time to update my Sheevaplug (running FC15) to FC18 as well.
>>>>>>
>>>>>> Using a minimally modified version of the 3.10 stock kernel I'm also using
>>>>>> on the mirabox, and the "Generic Root Filesystem arm" from the F18 remixes
>>>>>> page, everything appeared to be well at first.
>>>>>>
>>>>>> Then I tried to get pcs up and running. Corosync segfaults at startup. I
>>>>>> tried to
>>>>>> do some debugging, but noticed that gdb also segfaults when trying to see
>>>>>> what's going on with corosync.
>>>>>>
>>>>>> After a bit more digging, it now seems that gdb segfaults no matter what
>>>>>> program
>>>>>> I use it with. e.g. a simple ls:
>>>>>>
>>>>>> [root at flea ~]# gdb /usr/bin/ls
>>>>>> GNU gdb (GDB) Fedora (7.5.1-38.fc18)
>>>>>> Copyright (C) 2012 Free Software Foundation, Inc.
>>>>>> License GPLv3+: GNU GPL version 3 or later
>>>>>> <http://gnu.org/licenses/gpl.html>
>>>>>> 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 "armv5tel-redhat-linux".
>>>>>> For bug reporting instructions, please see:
>>>>>> <http://www.gnu.org/software/gdb/bugs/>...
>>>>>> Reading symbols from /usr/bin/ls...Reading symbols from
>>>>>> /usr/lib/debug/usr/bin/ls.debug...done.
>>>>>> done.
>>>>>> (gdb) r
>>>>>> Starting program: /usr/bin/ls
>>>>>> Segmentation fault
>>>>>> anaconda-ks.cfg  install.log  install.log.syslog
>>>>>> [root at flea ~]#
>>>>>>
>>>>>> Note that the ls itself did appear to complete fine in this case, and
>>>>>> just running ls outside
>>>>>> of gdb works fine.  I haven't found anything else other than corosync
>>>>>> and gdb that's segfaulting.
>>>>>>
>>>>>> Any idea what's going anyone?
>>>>>>
>>>>>> J.
>>>>>>
>>>>>> PS: Is there a generic armv5tel root fs for F19 anywhere? Don't see a
>>>>>> link on the wiki yet.
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> arm mailing list
>>>>>> arm at lists.fedoraproject.org
>>>>>> https://admin.fedoraproject.org/mailman/listinfo/arm