[U-Boot] Travis test/py sandbox_spl test fail
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
Thanks,
- Kever
+Stephen
Hi Kever,
On Tue, 13 Aug 2019 at 03:35, Kever Yang kever.yang@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:
When I've seen this (ugly) error it is normally because U-Boot crashed, e.g. with a segfault.
It is maybe possible that a unicode character is being split over a 1024-byte boundary. I had to fix that behaviour in buildman (using binary files and the 'bytes' type).
Regards, Simon
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@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:
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.
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@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:
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?
Thanks,
- Kever
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@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:
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.
Hi Simon, Stephen,
Could you help to comment on my other mail, which patch cause this failure.
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@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:
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.
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.
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@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:
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.
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@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.
Hi Kever,
On Mon, 19 Aug 2019 at 19:53, Kever Yang kever.yang@rock-chips.com wrote:
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 causethis 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:
Here's what I found:
$ gdb --args /tmp/b/sandbox_spl/u-boot -D GNU gdb (Debian 8.1-4+build1) 8.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /tmp/b/sandbox_spl/u-boot...done. (gdb) r Starting program: /tmp/b/sandbox_spl/u-boot -D [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". bloblist_init() Existing bloblist not found: creating new bloblist
Program received signal SIGSEGV, Segmentation fault. 0x0000555555617db5 in strcmp (cs=cs@entry=0x5555556602cf "root_driver", ct=0x1 <error: Cannot access memory at address 0x1>) at /home/sjg/c/src/third_party/u-boot/files/lib/string.c:190 190 if ((__res = *cs - *ct++) != 0 || !*cs++) (gdb) up #1 0x00005555555a9f91 in lists_driver_lookup_name (name=0x5555556602cf "root_driver") at /home/sjg/c/src/third_party/u-boot/files/drivers/core/lists.c:28 28 if (!strcmp(name, entry->name)) (gdb) print entry->name $1 = 0x0 (gdb) print *entry $2 = {name = 0x0, id = UCLASS_ROOT, of_match = 0x0, bind = 0x55555569b660, probe = 0x3e, remove = 0x5555556fd1e0 <rk8xx_ids>, unbind = 0x5555555d0ad6 <rk8xx_bind>, ofdata_to_platdata = 0x5555555d0a77 <rk8xx_probe>, child_post_bind = 0x0, child_pre_probe = 0x0, child_post_remove = 0x0, priv_auto_alloc_size = 0, platdata_auto_alloc_size = 0, per_child_auto_alloc_size = 0, per_child_platdata_auto_alloc_size = 0, ops = 0x0, flags = 4}
Here you have a rockchip driver in UCLASS_ROOT with no name.
The symbol is _u_boot_list_2_driver_2_pmic_rk8xx so perhaps it is getting corrupted?
(gdb) where #0 0x0000555555617db5 in strcmp (cs=cs@entry=0x5555556602cf "root_driver", ct=0x1 <error: Cannot access memory at address 0x1>) at /home/sjg/c/src/third_party/u-boot/files/lib/string.c:190 #1 0x00005555555a9f91 in lists_driver_lookup_name (name=0x5555556602cf "root_driver") at /home/sjg/c/src/third_party/u-boot/files/drivers/core/lists.c:28 #2 0x00005555555a9561 in device_bind_by_name (parent=parent@entry=0x0, pre_reloc_only=pre_reloc_only@entry=false, info=info@entry=0x5555556fa560 <root_info>, devp=0x7fffffffdd08) at /home/sjg/c/src/third_party/u-boot/files/drivers/core/device.c:250 #3 0x00005555555aa423 in dm_init (of_live=<optimized out>) at /home/sjg/c/src/third_party/u-boot/files/drivers/core/root.c:148 #4 0x00005555555aa558 in dm_init_and_scan (pre_reloc_only=pre_reloc_only@entry=true) at /home/sjg/c/src/third_party/u-boot/files/drivers/core/root.c:373 #5 0x000055555559381a in initf_dm () at /home/sjg/c/src/third_party/u-boot/files/common/board_f.c:807 #6 0x000055555559395a in initcall_run_list (init_sequence=0x5555556fe840 <init_sequence_f>) at /home/sjg/c/src/third_party/u-boot/files/include/initcall.h:38 #7 board_init_f (boot_flags=<optimized out>) at /home/sjg/c/src/third_party/u-boot/files/common/board_f.c:986 #8 0x00005555555774d6 in main (argc=2, argv=0x7fffffffdf58) at /home/sjg/c/src/third_party/u-boot/files/arch/sandbox/cpu/start.c:360 (gdb) q
Regards, Simon
On 2019/8/24 下午12:19, Simon Glass wrote:
Hi Kever,
On Mon, 19 Aug 2019 at 19:53, Kever Yang kever.yang@rock-chips.com wrote:
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 causethis 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:
Here's what I found:
$ gdb --args /tmp/b/sandbox_spl/u-boot -D GNU gdb (Debian 8.1-4+build1) 8.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /tmp/b/sandbox_spl/u-boot...done. (gdb) r Starting program: /tmp/b/sandbox_spl/u-boot -D [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". bloblist_init() Existing bloblist not found: creating new bloblist
Program received signal SIGSEGV, Segmentation fault. 0x0000555555617db5 in strcmp (cs=cs@entry=0x5555556602cf "root_driver", ct=0x1 <error: Cannot access memory at address 0x1>) at /home/sjg/c/src/third_party/u-boot/files/lib/string.c:190 190 if ((__res = *cs - *ct++) != 0 || !*cs++) (gdb) up #1 0x00005555555a9f91 in lists_driver_lookup_name (name=0x5555556602cf "root_driver") at /home/sjg/c/src/third_party/u-boot/files/drivers/core/lists.c:28 28 if (!strcmp(name, entry->name)) (gdb) print entry->name $1 = 0x0 (gdb) print *entry $2 = {name = 0x0, id = UCLASS_ROOT, of_match = 0x0, bind = 0x55555569b660, probe = 0x3e, remove = 0x5555556fd1e0 <rk8xx_ids>, unbind = 0x5555555d0ad6 <rk8xx_bind>, ofdata_to_platdata = 0x5555555d0a77 <rk8xx_probe>, child_post_bind = 0x0, child_pre_probe = 0x0, child_post_remove = 0x0, priv_auto_alloc_size = 0, platdata_auto_alloc_size = 0, per_child_auto_alloc_size = 0, per_child_platdata_auto_alloc_size = 0, ops = 0x0, flags = 4}
Here you have a rockchip driver in UCLASS_ROOT with no name.
The symbol is _u_boot_list_2_driver_2_pmic_rk8xx so perhaps it is getting corrupted?
But I don't understand how this corrupt happen, does this area should be RO data? When I compare the good case and error case, I got below difference, the 'fill' data only present at error case, does it suppose to be there?
.u_boot_list_2_driver_2_pmic_pm8916 0x00000000003b14f0 0x78 drivers/power/pmic/built-in.o 0x00000000003b14f0 _u_boot_list_2_driver_2_pmic_pm8916 *fill* 0x00000000003b1568 0x18 .u_boot_list_2_driver_2_pmic_rk8xx 0x00000000003b1580 0x78 drivers/power/pmic/built-in.o 0x00000000003b1580 _u_boot_list_2_driver_2_pmic_rk8xx
Thanks, - Kever
(gdb) where #0 0x0000555555617db5 in strcmp (cs=cs@entry=0x5555556602cf "root_driver", ct=0x1 <error: Cannot access memory at address 0x1>) at /home/sjg/c/src/third_party/u-boot/files/lib/string.c:190 #1 0x00005555555a9f91 in lists_driver_lookup_name (name=0x5555556602cf "root_driver") at /home/sjg/c/src/third_party/u-boot/files/drivers/core/lists.c:28 #2 0x00005555555a9561 in device_bind_by_name (parent=parent@entry=0x0, pre_reloc_only=pre_reloc_only@entry=false, info=info@entry=0x5555556fa560 <root_info>, devp=0x7fffffffdd08) at /home/sjg/c/src/third_party/u-boot/files/drivers/core/device.c:250 #3 0x00005555555aa423 in dm_init (of_live=<optimized out>) at /home/sjg/c/src/third_party/u-boot/files/drivers/core/root.c:148 #4 0x00005555555aa558 in dm_init_and_scan (pre_reloc_only=pre_reloc_only@entry=true) at /home/sjg/c/src/third_party/u-boot/files/drivers/core/root.c:373 #5 0x000055555559381a in initf_dm () at /home/sjg/c/src/third_party/u-boot/files/common/board_f.c:807 #6 0x000055555559395a in initcall_run_list (init_sequence=0x5555556fe840 <init_sequence_f>) at /home/sjg/c/src/third_party/u-boot/files/include/initcall.h:38 #7 board_init_f (boot_flags=<optimized out>) at /home/sjg/c/src/third_party/u-boot/files/common/board_f.c:986 #8 0x00005555555774d6 in main (argc=2, argv=0x7fffffffdf58) at /home/sjg/c/src/third_party/u-boot/files/arch/sandbox/cpu/start.c:360 (gdb) q
Regards, Simon
Hi Kever,
On Thu, 29 Aug 2019 at 02:27, Kever Yang kever.yang@rock-chips.com wrote:
On 2019/8/24 下午12:19, Simon Glass wrote:
Hi Kever,
On Mon, 19 Aug 2019 at 19:53, Kever Yang kever.yang@rock-chips.com wrote:
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 causethis 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/
Here's what I found:
$ gdb --args /tmp/b/sandbox_spl/u-boot -D GNU gdb (Debian 8.1-4+build1) 8.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /tmp/b/sandbox_spl/u-boot...done. (gdb) r Starting program: /tmp/b/sandbox_spl/u-boot -D [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". bloblist_init() Existing bloblist not found: creating new bloblist
Program received signal SIGSEGV, Segmentation fault. 0x0000555555617db5 in strcmp (cs=cs@entry=0x5555556602cf "root_driver", ct=0x1 <error: Cannot access memory at address 0x1>) at /home/sjg/c/src/third_party/u-boot/files/lib/string.c:190 190 if ((__res = *cs - *ct++) != 0 || !*cs++) (gdb) up #1 0x00005555555a9f91 in lists_driver_lookup_name (name=0x5555556602cf "root_driver") at /home/sjg/c/src/third_party/u-boot/files/drivers/core/lists.c:28 28 if (!strcmp(name, entry->name)) (gdb) print entry->name $1 = 0x0 (gdb) print *entry $2 = {name = 0x0, id = UCLASS_ROOT, of_match = 0x0, bind = 0x55555569b660, probe = 0x3e, remove = 0x5555556fd1e0 <rk8xx_ids>, unbind = 0x5555555d0ad6 <rk8xx_bind>, ofdata_to_platdata = 0x5555555d0a77 <rk8xx_probe>, child_post_bind = 0x0, child_pre_probe = 0x0, child_post_remove = 0x0, priv_auto_alloc_size = 0, platdata_auto_alloc_size = 0, per_child_auto_alloc_size = 0, per_child_platdata_auto_alloc_size = 0, ops = 0x0, flags = 4}
Here you have a rockchip driver in UCLASS_ROOT with no name.
The symbol is _u_boot_list_2_driver_2_pmic_rk8xx so perhaps it is getting corrupted?
But I don't understand how this corrupt happen, does this area should be RO data? When I compare the good case and error case, I got below difference, the 'fill' data only present at error case, does it suppose to be there?
.u_boot_list_2_driver_2_pmic_pm8916 0x00000000003b14f0 0x78 drivers/power/pmic/built-in.o 0x00000000003b14f0 _u_boot_list_2_driver_2_pmic_pm8916 *fill* 0x00000000003b1568 0x18 .u_boot_list_2_driver_2_pmic_rk8xx 0x00000000003b1580 0x78 drivers/power/pmic/built-in.o 0x00000000003b1580 _u_boot_list_2_driver_2_pmic_rk8xx
Thanks,
- Kever
I don't understand it either.
It should be possible to see it by setting a watchpoint on an address that is getting corrupted.
I haven't made time to look at this further.
Regards, Simon
(gdb) where #0 0x0000555555617db5 in strcmp (cs=cs@entry=0x5555556602cf "root_driver", ct=0x1 <error: Cannot access memory at address 0x1>) at /home/sjg/c/src/third_party/u-boot/files/lib/string.c:190 #1 0x00005555555a9f91 in lists_driver_lookup_name (name=0x5555556602cf "root_driver") at /home/sjg/c/src/third_party/u-boot/files/drivers/core/lists.c:28 #2 0x00005555555a9561 in device_bind_by_name (parent=parent@entry=0x0, pre_reloc_only=pre_reloc_only@entry=false, info=info@entry=0x5555556fa560 <root_info>, devp=0x7fffffffdd08) at /home/sjg/c/src/third_party/u-boot/files/drivers/core/device.c:250 #3 0x00005555555aa423 in dm_init (of_live=<optimized out>) at /home/sjg/c/src/third_party/u-boot/files/drivers/core/root.c:148 #4 0x00005555555aa558 in dm_init_and_scan (pre_reloc_only=pre_reloc_only@entry=true) at /home/sjg/c/src/third_party/u-boot/files/drivers/core/root.c:373 #5 0x000055555559381a in initf_dm () at /home/sjg/c/src/third_party/u-boot/files/common/board_f.c:807 #6 0x000055555559395a in initcall_run_list (init_sequence=0x5555556fe840 <init_sequence_f>) at /home/sjg/c/src/third_party/u-boot/files/include/initcall.h:38 #7 board_init_f (boot_flags=<optimized out>) at /home/sjg/c/src/third_party/u-boot/files/common/board_f.c:986 #8 0x00005555555774d6 in main (argc=2, argv=0x7fffffffdf58) at /home/sjg/c/src/third_party/u-boot/files/arch/sandbox/cpu/start.c:360 (gdb) q
Regards, Simon
participants (3)
-
Kever Yang -
Simon Glass -
Stephen Warren