From owner-freebsd-arm@FreeBSD.ORG  Wed Jul  8 14:01:01 2009
Return-Path: <owner-freebsd-arm@FreeBSD.ORG>
Delivered-To: freebsd-arm@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 40528106564A;
	Wed,  8 Jul 2009 14:01:01 +0000 (UTC)
	(envelope-from mih@semihalf.com)
Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109])
	by mx1.freebsd.org (Postfix) with ESMTP id 400E68FC19;
	Wed,  8 Jul 2009 14:01:00 +0000 (UTC)
	(envelope-from mih@semihalf.com)
Received: from [10.0.0.43] (cardhu.semihalf.com [213.17.239.108])
	by smtp.semihalf.com (Postfix) with ESMTPSA id 75989C3AAA;
	Wed,  8 Jul 2009 15:59:55 +0200 (CEST)
Message-ID: <4A54A6B2.1020400@semihalf.com>
Date: Wed, 08 Jul 2009 16:01:22 +0200
From: Michal Hajduk <mih@semihalf.com>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Mark Tinguely <tinguely@casselton.net>
References: <200907071554.n67Fsouv016804@casselton.net>
In-Reply-To: <200907071554.n67Fsouv016804@casselton.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: stas@FreeBSD.org, freebsd-arm@FreeBSD.org
Subject: Re: pmap problem in FreeBSD current
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Porting FreeBSD to the StrongARM Processor <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
	<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
	<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2009 14:01:01 -0000

Mark Tinguely wrote:
> Apologies for the noise. I am not familiar with the sf_buf_alloc/sf_buf_free
> code and sent a bad code sequence. If we remove the mapping, it has to
> come off the active list also:
>
> /*
>  * Detatch mapped page and release resources back to the system.
>  */
> void
> sf_buf_free(struct sf_buf *sf)
> {
> #ifndef ARM_USE_SMALL_ALLOC
> 	mtx_lock(&sf_buf_lock);
> 	sf->ref_count--;
> 	if (sf->ref_count == 0) {
> 		TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry);
> 		nsfbufsused--;
> +		pmap_kremove(sf->kva);
> +		sf->m = NULL;
> +		LIST_REMOVE(sf, list_entry);
> 		if (sf_buf_alloc_want > 0)
> 			wakeup_one(&sf_buf_freelist);
> 	}
> 	mtx_unlock(&sf_buf_lock);
> #endif
>
> --Mark Tinguely.
>
>   
Hello Mark,
Thank you for looking again on r194459.

I've tried to compile kernel using your patch with
changes regarding PG_WRITABLE and arm_unmap_nocache(),
but it didn't help.

My problems are rather related to memory corruption, which
I've observed in uma_core (pointers had bad values and
count of free items in slab had negative value).

I am still concerned about LOR, which has appeared in
svn commit r194459 (I wrote about it in my first mail).
Could you take a look at this LOR?

Thanks for your help.

Best regards,
Michał Hajduk