Re: [ECOS] Problem when debugging via gdb over ethernet

[Gary Thomas <gary at mlbassoc dot com>]

Guenter Ebermann wrote:
> Hi,
>
> Gary Thomas wrote:
> > Guenter Ebermann wrote:
> > > I would propose the following change in eth_drv.c.
> > >
> > > Had the problem when debugging with gdb over ethernet and a diag_printf
> > > (which would then be redirected to the gdb-stub sitting in RedBoot
> > > ROMRAM) is used during the ethernet driver is stopped my system crashed
> > > (using FEC driver on MPC5200).
> > >
> > > I found a config option which already exists and is used in the same way
> > > in other files where the ethernet driver is stopped/reconfigured temporary.
> > > I think it should be also used in this case.
> > >
> > > The suspeced code is called from my RAM application indirectly from
> > > init_net() in
> > > bootp_support.c.
> > >
> > > Sorry my patch is against our local CVS repository. Our company
> > > restriced cvs access
> > > to the outside. Anyway, I checked the place the code is on dev-head over
> > > WebCVS
> >   ... snip
> > > What do you think?
> > I agree that this is a potential problem (just FYI, the notion of
> > having debug I/O happen over the ethernet while the same interface
> > was being configured was not present when I designed/wrote this
> > code originally.  It's a happy result, but there are many caveats
> > to consider...)
> >
> > I think that this protection belongs in the eth_drv_start() and
> > eth_drv_stop() functions, as they can be called from other places
> > and the problem you are seeing could potentially exist there
> > as well.
> >
> > Can you try the attached patch to see if it works for you?
>
> Thank you for your suggestions!
> I also think the protection is better situated in the eth_drv_start/stop
> functions.
>
> Did not compile in the first try because the static variable _orig_console
> should be renamed to orig_console. The paramter of the functions
> start_safe_io() and stop_safe_io() can possibly be removed.

Thanks.  I put the parameters in there so these functions could
potentially be smarter (don't fiddle with the console if it's not
using the network)

> The patch worked for me (because the diag_printf was in a code 
> called from within eth_drv_start)!
>
> However if I add a diag_printf between a eth_drv_start() and
> eth_drv_stop() my system crashes again. Although I think this
> situation is handled correctly in eth_io.c (the console and debug interface
> in the redboot), because it reverts to the original console if a ethernet
> write or read returned with failure. I think this error is in the
> ethernet driver implementation (if_fec.c MPC5200's FEC driver
> implementation) of my platform. Anyway, I think we could live with
> this for now, because we can also handle this at application level.

Can you elucidate?  Where is this diag_printf() that causes the error?

Where did you get the mpc5200 (if_fec.c) support?  It's not in the
public tree...


--
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss