kernel-testers.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Kernel Testers List <kernel-testers@vger.kernel.org>
Subject: wrong final bzImage build (regading #14270)
Date: Fri, 09 Oct 2009 18:17:50 +0400	[thread overview]
Message-ID: <4ACF460E.7000901@msgid.tls.msk.ru> (raw)

Ok, finally the mystery solved.  After a week of
digging.

The original problem was titled "Cannot boot on
a PIII Celeron", and Rafael filed a bug #14270
for this.

In short, what I observed was that a new kernel
(2.6.31) fails to boot on a PIII Celeron machine.
But changing just the CPU to plain PIII and voila,
it now works.  I don't know why it behaved this
way, but I found where was the problem, finally.

And the problem is in the last stage of build, when
building the bzImage.

make -f scripts/Makefile.build obj=arch/x86/boot/compressed arch/x86/boot/compressed/vmlinux
...
   (cat arch/x86/boot/compressed/vmlinux.bin | lzma -9 && echo -ne \\x38\\xd6\\x37\\x00) > arch/x86/boot/compressed/vmlinux.bin.lzma
...

Note the echo command.

Now, Debian switched to dash as /bin/sh.  And dash
does not understand the -e option:

$ dash -c 'echo -ne \\x38\\xd6\\x37\\x00' | od -x
0000000 6e2d 2065 785c 3833 785c 3664 785c 3733
0000020 785c 3030 000a

$ bash -c 'echo -ne \\x38\\xd6\\x37\\x00' | od -x
0000000 d638 0037

So the final size (it's the size of uncompressed file)
becomes incorrect.  Here's what mkpiggy outputs for
this (in arch/x86/boot/compressed/piggy.S):

  z_output_len = 170930296

while it should be

  z_output_len = 3659320

And with the former (wrong, larger) size, the whole
thing just reboots on a PIII Celeron.  I've no idea
why, but the original problem is here.

The same thing happens with bzip2 algorithm which is
not new, not only with lzma.

The whole thing looks quite hackish to me, -- mkpiggy
can know the size from the original image just fine,
instead of getting it from the end of already compressed
file.

For now, quick fix is to change echo to printf in there.
Correct fix is to re-write mkpiggy to look at the
original file for size (IMHO anyway).

And this is a very good candidate for -stable as well.
The bug is very difficult to find.  And now when more
and more people who use Debian are switching to dash,
it will be more common.

Thanks!

/mjt

             reply	other threads:[~2009-10-09 14:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-09 14:17 Michael Tokarev [this message]
2009-10-09 14:26 ` wrong final bzImage build (regading #14270) Michael Tokarev
2009-10-09 14:58 ` Cyrill Gorcunov
2009-10-09 17:03   ` H. Peter Anvin
     [not found]     ` <4ACF6CF8.4060204-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
2009-10-09 17:14       ` Michael Tokarev
2009-10-09 19:39   ` Michael Tokarev
     [not found]     ` <4ACF9184.9040104-Gdu+ltImwkhes2APU0mLOQ@public.gmane.org>
2009-10-09 19:59       ` Cyrill Gorcunov
2009-10-09 20:02     ` Arkadiusz Miskiewicz
2009-10-09 20:56       ` H. Peter Anvin
     [not found]         ` <4ACFA36F.6000105-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
2009-10-09 21:27           ` Michael Tokarev
2009-10-09 21:29             ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ACF460E.7000901@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=gorcunov@gmail.com \
    --cc=kernel-testers@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@sisk.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).