How to debug 4.10.99 network stack?

[Emeric Vigier]

>> On Jul 19, 2016 1:45 PM, "Emeric Vigier" <emeric.vigier at algolux.com> wrote:
>>>
>>> Hi,
>>>
>>> I run RTEMS-4.10.99 on a custom Leon board. I transfer data over ethernet (stream socket). My board can receive packets successfully (RX) but stalls sending packets (TX). I'd like to debug that issue, but have limited experience debugging network stack. Switching to 4.11 is not an option as it involves too much code to port. I have a JTAG and can break into RTEMS code. I read https://docs.rtems.org/doc-current/share/rtems/html/networking/Debug-Output.html#Debug-Output but didn't find any printf in mbuf.h nor if.h.
>>>
>>> How can I enable debugging in 4.10.99 network stack?
>>> Where can I find the 4.11 network stack doc?

My custom Leon4 board runs RTEMS-4.10.99 and includes a GRETH ethernet
MAC. I use a driver version from the board manufacturer, very close to
greth.c. I gathered some more information:

- stall is random, either the network works like a charm, I can RX, TX
several MB from/to a stream socket, either it refuses to receive a
bare kB. In fact it does not stall completely, the board RX/TX 100kB
every 5s or so.

- My PHY always shows activity: steady green LED (100Mb FD), blinking green LED

- GRETH uses RX descriptors in DDR to copy packet payload. My driver
allocates 16 TX and 16 RX desc.

- I checked GRETH registers during a RX stalls: the 16 RX descriptors
are full. MAC Control reg says _Receive-Interrupt_ is enabled, Status
reg says _Receive successful_ (RI).

- kiwichris (#rtems IRC) suggested me to check the interrupt level
conf: I listed three interrupts: 1) MAC > Leon CPU; 2) PHY > PMIC; 3)
PHY > MAC.
1) uses an interrupt internal of the SoC, I assume its configuration
is correct since ethernet someitme works like a charm at 11MBps
(100Mb).
2) the PHY has an interrupt pin connected to a PMIC gpio (configured
in Output, Wake/sleep, no internal PullUp, falling-edge, active low,
CMOS). The PMIC is connected to my SoC through i2c and another
interrupt pin (which I haven't found the configuration yet).
3) it is disabled on the MAC side

- When I halt my Leon core during a RX stall, MAC Control register
says Receiver-Interrupt (RI) enabled, Receiver-Enable (RE) is
disabled. And all my RX desc are disabled... It seems the MAC driver
messed up with last interrupt and forgot to enable the Receiver.

greth.c is very close to the driver version I have. I have about
greth_gbit_Daemon() RX implementation:

                    // enable RX descriptor (
                    if (dp->rx_ptr == dp->rxbufs - 1) {
                            dp->rxdesc[dp->rx_ptr].ctrl =
GRETH_RXD_ENABLE | GRETH_RXD_IRQ | GRETH_RXD_WRAP;
                    } else {
                            dp->rxdesc[dp->rx_ptr].ctrl =
GRETH_RXD_ENABLE | GRETH_RXD_IRQ;
                    }

                    // enable Receiver (RE)
                    rtems_interrupt_disable(level);
                    dp->regs->ctrl |= GRETH_CTRL_RXEN;
                    rtems_interrupt_enable(level);
                    dp->rx_ptr = (dp->rx_ptr + 1) % dp->rxbufs;
            }

        /* Always scan twice to avoid deadlock */
        // enable Receiver Interrupt (RI)
        if ( first ){
            first=0;
            rtems_interrupt_disable(level);
            dp->regs->ctrl |= GRETH_CTRL_RXIRQ;
            rtems_interrupt_enable(level);
            goto again;
        }

What is this "deadlock" about? In what scenario does it happen?
Why don't we enable RI right after we enabled RE here? While
interrupts are disabled.

thanks for your answer.
Emeric

>>>
>>> thanks,
>>> --
>>> Emeric
>>> @Algolux