Re: Question w.r.t. crash inside select call from libbsd.

2023-01-31 Thread Karel Gardas 

On 1/31/23 07:30, Sebastian Huber wrote:
so with zone being NULL the crash is expected here. However I'm still 
curious if this is libbsd issue or my issue with naive configuration?


Did you use select() before libbsd is initialized? Do you have more than 
64 file descriptors? In this case the fd set type is too small and you 
have a stack overflow.


And this is exactly what was happening and why I increase STACK size 
insanely. Anyway, thanks to your help, this is no longer happening.


Which branch of libbsd do you use? Maybe try out 
the other branch as well.


master. I've thought this is were development happens, isn't it?

Also noted interesting thing. If I modify buildset to remove all USB, I 
still get linked error USB related (missing functions) due to functions 
being used from device-nexus.h. Is this current behavior or have I did 
anything wrong again?


E.g. stm32h7 USB setup in libbsd is wrong for my board (causes RTEMS 
crash) so I've tried to disable that by build set modification (all 
dev_usb* = off) and this does not helped hence I've modified 
device-nexus.h also to not use dwg at all.
Hmm, looks like patch like attach may solve the issue? At least it did 
for my case here. But I don't know if this is the right way to attack 
this issue.


 From the 16MiB you already waste 4MiB for unused features if you use 
the latest 6-freebsd-12 branch of libbsd.


No, master here. Also I've not attempted to optimize for size yet as the 
project is currently still not done yet.


Thanks!
Karel

diff --git a/rtemsbsd/include/bsp/nexus-devices.h b/rtemsbsd/include/bsp/nexus-devices.h
index d98e6f76..11f74771 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -187,6 +187,7 @@ RTEMS_BSD_DRIVER_USB_MASS;
 RTEMS_BSD_DEFINE_NEXUS_DEVICE(stmac, 0, 0, NULL);
 SYSINIT_DRIVER_REFERENCE(ukphy, miibus);
 
+#if defined(RTEMS_BSD_MODULE_DEV_USB_CONTROLLER)
 static const rtems_bsd_device_resource dwcotg_res[] = {
 	{
 		.type = RTEMS_BSD_RES_MEMORY,
@@ -200,6 +201,8 @@ static const rtems_bsd_device_resource dwcotg_res[] = {
 };
 RTEMS_BSD_DEFINE_NEXUS_DEVICE(dwcotg, 0, RTEMS_ARRAY_SIZE(dwcotg_res),
 dwcotg_res);
+#endif
+
 RTEMS_BSD_DRIVER_ST_SDMMC(0, SDMMC1_BASE, DLYB_SDMMC1_BASE, SDMMC1_IRQn);
 RTEMS_BSD_DRIVER_MMC;
 RTEMS_BSD_DRIVER_USB;
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Question w.r.t. crash inside select call from libbsd.

2023-01-30 Thread Sebastian Huber 



On 30.01.23 23:33, Karel Gardas wrote:


I'm debugging crash inside the select call from libbsd library. The code 
comes from few days old RTEMS and few days old libbsd trees. My naive 
configuration for the RTEMS is below.


The crash backtrace is:

_CPU_Fatal_halt (source=source@entry=9, error=, 
error@entry=604203640) at ../../../cpukit/score/cpu/arm/cpu.c:203

203   while ( true ) {
(gdb) where
#0  _CPU_Fatal_halt (source=source@entry=9, error=, 
error@entry=604203640)

     at ../../../cpukit/score/cpu/arm/cpu.c:203
#1  0x080fb9b4 in _Terminate 
(the_source=the_source@entry=RTEMS_FATAL_SOURCE_EXCEPTION,

     the_error=604203640) at ../../../cpukit/score/src/interr.c:58
#2  0x08104e56 in rtems_fatal (fatal_code=,
     fatal_source=RTEMS_FATAL_SOURCE_EXCEPTION) at 
../../../cpukit/include/rtems/fatal.h:160

#3  _ARM_Exception_default (frame=)
     at ../../../cpukit/score/cpu/arm/arm-exception-default.c:37
#4  
#5  _bsd_uma_zalloc_arg (zone=0x9, udata=udata@entry=0x0, 
flags=flags@entry=2)

     at ../../freebsd/sys/vm/uma_core.c:2624
#6  0x0807c180 in uma_zalloc (flags=2, zone=)
     at ../../freebsd/sys/vm/uma.h:356
#7  0x080b51b8 in rtems_bsd_thread_create (thread=0xd0003048 
<_RTEMS_tasks_Objects>,

     wait=) at ../../rtemsbsd/rtems/rtems-kernel-thread.c:93
#8  0x080b5250 in rtems_bsd_get_curthread (wait=0)
     at ../../rtemsbsd/rtems/rtems-kernel-thread.c:116
#9  0x0807e59a in select (nfds=1, readfds=readfds@entry=0xd000da30,
     writefds=writefds@entry=0xd000da38, errorfds=errorfds@entry=0x0,
     _bsd_timeout=_bsd_timeout@entry=0x0) at 
../../freebsd/sys/kern/sys_generic.c:1170



When I put breakpoint here and there I found strange fact that zone = 
0x0 in frame #5 and not 0x9:


Breakpoint 1, _bsd_uma_zalloc_arg (zone=0x0, udata=udata@entry=0x0, 
flags=flags@entry=2) at ../../freebsd/sys/vm/uma_core.c:2562

2562    {
(gdb) next
2680    bucket_free(zone, bucket, udata);
(gdb) next
2622    critical_enter();
(gdb) next
196   cpu_self->thread_dispatch_disable_level = disable_level + 1;
(gdb) next
2622    critical_enter();
(gdb) next
2624    cache = >uz_cpu[cpu];
(gdb) next
_ARMV7M_Exception_default () at 
../../../cpukit/score/cpu/arm/armv7m-exception-default.c:51

51    __asm__ volatile (
(gdb)


so with zone being NULL the crash is expected here. However I'm still 
curious if this is libbsd issue or my issue with naive configuration?


Did you use select() before libbsd is initialized? Do you have more than 
64 file descriptors? In this case the fd set type is too small and you 
have a stack overflow. Which branch of libbsd do you use? Maybe try out 
the other branch as well.




The platform is STM32H757i-eval board, the linking is using flash_sdram 
configuration. The board provides 16MB of SDRAM so hopefully this should 
be enough even for libbsd... The board configuration is more or less 
default except disabling of MPU alignment. If I don't do this, my 
testing app (quickjs) would not fit 2MB of CPU flash. When MPU alignment 
is disabled, I'm on 1.4MB of flash consumption (before disabling 2.3MB)


From the 16MiB you already waste 4MiB for unused features if you use 
the latest 6-freebsd-12 branch of libbsd.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel