public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: robert.jarzmik@free•fr (Robert Jarzmik)
To: linux-arm-kernel@lists•infradead.org
Subject: Initrd and 2.6.33 curious behaviour
Date: Sat, 22 May 2010 11:37:43 +0200	[thread overview]
Message-ID: <87fx1k46qg.fsf@free.fr> (raw)
In-Reply-To: <20100521204343.GA18032@n2100.arm.linux.org.uk> (Russell King's message of "Fri\, 21 May 2010 21\:43\:43 +0100")

Russell King - ARM Linux <linux@arm•linux.org.uk> writes:

> On Fri, May 21, 2010 at 10:27:05PM +0200, Robert Jarzmik wrote:
>> I pulled the 2.6.33 kernel and tried my mainboard with it (mioa701). My
>> kernel boots fine, but initrd load always fails.
>
> Please post all the kernel messages.

If only I could ...
I have no serial console, only the screen, and until initrd is loaded, no
network connection. The mioa701 is a smartphone, with no keyboard, and only
bluetooth and USB as a communication mean.

The only thing I can see is the console output on the framebuffer, which is damn
small.

I was thinking that if at least 1 person could load the initrd, then I would
have no other choice but investigate. But if all people have the same problem,
there would be someone with a development board who will have a full console
output and find the issue easier.

>> After digging a bit in arch/arm/mm/init.c, I find that :
>>  - phys_initrd_start = 0xa0508000
>>  - phys_initrd_size = 3 759 480
>>  - initrd_start = 0 and initrd_end = 0
>
> It's unclear where you're checking this.  The virtual pointers are only
> setup if we're satisfied that the phys_* are within RAM, and we can
> exclusively reserve the region.
I added printk in do_mounts_rd.c, in the first lines of rd_load_image().
I had to remove the "static" statement from phys_initrd_* declaration in init.c,
and added extern declarations to reach the phys_initrd_* variables.

> If we can't reserve the region, that means something's overwritten it
> during kernel boot and it's become unusable.
When you say "overwritten", what is the criteria ? (ie. is it at least one byte
is non-zero, checksum failed, ...).

Or alternatively, is there a clever way of storing some data relative to
reserve_bootmem_node() or __reserve() to be printed at the tail of kernel log
(ie. in do_mounts_rd()) which would help me investigate ?

Cheers.

--
Robert

  parent reply	other threads:[~2010-05-22  9:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-21 20:27 Initrd and 2.6.33 curious behaviour Robert Jarzmik
2010-05-21 20:43 ` Russell King - ARM Linux
2010-05-22  9:36   ` Robert Jarzmik
2010-05-22  9:37   ` Robert Jarzmik [this message]
2010-05-22  9:46     ` Russell King - ARM Linux
2010-05-23  0:23       ` Robert Jarzmik
2010-05-23  9:01         ` Russell King - ARM Linux
2010-05-23 10:09           ` Robert Jarzmik
2010-05-24 19:22             ` Robert Jarzmik
2010-05-27 12:00             ` Robert Jarzmik

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=87fx1k46qg.fsf@free.fr \
    --to=robert.jarzmik@free$(echo .)fr \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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