djwillis/meta-raspberrypi

Kernel build fails with "Inconsistent kallsyms data"

keylevel opened this issue · 23 comments

keylevel commented

It goes on to say:

"This is a bug - please report about it
Try make KALLSYMS_EXTRA_PASS=1 as a workaround"

adding:
EXTRA_OEMAKE = "KALLSYMS_EXTRA_PASS=1"
to linux-raspberrypi_3.1.9.bb does the job.

This doesn't affect all SRCREVs, but "fc48dbcb3a1eb6a80ddf132b6ca65d408c268c84" (the latest at the moment) does fail without the above.

agherzan commented

We don't have this version in meta-rpi right now.

@g

keylevel commented

True, but:

  1. This seems to be a common issue with ARM kernel builds (hence the diagnostic advising of the fix);
  2. It depends on how the build runs (i.e. no way to predict when it will bite);
  3. I've now seen it with one commit against the 3.1.9 kernel;
  4. I've had to use it for the 3.2.21 ('bootc') kernel.

Seems like it would make sense to put it in now as a preventative measure as it doesn't break other builds.

agherzan commented

Would you please provide a link to the original bug?

Thank you,
Andrei

koenkooi commented

FWIW these "it can't hurt" type of cargo-cult changes have a habit of coming back to bite you in the future. Things like this should only be added if they fix a problem that exists in the build.

agherzan commented

I definitely agree. That's why in my opinion a fix should have a bug. No bug. No fix. :)
So right now i will close this issue but fell free to reopen it whenever you find that this bug appears somewhere.

Thank you,
@g

keylevel commented

It would be nice if the originator of an issue were allowed to comment before it is closed, especially when they can't re-open it themselves and they they have a day job that means they can't comment at the drop of a hat ;-)

This isn't currently hitting at the moment because we aren't using the latest kernel commit.

There is discussion of the issue at http://www.spinics.net/lists/linux-kbuild/msg06072.html (from the linux kernel mailing list).

agherzan commented

@keylevel Sorry. Didn't know you cannot reopen the issue. My bad this time :)

keylevel commented

NP ;-)

The kernel commit raspberrypi/linux@529f715 means that compressed kernels are working again.

  1. This needs the KALYSYMS fix, above;
  2. The patch at bootc/linux-rpi-orig@bff06d1 is needed and isn't yet in the kernel git.
agherzan commented

So that commit it's working only with the KALYSYMS fix above? Did you test it?

I don't understand how what that commit merged as long as UART0_CLOCK is not defined...

@agherzan

agherzan commented

Fixed in upstream. Would you please confirm that it works only with KALYSYMS fix?

@agherzan

keylevel commented

Yes raspberrypi/linux@d461c6d boots using zImage.

The KALYSYMS fix is needed for it to compile under GCC 4.6.4 (Denzil).

Should be able to switch back to using zImage now ;-)

agherzan commented

@keylevel It seems like this is not needed with the new updates from rpi-kernel.
Could you please test #46 and provide some feedback?

Thanks,
Andrei

keylevel commented

This relates to an issue with the way GCC 4.6.4 compiles/links. It's not deterministic, so some builds work, some don't. The fact that a particular build now works is just 'luck' and doesn't mean that the issue will not re-appear in future kernel updates. I would be inclined to leave the fix in place until GCC is fixed.

It could possibly be commented-out with a note to explain why it was in so that if anyone does get hit they can see what the fix is, but given it adds virtually nothing to the build time it's probably as easy to leave it in.

agherzan commented

Do you have a log when this failed?

Thank you,
Andrei

keylevel commented

Not at the moment, but it's related to the order in which some items are linked and is therefore sensitive to the build order of other parts.

agherzan commented

So this is reproducible only on denzil?

keylevel commented

No idea as I've only tried with denzil.

I suspect any build using GCC 4.6.4 (and maybe others) could hit it.

agherzan commented

Post us a log when you hit it next time. Thanks.

keylevel commented

Will do, but I'm not doing a lot with the RPi at the moment.

In the mean time, a google throws up lots of hits like http://lists.fedoraproject.org/pipermail/arm/2012-March/003001.html

agherzan commented

Ok. I understand a bit the problem. The idea is that they really suggest to activate this only if a bug is spotted. So i will wait to a log with the kernel i will push this weekend.

If kallsyms is not working correctly, the build will fail with

  •  inconsistent kallsyms data.  If that occurs, log a bug report and

  •  turn on KALLSYMS_EXTRA_PASS which should result in a stable build.

  •  Always say N here unless you find a bug in kallsyms, which must be

  •  reported.  KALLSYMS_EXTRA_PASS is only a temporary workaround while

  •  you wait for kallsyms to be fixed.

Btw, why don't you use master?

keylevel commented

Why not master? Because I'm generally working with products that need a stable build and master is too 'risky'. It's also muck easier to have a consistent build when systems are in different locations and may end up using different commits.

It's also easier to test changes for something like the RPi kernel when nothing else is changing at the same time.

agherzan commented

Indeed. This is why the branch is called master :)

Throw me a log as soon as you can reproduce this kallsyms bug.

Cheers!

agherzan commented

I was able to compile with GCC 4.6.4 without this workaround. Could have been fixed in the meanwhile?

ag

EDIT: I will close this bug for now. I will reopen it if things reappear. Hope this was a bug fixed in kernel. As I said above, I wasn't able to reproduce this not even with gcc 4.6.4. Thanks @keylevel