Hi,
I am trying to understand the page table page allocation for a process in
FBSD6.1. I see that the page table pages are allocated by vm_page_alloc().
I believe the virtual address for this allocated page can be derived by
PHYS_TO_DMAP(VM_PAGE_TO_PHYS(m)), however when I compare this address
Guys,
The crash on my machine with debugging has evaded me for a few days. I'm
still looking for further suggestions of things I should grab from the DDB
when it happens again.
Thanks for the help everyone!
___
freebsd-hackers@freebsd.org mailing
On Tue, Apr 3, 2012 at 8:33 AM, vasanth rao naik sabavat
vasanth.raon...@gmail.com wrote:
Hi,
I am trying to understand the page table page allocation for a process in
FBSD6.1. I see that the page table pages are allocated by vm_page_alloc().
I believe the virtual address for this allocated
On 03.04.2012 00:58, Eric McCorkle wrote:
I'm assessing possible summer of code projects, and the EFI work caught
my attention. I've been running FreeBSD on a macbook for a little under
a year now, and booting on EFI is definitely an interest to me. Does
anyone know if this is still a viable
Hello Mark,
Thank you for replying,
Could you please point me to any document which illustrates the
implementation of recursive page tables in FreeBSD for amd64.
Also, I just found that with the following patch from Alon, the usage of
vtopte() is removed in pmap_remove_pages(). Why was this
On Tue, Apr 3, 2012 at 10:18 AM, vasanth rao naik sabavat
vasanth.raon...@gmail.com wrote:
Hello Mark,
Thank you for replying,
Could you please point me to any document which illustrates the
implementation of recursive page tables in FreeBSD for amd64.
Also, I just found that with the
Eric McCorkle writes:
| I'm assessing possible summer of code projects, and the EFI work caught
| my attention. I've been running FreeBSD on a macbook for a little under
| a year now, and booting on EFI is definitely an interest to me. Does
| anyone know if this is still a viable project
On Mon, 2 Apr 2012 10:55:31 -0700
Jerry Toung jryto...@gmail.com wrote:
I am convinced that there is a bug in the CAM code that leads to I/O
starvation.
I have already discussed this privately with some. I am now bringing this up
to
the general audience to get more feedback.
I've
On 04/03/12 13:22, Doug Ambrisko wrote:
EFI is a good task. For generic PC's we need an X64 format. The current
version in FreeBSD is IA32 format. The X64 can boot i386/amd64.
Qemu can be used to test both IA32 and X64 formats. I added some
notes about this on the wiki at:
On 4/2/2012 3:59 PM, Joe Greco wrote:
On 4/2/2012 11:43 AM, Joe Greco wrote:
As a user, you can't win. If you don't report
a problem, you get criticized. If you report a problem but can't figure
out how to reproduce it, you get criticized. If you can reproduce it
but you don't submit a
Hello Mark,
I think pmap_remove_pages() is executed only for the current process.
2549 #ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY
2550 if (pmap != vmspace_pmap(curthread-td_proc-p_vmspace)) {
2551 printf(warning: pmap_remove_pages called with non-current
pmap\n);
2552
Hi,
I open the file, then call mmap() on the whole file and get pointer,
then I work with this pointer. I expect that page should be only once
touched to get it into the memory (disk cache?), but this doesn't work!
I wrote the test (attached) and ran it for the 1G file generated from
On Tue, Apr 3, 2012 at 1:52 PM, vasanth rao naik sabavat
vasanth.raon...@gmail.com wrote:
Hello Mark,
I think pmap_remove_pages() is executed only for the current process.
2549 #ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY
2550 if (pmap != vmspace_pmap(curthread-td_proc-p_vmspace)) {
9.0 R i386
EBR scheme never installed
md0s3 has BSD labels scheme
# gpart destroy -F md0s3
md0s3 destroyed
# gpart create -s BSD md0s3
gpart: geom 'md0s3': File exists
# gpart show -p md0s3
= 0 1023120 md0s3 EBR (499M) [CORRUPT]
0 1023120 - free - (499M)
Eric McCorkle writes:
| On 04/03/12 13:22, Doug Ambrisko wrote:
| EFI is a good task. For generic PC's we need an X64 format. The current
| version in FreeBSD is IA32 format. The X64 can boot i386/amd64.
| Qemu can be used to test both IA32 and X64 formats. I added some
| notes about this
On Tue, Apr 3, 2012 at 3:46 PM, rank1see...@gmail.com wrote:
9.0 R i386
EBR scheme never installed
md0s3 has BSD labels scheme
# gpart destroy -F md0s3
md0s3 destroyed
# gpart create -s BSD md0s3
gpart: geom 'md0s3': File exists
# gpart show -p md0s3
= 0 1023120 md0s3
On 4/3/12, Gary Jennejohn gljennj...@googlemail.com wrote:
It would be interesting to see your patch. I always run HEAD but maybe
I could use it as a base for my own mods/tests.
Here is the patch
diff -rup cam/cam_sim.c cam/cam_sim.c
--- cam/cam_sim.c 2010-06-13 19:09:06.0
On 04/03/12 13:22, Doug Ambrisko wrote:
Eric McCorkle writes:
| I'm assessing possible summer of code projects, and the EFI work caught
| my attention. I've been running FreeBSD on a macbook for a little under
| a year now, and booting on EFI is definitely an interest to me. Does
| anyone
Hi all,
FreeBSD still doesn't have the hotplug side of expresscard support. (I
don't think we have APSM support either, but that's a later problem.)
Would anyone be interested (and have the hardware/skills) to make it work?
If you can make something work, you'll make my 802.11n development
On 03.04.2012 23:46, rank1see...@gmail.com wrote:
GEOM: md0s3: invalid entries in the EBR ignored.
--
Not 100% reproducible.
Running again SAME 'gpart destroy' then 'gpart create', worked.
This should be fixed in stable/9 with r232535.
--
WBR, Andrey V. Elsukov
On 4/2/12 10:12 AM, John Baldwin wrote:
On Monday, April 02, 2012 12:39:26 pm Yuri wrote:
On 04/02/2012 05:31, John Baldwin wrote:
Hmm, I don't know if the port has it, but I did some work on pstack a while
ago to make it work with libthread_db so it at least handles i386 ok. It
needs to be
21 matches
Mail list logo
