From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7581 invoked by alias); 7 Sep 2007 14:52:33 -0000 Received: (qmail 7572 invoked by uid 22791); 7 Sep 2007 14:52:33 -0000 X-Spam-Check-By: sourceware.org Received: from wa-out-1112.google.com (HELO wa-out-1112.google.com) (209.85.146.179) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Sep 2007 14:52:29 +0000 Received: by wa-out-1112.google.com with SMTP id l24so630352waf for ; Fri, 07 Sep 2007 07:52:27 -0700 (PDT) Received: by 10.115.75.1 with SMTP id c1mr1749573wal.1189176747515; Fri, 07 Sep 2007 07:52:27 -0700 (PDT) Received: by 10.114.38.7 with HTTP; Fri, 7 Sep 2007 07:52:27 -0700 (PDT) Message-ID: <2a3305fe0709070752w7c1bca5eg37b06c2f6ab0ffe8@mail.gmail.com> Date: Fri, 07 Sep 2007 14:52:00 -0000 From: "Mike Arthur" To: ecos-discuss@ecos.sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] Erroneous Network Traffic Affects Ethernet Debugging on PowerPC X-SW-Source: 2007-09/txt/msg00038.txt.bz2 We have an in house HAL for a PowerPC target that can be fatally affected by erroneous network traffic while debugging over the ethernet. If there is network traffic going to the RedBoot IP (i.e. ping flooding the RedBoot IP) or there are network broadcasts during tests such as heaptest, the target will become unresponsive to the point that GDB will lose its connection to the target. We are not sure what is causing GDB to timeout from the target. It appears the target gets stuck in the RedBoot ethernet code processing packets; we have determined this by the use of a JTAG. This of course does not happen if the host and target are on an isolated network without any other traffic besides GDB packets going to RedBoot. Debugging works great over ethernet on an isolated network. Does anybody have any ideas of where the bug could reside? Could the bug be in the ethernet drivers, in the stand alone stack, somewhere in the variant or platform HALs? Has anyone ever ran into problems with network traffic during network debug sessions? What caused the problem? Any tips on how to debug problems with ethernet debugging? The target becomes unresponsive at different points depending on the template. Here is how far the target gets with the 'default' template running heaptest: --------------------------------------------------------------------------------------------------------- (gdb) load Loading section .text, size 0x15950 lma 0x100000 Loading section .rodata, size 0x103c lma 0x115950 Loading section .eh_frame, size 0x84 lma 0x116990 Loading section .data, size 0x3a40 lma 0x116a18 Start address 0x100000, load size 107600 Transfer rate: 286933 bits/sec, 505 bytes/write. (gdb) c Continuing. INFO: 0x00115950, CRC a75f> INFO: INFO: INFO: INFO: PASS: Here is how far the target gets with the 'net' template running heaptest: ---------------------------------------------------------------------------------------------------- (gdb) load Loading section .text, size 0x63958 lma 0x100000 Loading section .rodata, size 0x310c lma 0x163958 Loading section .eh_frame, size 0x84 lma 0x166a68 Loading section .data, size 0x4988 lma 0x166af0 Start address 0x100000, load size 439408 Transfer rate: 292938 bits/sec, 510 bytes/write. (gdb) c Continuing. [cyg_net_init] Init: mbinit(0x00000000) Remote communication error: No route to host. Thanks, Mike -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss