
Hi Joe,
On 21 April 2015 at 14:10, Joe Hershberger joe.hershberger@gmail.com wrote:
Hi Simon,
On Tue, Apr 21, 2015 at 12:00 PM, Simon Glass sjg@chromium.org wrote:
Hi Joe,
On 21 April 2015 at 10:57, Joe Hershberger joe.hershberger@gmail.com wrote:
Hi Simon,
On Tue, Apr 21, 2015 at 11:19 AM, Simon Glass sjg@chromium.org wrote:
Hi Joe,
On 21 April 2015 at 10:05, Joe Hershberger joe.hershberger@gmail.com wrote:
Hi Simon,
On Tue, Apr 21, 2015 at 8:14 AM, Simon Glass sjg@chromium.org wrote:
Hi Joe,
On 20 April 2015 at 23:24, Joe Hershberger joe.hershberger@gmail.com wrote: > Hi Simon, > > On Wed, Mar 25, 2015 at 1:23 PM, Simon Glass sjg@chromium.org wrote: >> This adds a simple test for probing and a functional test using the flash >> stick emulator, which tests a large chunk of the USB stack. >> >> Signed-off-by: Simon Glass sjg@chromium.org > > I'm seeing a seg fault when running the dm tests and bisected it to this patch. > > I'm not sure why it's related, but it appears to seg fault on a GPIO test...
<--snip-->
> Thoughts?
Yes it is broken. I sent a series to fix this recent ('dm: core: Fix up test failures') starting with this patch:
http://patchwork.ozlabs.org/patch/462556/
If you are able to test it that would be good.
I tested the series, but I still have a USB test failure...
""" Test: dm_test_usb_flash USB-1: scanning bus 1 for devices... 2 USB Device(s) found /home/joe/u-boot/test/dm/usb.c:45, dm_test_usb_flash(): 2 == dev_desc->block_read(dev_desc->dev, 0, 2, cmp): Expected 2, got 0 """
Have you seen that one?
No I don't see that. It is saying that it was not able to read 2 512-byte blocks from the testflash.bin file. It should be created by the test script. I just tried it again.
That makes sense... I wasn't creating that file. D'oh! Working for me now too.
BTW I'd like to get a sandbox network device that works in a purely emulated way (i.e. without any reference to real hardware). Then we could use it for ping tests, etc. and they would run instantly. At present the network tests are quite slow. What do you think?
The tests are all using fully emulated Ethernet... the issue is that the ping test ensures that on timeout an error is returned. Even though it is an emulated MAC, the timeout in the network stack is still there.
I'll work on a patch that adds a way to change the ping timeout to make this faster.
OK thanks for explaining this. Rather than changing the ping timeout, can you look at changing the time? With sandbox it should be possible to adjust the time so that timeouts appear to happen instantly. The arch/sandbox/include/test.h file has some test functions used by various parts of the stack.
I posted a series that handles the issue as you recommended and called it "test: Speed up test timeouts by advancing time".
I see it. This is great, thank you!
I now notice that the only test that takes any time is the USB Flash test.
""" Test: dm_test_usb_flash USB-1: scanning bus 1 for devices... 2 USB Device(s) found """
It takes about 3 seconds. Is that a timeout too?
Yes. I'll take a look at how you have advanced time - we should do this for USB too.
Regards, Simon