[ECOS] Problem when debugging via gdb over ethernet

Guenter Ebermann guenter.ebermann@gmx.at
Thu Jun 5 13:30:00 GMT 2008


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

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.

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.


Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

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

More information about the Ecos-discuss mailing list