Hi Joe,
On 21 April 2015 at 14:10, Joe Hershberger <joe.hershber...@gmail.com> wrote:
> Hi Simon,
>
> On Tue, Apr 21, 2015 at 12:00 PM, Simon Glass <s...@chromium.org> wrote:
>> Hi Joe,
>>
>> On 21 April 2015 at 10:57, Joe Hershberger <joe.hershber...@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Tue, Apr 21, 2015 at 11:19 AM, Simon Glass <s...@chromium.org> wrote:
>>>> Hi Joe,
>>>>
>>>> On 21 April 2015 at 10:05, Joe Hershberger <joe.hershber...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi Simon,
>>>>>
>>>>> On Tue, Apr 21, 2015 at 8:14 AM, Simon Glass <s...@chromium.org> wrote:
>>>>> > Hi Joe,
>>>>> >
>>>>> > On 20 April 2015 at 23:24, Joe Hershberger <joe.hershber...@gmail.com>
>>>>> > wrote:
>>>>> >> Hi Simon,
>>>>> >>
>>>>> >> On Wed, Mar 25, 2015 at 1:23 PM, Simon Glass <s...@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 <s...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
