From owner-freebsd-current  Sat Apr 17 16:58:35 1999
Delivered-To: freebsd-current@freebsd.org
Received: from midten.fast.no (midten.fast.no [195.139.251.11])
	by hub.freebsd.org (Postfix) with ESMTP id 3D47514EE9
	for <current@FreeBSD.ORG>; Sat, 17 Apr 1999 16:58:29 -0700 (PDT)
	(envelope-from tegge@fast.no)
Received: from fast.no (IDENT:tegge@midten.fast.no [195.139.251.11])
	by midten.fast.no (8.9.1/8.9.1) with ESMTP id BAA12947;
	Sun, 18 Apr 1999 01:55:58 +0200 (CEST)
Message-Id: <199904172355.BAA12947@midten.fast.no>
To: dillon@apollo.backplane.com
Cc: current@FreeBSD.ORG
Subject: Re: successfull SMP / current on duel P-III box.Yahhhh.  I've successfully brought -current up in SMP on a duel P-III box.
From: Tor.Egge@fast.no
In-Reply-To: Your message of "Sat, 17 Apr 1999 00:36:00 -0700 (PDT)"
References: <199904170736.AAA67808@apollo.backplane.com>
X-Mailer: Mew version 1.70 on Emacs 19.34.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Sun, 18 Apr 1999 01:55:58 +0200
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>     I have one problem, though.  During the kernel boot:
> 
> 	isa_dmainit(2, 1024) failed
> 
>     And, of course, any access to something that needs isa 
>     dma (e.g. floppy) panics.  It's a large-memory machine (1G).
>     I was under the impression that this was supposed to be fixed
>     in the vm/vm_page.c commit:

[...]

>     Anyone have any ideas?

Yes.

Using a recent -current GENERIC kernel, I reproduced the problem with
a machine having 512 MB memory.

All physical memory below 16 MB is used.

vm_page_list_find uses TAILQ_LAST when prefer_zero is set, thus 
pv_table occupies the physical memory below 640 KB.

The remaining physical memory below 16 MB is allocated to
vm_page_array and vm_page_buckets in vm_page_startup, or was reserved
earlier (e.g. kernel text, data, bss).

IMO, vm_page_array and vm_page_buckets should not use physical memory
below 16 MB on large-memory machines. This can be achieved by
modyfing the contents of phys_avail, causing the largest region to 
be above 16 MB.

GENERIC kernel:
	(kgdb) print phys_avail
	$66 = {4096, 651264, 3624960, 536862720, 0, 0, 0, 0, 0, 0}

The kernel I normally use:
	(kgdb) print phys_avail
	$1 = {4096, 651264, 3301376, 16777216, 16777216, 536608768, 0, 0, 0, 0}

This works fine for machines with 512 MB and 1 GB memory.

For machines with more than 2 GB memory, the size of pv_table might become
a problem.

Alternating between TAILQ_INSERT_HEAD and TAILQ_INSERT_TAIL in
vm_page_startup might be a workaround for this second problem (causing
the memory below 16 MB not already allocated by vm_page_startup to be
in the middle of the page queues).

- Tor Egge


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message