From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 22 May 2015 18:38:27 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:53395 "EHLO linux-mips.org" rhost-flags-OK-OK-OK-FAIL) by eddie.linux-mips.org with ESMTP id S27006677AbbEVQiZhZeuo (ORCPT ); Fri, 22 May 2015 18:38:25 +0200 Received: from scotty.linux-mips.net (localhost.localdomain [127.0.0.1]) by scotty.linux-mips.net (8.14.9/8.14.8) with ESMTP id t4MGcRWM007971; Fri, 22 May 2015 18:38:27 +0200 Received: (from ralf@localhost) by scotty.linux-mips.net (8.14.9/8.14.9/Submit) id t4MGcRFs007970; Fri, 22 May 2015 18:38:27 +0200 Date: Fri, 22 May 2015 18:38:27 +0200 From: Ralf Baechle To: Joshua Kinard Cc: linux-mips@linux-mips.org Subject: Re: IP30: SMP, Almost there? Message-ID: <20150522163826.GB6467@linux-mips.org> References: <55597B21.4010704@gentoo.org> <5559D483.905@gentoo.org> <555C1A53.9010803@gentoo.org> <555D7469.7090806@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <555D7469.7090806@gentoo.org> User-Agent: Mutt/1.5.23 (2014-03-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 47570 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips On Thu, May 21, 2015 at 02:00:09AM -0400, Joshua Kinard wrote: > Where I am lost is, though, why would I get an IBE on a 'beqz' instruction? > It's a valid instruction from MIPS-I ('beqz' is just 'beq' w/ $0 as rt). the > R10K Manual states this: > > """ > A Bus Error exception occurs when a processor block read, upgrade, or > double/single/partial-word read request receives an external ERR completion > response, or a processor double/single/partial-word read request receives an > external ACK completion response where the associated external > double/single/partial-word data response contains an uncorrectable error. This > exception is not maskable. > """ > > My guess is there's still something not kosher with icache flushing somewhere. > I can reboot this kernel multiple times and not always get the same IBE. Most Not or improperly flush the I-cache will result in stale instructions getting executed. An IBE error otoh is the result of a bus error being signalled for the CPU's attempt to load instructions from memory. With the exception of a few special cases I-cache flushing doesn't happen when eecuting kernel code, but only for userland and it's also somewhat unlikely for improper I-cache flushing to result in an IBE error. A huge problem tracking down the cause of a bus error is that they're getting signalled by an external agent that is they are not generated by the CPU itself and there may be a significant delay until the CPU actually takes the exception. In my experience the EPC is practically always worthless in tracking down the cause of the bus error. Details depend on circumstances, as usual. Ralf