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.htmlI 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