From owner-freebsd-mips@FreeBSD.ORG  Mon Aug 10 02:20:33 2009
Return-Path: <owner-freebsd-mips@FreeBSD.ORG>
Delivered-To: freebsd-mips@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id D8ACF106564A
	for <freebsd-mips@freebsd.org>; Mon, 10 Aug 2009 02:20:33 +0000 (UTC)
	(envelope-from gonzo@bluezbox.com)
Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78])
	by mx1.freebsd.org (Postfix) with ESMTP id 91DF58FC16
	for <freebsd-mips@freebsd.org>; Mon, 10 Aug 2009 02:20:33 +0000 (UTC)
Received: from [24.87.52.209] (helo=lair.bluezbox.com)
	by expo.ukrweb.net with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD)) (envelope-from <gonzo@bluezbox.com>)
	id 1MaK2U-000FqL-6b; Mon, 10 Aug 2009 04:51:09 +0300
Message-ID: <4A7F7CDB.2030009@bluezbox.com>
Date: Sun, 09 Aug 2009 18:50:19 -0700
From: Oleksandr Tymoshenko <gonzo@bluezbox.com>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Neelkanth Natu <neelnatu@yahoo.com>
References: <153254.15259.qm@web34402.mail.mud.yahoo.com>
In-Reply-To: <153254.15259.qm@web34402.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-mips@freebsd.org
Subject: Re: Diffs to fix L1 cache flush problems
X-BeenThere: freebsd-mips@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Porting FreeBSD to MIPS <freebsd-mips.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
	<mailto:freebsd-mips-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mips>
List-Post: <mailto:freebsd-mips@freebsd.org>
List-Help: <mailto:freebsd-mips-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-mips>,
	<mailto:freebsd-mips-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2009 02:20:34 -0000

Neelkanth Natu wrote:
> Hi,
> 
> This is a simple change that fixes problems invalidating L1 
> data/instruction caches. The problem is that the type of the variable
> that holds the size of the instruction/data caches is uint8_t. Clearly
> this is going to overflow.
> 
> On the Sibyte with 32KB cache size the uint8_t was causing it to be 
> truncated to 0. This in turn makes the cache flush routines turn into
> no-ops.
> 
> I ran into this when testing kernel loadable modules and have verified that
> this change fixes the problem.
     Thanks, committed.