x1000 onboard network opensource driver in progress

@balaton
Quote:

Yes, there is:

https://kas1e.mikendezign.com/aos4/x10 ... etwork/bug/cfe_dma_test.c

And the point is there is no conditions. Pure random in time. Does not matter what i try can happens fast, can happens not so fast. All i can say for now is:

Sustained concurrent DMA writes + CPU access to ring memory causes a hard internal bus deadlock, with no exception, no error register, no info in debug registers (all clean), nothing. The CPU completely dies — not stuck in a loop, not in an exception handler. Three independent watchdogs (VERTB, CPU timer, IRQ counters) all stop simultaneously , serial also becomes inaccessible, bus lockup.

In test case interrupts not involved, amigaos4/roadshow not involved, same from pure CFE. Descriptor parsing is not involved — blind recycling (no data reading, no validation) locks up identically. DMA channel number doesn't matter(1, 44, 56 were tried, all same). TX channels not invovled, just enough RX one.


But what for sure is that continuous DMA + CPU ring access is REQUIRED to crash - when DMA fills the ring and stops (no recycling), no crash. When CPU doesn't touch the ring (NO_POLL), no crash. Only when both run simultaneously does it lock up.

Only that fewer packets per second = longer before lockup, but it can be just luck and random.


Quote:

Yes, just framebuffer and command prompt is enough. I just fighting now to find any distro which i boot up from usb on x1000. And all i will do, is setup network , and then do udp-flood from pc as i do now for aos4 version and for CFE version. Will it die the same or not will clear a lot. If it will survive i can just debug it till death and simple mimic the same.

This loop in your dma_test.c is very confusing.

You have 3 different indexes (idx, buf_idx, rx_next_buf).

Sure this is all correct "logic"? That you don't end up having two (or more) identical rx_buf_phys pointers that are active (~dma'ing) in the rx_buf_ring at the same time?

@Georg
The indices are confusing because of the different naming: it's two variables for one thing.. buf_idx and br_idx always same value because NUM_RX_BUFS == RX_BUF_RING_SIZE == 2048

@kas1e

I'm talking about the old "dma_test.c". Not your new one for cfe.

There you do



buf_idx = 0 .. 15, because batch = 16. So you only ever repost rx_bufs_phys[0 .. 15].

@Georg
Oh, missed that, will check later, but what i want to say now:

@All
i installed some "Void" ppc linux on x1000, and run udpflood on the onboard network, over 1gb link : millions packets were handled (i can see by "ip -s link show" that they are recieved and counted) and no lockup !

So, it indeed works under linux. For today that for sure enough : it proved that hardware CAN work, mean that i dind't do something. Ok for amigaos4 can be all sort of bugs with roadshow and kernel, but CFE version lockup mean my own issue, it should work if it work under linux. I just need to find what they do differently, how they handle it all.

@kas1e
Quote:
There you have it. As I said before it's likely that you can't touch memory that is used by DMA. Looks like you can't even read it. (That makes sense because if network chip is accessing some memory, the CPU can't access the same area. I don't know if it's just the same address or a whole page.) So in your driver you must make sure that if you pass a pointer to the network interface for DMA nothing will touch that buffer until the DMA is finished so you will have to manage these buffers to avoid concurrent use by the network chip and CPU. This seems to explain the test case as you just run DMA then concurently read buffers by CPU if you're lucky both are the same speed so they are racing around until CPU read reaches the buffer that is being DMA'd into. So you have to keep off of buffers that are active in DMA and only replace it when either DMA has finished or stopped to not try to simlutaneously access the same buffer by card and DMA. This is what I said before that you need some kind of synchronisation between the network chip and CPU access and I think that's what the interrupt is for. The chip will raise an interrupt when it finished DMA and only then you can touch the buffer from the CPU. If the chip is continuing DMA it might wrap around before you finish accessing the buffer so either stop DMA until that or have another buffer ready and quickly replace the pointer in the ring so DMA will use new buffer.