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 wit
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
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 page can be derived by
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 via
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 remo
On Tue, Apr 3, 2012 at 10:18 AM, vasanth rao naik sabavat
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 following patch from A
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 proposal
On Mon, 2 Apr 2012 10:55:31 -0700
Jerry Toung 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 observed this with
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:
>
> ht
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
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
/dev/r
On Tue, Apr 3, 2012 at 1:52 PM, vasanth rao naik sabavat
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)) {
> 2551 print
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 th
On Tue, Apr 3, 2012 at 3:46 PM, 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 EBR (49
On 4/3/12, Gary Jennejohn 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 -0700
+++ cam/cam_sim.c
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
> | anyo
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
happe
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 mo
21 matches
Mail list logo
