SUPERH platform development
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@kernel.org>
To: linux-sh@vger.kernel.org
Subject: Re: stable boot: 93 boots: 92 pass, 1 fail (v3.17.6)
Date: Mon, 08 Dec 2014 16:45:00 +0000	[thread overview]
Message-ID: <7htx16um43.fsf@deeprootsystems.com> (raw)
In-Reply-To: <2553650.3KSUKtTdo3@wuerfel>

Arnd Bergmann <arnd@arndb.de> writes:

> On Monday 08 December 2014 14:48:20 Geert Uytterhoeven wrote:
>> On Mon, Dec 8, 2014 at 12:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Sunday 07 December 2014 21:49:05 Kevin's boot bot wrote:
>> >> Full Build report: http://status.armcloud.us/build/stable/kernel/v3.17.6/
>> >> Full Boot report:  http://status.armcloud.us/boot/all/job/stable/kernel/v3.17.6/
>> >>
>> >> Tree/Branch: stable
>> >> Git describe: v3.17.6
>> >>
>> >> Failed boot tests
>> >> ========>> >>                      emev2-kzm9d:     FAIL:    arm-shmobile_defconfig
>> >>                                       http://storage.armcloud.us/kernel-ci/stable/v3.17.6/arm-shmobile_defconfig/boot-emev2-kzm9d.html
>> >>
>> >
>> > I tried to look at the reports, but the links don't work. Going
>> > back in the archive, I see that it was still working until v3.17.2,
>> > broken in v3.17.4/.5/.6 and the boot report for v3.17.3 seemed to run
>> > into an unrelated issue. Mainline was always fine since 3.17, only
>> > the stable kernels had problems:
>> >
>> > http://storage.armcloud.us/kernel-ci/stable/v3.17.2/arm-shmobile_defconfig/boot-emev2-kzm9d.html
>> > http://storage.armcloud.us/kernel-ci/stable/v3.17.3/arm-shmobile_defconfig/boot-emev2-kzm9d.html
>> > http://storage.armcloud.us/kernel-ci/stable/v3.17.4/arm-shmobile_defconfig/boot-emev2-kzm9d.html
>> >
>> > It may be worth having the sh team investigate the problem some more,
>> > to see if a bad patch made it into stable kernels.
>> 
>> Thanks for telling us!
>> 
>> I don't have a kzm9d, so I'm just guessing based on the evidence.
>> 
>> 1. When comparing successful v3.1.72 with failed v3.17.4, I see:
>> 
>>  Sending DHCP requests ., OK
>> -IP-Config: Got DHCP answer from 192.168.1.3, my address is 192.168.1.189
>> +IP-Config: Got DHCP answer from 192.168.1.254, my address is 192.168.1.188
>>  IP-Config: Complete:
>> -     device=eth0, hwaddr\0:01:9b:04:03:cd, ipaddr\x192.168.1.189,
>> mask%5.255.255.0, gw\x192.168.1.254
>> -     host=kzm9d, domain=lan, nis-domain=(none)
>> -     bootserver\x192.168.1.2, rootserver\x192.168.1.2,
>> rootpath=/opt/kjh/rootfs/debian/armel,rsize@96,wsize@96
>> -     nameserver0\x192.168.1.254, nameserver1f.93.87.2,
>> nameserver2!6.231.41.2
>> +     device=eth0, hwaddr\0:01:9b:04:03:cd, ipaddr\x192.168.1.188,
>> mask%5.255.255.0, gw\x192.168.1.254
>> +     host\x192.168.1.188, domain=lan, nis-domain=(none)
>> +     bootserver\x192.168.1.254, rootserver\x192.168.1.254, rootpath>> +     nameserver0\x192.168.1.254
>>  ALSA device list:
>>    No soundcards found.
>> 
>> So both the client and server IP addresses have changed. Is there a proper NFS
>> root file system available? Mounting of NFS root will time out, but the boot
>> farm management software may time out earlier, so we don't get to see the
>> panic message?
>
> The 3.18-rc7 boot got these:
>
> IP-Config: Got DHCP answer from 192.168.1.254, my address is 192.168.1.185
> IP-Config: Complete:
>      device=eth0, hwaddr\0:01:9b:04:03:cd, ipaddr\x192.168.1.185, mask%5.255.255.0, gw\x192.168.1.254
>      host\x192.168.1.185, domain=lan, nis-domain=(none)
>      bootserver\x192.168.1.254, rootserver\x192.168.1.254, rootpath>      nameserver0\x192.168.1.254
>
> So it's the same server as the failing config, and yet another client
> address. I'd say it's unlikely to be related.

I figured it out.

The problem is that my DHCP is no longer giving out a default root-path,
and I neglected to update the commandline for this board.  I'd forgotten
that the shmobile_defconfig doesn't have initrd support in v3.17, so it
can't boot from a ramdisk like all my other boards.

Geert, Simon, any objections to enabling initrd support in v3.17 stable?
Probably just asking Greg to cherry-pick mainline commit which does
this[1] should suffice.

Kevin

[1]
commit 874ee23c83d888f8824305c277e047c7799f30b9
Author: Kevin Hilman <khilman@linaro.org>
Date:   Wed Aug 13 17:07:15 2014 -0700

    ARM: shmobile: defconfig: enable initrd

    Enable initrd support.

    Signed-off-by: Kevin Hilman <khilman@linaro.org>
    [horms+renesas@verge.net.au: dropped enabling atag dtb compat]
    Signed-off-by: Simon Horman <horms+renesas@verge.net.au>2H


  parent reply	other threads:[~2014-12-08 16:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-08 11:35 stable boot: 93 boots: 92 pass, 1 fail (v3.17.6) Arnd Bergmann
2014-12-08 13:48 ` Geert Uytterhoeven
2014-12-08 15:39 ` Arnd Bergmann
2014-12-08 16:23 ` Tyler Baker
2014-12-08 16:45 ` Kevin Hilman [this message]
2014-12-08 17:03 ` Geert Uytterhoeven
2014-12-08 17:17 ` Kevin Hilman
2014-12-08 17:35 ` Kevin Hilman
2014-12-09  0:27 ` Simon Horman

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=7htx16um43.fsf@deeprootsystems.com \
    --to=khilman@kernel.org \
    --cc=linux-sh@vger.kernel.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