From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17299 invoked by alias); 31 Jul 2014 06:22:40 -0000 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 Received: (qmail 17272 invoked by uid 89); 31 Jul 2014 06:22:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL autolearn=no version=3.3.2 X-HELO: nm23-vm7.access.bullet.mail.bf1.yahoo.com Received: from nm23-vm7.access.bullet.mail.bf1.yahoo.com (HELO nm23-vm7.access.bullet.mail.bf1.yahoo.com) (216.109.115.166) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 31 Jul 2014 06:22:37 +0000 Received: from [66.196.81.165] by nm23.access.bullet.mail.bf1.yahoo.com with NNFMP; 31 Jul 2014 06:22:35 -0000 Received: from [98.138.226.241] by tm11.access.bullet.mail.bf1.yahoo.com with NNFMP; 31 Jul 2014 06:22:35 -0000 Received: from [127.0.0.1] by smtp112.sbc.mail.ne1.yahoo.com with NNFMP; 31 Jul 2014 06:22:35 -0000 X-Yahoo-SMTP: DAVHEHCswBBSt52LEL26uXq8GY.pd.0s2WK3iX0- Message-ID: <53D9DF7D.8050705@verizon.net> Date: Thu, 31 Jul 2014 06:22:00 -0000 From: Les Miklosy User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Kurt Siedenburg CC: "ecos-discuss@ecos.sourceware.org" References: <53D8804D.2050404@verizon.net> <279D77960F36224FAA5BAC312F54F6F73712AA9C@AUSP01DAG0302.collaborationhost.net> In-Reply-To: <279D77960F36224FAA5BAC312F54F6F73712AA9C@AUSP01DAG0302.collaborationhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ECOS] RedBoot hits fetch instruction trap X-SW-Source: 2014-07/txt/msg00015.txt.bz2 Hope the following is useful information. I used the -nb -nswb switches when starting grmon to remove the erroneous exception notices. With a break point at RedBoot's _rb_gets I still see multiple traps (think grmon creates the last one in each list). The instruction at 0x4000bee8 is _rb_gets_preloaded. After a 'cont' command the process is trapped and neither RedBoot nor grmon returns control to the user. Anyone have a clue? Here is the sequence just described: grmon2> go 0 breakpoint 1 hit 0x4000c5a4: c02a0000 clrb [%o0] grmon2> hist TIME ADDRESS INSTRUCTIONS/AHB SIGNALS RESULT/DATA 98758063 4000AE00 or %l0, 0x298, %o0 [4001FA98] 98758064 4000C5AC AHB read mst=0 size=2 [7FFFFE4B] 98758065 4000C5B0 AHB read mst=0 size=2 [9E104000] 98758066 4000C5B4 AHB read mst=0 size=2 [01000000] 98758067 4000C5B8 AHB read mst=0 size=2 [9DE3BF90] 98758068 4000C5BC AHB read mst=0 size=2 [9210001A] 98758070 4000AE04 mov 256, %o1 [00000100] 98758071 4000AE08 call 0x4000C5A4 [4000AE08] 98758072 4000AE0C mov 10, %o2 [0000000A] 98758073 4000C5A4 clrb [%o0] [ TRAP ] grmon2> step 10 0x4000c5a4: c02a0000 clrb [%o0] 0x4000c5a8: 8213c000 or %o7, %g1 0x4000c5ac: 7ffffe4b call 0x4000BED8 0x4000c5b0: 9e104000 or %g1, %o7 0x4000bed8: 9de3bf90 save %sp, -112, %sp 0x4000bedc: 1110004e sethi %hi(0x40013800), %o0 0x4000bee0: ea022390 ld [%o0 + 0x390], %l5 0x4000bee4: a4100018 mov %i0, %l2 0x4000bee8: d24e0000 ldsb [%i0], %o1 0x4000beec: a6102000 mov 0, %l3 grmon2> hist TIME ADDRESS INSTRUCTIONS/AHB SIGNALS RESULT/DATA 98758147 40013B90 AHB read mst=0 size=2 [FFFFFFFF] 98758148 4000BEE0 ld [%o0 + 0x390], %l5 [FFFFFFFF] 98758149 4000BEE4 mov %i0, %l2 [ TRAP ] 98758155 4000BEE4 mov %i0, %l2 [4001FA98] 98758156 4000BEE8 ldsb [%i0], %o1 [ TRAP ] 98758169 4001FA98 AHB read mst=0 size=2 [00656C70] 98758170 4000BEE8 ldsb [%i0], %o1 [00000000] 98758171 4000BEEC mov 0, %l3 [ TRAP ] 98758177 4000BEEC mov 0, %l3 [00000000] 98758178 4000BEF0 cmp %o1 [ TRAP ] grmon2> cont -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss