Hi Joe,
On Tue, Dec 22, 2015 at 10:39 AM, Joe Hershberger
<joe.hershber...@gmail.com> wrote:
> On Mon, Dec 21, 2015 at 8:36 PM, Bin Meng <bmeng...@gmail.com> wrote:
>> Hi Joe,
>>
>> On Tue, Dec 22, 2015 at 10:32 AM, Joe Hershberger
>> <joe.hershber...@gmail.com> wrote:
>>> Hi Bin,
>>>
>>> On Mon, Dec 21, 2015 at 8:12 PM, Bin Meng <bmeng...@gmail.com> wrote:
>>>> Hi Joe, Simon,
>>>>
>>>> On Tue, Dec 22, 2015 at 6:46 AM, Joe Hershberger
>>>> <joe.hershber...@gmail.com> wrote:
>>>>> Hi Simon and Bin
>>>>>
>>>>> On Thu, Dec 10, 2015 at 8:05 PM, Simon Glass <s...@chromium.org> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> The following three commits causes breakages in the driver model tests:
>>>>>>
>>>>>> 4efad20a sf: Update status reg check in spi_flash_cmd_wait_ready
>>>>>> 45b47734 net/arp: account for ARP delay, avoid duplicate packets on
>>>>>> timeout
>>>>>> 9961a0b6 sandbox: add a sandbox timer and basic test
>>>>>>
>>>>>> Can you please take a look? You can run them with ./test/dm/test-dm.sh
>>>>>
>>>>> It appears that ac1d313 (net: eth: Check return value in various
>>>>> places) breaks the eth_rotate test.
>>>>>
>>>>> Looking into it. Bin, do you have any ideas?
>>>>
>>>> I will look into this.
>>>>
>>>> BTW: I applied the following two patches [1][2] to the tree based on
>>>> dm/master, and got a segmentation fault:
>>>>
>>>> Test: dm_test_usb_keyb
>>>> ./test/dm/test-dm.sh: line 14: 24902 Segmentation fault
>>>> ./sandbox/u-boot -d ./sandbox/arch/sandbox/dts/test.dtb -c "ut dm"
>>>>
>>>> [1] http://patchwork.ozlabs.org/patch/555597/
>>>> [2] http://patchwork.ozlabs.org/patch/559783/
>>>
>>> Interesting. I haven't tested on top of dm/master, but I tested it
>>> based on origin/master and the issue is resolved.
>>>
>>
>> Which issue is resolved? I just tested on top of origin/master with
>> the above two patches, still the same segmentation fault.
>
> The net_retry dm test hang that Simon reported.
>
The segmentation fault happens after "Test: dm_test_usb_keyb". It
seems to be a new issue.
I am looking into _dm_test_eth_rotate1 failure, but I don't understand
the comments here.
/* If ethrotate is no, then we should fail on a bad MAC */
setenv("ethact", "eth@10004000");
setenv("ethrotate", "no");
ut_asserteq(-EINVAL, net_loop(PING));
ut_asserteq_str("eth@10004000", getenv("ethact"));
Does 'bad MAC' mean no MAC address? For eth@10004000, it does have a
MAC address defined in the env variable in sandbox.h.
I also tested manually with the same test sequence from U-Boot shell,
it can pass. I am still looking into it.
=> setenv ethact eth@10004000;setenv ethrotate no;ping 1.1.1.1
Using eth@10004000 device
host 1.1.1.1 is alive
=> printenv ethact
ethact=eth@10004000
Regards,
Bin
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
