public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: arm-soc boot: 320 boots: 12 failed, 308 passed (v4.4-rc3-483-gb48b5ceb7227)
Date: Wed, 16 Dec 2015 23:09:36 +0100	[thread overview]
Message-ID: <1855103.nkkrE7bpzX@wuerfel> (raw)
In-Reply-To: <CANMBJr4h3JDJk6eufdirvy9fVxBGZUA4zu5e5mtfGdUF13qLwA@mail.gmail.com>

On Wednesday 16 December 2015 13:51:10 Tyler Baker wrote:
> On 16 December 2015 at 12:16, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday 16 December 2015 11:34:30 Tyler Baker wrote:
> >> > * bcm4708-smartrg-sr400ac doesn't find its rootfs any more
> >> >
> >> > [   16.670994] No filesystem could mount root, tried:  ext3 ext2 ext4 squashfs vfat msdos ntfs
> >> > [   16.679388] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
> >> >
> >> >   I merged some patches from Florian yesterday, but it could also be a problem with
> >> >   the defconfig changes
> >>
> >> The bisection pointed to b02ec7658c98 ("ARM: multi_v7_defconfig:
> >> Enable some drivers for LS1021A")
> >>
> >> I've rebased my tree with arm-soc for-next, and reverted the commits
> >> listed above. Should know shortly if the reverts fix the boot issues.
> >
> > I've looked at the built-in drivers to see if they might do something
> > on unrelated hardware (we've had bugs like that before), but didn't
> > find anything: the watchdog and cpufreq drivers all look sane, everything
> > else is a loadable module.
> >
> > One possible explanation would be a buggy bootloader that fails to pass
> > a correct initrd and/or dtb if the kernel image gets too big.
> >
> > Do you know if there is an initrd that is passed on this platform?
> 
> There is, and if I disable only CONFIG_BLK_DEV_RAM the
> bcm4708-smartrg-sr400ac boots again. This platform runs a CFE
> bootloader, and this is these are the kernel arguments injected into
> the DT - "console=ttyS0,115200 initrd=0x4000000,8M root=/dev/ram0
> ip=dhcp".

Ok, so it's probably the initrd= argument that causes the problem: as
long as CONFIG_BLK_DEV_INITRD was disabled, the code in arm_memblock_init
would ignore the initrd that gets passed by the bootloader and just
use the initramfs that is appended to the kernel.

There may also be some problem related to how the bootloader uses
a command line rather than the appropriate ATAG to pass the initrd
location.

	Arnd

      reply	other threads:[~2015-12-16 22:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <567128b4.46b71c0a.17f65.7531@mx.google.com>
2015-12-16 10:17 ` arm-soc boot: 320 boots: 12 failed, 308 passed (v4.4-rc3-483-gb48b5ceb7227) Arnd Bergmann
2015-12-16 11:12   ` Jon Medhurst (Tixy)
2015-12-16 13:15   ` Heiko Stübner
2015-12-16 19:34   ` Tyler Baker
2015-12-16 20:16     ` Arnd Bergmann
2015-12-16 21:51       ` Tyler Baker
2015-12-16 22:09         ` Arnd Bergmann [this message]

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=1855103.nkkrE7bpzX@wuerfel \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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