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/b... http://storage.armcloud.us/kernel-ci/stable/v3.17.3/arm-shmobile_defconfig/b... http://storage.armcloud.us/kernel-ci/stable/v3.17.4/arm-shmobile_defconfig/b...
It may be worth having the sh team investigate the problem some more, to see if a bad patch made it into stable kernels.
Arnd
Hi Arnd,
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/b... http://storage.armcloud.us/kernel-ci/stable/v3.17.3/arm-shmobile_defconfig/b... http://storage.armcloud.us/kernel-ci/stable/v3.17.4/arm-shmobile_defconfig/b...
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=00:01:9b:04:03:cd, ipaddr=192.168.1.189, mask=255.255.255.0, gw=192.168.1.254 - host=kzm9d, domain=lan, nis-domain=(none) - bootserver=192.168.1.2, rootserver=192.168.1.2, rootpath=/opt/kjh/rootfs/debian/armel,rsize=4096,wsize=4096 - nameserver0=192.168.1.254, nameserver1=66.93.87.2, nameserver2=216.231.41.2 + device=eth0, hwaddr=00:01:9b:04:03:cd, ipaddr=192.168.1.188, mask=255.255.255.0, gw=192.168.1.254 + host=192.168.1.188, domain=lan, nis-domain=(none) + bootserver=192.168.1.254, rootserver=192.168.1.254, rootpath= + nameserver0=192.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?
Could this be a configuration issue? Do you have more logs, e.g. from successful v3.18-rc* builds??
2. v3.17.4 has
commit a54857a74cf6724a872217477fa5827d6b9d26c8 Author: Enric Balletbo i Serra eballetbo@iseebcn.com Date: Thu Nov 13 09:14:34 2014 +0100
smsc911x: power-up phydev before doing a software reset.
[ Upstream commit ccf899a27c08038db91765ff12bb0380dcd85887 ]
Seems unlikely the above is the culprit, but please note that upstream does have a few more fixes in this area:
6ff53fd37175e35d net/smsc911x: Fix delays in the PHY enable/disable routines 242bcd5ba1dcea80 net/smsc911x: Fix rare soft reset timeout issue due to PHY power-down mode
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
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/b... http://storage.armcloud.us/kernel-ci/stable/v3.17.3/arm-shmobile_defconfig/b... http://storage.armcloud.us/kernel-ci/stable/v3.17.4/arm-shmobile_defconfig/b...
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.
- 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=00:01:9b:04:03:cd, ipaddr=192.168.1.189,
mask=255.255.255.0, gw=192.168.1.254
host=kzm9d, domain=lan, nis-domain=(none)
bootserver=192.168.1.2, rootserver=192.168.1.2,
rootpath=/opt/kjh/rootfs/debian/armel,rsize=4096,wsize=4096
nameserver0=192.168.1.254, nameserver1=66.93.87.2,
nameserver2=216.231.41.2
device=eth0, hwaddr=00:01:9b:04:03:cd, ipaddr=192.168.1.188,
mask=255.255.255.0, gw=192.168.1.254
host=192.168.1.188, domain=lan, nis-domain=(none)
bootserver=192.168.1.254, rootserver=192.168.1.254, rootpath=
nameserver0=192.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=00:01:9b:04:03:cd, ipaddr=192.168.1.185, mask=255.255.255.0, gw=192.168.1.254 host=192.168.1.185, domain=lan, nis-domain=(none) bootserver=192.168.1.254, rootserver=192.168.1.254, rootpath= nameserver0=192.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.
Could this be a configuration issue? Do you have more logs, e.g. from successful v3.18-rc* builds??
http://lists.linaro.org/pipermail/kernel-build-reports/2014-November/author.... has all the build reports from November, and you can navigate the archives to find other months.
See http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc7/arm-shmobile_defconf...
for another example of a successful log, or navigate the directories on that server for others.
- v3.17.4 has
commit a54857a74cf6724a872217477fa5827d6b9d26c8 Author: Enric Balletbo i Serra eballetbo@iseebcn.com Date: Thu Nov 13 09:14:34 2014 +0100
smsc911x: power-up phydev before doing a software reset. [ Upstream commit ccf899a27c08038db91765ff12bb0380dcd85887 ]
Seems unlikely the above is the culprit, but please note that upstream does have a few more fixes in this area:
6ff53fd37175e35d net/smsc911x: Fix delays in the PHY enable/disable routines 242bcd5ba1dcea80 net/smsc911x: Fix rare soft reset timeout issue due to PHY power-down mode
If you think it helps, we could try reverting this commit and have the boot farm try the latest 3.17.6 without this patch.
Arnd
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/b... http://storage.armcloud.us/kernel-ci/stable/v3.17.3/arm-shmobile_defconfig/b... http://storage.armcloud.us/kernel-ci/stable/v3.17.4/arm-shmobile_defconfig/b...
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.
- 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=00:01:9b:04:03:cd, ipaddr=192.168.1.189,
mask=255.255.255.0, gw=192.168.1.254
host=kzm9d, domain=lan, nis-domain=(none)
bootserver=192.168.1.2, rootserver=192.168.1.2,
rootpath=/opt/kjh/rootfs/debian/armel,rsize=4096,wsize=4096
nameserver0=192.168.1.254, nameserver1=66.93.87.2,
nameserver2=216.231.41.2
device=eth0, hwaddr=00:01:9b:04:03:cd, ipaddr=192.168.1.188,
mask=255.255.255.0, gw=192.168.1.254
host=192.168.1.188, domain=lan, nis-domain=(none)
bootserver=192.168.1.254, rootserver=192.168.1.254, rootpath=
nameserver0=192.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=00:01:9b:04:03:cd, ipaddr=192.168.1.185, mask=255.255.255.0, gw=192.168.1.254 host=192.168.1.185, domain=lan, nis-domain=(none) bootserver=192.168.1.254, rootserver=192.168.1.254, rootpath= nameserver0=192.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.au2H
Hi Kevin,
On Mon, Dec 8, 2014 at 5:45 PM, Kevin Hilman khilman@kernel.org wrote:
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 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.
Good to hear that!
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.
Personally, I have no objections. It's just stretching stable-kernel-rules a little bit ;-)
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
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Geert Uytterhoeven geert@linux-m68k.org writes:
Hi Kevin,
On Mon, Dec 8, 2014 at 5:45 PM, Kevin Hilman khilman@kernel.org wrote:
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 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.
Good to hear that!
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.
Personally, I have no objections. It's just stretching stable-kernel-rules a little bit ;-)
Yeah, but since it's just defconfig, and very platform specific, I think Greg would accept it if it's coming from the platform maintainer. So I guess it's up to Simon to decide.
Kevin
P.S. I reran the v3.17.6 stable tree for this board, and the reports and boot logs reflect the working state
http://status.armcloud.us/boot/emev2-kzm9d/job/stable/kernel/v3.17.6/defconf...
Kevin
On Mon, Dec 8, 2014 at 9:17 AM, Kevin Hilman khilman@kernel.org wrote:
Geert Uytterhoeven geert@linux-m68k.org writes:
Hi Kevin,
On Mon, Dec 8, 2014 at 5:45 PM, Kevin Hilman khilman@kernel.org wrote:
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/b...
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.
Good to hear that!
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.
Personally, I have no objections. It's just stretching stable-kernel-rules a little bit ;-)
Yeah, but since it's just defconfig, and very platform specific, I think Greg would accept it if it's coming from the platform maintainer. So I guess it's up to Simon to decide.
FWIW, Just to be sure, I double-checked and verified that cherry-picking that shmobile_defconfig patch from mainline gets ramdisk booting working again on v3.17.y stable.
Kevin
On Mon, Dec 08, 2014 at 09:35:49AM -0800, Kevin Hilman wrote:
On Mon, Dec 8, 2014 at 9:17 AM, Kevin Hilman khilman@kernel.org wrote:
Geert Uytterhoeven geert@linux-m68k.org writes:
Hi Kevin,
On Mon, Dec 8, 2014 at 5:45 PM, Kevin Hilman khilman@kernel.org wrote:
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/b...
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.
Good to hear that!
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.
Personally, I have no objections. It's just stretching stable-kernel-rules a little bit ;-)
Yeah, but since it's just defconfig, and very platform specific, I think Greg would accept it if it's coming from the platform maintainer. So I guess it's up to Simon to decide.
FWIW, Just to be sure, I double-checked and verified that cherry-picking that shmobile_defconfig patch from mainline gets ramdisk booting working again on v3.17.y stable.
Personally I am not entirely convinced that the change really is stable material. However, if you feel strongly about it I would be happy for you to submit it to stable: I'll Ack it if you do so.
On 8 December 2014 at 03:35, 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
Apologies, a fix for this issue is being pushed now.
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/b... http://storage.armcloud.us/kernel-ci/stable/v3.17.3/arm-shmobile_defconfig/b... http://storage.armcloud.us/kernel-ci/stable/v3.17.4/arm-shmobile_defconfig/b...
It may be worth having the sh team investigate the problem some more, to see if a bad patch made it into stable kernels.
Arnd
Kernel-build-reports mailing list Kernel-build-reports@lists.linaro.org http://lists.linaro.org/mailman/listinfo/kernel-build-reports
kernel-build-reports@lists.linaro.org