Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12589 Discussions

Debugging "panic: pktdemux: corrupted pkt" error

Altera_Forum
Honored Contributor II
1,609 Views

Hi, 

 

I know there are some topics related to the error message "pktdemux: corrupted pkt". I've checked them all and none helps, most of them being related to some Quartus 9.0sp1 NicheStack release. 

 

I have a web server application on a Nios /f, with uC/OS-ii and NicheStack, external Marvel 88E1111 GMII Phy. Quartus/EDS Software version 13.1.4 Build 182. 

 

My observation is that if during Nios boot (or imediately after the NicheStack task was started) I ping / access the IP via browser, the Nios is likely to hang with the above message. 

 

In ipnet.c I have added the following line: 

printf("maximum packet size %d, received %d", pkt->nb_blen and pkt->nb_plen) //nb_blen -> raw buffer size 1536, nb_plen -> received payload length fflush(stdout);  

 

nb_blen, the raw buffer size is defined in ipport,h as 1536. Since only the packet payload is stored in this buffer, never should nb_plen exceed 1500. However in the situation the panic message is displayed, the received payload length is above the nb_blen. (e.g. "maximum packet size 1536, received 3106") 

 

Can anyone give me a clue what I should be looking for? 

 

Exactly the same software runs smoothly on a different system where the PHY is internal (with an external SFP transceiver). 

 

Thanks!
0 Kudos
1 Reply
Altera_Forum
Honored Contributor II
491 Views

I was able to figgure out what causes this problem. The wrong payload was already wrong by the time Rx SG-DMA updated the status word in descriptor memory.  

 

It is the TSE MAC that does not generate an EOP in some scenarios - which exactly I am still investigating. With EOP missing the internal FSM of the SG-DMA does not reset length counter, so eventually a length corresponding to multiple summed-up packets is written in descriptor's status word. In the attachment you can see the invalid AvST packet and the internal SGDMA counter.
0 Kudos
Reply