Thanks, but I sincerely doubt that it'll solve anything.
Originally Posted by doctorxyz
The Sync instructions are for ensuring that write operations to hardware registers are done in sequence. You see it used in GSM as GSM deals with writing to the GS's registers, and the writes made to some of those registers must be done in a particular order.
Flushing the D-Cache hurts performance, and should not be done often. I don't even need to flush the D-cache, write back to it or invalidate it because I write to the uncached segment when passing data over to the IOP via DMA - bypassing the cache to begin with.
The issue seems to be some sort of race condition - as we're probably driving the stack faster than it would usually run at. Plus unlike previously, the receive function is now run from a thread (Required by dev9DmaTransfer) - if a critical region within that stack is not protected properly and two or more threads access it at the same time, undefined behaviour may result.
Since even LWIP v1.1.1 (The stack which the SMS stack was based on) doesn't seem to have this issue, it's probably because this stack is broken in some of its modified areas.
I don't actually remember, but it's probably about the same or worse (Most likely worse). At least, the strain on the IOP will not be as great if DMA transfers are used.
Originally Posted by Slider2k
But the bigger problem here that we're trying to resolve is the auto-negotiation issue which plagues the current homebrew SMAP driver.
Not to mention the redundancy of the macro definitions within the smap.c file. There is a similar set of definitions in common/smapregs.h and common/speedregs.h.
SCPH-10000 S. MINOKAMO v1.01 (Defunct)
SCPH-10000 S. KISARAZU v1.00 (faulty)
SCPH-15000 S. KOHDA (With warranty seal!) :D
DESR-5100 S. EMCS