[ECOS] Debugging net stack.

[ECOS] Debugging net stack.

[Fabrice Gautier]

Hi,

As you may have noticed I'm trying to port the i82559 ethernet driver for
PC.

I'm on the point were it compiles but it won't run. 

The problem debugging the net stack is that it get initialized before the
debug stuff... When I get:

HAL/diag SERIAL init
Interrupt: 3
Network stack using 65536 bytes for misc space
                    65536 bytes for mbufs
                    131072 bytes for mbuf clusters
Interrupt: 3
pc_i82559_init
Bad device private pointer 188E00

then I guess the "interrupt: 3" message means "Sorry guy! Debug interrupt is
not set up yet..."

How can I modify the initialisation order so that I can at least see what
calls lead to this erroneous pointer ? 

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

 

Re: [ECOS] Debugging net stack.

[Andrew Lunn]

> How can I modify the initialisation order so that I can at least see what
> calls lead to this erroneous pointer ? 

Sorry, cannot help you here, that all C++ magic i never learnt.  As a
workaround put a breakpoint on diag_printf.

        Andrew

Re: [ECOS] Debugging net stack.

[Jonathan Larmour]

Fabrice Gautier wrote:
> 
> The problem debugging the net stack is that it get initialized before the
> debug stuff... When I get:
> 
> HAL/diag SERIAL init
> Interrupt: 3
> Network stack using 65536 bytes for misc space
>                     65536 bytes for mbufs
>                     131072 bytes for mbuf clusters
> Interrupt: 3
> pc_i82559_init
> Bad device private pointer 188E00
> 
> then I guess the "interrupt: 3" message means "Sorry guy! Debug interrupt is
> not set up yet..."
> 
> How can I modify the initialisation order so that I can at least see what
> calls lead to this erroneous pointer ?

[ Yes, I'm trawling the old e-mail I missed before ]

You could try changing the order by editing the relative priorities in
infra/current/include/cyg_type.h, but I greatly doubt that's the issue
here.

If you are debugging via serial, with stubs included, normally you should
just be able to set a breakpoint in the initialization code before the C++
constructors are run (which is the point the stack gets initialized). I've
certainly done that before.

The problem is almost certainly simply the following bit in the i386
vectors.S:

        .extern cyg_hal_invoke_constructors
        call    cyg_hal_invoke_constructors

#ifdef CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
        .extern initialize_stub
        call    initialize_stub
#endif /* CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS */

Try just swapping these around.

If it works, let us know so we can update the sources. Thanks!

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

RE: [ECOS] Debugging net stack.

[Fabrice Gautier]

> -----Original Message-----
> From: Jonathan Larmour [ mailto:jlarmour@redhat.com ]
> Sent: Friday, October 20, 2000 6:10 AM
> To: Fabrice Gautier
> Cc: Ecos-List (E-mail)
> Subject: Re: [ECOS] Debugging net stack.
> 
[...] 
> The problem is almost certainly simply the following bit in the i386
> vectors.S:
> 
>         .extern cyg_hal_invoke_constructors
>         call    cyg_hal_invoke_constructors
> 
> #ifdef CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
>         .extern initialize_stub
>         call    initialize_stub
> #endif /* CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS */
> 
> Try just swapping these around.
> 
> If it works, let us know so we can update the sources. Thanks!

Yes you're right, I currently have this order in my vectors.S for a few days
and it seems better. 

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com