On Mon, Sep 30, 2013 at 11:09 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 09/30/2013 11:22 AM, Kevin Hilman wrote:
On Mon, Sep 30, 2013 at 10:12 AM, Kevin Hilman khilman@linaro.org wrote:
On Mon, Sep 30, 2013 at 8:31 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 09/29/2013 06:15 PM, Kevin Hilman build bot wrote:
Automated DT boot report for various ARM defconfigs.
Boot test simply checks if kernel can boot to initramfs with busybox and run some basic commands (e.g. 'cat /proc/cpuinfo').
arm-tegra_defconfig
...
[ 3.693969] Freeing unused kernel memory: 232K (c0742000 - c077c000) Starting logging: OK Initializing random number generator... done. Starting network... /bin/sh: can't access tty; job control turned off / # cat /proc/cmdline cat /proc/cmdline console=ttyS0,115200n8 debug earlyprintk / # uname -r uname -r 3.12.0-rc2-00245-g30ceb4e / # [ 3.993683] usb 1-1: new high-speed USB device number 2 using tegra-ehci [ 4.485573] asix 1-1:1.0 eth1: register 'asix' at usb-7d008000.usb-1, ASIX AX88772 USB 2.0 Ethernet, b8:8d:12:55:d1:b9 ~$off # PYBOOT: Exception: ERROR: Timeout waiting for command: uname -r.
This seems to be failing because dmesg output is confusing the code that's searching for the command output. Perhaps dmesg could be turned off immediately after login and/or the commands retried if they time out? That said, I do see the command prompt being printed right after uname executes, so I'm not sure why the scripts are getting confused.
Yeah, the prompt is definitely showing up.
I'm not sure why it's getting confused either, and seems to only happen on the jenkins triggered jobs, and not when I do launch the script manually. I'm still looking into it.
Ah, it's because when it looks for the prompt, it expects a '#' at the end of line, and with more messages on the console, that isn't happening. Your suggestion of turning of console output should fix that. I'll add a 'dmesg -n1' as the first thing to do at the shell (and I wont wait for a prompt on that one, so it shouldn't fail.)
The one risk with turning off dmesg is whether console messages are useful when diagnosing failures. I assume that oopses always show up no matter what though so perhaps it's not a big deal. Still, some other messages might be useful?
Perhaps. maybe just retrying the command is going to be more robust and provide more useful debug output.
Kevin