> 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 majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
