From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Tue, 16 Aug 2016 07:19:44 +0200 Subject: [U-Boot] test.py and tftp crc32 test? In-Reply-To: <6b0db8bd-72b4-bd48-eeac-3a06992b8fd1@wwwdotorg.org> References: <20160815224940.GC5342@bill-the-cat> <4b004b3c-b448-eb15-e44f-f7e82a136600@wwwdotorg.org> <20160815232000.GD5342@bill-the-cat> <6b0db8bd-72b4-bd48-eeac-3a06992b8fd1@wwwdotorg.org> Message-ID: <57B2A270.2030300@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Stephen, Am 16.08.2016 um 05:35 schrieb Stephen Warren: > On 08/15/2016 05:20 PM, Tom Rini wrote: >> On Mon, Aug 15, 2016 at 04:59:02PM -0600, Stephen Warren wrote: >>> On 08/15/2016 04:49 PM, Tom Rini wrote: >>>> Hey guys, >>>> >>>> Is anyone else running the crc32 tftp tests with test.py? I'm trying to >>>> do it locally but even with a 2MiB file it looks like somehow the crc32 >>>> is never captured in the output. I've already made sure that the crc32 >>>> value is in lowercase to match the U-Boot output and running the test >>>> steps in console gives me the expected output. And the rest of the >>>> network tests pass, any ideas? Thanks! >>> >>> I'm not certain that anyone other than myself is running test.py on >>> real HW (vs. sandbox where it's trivial). >>> >>> If you look at test-log.html it should show what U-Boot outputs on >>> the console, and where any error was detected in the test. >>> Alternativeluy, add "-s" to the invocation and U-Boot output should >>> show up on stdout while the tests are running. What's the error >>> reported there; just a timeout waiting for the CRC? Here's an >>> example of what test_net_tftpboot looks like for me: >>> >>>> Tegra210 (P2371-2180) # tftpboot 80000000 ubtest-readable.bin >>>> Using eth_rtl8169 device >>>> TFTP from server 10.20.204.51; our IP address is 10.20.204.52 >>>> Filename 'ubtest-readable.bin'. >>>> Load address: 0x80000000 >>>> Loading: *%08################################################################# >>>> ################################################################# >>>> ################################################################# >>>> ################################################################# >>>> ################################################################# >>>> #################### >>>> 2.9 MiB/s >>>> done >>>> Bytes transferred = 5058624 (4d3040 hex) >>>> Tegra210 (P2371-2180) # crc32 80000000 $filesize >>>> crc32 for 80000000 ... 804d303f ==> c2244b26 >>>> Tegra210 (P2371-2180) # >>> >>> In the past, I have seen tests pass when run manually but not under >>> test.py, e.g. due to heap fragmentation, state, or corrupted memory >>> due to earlier tests, which weren't run in the manual case. Might >>> that be the issue? >> >> Adding in -s this is part of what I see: >> >> => .s=> ping $serverip >> Waiting for Ethernet connection... done. >> Using sms0 device >> host 192.168.0.3 is alive >> => .=> tftpboot 80000000 1MiBtest.bin >> Waiting for Ethernet connection... done. >> Using sms0 device >> TFTP from server 192.168.0.3; our IP address is 192.168.0.140 >> Filename '1MiBtest.bin'. >> Load address: 0x80000000 >> Loading: ################################################################# >> ################################################################# >> ################################################################# >> ########## >> 171.9 KiB/s >> done >> Bytes transferred = 1048576 (100000 hex) >> => crc32 80000000 $filesize >> CRC32 for 80000000 ... 800fffff ==> F2fa737e0 >> => >> >> For some reason there's an extra 'F' at the start of the crc32 output. >> Looking at it in the html file, it looks all correct there. In the >> output from test.py the captured stdout end just before the CRC32 value >> would be. I've tried larger test binaries and get the same output so >> I'd assume if there was some heap corruption or similar, I'd not tickle >> it with bigger files too (2MiB, 4MiB and I think even 8MiB are small >> enough to be downloaded in the time the test allows). Thanks! > > The "F" is coming from the test infrastructure, not U-Boot's output. A character is printed per > test, such as "." for pass, "s" for skip, and "F" for fail. For some reason, the test is seeing a > failure before it's read the output from the crc32 command. > > Ah, I see the issue now: the command prompt (=>) in use is part of the output from the crc32 > command, so the test infra-structure thinks the ==> printed by crc32 is the end of the crc32 output. > Perhaps test.py should look for "[\r\n]${prompt}" rather than "${prompt}", or this board could have > a prompt that's slightly less likely to trigger false matches. Argh, yes, I had the same problem and added an "ignore list" to tbot, see: https://github.com/hsdenx/tbot/blob/master/src/common/tbot_connection_paramiko.py#L39 bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany