[U-Boot] Travis test/py sandbox_spl test fail

Kever Yang kever.yang at rock-chips.com
Tue Aug 20 02:53:12 UTC 2019


Hi Stephen,

On 2019/8/20 上午1:34, Stephen Warren wrote:
> On 8/18/19 7:01 PM, Kever Yang wrote:
>> Hi Simon, Stephen,
>>
>>      Could you help to comment on my other mail, which patch cause 
>> this failure.
>
> If you run "git bisect", you should be able to track down which patch 
> introduced the problem.


I already locate the patch,  and it seems some but in sandbox_spl or 
test, but not the driver,

see below:

https://patchwork.ozlabs.org/patch/1100742/

Thanks,

- Kever

>
>>
>>
>> Thanks,
>>
>> - Kever
>>
>> On 2019/8/14 下午11:49, Stephen Warren wrote:
>>> On 8/13/19 8:06 PM, Kever Yang wrote:
>>>> Hi Stephen,
>>>>
>>>> On 2019/8/14 上午4:54, Stephen Warren wrote:
>>>>> On 8/13/19 3:39 AM, Simon Glass wrote:
>>>>>> +Stephen
>>>>>>
>>>>>> Hi Kever,
>>>>>>
>>>>>> On Tue, 13 Aug 2019 at 03:35, Kever Yang 
>>>>>> <kever.yang at rock-chips.com> wrote:
>>>>>>>
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>>      I got fail in test/py sandbox_spl, and the log says:
>>>>>>>
>>>>>>> E OSError: [Errno 5] Input/output error
>>>>>>>
>>>>>>> I have no idea about what's wrong in source code, could you help
>>>>>>>
>>>>>>> to take a look?
>>>>>>>
>>>>>>> Travis job:
>>>>>>>
>>>>>>> https://travis-ci.org/keveryang/u-boot/jobs/571125119
>>>>>>
>>>>>> When I've seen this (ugly) error it is normally because U-Boot
>>>>>> crashed, e.g. with a segfault.
>>>>>
>>>>> Yes, that's the typical reason. If you run test.py locally you'll 
>>>>> be able to access the log file (which Travis doesn't save), which 
>>>>> will likely give you more details about the crash, and/or you 
>>>>> could attach gdb to the sandbox process to trap the problem too.
>>>>
>>>> I got:
>>>>
>>>> $ ./u-boot
>>>> bloblist_init() Existing bloblist not found: creating new bloblist
>>>> [1]    958 segmentation fault (core dumped)  ./u-boot
>>>>
>>>> And no more logs, is there any other log file I can check?
>>>
>>> There probably isn't any more log information beyond that. I think 
>>> the next step would be to run U-Boot sandbox under gdb, reproduce 
>>> the problem, and then debug it.
>>
>>
>
>




More information about the U-Boot mailing list