You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Sebastien Lorquet <se...@lorquet.fr> on 2022/05/19 16:39:52 UTC

Network debug info level breaks nx_start -> group_setupidlefiles

Hi,

I have a nucleo-h743zi, in which I have enabled network.

It seems to work so far.

When I enable Network Info Debug, I get a crash.

The crash does not happen with Network info disabled (Enabling network 
warnings and errors is ok)

I am writing on the mailing list to get feedback and discussion.

Here is the crash, pretty obvious cause:

A▒DE
stm32_ethinitialize: intf: 0
stm32_ifdown: Taking the network down
netdev_register: Registered MAC: 2e:7e:27:a2:69:88 as dev: eth0
up_assert: Assertion failed at file:init/nx_start.c line: 703 task: Idle 
Task

First of all I dont know where this MAC is obtained but whatever, thats 
not my problem. I will put the real mac later.


Note that nx_start is a pretty general file for nuttx, not related to 
board or chip.

(gdb) break nx_start.c:703
Breakpoint 1 at 0x8002b9a: file init/nx_start.c, line 703.
Note: automatically using hardware breakpoints for read-only addresses.
(gdb) mon reset init
SWD DPIDR 0x6ba02477
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080002e0 msp: 0x240059fc
(gdb) c
Continuing.

Breakpoint 1, nx_start () at init/nx_start.c:703
703 DEBUGVERIFY(group_setupidlefiles(&g_idletcb[i]));
(gdb) s
group_setupidlefiles (tcb=0x24001114 <g_idletcb>) at 
group/group_setupidlefiles.c:61
61        FAR struct task_group_s *group = tcb->cmn.group;
(gdb) n
66        DEBUGASSERT(group != NULL);
(gdb) n
74        fd = nx_open("/dev/console", O_RDWR);
(gdb) n
75        if (fd == 0)
(gdb) n
88            if (fd > 0)
(gdb) n
98            return -ENFILE;

=>assert

This function group_setupidlefiles fails to open /dev/console and 
triggers an assert.

Now please dont tell me that this code will work when I remove debug, I 
dont care. This is not the root cause.


Does this code fails to open the console because some network debug has 
been emitted first?

What to do, then?

It is pretty common to have boards emit debug messages before the OS is 
started. I cant believe I'm the only one that will see this.

It seems to happen before I have CONFIG_DEV_CONSOLE, which is the 
default, and is ok, since i'm just using a serial port with this board.

If I disable CONFIG_DEV_CONSOLE, then nsh does not start, so I believe 
this setting is required.

USB console is not enabled nor planned to be used.


Can you please help me understand and fix this?

It does not look to be recent code.

Thanks,

Sebastien


Re: Network debug info level breaks nx_start -> group_setupidlefiles

Posted by Petro Karashchenko <pe...@gmail.com>.
Hi,

Most probably we need to trace when network init is done. Usually in the
early stages the "#  define showprogress(c) arm_lowputc(c)" and
"arm_lowputs" is used to trace the init process, so maybe you can
instrument the code to find out what is going on.

Best regards,
Petro

чт, 19 трав. 2022 р. о 22:15 Nathan Hartman <ha...@gmail.com> пише:

> On Thu, May 19, 2022 at 12:40 PM Sebastien Lorquet <se...@lorquet.fr>
> wrote:
> >
> > Hi,
> >
> > I have a nucleo-h743zi, in which I have enabled network.
> >
> > It seems to work so far.
> >
> > When I enable Network Info Debug, I get a crash.
> >
> > The crash does not happen with Network info disabled (Enabling network
> > warnings and errors is ok)
> >
> > I am writing on the mailing list to get feedback and discussion.
> >
> > Here is the crash, pretty obvious cause:
> >
> > A▒DE
> > stm32_ethinitialize: intf: 0
> > stm32_ifdown: Taking the network down
> > netdev_register: Registered MAC: 2e:7e:27:a2:69:88 as dev: eth0
> > up_assert: Assertion failed at file:init/nx_start.c line: 703 task: Idle
> > Task
> >
> > First of all I dont know where this MAC is obtained but whatever, thats
> > not my problem. I will put the real mac later.
> >
> >
> > Note that nx_start is a pretty general file for nuttx, not related to
> > board or chip.
> >
> > (gdb) break nx_start.c:703
> > Breakpoint 1 at 0x8002b9a: file init/nx_start.c, line 703.
> > Note: automatically using hardware breakpoints for read-only addresses.
> > (gdb) mon reset init
> > SWD DPIDR 0x6ba02477
> > target halted due to debug-request, current mode: Thread
> > xPSR: 0x01000000 pc: 0x080002e0 msp: 0x240059fc
> > (gdb) c
> > Continuing.
> >
> > Breakpoint 1, nx_start () at init/nx_start.c:703
> > 703 DEBUGVERIFY(group_setupidlefiles(&g_idletcb[i]));
> > (gdb) s
> > group_setupidlefiles (tcb=0x24001114 <g_idletcb>) at
> > group/group_setupidlefiles.c:61
> > 61        FAR struct task_group_s *group = tcb->cmn.group;
> > (gdb) n
> > 66        DEBUGASSERT(group != NULL);
> > (gdb) n
> > 74        fd = nx_open("/dev/console", O_RDWR);
> > (gdb) n
> > 75        if (fd == 0)
> > (gdb) n
> > 88            if (fd > 0)
> > (gdb) n
> > 98            return -ENFILE;
> >
> > =>assert
> >
> > This function group_setupidlefiles fails to open /dev/console and
> > triggers an assert.
> >
> > Now please dont tell me that this code will work when I remove debug, I
> > dont care. This is not the root cause.
> >
> >
> > Does this code fails to open the console because some network debug has
> > been emitted first?
> >
> > What to do, then?
> >
> > It is pretty common to have boards emit debug messages before the OS is
> > started. I cant believe I'm the only one that will see this.
> >
> > It seems to happen before I have CONFIG_DEV_CONSOLE, which is the
> > default, and is ok, since i'm just using a serial port with this board.
> >
> > If I disable CONFIG_DEV_CONSOLE, then nsh does not start, so I believe
> > this setting is required.
> >
> > USB console is not enabled nor planned to be used.
> >
> >
> > Can you please help me understand and fix this?
> >
> > It does not look to be recent code.
>
>
> Unfortunately I don't know the cause, but I have actually run into a
> rather similar problem just a few days ago. In my case it's on Tiva
> platform (armv7m-based) and there is an assertion failure related in
> some way to the console device. In my case, the board is a custom
> board that does not have a serial console (though it does have a UART
> which controls an another chip). For everything else, this board has
> only network connectivity. For the time being I have worked around the
> crash by disabling a bunch of Kconfigs. I didn't know it was the
> network debugging but I do remember that being one of the Kconfigs I
> turned off. I will try to look at the specific areas you mentioned and
> I'll post back if I figure out what's going on with that. It might
> take me a few days though. Inundated with other work at the moment...
>
> Nathan
>

Re: Network debug info level breaks nx_start -> group_setupidlefiles

Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, May 19, 2022 at 12:40 PM Sebastien Lorquet <se...@lorquet.fr> wrote:
>
> Hi,
>
> I have a nucleo-h743zi, in which I have enabled network.
>
> It seems to work so far.
>
> When I enable Network Info Debug, I get a crash.
>
> The crash does not happen with Network info disabled (Enabling network
> warnings and errors is ok)
>
> I am writing on the mailing list to get feedback and discussion.
>
> Here is the crash, pretty obvious cause:
>
> A▒DE
> stm32_ethinitialize: intf: 0
> stm32_ifdown: Taking the network down
> netdev_register: Registered MAC: 2e:7e:27:a2:69:88 as dev: eth0
> up_assert: Assertion failed at file:init/nx_start.c line: 703 task: Idle
> Task
>
> First of all I dont know where this MAC is obtained but whatever, thats
> not my problem. I will put the real mac later.
>
>
> Note that nx_start is a pretty general file for nuttx, not related to
> board or chip.
>
> (gdb) break nx_start.c:703
> Breakpoint 1 at 0x8002b9a: file init/nx_start.c, line 703.
> Note: automatically using hardware breakpoints for read-only addresses.
> (gdb) mon reset init
> SWD DPIDR 0x6ba02477
> target halted due to debug-request, current mode: Thread
> xPSR: 0x01000000 pc: 0x080002e0 msp: 0x240059fc
> (gdb) c
> Continuing.
>
> Breakpoint 1, nx_start () at init/nx_start.c:703
> 703 DEBUGVERIFY(group_setupidlefiles(&g_idletcb[i]));
> (gdb) s
> group_setupidlefiles (tcb=0x24001114 <g_idletcb>) at
> group/group_setupidlefiles.c:61
> 61        FAR struct task_group_s *group = tcb->cmn.group;
> (gdb) n
> 66        DEBUGASSERT(group != NULL);
> (gdb) n
> 74        fd = nx_open("/dev/console", O_RDWR);
> (gdb) n
> 75        if (fd == 0)
> (gdb) n
> 88            if (fd > 0)
> (gdb) n
> 98            return -ENFILE;
>
> =>assert
>
> This function group_setupidlefiles fails to open /dev/console and
> triggers an assert.
>
> Now please dont tell me that this code will work when I remove debug, I
> dont care. This is not the root cause.
>
>
> Does this code fails to open the console because some network debug has
> been emitted first?
>
> What to do, then?
>
> It is pretty common to have boards emit debug messages before the OS is
> started. I cant believe I'm the only one that will see this.
>
> It seems to happen before I have CONFIG_DEV_CONSOLE, which is the
> default, and is ok, since i'm just using a serial port with this board.
>
> If I disable CONFIG_DEV_CONSOLE, then nsh does not start, so I believe
> this setting is required.
>
> USB console is not enabled nor planned to be used.
>
>
> Can you please help me understand and fix this?
>
> It does not look to be recent code.


Unfortunately I don't know the cause, but I have actually run into a
rather similar problem just a few days ago. In my case it's on Tiva
platform (armv7m-based) and there is an assertion failure related in
some way to the console device. In my case, the board is a custom
board that does not have a serial console (though it does have a UART
which controls an another chip). For everything else, this board has
only network connectivity. For the time being I have worked around the
crash by disabling a bunch of Kconfigs. I didn't know it was the
network debugging but I do remember that being one of the Kconfigs I
turned off. I will try to look at the specific areas you mentioned and
I'll post back if I figure out what's going on with that. It might
take me a few days though. Inundated with other work at the moment...

Nathan