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.
Gordan