x1000 onboard network opensource driver in progress

	Bottom Previous Topic Next Topic
Register To Post

« 1 2 (3)

Georg

Re: x1000 onboard network opensource driver in progress

Posted on: Yesterday 7:08 #41

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

LiveForIt

Re: x1000 onboard network opensource driver in progress

Posted on: Yesterday 12:29 #42

Home away from home

@TSK

Boot from cdrom, and check that you don't have outdated tools in s:startup-sequence, or user-startup.
often when the OS is frozen its possible get into Amiga computer by using serial cable, but you need to setup a termial on aux: using newshell.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.

kas1e

Re: x1000 onboard network opensource driver in progress

Posted on: Yesterday 18:52 #43

Home away from home

@Georg
Quote:

What if you change your interrupt code to always return 0?

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 ?

Quote:

And/or change interrupt priority (either to very high or very low)?

Yep, will check 128 / -128

Quote:

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.

You think that CPU still alive even if video dead, mouse/keyboard dead, and serial dead ?

Quote:

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.

That worth of trying too, of course, thanks, will check this all out.

There also another idea coming when i read yours : memory can survive "reset" button after lockup, so we just rom irq handler doing a counter , which line reached, timestap maybe , when lockup happens, reset, boot with no s-s , read from that memory, see the last N interrupt events before lockup. Can works ? I can do a simple test like just write some crap to some fixed address, press reset, immediately after boot check if that value is still there. If yes - idea can works. What you think ?

Also, thinking more about, if nothing will help, X1000 do have COP (Debug) Header. In TRM written that "The COP (debugger) header is provided for factory test purposes and its use is not
recommended.", but we know what mean those "factory test purposes" : cpu tests :) But i currently do not know what of ppc jtag debugger support PA6T at all , Varysis of course know it, but not me :) I also can go OpenOCD + FTDI-based JTAG, but then, dunno if OpenOCD support PA6T-1682M.. But that for later, first will try to do all best from software side.

Join us to improve dopus5!
AmigaOS4 on youtube

Georg

Re: x1000 onboard network opensource driver in progress

Posted on: Yesterday 19:19 #44

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.

kas1e

Re: x1000 onboard network opensource driver in progress

Posted on: Yesterday 21:52 #45

Home away from home

@Georg
Quote:

What does your interrupt handler return at the moment?

Was 1, tried 0 : still lockup , so reverted to 1 again.

Quote:

127 / -128

Originally i set 10, now tried with both 127 and -128 : lockups too on both values :(

Quote:

Would try to run a little program in the background which installs maybe a vertical blank interrupt and periodically outputs something to serial.

So doing simple:


static ULONG WatchdogHandler(struct ExceptionContext *ctx, struct ExecBase *SysBase, APTR data)

{

    (void)ctx;

    (void)SysBase;



    struct WatchdogData *wd = (struct WatchdogData *)data;



    wd->tick++;



    /* Print approximately once per second.

     * VERTB fires at ~50 Hz on most display modes. */

    if (wd->tick - wd->last_tick >= 50)

    {

        wd->last_tick = wd->tick;

        wd->seconds++;



        wd->IExec->DebugPrintF("[WD] alive: %lu s (tick=%lu)\n",

                               wd->seconds, wd->tick);

    }



    return 0;   /* not our */

}



and



    struct Interrupt handler;

    handler.is_Node.ln_Type = NT_INTERRUPT;

    handler.is_Node.ln_Pri  = 127;   

    handler.is_Node.ln_Name = (STRPTR)"pa6t_eth watchdog";

    handler.is_Data         = (APTR)&wd;

    handler.is_Code         = (VOID (*)())WatchdogHandler;



    IExec->AddIntServer(INTB_VERTB, &handler);

Then installed like "watchdog &", running stress text via network => lockup , all i got just 2 lines before all die:


[stress] 8/8 connections open.  Starting receive...

[stress]  Time | Received  | Est.pkts  | Est.wraps | Active

[stress] ------|-----------|-----------|-----------|-------

[WD] alive: 39 s (tick=1950)

[WD] alive: 40 s (tick=2000)

Damn ! :)

Maybe i need to install it let's say to be one time in 1/4 of second, so maybe will have time to print anything before all die but cause of lockup happens ?

Join us to improve dopus5!
AmigaOS4 on youtube

Register To Post	« 1 2 (3)
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )