On 01/07/2011 09:25 PM, Gordan Bobic wrote:
> On 01/07/2011 08:27 PM, Andy Green wrote:
>> On 01/07/11 20:17, Somebody in the thread at some point said:
>>> On 01/07/2011 08:13 PM, Andy Green wrote:
>>>
>>>>> counters haven't increased at all, my guess is that it all happened
>>>>> last
>>>>> night when I was building/testing dietlibc stuff. I'll test that
>>>>> hypothesis when the new kernel is built.
>>>>
>>>> Fine but what has happened with your sha512sum then?
>>>
>>> That didn't cause thousands of errors, only a handful - it wasn't being
>>> used much. The only thing I can think if that could have produced that
>>
>> So both sha512sum binaries are giving correct results now or what?
>
> No. The broken one is still broken if I disable alignment fix-ups.
>
>>> may alignment errors (and segfaults to go with them, as it happens) was
>>> what I was doing with dietlibc.
>>>
>>>> Is it the case that
>>>> somehow the shared libc in memory is the dietlibc one? Maybe if you
>>>> reboot without touching anything that touches dietlibc you won't see
>>>> this issue again and the whole thing is a painful lesson to leave
>>>> dietlibc the hell alone ^^
>>>
>>> I don't really see how. As I said, dietlibc is long uninstalled and the
>>> boot-up still trips this 24+1 times. I think the coreutils bug was a
>>> separate one. Now I just need to find what is causing the remaining few
>>> alignment issues.
>>
>> What you should do about that is set
>>
>> alignment=3
>>
>> on your kernel commandline. That'll then be the default reaction to the
>> alignment fault and it should give some logging about who is the process
>> with the alignment faults.
>
> Ooo, thanks for that. :)
> I've attached the dmesg output.
>
> All the errors on boot seem to be coming from
> /lib/udev/devkit-disks-part-id.
>
> # rpm -qf /lib/udev/devkit-disks-part-id
> DeviceKit-disks-009-3.fc12.armv5tel
>
> yum updating this (and the 13 dependencies it has) from the F13
> repository doesn't make the problem go away. :(
>
> Thankfully, though, nothing on the Sheeva uses this. I'll try rebuilding
> the latest version of DeviceKit from source and see if that makes the
> problem go away.
Bah. The F14 DeviceKit src.rpm doesn't build. :(
/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.4/../../../libgirepository-1.0.so:
undefined reference to `g_malloc0_n'
collect2: ld returned 1 exit status
Traceback (most recent call last):
File "/usr/bin/g-ir-scanner", line 38, in <module>
sys.exit(scanner_main(sys.argv))
File "/usr/lib/python2.6/site-packages/giscanner/scannermain.py",
line 313, in scanner_main
glibtransformer.get_get_type_functions())
File "/usr/lib/python2.6/site-packages/giscanner/dumper.py", line
231, in compile_introspection_binary
return dc.run()
File "/usr/lib/python2.6/site-packages/giscanner/dumper.py", line
132, in run
self._link(bin_path, o_path)
File "/usr/lib/python2.6/site-packages/giscanner/dumper.py", line
226, in _link
subprocess.check_call(args)
File "/usr/lib/python2.6/subprocess.py", line 488, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/bin/sh', '../libtool',
'--mode=link', '--tag=CC', '--silent', 'gcc', '-o',
'/usr/src/redhat/BUILD/UPower-0.9.0/devkit-power-gobject/tmp-introspectz_WQKT/DeviceKitPowerGlib-1.0',
'-O2', '-g', '-march=armv5te', '-L.', 'libdevkit-power-gobject.la',
'-pthread', '-Wl,--export-dynamic', '-lgio-2.0', '-lgirepository-1.0',
'-lgobject-2.0', '-lgmodule-2.0', '-lgthread-2.0', '-lrt', '-lffi',
'-lglib-2.0',
'/usr/src/redhat/BUILD/UPower-0.9.0/devkit-power-gobject/tmp-introspectz_WQKT/DeviceKitPowerGlib-1.0.o']'
returned non-zero exit status 1
make[2]: *** [DeviceKitPowerGlib-1.0.gir] Error 1
make[2]: Leaving directory
`/usr/src/redhat/BUILD/UPower-0.9.0/devkit-power-gobject'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/UPower-0.9.0'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.C7DE1t (%build)
In the end, I just gave up and did
rpm -e DeviceKit-disks since I don't actually need it. Works fine now,
but it looks like DeviceKit needs fixing.
Gordan
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
