Who's Online |
277 user(s) are online ( 101 user(s) are browsing Forums)
Members: 0
Guests: 277
more...
|
|
Headlines |
-
sdl2.lha - library/misc
May 18, 2026
-
sdl3.lha - library/misc
May 18, 2026
-
audiocast.lha - audio/misc
May 15, 2026
-
airscanner.lha - utility/print
May 15, 2026
-
nodeamiga.lha - development/language
May 14, 2026
-
unzip.lha - utility/archive
May 13, 2026
-
reportplus.lha - utility/misc
May 12, 2026
-
alienbreed3d.lha - game/fps
May 11, 2026
-
hwp_ahx.lha - library/hollywood
May 11, 2026
-
hwp_digibooster.lha - library/hollywood
May 11, 2026
|
|
|
|
|
Re: x1000 onboard network opensource driver in progress
|
|
Just popping in 
|
@kas1eQuote:
but : by the linux functions: dma_map_single, dma_alloc_coherent, dev_alloc_skb, i.e. stuff which handle IOMMU translation, cache coherency, and memory allocation..
Btw, your allocations with AllocVecTags(). You use "AVT_Alignment, 64". Docs say there's also "AVT_PhysicalAlignemnt" ("mainly used for DMA Drivers"). How does this work later if doing IMMU->SetMemoryAttrs on memory which is only 64 byte aligned, if MMU works per-page? What if someone else has memory in same page and changes memory attributes, too? Maybe try to change your driver (not "dma_test.c" before checking the confusing-index-thing I mentioned) to use allocations with page size alignments.
|
|
|
|
|
|
Re: x1000 onboard network opensource driver in progress
|
|
Just popping in
|
@kas1e I'm talking about the old "dma_test.c". Not your new one for cfe. There you do
uint32 buf_idx = i % num_bufs_alloced;
rx_buf_ring[rx_next_buf & (RX_BUF_RING_SIZE - 1)] = XCT_RXB_LEN(RX_BUF_SIZE) | XCT_RXB_ADDR(rx_bufs_phys[buf_idx]);
buf_idx = 0 .. 15, because batch = 16. So you only ever repost rx_bufs_phys[0 .. 15].
|
|
|
|
|
|
Re: x1000 onboard network opensource driver in progress
|
|
Just popping in
|
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?
|
|
|
|
|
|
Re: x1000 onboard network opensource driver in progress
|
|
Just popping in
|
Surround the "for(;;)" loop with Forbid()/Permit() (or even Disable()/Enable()).
And see if the debug output stops or not after some time. You will not be able to ctrl-c break (unfortunately "btst #6,$bfe001" may not work ...) the loop so you'll always have to reboot.
|
|
|
|
|
|
Re: x1000 onboard network opensource driver in progress
|
|
Just popping in
|
@kas1e Quote: Try under Linux? Quote:
So we can rule out sharing of same channels.
Theoretically whoever uses it (gfx? gfx driver?) could still screw you if they do something like:
gfx_function_xyz()
if (using_preallocated_dma_channel == FALSE)
{
/* fast path */
using_preallocated_dma_channel = TRUE;
ch = preallocated_dma_channel;
}
else
{
/* slow path */
ch = alloc_channel();
}
DO_DMA_STUFF(ch);
if (using_preallocate_channel == FALSE)
{
free_channel(ch);
}
else
{
using_preallocated_channel = FALSE;
}
Are gfx drivers in AOS4 already loaded/running when S:startup-sequence is executed? If not, maybe try to run network stress test there when as few as possible other things (gfx/audio/...) are running in the background.
|
|
|
|
|
|
Re: x1000 onboard network opensource driver in progress
|
|
Just popping in
|
@kas1e Quote: Then I fall back to the loop-in-some-list theory. Maybe some stupid little bug that causes some Node (or io request or whatever has a node in it) to be removed while it is not in a list, or added to a new list while it is still part of another list, or added a second time when it already is in the list (io: re-send an io request while it is still pending). Something like that.
|
|
|
|
|
|
Re: x1000 onboard network opensource driver in progress
|
|
Just popping in
|
@kas1e Quote:
Soft-int with maximum priority died.
One problem with this timer softint loop I forgot is that (unless AOS4 does it differently) the softints caused from a hw interrupt are not executed immediately, but only when the last hw interrupt is done, ie. before returning to usermode. So even if hw timer interrupt would still be running/runnable, a "stuck" lower hw priority interrupt could still prevent the "loop" (which re-sends the timer request) from working. Using AOS4 version of maybe undocumented ~PA_CALL/~PA_FASTCALL instead of PA_SOFTINT for the timer replyport would work better. Because the difference to PA_SOFTINT is that when the timer is replied, it does not result in Cause(), but in a direct function call. Quote:
Interrupts with maximum priority died.
The priority of your interrupt handler is just for multiple handlers among same hw irq. Hw pri is still the same whatever it is. You can set it to max. possible values, but interrupts which have higher hardware priority are not affected. So even with the test results it's probably still not 100% sure, that it isn't "simply" some (high pri) interrupt handler being stuck in a loop or that's there endless interrupt flood.
|
|
|
|
|
|
Re: x1000 onboard network opensource driver in progress
|
|
Just popping in
|
@kas1e Quote:
But to be honest i not very well understand why pasemi_dma.resource should allocate anything about network, if it's work of network device, which can (or can not) use this pasemi_dma.resource ?
Aren't this pasemi dma channels ~general purpose things? Meaning there is no specific reserved channels (by cpu/hardware itself) for network or other specific things? Maybe AOS on X1000 accelerates (big) memcpys with this dma-stuff and uses pasemi_dma.resource to dynamically/on-demand allocate channels (more tasks can be doing this memcpys at the same time), so it's not the resource itself allocating channels but users of the resource request allocations.
|
|
|
|
|
|
Re: x1000 onboard network opensource driver in progress
|
|
Just popping in
|
@kas1e Quote:
CPU died, soft-int died, hardware interrupts died, and this is not MCE too. Then what to check next ? I mean, BUS lockup ? Busy-wait ?
Maybe unlikely, but one possibility is some missing protection when a List is modified by more tasks (or task(s) and interrupt). IIRC I did see cases in some other OS where it did cause funny things like a loop in the List (node->ln_Succ == node). If someone then traversed this List while in Disabled() state you would get a lockup like the one you see (no ints happening, etc.) Or broken protection in the sense of mismatch between lock (forbid/Disable/...) and unlock (permit/enable) calls. Or only lock call, but forgetten unlock call. This once upon a time in another OS caused funny and hard to reproduce disappearing-task problem (disappeared from taskready/taskwait/thistask). Because every so often when the locking nest count - because of overflow/wrappingback - reached the unlocked-value, things were done in a unlocked state, when they shouldn't have been and in the source it did not look like that because the LOCK was there, but missing/mismatched UNLOCK screwed things up.
|
|
|
|
|
|
Re: x1000 onboard network opensource driver in progress
|
|
Just popping in
|
Do you do this DMA stuff all by yourself or are you using some OS functionality for it? If the first, maybe the OS uses pasemi DMA "stuff" itself and there's clash because of missing arbitration. Like on AOS Classic if someone tried to use the blitter directly, without OwnBlitter()/DisownBlitter). (Stumbled on https://wiki.amigaos.net/wiki/DMA_Resource, but X1000 isn't mentioned).
|
|
|
|
|
|
Re: x1000 onboard network opensource driver in progress
|
|
Just popping in
|
@kas1e Instead of VERTB watchdog, maybe try also timer.device softint loop instead, as that's maybe less relying on "external" stuff (gfx card, bus / pci / ??): 68k sample code From Amiga Dev CD 2.1:
#include <exec/memory.h>
#include <exec/interrupts.h>
#include <devices/timer.h>
#include <dos/dos.h>
#include <clib/exec_protos.h>
#include <clib/dos_protos.h>
#include <clib/alib_protos.h>
#include <stdio.h>
#define MICRO_DELAY 1000
#define OFF 0
#define ON 1
#define STOPPED 2
struct TSIData {
ULONG tsi_Counter;
ULONG tsi_Flag;
struct MsgPort *tsi_Port;
};
struct TSIData *tsidata;
void tsoftcode(void); /* Prototype for our software interrupt code */
void main(void)
{
struct MsgPort *port;
struct Interrupt *softint;
struct timerequest *tr;
ULONG endcount;
/* Allocate message port, data & interrupt structures. Don't use CreatePort() */
/* or CreateMsgPort() since they allocate a signal (don't need that) for a */
/* PA_SIGNAL type port. We need PA_SOFTINT. */
if (tsidata = AllocMem(sizeof(struct TSIData), MEMF_PUBLIC|MEMF_CLEAR))
{
if(port = AllocMem(sizeof(struct MsgPort), MEMF_PUBLIC|MEMF_CLEAR))
{
NewList(&(port->mp_MsgList)); /* Initialize message list */
if (softint = AllocMem(sizeof(struct Interrupt), MEMF_PUBLIC|MEMF_CLEAR))
{
softint->is_Code = tsoftcode; /* The software interrupt routine */
softint->is_Data = tsidata;
softint->is_Node.ln_Pri = 0;
port->mp_Node.ln_Type = NT_MSGPORT; /* Set up the PA_SOFTINT message port */
port->mp_Flags = PA_SOFTINT; /* (no need to make this port public). */
port->mp_SigTask = (struct Task *)softint; /* pointer to interrupt structure */
/* Allocate timerequest */
if (tr = (struct timerequest *) CreateExtIO(port, sizeof(struct timerequest)))
{
/* Open timer.device. NULL is success. */
if (!(OpenDevice("timer.device", UNIT_MICROHZ, (struct IORequest *)tr, 0)))
{
tsidata->tsi_Flag = ON; /* Init data structure to share globally. */
tsidata->tsi_Port = port;
/* Send of the first timerequest to start. IMPORTANT: Do NOT */
/* BeginIO() to any device other than audio or timer from */
/* within a software or hardware interrupt. The BeginIO() code */
/* may allocate memory, wait or perform other functions which */
/* are illegal or dangerous during interrupts. */
printf("starting softint. CTRL-C to break...\n");
tr->tr_node.io_Command = TR_ADDREQUEST; /* Initial iorequest to start */
tr->tr_time.tv_micro = MICRO_DELAY; /* software interrupt. */
BeginIO((struct IORequest *)tr);
Wait(SIGBREAKF_CTRL_C);
endcount = tsidata->tsi_Counter;
printf("timer softint counted %ld milliseconds.\n", endcount);
printf("Stopping timer...\n");
tsidata->tsi_Flag = OFF;
while (tsidata->tsi_Flag != STOPPED) Delay(10);
CloseDevice((struct IORequest *)tr);
}
else printf("couldn't open timer.device\n");
DeleteExtIO(tr);
}
else printf("couldn't create timerequest\n");
FreeMem(softint, sizeof(struct Interrupt));
}
FreeMem(port, sizeof(struct MsgPort));
}
FreeMem(tsidata, sizeof(struct TSIData));
}
}
void tsoftcode(void)
{
struct timerequest *tr;
/* Remove the message from the port. */
tr = (struct timerequest *)GetMsg(tsidata->tsi_Port);
/* Keep on going if main() hasn't set flag to OFF. */
if ((tr) && (tsidata->tsi_Flag == ON))
{
/* increment counter and re-send timerequest--IMPORTANT: This */
/* self-perpetuating technique of calling BeginIO() during a software */
/* interrupt may only be used with the audio and timer device. */
tsidata->tsi_Counter++;
tr->tr_node.io_Command = TR_ADDREQUEST;
tr->tr_time.tv_micro = MICRO_DELAY;
BeginIO((struct IORequest *)tr);
}
/* Tell main() we're out of here. */
else tsidata->tsi_Flag = STOPPED;
}
|
|
|
|
|
|
Re: x1000 onboard network opensource driver in progress
|
|
Just popping in
|
Quote: Those changes were mostly a theory in case the irq is shared with other device drivers. Is there a tool (scout? sysmon?) where you can check if there are other installed interrupt handler for the irq your driver is using, or if your driver is the only one using the specific irq? If it's not the only one, maybe try what happens if you disable the driver (sound? whatever) that's using same irq. Maybe another thing you can try is to add a counter and a little serial debug output at beginning of your interrupt and at the end before the return. Don't know how many interrupts are typically happening during net transfer, so don't know if you have to do the output every 1000 ticks, every 10000 ticks or whatever.
|
|
|
|
|
|
Re: x1000 onboard network opensource driver in progress
|
Posted on: 3/13 19:19
#13
|
Just popping in
|
@kas1eQuote: kas1e wrote:@Georg
You mean probably not just return 0, as we still need to write to RXCH_RESET so, if we not, it surely will lockup, but you mean to strip interrupt handler code to the bare minimum write+return 0 and see if it change anything, that what you mean ?
No, don't strip/change code in the interrupt handler. Only change the return value to always be 0. Unless things are different in AOS4 I think it used to be so that an interrupt handler returns TRUE or 1 if the interrupt handler found out that "yes, the interrupt was for me" and FALSE or 0 if the interrupt handler finds out that it "was not for me". That return value should really just be some optimization for the OS (to call less interrupt handlers if it thinks or it is being told that the interrupt was already handled by the current handler it is calling). But I think it should be safe to always return 0 and then cause other interrupt handlers of an IRQ to be called anyway. I think in theory the interrupt handlers for an IRQ that can be shared anyway need to handle the situation where the handler is called even if the IRQ was triggered by a different device than it's own. What does your interrupt handler return at the moment? Quote:
Yep, will check 128 / -128
127 / -128 Quote:
You think that CPU still alive even if video dead, mouse/keyboard dead, and serial dead ?
My guess is that it likely is. Would try to run a little program in the background which installs maybe a vertical blank interrupt and periodically outputs something to serial. Don't know if vertb is best for this. It should be some interrupt that has higher (hw) priority than those external device (network/audio/...) interrupts.
|
|
|
|
|
|
Re: x1000 onboard network opensource driver in progress
|
|
Just popping in
|
What if you change your interrupt code to always return 0?
And/or change interrupt priority (either to very high or very low)?
Edit: also I would add a static counter variable to the interrupt and every 1000 counts or so debug-output it to serial (unconditionally = even if "interrupt is not for me")). To see at lockup what happens: maybe there's interrupt-flood.
I would generally also look more at what happens during lockup (the OS is still likely doing/executing something) not just how to reproduce it.
Edit2: One idea behind the tests mentioned is to check whether there maybe is some interrupt handler installed in the system by some other driver for the same irq that maybe erraneously (sometimes) thinks and says "yes, this irq is for me" - when it isn't - and returning != 0 and then causing other interrupt handlers for the same irq not to be called anymore. So those other interrupt handler never get chance to clear the irq-pending-state and the interrupts from then on keeps happening endlessly -> lockup.
Edited by Georg on 2026/3/13 11:57:20
|
|
|
|
|
|
Re: x1000 onboard network opensource driver in progress
|
Posted on: 3/12 19:07
#15
|
Just popping in
|
Isn't there some way to investigate lockup from QEmu Monitor?
"info registers" ?
"info pic" ?
To see what it is doing during lockup. If it stays hanging in (endless happening?) interrupt-state (~AOS68k supervisor mode) or something.
Or maybe there's some way from Monitor to manually clear interrupt pending (~AOS68k INTREQ clearing) states. To see if you can break out of the lockup.
If not, I would investigate this from AOS side with something like a high pri watchdog task which every 10 seconds does some debug output to serial. To see if any tasks at all running during lockup.
If not, maybe some INTB_VERTB watchdog interrupt which does same thing.
If tasks do still run during lockup, find out which one of the higher pri tasks is not giving up CPU. By lowering watchdog task pri.
Something like that.
|
|
|
|
|
|
Re: x1000 onboard network opensource driver in progress
|
Posted on: 3/12 16:27
#17
|
Just popping in
|
Edit: wrong topic
|
|
|
|
|
|
Re: working virtio-net.device for QEMU : no more issues with rtl drivers !
|
Posted on: 3/12 16:19
#18
|
Just popping in
|
@joergQuote: joerg wrote:@smarkusg
AROS RTL 8139 driver needed workarounds for QEmu as well. Not sure it was workaround. May have been real bug. The driver readme says "incomplete/experimental". Don't know how much tested or used at all it was. And how much on real hw or "only" emus or virtual machines. Maybe it was fine on things like VirtualBox or VMWare which is or was typically used for AROS instead of qemu. The driver definitely has more bugs, for example you can see some code (32bit status peeking from rx packet header) that would certainly not work on AROS big endian versions.
|
|
|
|
|
|
Re: x1000 onboard opensource driver in progress
|
Posted on: 3/10 16:30
#19
|
Just popping in
|
@kas1eQuote: kas1e wrote:
but, still have some problem with whole thing, awfull pings (sometime good enough like 0.5ms, sometime 1000(!) ms), and so all the data load up like "load fast -> stall for a while -> load fast".
2 years ago I tried AROS x86 in qemu with it's rtl8139 driver. It showed similiar behaviour. I did not have much clue about networking stuff, but I looked in the driver source and it had a "TODO:" comment about "wrapped buffers". I managed to do a quick fix and the bad behaviour (load fast, stall, load fast, ...) disappeared. The issue was that a packet in the rx buffer for whatever reason (maybe not happening on real hw) can end up being partly put at the end of the rx buffer, and the rest of it (parts which did not fit) wrapped over and was put at the beginning of the rx buffer. So the quick fix was to allocate the rx buffer 2 times as big, and when a wrap over was detected ("if (ring_offset + rx_size > np->rx_buf_len)" copy the overspilled part from the beginning to "rx_buffer + rx_buf_len". Without this (I think) ~broken packets (only parts of them valid, because not fully/correctly copied) ended up going through network stack.
|
|
|
|
|
|
Re: Deleting complete pixel lines in ImageFx4?
|
Posted on: 2025/9/30 17:31
#20
|
Just popping in
|
Quote:
I already had a quick look on Gimp but did not find that type of command.
Maybe layer -> transformation -> offset (with activated wrap around) to move the lines in the middle of the picture to the outside. Then normal crop. Then reverse offset.
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
