Nios® II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
12366 Discussions

Debugging "panic: pktdemux: corrupted pkt" error

Altera_Forum
Honored Contributor I
1,223 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 I
105 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.
Reply