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. :-(
Jochen De Smet jochen.arm@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@leahnim.org wrote:
Is that a kernel option or a system config setting?
Kernel-wise, a grep for align shows:
[root@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@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@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@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
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@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@leahnim.org wrote:
Is that a kernel option or a system config setting?
Kernel-wise, a grep for align shows:
[root@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@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@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@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm