This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: RE: Lock in Cyg_Interrupt::call_pending_DSRs_inner
- From: Jonathan Larmour <jlarmour at redhat dot com>
- To: David Hsu <davidhsu at realtek dot com dot tw>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Fri, 25 Jan 2002 19:40:34 +0000
- Subject: Re: [ECOS] RE: Lock in Cyg_Interrupt::call_pending_DSRs_inner
- Organization: Red Hat UK Ltd.
- References: <MDEDKIDHDCFJNIMOJHIPIEJJCBAA.davidhsu@realtek.com.tw>
David Hsu wrote:
>
> I am still fighting this problem. Could somebody give me some hints?
Maybe the processor has got wedged somehow when processing an interrupt,
and the fact you took an exception unwedges it.
I suggest using the old faithful technique of
diag_printf("got here #1\n");
etc. to find out where it reaches! You could also consider using the kernel
instrumentation.
Jifl
> -----Original Message-----
> From: David Hsu [mailto:davidhsu@realtek.com.tw]
> Sent: Friday, January 18, 2002 3:24 PM
> To: ecos-discuss@sources.redhat.com
> Subject: Lock in Cyg_Interrupt::call_pending_DSRs_inner
>
> Dear all,
>
> I implemented my own Ethernet driver and which will bridge the LAN traffics between two Ethernet adapters under PC environment. After running the bridge driver for a while (a couple of hours), the program seemed pending.
>
> The interesting thing was when I stop the GDB debugger, it will always stay at the line Cyg_Interrupt::call_pending_DSRs_inner(), and the traffics birding could be operated again after GDB is free run.
>
> It seemed the problem is locked in INTR module, and it will be resolved automatically after GDB invoked.
>
> Any idea is appreciated.
>
> Thanks.
>
> /David
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine