question about amd64 pagetable page allocation.
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 with the virtual address accessed in pmap_remove_pages() they are not the same. The virtual address of a *PTE in pmap_remove_pages() is something like *0x80643200 * However, the virtual address of the page allocated by vm_page_alloc() is * 0xff033c6a *I would also like to understand the importance of loc_PTmap, I believe the pmap_remove_pages() is derving the page table page addresses from loc_PTmap? (kgdb) p loc_PTmap Cannot access memory at address 0x8000 How do we relate the loc_PTmap to the page table pages allocated by vm_page_alloc() in _pmap_allocpte(). Thanks, Vasanth ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
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 list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: question about amd64 pagetable page allocation.
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 page can be derived by PHYS_TO_DMAP(VM_PAGE_TO_PHYS(m)), however when I compare this address with the virtual address accessed in pmap_remove_pages() they are not the same. The virtual address of a *PTE in pmap_remove_pages() is something like *0x80643200 * However, the virtual address of the page allocated by vm_page_alloc() is * 0xff033c6a *I would also like to understand the importance of loc_PTmap, I believe the pmap_remove_pages() is derving the page table page addresses from loc_PTmap? (kgdb) p loc_PTmap Cannot access memory at address 0x8000 How do we relate the loc_PTmap to the page table pages allocated by vm_page_alloc() in _pmap_allocpte(). Thanks, Vasanth The answer to your questions will be more obvious when you get an understanding of the Recursive Page Tables. --Mark Tinguely. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: EFI on intel
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 project proposal? I certainly have the skills to undertake it, I just want to make sure that it stands a chance of actually being selected. Hi, Eric Yes, this project is still needed for the FreeBSD. -- WBR, Andrey V. Elsukov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: question about amd64 pagetable page allocation.
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 removed? http://lists.freebsd.org/pipermail/svn-src-all/2009-March/006006.html Thanks, Vasanth On Tue, Apr 3, 2012 at 10:56 AM, Mark Tinguely marktingu...@gmail.comwrote: 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 page can be derived by PHYS_TO_DMAP(VM_PAGE_TO_PHYS(m)), however when I compare this address with the virtual address accessed in pmap_remove_pages() they are not the same. The virtual address of a *PTE in pmap_remove_pages() is something like *0x80643200 * However, the virtual address of the page allocated by vm_page_alloc() is * 0xff033c6a *I would also like to understand the importance of loc_PTmap, I believe the pmap_remove_pages() is derving the page table page addresses from loc_PTmap? (kgdb) p loc_PTmap Cannot access memory at address 0x8000 How do we relate the loc_PTmap to the page table pages allocated by vm_page_alloc() in _pmap_allocpte(). Thanks, Vasanth The answer to your questions will be more obvious when you get an understanding of the Recursive Page Tables. --Mark Tinguely. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: question about amd64 pagetable page allocation.
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 following patch from Alon, the usage of vtopte() is removed in pmap_remove_pages(). Why was this removed? http://lists.freebsd.org/pipermail/svn-src-all/2009-March/006006.html Thanks, Vasanth On Tue, Apr 3, 2012 at 10:56 AM, Mark Tinguely marktingu...@gmail.com wrote: 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 page can be derived by PHYS_TO_DMAP(VM_PAGE_TO_PHYS(m)), however when I compare this address with the virtual address accessed in pmap_remove_pages() they are not the same. The virtual address of a *PTE in pmap_remove_pages() is something like *0x80643200 * However, the virtual address of the page allocated by vm_page_alloc() is * 0xff033c6a *I would also like to understand the importance of loc_PTmap, I believe the pmap_remove_pages() is derving the page table page addresses from loc_PTmap? (kgdb) p loc_PTmap Cannot access memory at address 0x8000 How do we relate the loc_PTmap to the page table pages allocated by vm_page_alloc() in _pmap_allocpte(). Thanks, Vasanth The answer to your questions will be more obvious when you get an understanding of the Recursive Page Tables. --Mark Tinguely. Search for recursive page tables start with 32 bits first. I did not read it, but the below page looks promising: http://www.rohitab.com/discuss/topic/31139-tutorial-paging-memory-mapping-with-a-recursive-page-directory/ The nice thing about recursive page table is the MMU does the work. But: 1) User recursive page tables work only for the current map. 2) Kernel mappings are placed at the top of every map - so the kernel recursive addresses will always be valid. As the comment in the link states, that change converted from using user recursive page table virtual address (which is only valid when the map is current) to using the physical to virtual direct map (which is always valid). --Mark Tinguely. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: EFI on intel
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? I certainly | have the skills to undertake it, I just want to make sure that it stands | a chance of actually being selected. 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: http://wiki.freebsd.org/IdeasPage#EFI_support_for_FreeBSD.2BAC8-i386_and_FreeBSD.2BAC8-amd64_.28GSoC.29 Qemu is nice since it can runs an UEFI BIOS via the OVMF project and emulate a DOS file system by pointing qemu to a directory. So then it is easy to build something, toss it into a directory, start qemu and test. Thanks, Doug A. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CAM disk I/O starvation
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 observed this with my onboard ATI IXP700 AHCI SATA controller and 2 or 3 SATA disks. When one disk gets busy all others are pretty much blocked until it finishes. Seems to me that this behavior is (fairly) recent. [snip] I have a patch and it fixes those problems. I can share it to the list if requested to. da0 and da1 now both automatically get 126 openings and based on that, extra logic implements fairness in cam/cam_xpt.c. No more 0 MB/s on da1. This is on 8.1-RELEASE FreeBSD. 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. -- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: EFI on intel
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: http://wiki.freebsd.org/IdeasPage#EFI_support_for_FreeBSD.2BAC8-i386_and_FreeBSD.2BAC8-amd64_.28GSoC.29 Qemu is nice since it can runs an UEFI BIOS via the OVMF project and emulate a DOS file system by pointing qemu to a directory. So then it is easy to build something, toss it into a directory, start qemu and test. Thanks, Doug A. I'm drafting an application right now. I emailed the listed contacts (Rui Paulo and Andrey Elsukov) a moment ago. I've done background research on this already, as part of getting FreeBSD to work on Mac hardware. QEMU caught my attention as a testbed. Also, I found out Apple EFI implementations are non-standard. They specifically look for an HFS+ partition and load a specific file. The workaround is pretty simple, of course: just wrap the boot loader in an HFS+ image and write it to a partition reserved for that purpose. Anyway, if I'm going to propose this, I need to list possible mentors. Skill-wise, I'm well equipped to take it on. I anticipate needing someone who's a committer, preferably with good knowledge of the kernel sources. -- Eric McCorkle Computer Science Ph.D Student e...@shadowsun.net signature.asc Description: OpenPGP digital signature
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
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 workaround, you get criticized. If you submit a workaround but you don't submit a patch, you get criticized. If you submit a patch but it's not in the preferred format, you get criticized. I'm still not sure what you're taking as criticism. Nothing I've said was intended that way, nor should it be read that way. If you feel that you've been criticized by others in the manner you describe, you should probably take it up with them on an individual basis. It certainly seemed to me that As much as I'm sensitive to your production requirements, realistically it's not likely that you'll get a helpful result without testing a newer version. 8.2 came out over a year ago, many many things have changed since then. was an unwarranted criticism for reasons that I've already explained. Everything in that paragraph is a fact. If you feel criticized when people state facts, I'm not sure how much I can help you. Please note, I didn't say, You're an idiot for running old stuff. I even explicitly stated that I understood *why* the OP is running an old version. Nevertheless, the facts are what they are. The only way we can deal rationally with the world is to acknowledge reality and deal with it. Wishing it were otherwise isn't really useful. :) Or perhaps this: And since you can't reliably reproduce the problem, how do you expect us to? I understand that these sorts of bugs are difficult/annoying, etc. Been there, done that. Which would appear to be suggesting that either (or possibly both): 1) The reporter has a duty to be able to reliably reproduce the problem prior to reporting, and/or 2) That there was some unreasonable expectation on the reporter's part that you were expected to reproduce it. Quite the contrary, I was responding to your implication that there is some other answer that we should be able to give the OP, other than Try a newer version. Various people have chimed in on the thread, all have offered suggestions, none of which (AFAICS) have helped. I continue to maintain that the best course of action for the OP would be to try the latest 8-stable. And BTW, there are (at least) 2 reasons for that. First, the bug may actually be fixed. But second, we're in the middle of a release cycle for 8.3 right now. If the bug persists in the latest code it will be easier to get the right eyes onto the problem. That benefits both the OP and the community at large. Doug ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: question about amd64 pagetable page allocation.
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 return;
2553 }
2554 #endif
I dont still get it why this was removed?
Thanks,
Vasanth
On Tue, Apr 3, 2012 at 12:42 PM, Mark Tinguely marktingu...@gmail.comwrote:
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 following patch from Alon, the usage of
vtopte() is removed in pmap_remove_pages(). Why was this removed?
http://lists.freebsd.org/pipermail/svn-src-all/2009-March/006006.html
Thanks,
Vasanth
On Tue, Apr 3, 2012 at 10:56 AM, Mark Tinguely marktingu...@gmail.com
wrote:
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 page can be derived
by
PHYS_TO_DMAP(VM_PAGE_TO_PHYS(m)), however when I compare this address
with
the virtual address accessed in pmap_remove_pages() they are not the
same.
The virtual address of a *PTE in pmap_remove_pages() is something like
*0x80643200
*
However, the virtual address of the page allocated by vm_page_alloc()
is
*
0xff033c6a
*I would also like to understand the importance of loc_PTmap, I
believe
the
pmap_remove_pages() is derving the page table page addresses from
loc_PTmap?
(kgdb) p loc_PTmap
Cannot access memory at address 0x8000
How do we relate the loc_PTmap to the page table pages allocated by
vm_page_alloc() in _pmap_allocpte().
Thanks,
Vasanth
The answer to your questions will be more obvious when you get an
understanding of the Recursive Page Tables.
--Mark Tinguely.
Search for recursive page tables start with 32 bits first. I did not
read it, but the below page looks promising:
http://www.rohitab.com/discuss/topic/31139-tutorial-paging-memory-mapping-with-a-recursive-page-directory/
The nice thing about recursive page table is the MMU does the work. But:
1) User recursive page tables work only for the current map.
2) Kernel mappings are placed at the top of every map - so the kernel
recursive addresses will always be valid.
As the comment in the link states, that change converted from using
user recursive page table virtual address (which is only valid when
the map is current) to using the physical to virtual direct map (which
is always valid).
--Mark Tinguely.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
problems with mmap() and disk caching
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/random, the result is the following:
Prepare file:
# swapoff -a
# newfs /dev/ada0b
# mount /dev/ada0b /mnt
# dd if=/dev/random of=/mnt/random-1024 bs=1m count=1024
Purge cache:
# umount /mnt
# mount /dev/ada0b /mnt
Run test:
$ ./mmap /mnt/random-1024 30
mmap: 1 pass took: 7.431046 (none: 262112; res: 32; super:
0; other: 0)
mmap: 2 pass took: 7.356670 (none: 261648; res:496; super:
0; other: 0)
mmap: 3 pass took: 7.307094 (none: 260521; res: 1623; super:
0; other: 0)
mmap: 4 pass took: 7.350239 (none: 258904; res: 3240; super:
0; other: 0)
mmap: 5 pass took: 7.392480 (none: 257286; res: 4858; super:
0; other: 0)
mmap: 6 pass took: 7.292069 (none: 255584; res: 6560; super:
0; other: 0)
mmap: 7 pass took: 7.048980 (none: 251142; res: 11002; super:
0; other: 0)
mmap: 8 pass took: 6.899387 (none: 247584; res: 14560; super:
0; other: 0)
mmap: 9 pass took: 7.190579 (none: 242992; res: 19152; super:
0; other: 0)
mmap: 10 pass took: 6.915482 (none: 239308; res: 22836; super:
0; other: 0)
mmap: 11 pass took: 6.565909 (none: 232835; res: 29309; super:
0; other: 0)
mmap: 12 pass took: 6.423945 (none: 226160; res: 35984; super:
0; other: 0)
mmap: 13 pass took: 6.315385 (none: 208555; res: 53589; super:
0; other: 0)
mmap: 14 pass took: 6.760780 (none: 192805; res: 69339; super:
0; other: 0)
mmap: 15 pass took: 5.721513 (none: 174497; res: 87647; super:
0; other: 0)
mmap: 16 pass took: 5.004424 (none: 155938; res: 106206; super:
0; other: 0)
mmap: 17 pass took: 4.224926 (none: 135639; res: 126505; super:
0; other: 0)
mmap: 18 pass took: 3.749608 (none: 117952; res: 144192; super:
0; other: 0)
mmap: 19 pass took: 3.398084 (none: 99066; res: 163078; super:
0; other: 0)
mmap: 20 pass took: 3.029557 (none: 74994; res: 187150; super:
0; other: 0)
mmap: 21 pass took: 2.379430 (none: 55231; res: 206913; super:
0; other: 0)
mmap: 22 pass took: 2.046521 (none: 40786; res: 221358; super:
0; other: 0)
mmap: 23 pass took: 1.152797 (none: 30311; res: 231833; super:
0; other: 0)
mmap: 24 pass took: 0.972617 (none: 16196; res: 245948; super:
0; other: 0)
mmap: 25 pass took: 0.577515 (none: 8286; res: 253858; super:
0; other: 0)
mmap: 26 pass took: 0.380738 (none: 3712; res: 258432; super:
0; other: 0)
mmap: 27 pass took: 0.253583 (none: 1193; res: 260951; super:
0; other: 0)
mmap: 28 pass took: 0.157508 (none: 0; res: 262144; super:
0; other: 0)
mmap: 29 pass took: 0.156169 (none: 0; res: 262144; super:
0; other: 0)
mmap: 30 pass took: 0.156550 (none: 0; res: 262144; super:
0; other: 0)
If I ran this:
$ cat /mnt/random-1024 /dev/null
before test, when result is the following:
$ ./mmap /mnt/random-1024 5
mmap: 1 pass took: 0.337657 (none: 0; res: 262144; super:
0; other: 0)
mmap: 2 pass took: 0.186137 (none: 0; res: 262144; super:
0; other: 0)
mmap: 3 pass took: 0.186132 (none: 0; res: 262144; super:
0; other: 0)
mmap: 4 pass took: 0.186535 (none: 0; res: 262144; super:
0; other: 0)
mmap: 5 pass took: 0.190353 (none: 0; res: 262144; super:
0; other: 0)
This is what I expect. But why this doesn't work without reading file
manually?
I've also never seen super pages, how to make them work?
I've been playing with madvise and posix_fadvise but no luck. BTW,
posix_fadvise(POSIX_FADV_WILLNEED) does nothing as the commentary says,
shouldn't this be documented in the manual page?
All tests were run under 9.0-STABLE (r233744).
--
Andrey Zonov
/*_
* Andrey Zonov (c) 2011
*/
#include sys/mman.h
#include sys/types.h
#include sys/time.h
#include sys/stat.h
#include err.h
#include fcntl.h
#include stdlib.h
#include string.h
#include unistd.h
int
main(int argc, char **argv)
{
int i;
int fd;
int num;
int block;
int pagesize;
size_t n;
size_t size;
size_t none, incore, super, other;
char *p;
char *tmp;
char *vec;
char *vecp;
struct stat sb;
struct timeval tp, tp1, tp2;
if (argc 2 || argc 4)
errx(1, usage: mmap filename [num] [block]);
fd = open(argv[1], O_RDONLY);
if (fd == -1)
err(1, open());
num = 1;
if (argc = 3)
num = atoi(argv[2]);
pagesize = getpagesize();
block = pagesize;
if (argc == 4)
block = atoi(argv[3]);
if
Re: question about amd64 pagetable page allocation.
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)) {
2551 printf(warning: pmap_remove_pages called with non-current
pmap\n);
2552 return;
2553 }
2554 #endif
I dont still get it why this was removed?
Thanks,
Vasanth
That is pretty old code. Newer code does not make that assumption.
Without the assumption that the pages are from the current map, then you
have to use the direct physical - virtual mapping:
2547#ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY
2548pte = vtopte(pv-pv_va);
2549#else
2550pte = pmap_pte(pmap, pv-pv_va);
2551#endif
--Mark Tinguely.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
gpart and it's EBR confusion
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) During one of above tasks, on main console kernel outputs: -- GEOM: md0s3: invalid entries in the EBR ignored. -- Not 100% reproducible. Running again SAME 'gpart destroy' then 'gpart create', worked. Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: EFI on intel
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 the wiki at: | http://wiki.freebsd.org/IdeasPage#EFI_support_for_FreeBSD.2BAC8-i386_and_FreeBSD.2BAC8-amd64_.28GSoC.29 | | Qemu is nice since it can runs an UEFI BIOS via the OVMF project | and emulate a DOS file system by pointing qemu to a directory. So | then it is easy to build something, toss it into a directory, start | qemu and test. | | I'm drafting an application right now. I emailed the listed contacts | (Rui Paulo and Andrey Elsukov) a moment ago. | | I've done background research on this already, as part of getting | FreeBSD to work on Mac hardware. QEMU caught my attention as a | testbed. Also, I found out Apple EFI implementations are non-standard. | They specifically look for an HFS+ partition and load a specific file. | The workaround is pretty simple, of course: just wrap the boot loader in | an HFS+ image and write it to a partition reserved for that purpose. | | Anyway, if I'm going to propose this, I need to list possible mentors. | Skill-wise, I'm well equipped to take it on. I anticipate needing | someone who's a committer, preferably with good knowledge of the kernel | sources. Both Rui and Andrey should be able to to fit your need for mentors. I can help with some stuff. It seems you've looked at the Mac side a fair amount. It might be good to look at X64 and IA64. Don't know how much can be shared. There is an efi loader in the tree for IA64. I've only played around with generic PC's (Dell, AMI based systems and qemu). I built grub and had grub boot via efi. Doug A. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gpart and it's EBR confusion
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 EBR (499M) [CORRUPT] 0 1023120 - free - (499M) During one of above tasks, on main console kernel outputs: -- GEOM: md0s3: invalid entries in the EBR ignored. I've had a similar problem, but with gpart destroy and a GPT partition. If I create a GPT partition on a disk then for some reason begin an install process again by rebooting and starting from the beginning of bsdinstall I am unable to destroy the old partition scheme. I encountered this with sysinstall and 8.0-8.2 as well. The workaround that I found is to use dd rather than gpart destroy. Just dd the drive or part of drive in question from /dev/zero or /dev/random and everything is a clean slate. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CAM disk I/O starvation
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 -0700
+++ cam/cam_sim.c 2012-03-19 13:05:10.0 -0700
@@ -87,6 +87,7 @@ cam_sim_alloc(sim_action_func sim_action
sim-refcount = 1;
sim-devq = queue;
sim-max_ccbs = 8; /* Reserve for management purposes. */
+ sim-dev_count = 0;
sim-mtx = mtx;
if (mtx == Giant) {
sim-flags |= 0;
diff -rup cam/cam_sim.h cam/cam_sim.h
--- cam/cam_sim.h 2010-06-13 19:09:06.0 -0700
+++ cam/cam_sim.h 2012-03-19 15:34:17.0 -0700
@@ -118,6 +118,8 @@ struct cam_sim {
u_int max_ccbs;
/* Current count of allocated ccbs */
u_int ccb_count;
+ /* Number of peripheral drivers mapped to this sim */
+ u_int dev_count;
};
diff -rup cam/cam_xpt.c cam/cam_xpt.c
--- cam/cam_xpt.c 2010-06-13 19:09:06.0 -0700
+++ cam/cam_xpt.c 2012-03-29 11:41:51.0 -0700
@@ -303,7 +303,7 @@ xpt_schedule_dev_allocq(struct cam_eb *b
int retval;
if ((dev-drvq.entries 0)
- (dev-ccbq.devq_openings 0)
+ (dev-runs_token dev-ccbq.queue.array_size)
(cam_ccbq_frozen(dev-ccbq, CAM_PRIORITY_TO_RL(
CAMQ_GET_PRIO(dev-drvq))) == 0)) {
/*
@@ -327,7 +327,7 @@ xpt_schedule_dev_sendq(struct cam_eb *bu
int retval;
if ((dev-ccbq.queue.entries 0)
- (dev-ccbq.dev_openings 0)
+ (dev-runs_token dev-ccbq.queue.array_size)
(cam_ccbq_frozen_top(dev-ccbq) == 0)) {
/*
* The priority of a device waiting for controller
@@ -973,6 +973,9 @@ xpt_add_periph(struct cam_periph *periph
struct cam_ed *device;
int32_t status;
struct periph_list *periph_head;
+ struct cam_eb *bus;
+ struct cam_et *target;
+ struct cam_ed *devptr;
mtx_assert(periph-sim-mtx, MA_OWNED);
@@ -991,6 +994,8 @@ xpt_add_periph(struct cam_periph *periph
status = camq_resize(device-drvq,
device-drvq.array_size + 1);
+ if (periph-periph_name != NULL
strncmp(periph-periph_name, da,2) ==0 )
+ device-sim-dev_count++;
device-generation++;
SLIST_INSERT_HEAD(periph_head, periph, periph_links);
@@ -998,6 +1003,24 @@ xpt_add_periph(struct cam_periph *periph
mtx_lock(xsoftc.xpt_topo_lock);
xsoftc.xpt_generation++;
+
+ if (device != NULL device-sim-dev_count 1
+(device-sim-max_dev_openings device-sim-dev_count)) {
+ TAILQ_FOREACH(bus, xsoftc.xpt_busses, links) {
+ if (bus-sim != device-sim)
+ continue;
+ TAILQ_FOREACH(target, bus-et_entries, links) {
+ TAILQ_FOREACH(devptr,
target-ed_entries, links) {
+ /*
+* The number of openings/tags
supported by the sim (i.e controller)
+* is evenly distributed between all
devices that share this sim.
+*/
+ cam_ccbq_resize(devptr-ccbq,
+
(devptr-sim-max_dev_openings/devptr-sim-dev_count));
+}
+}
+}
+}
mtx_unlock(xsoftc.xpt_topo_lock);
return (status);
@@ -3072,6 +3095,11 @@ xpt_run_dev_allocq(struct cam_eb *bus)
}
/* We may have more work. Attempt to reschedule. */
+ device-runs_token++;
+ if (device-runs_token = device-ccbq.queue.array_size) {
+ device-runs_token = 0;
+ break;
+ }
xpt_schedule_dev_allocq(bus, device);
}
devq-alloc_queue.qfrozen_cnt[0]--;
@@ -3139,7 +3167,6 @@ xpt_run_dev_sendq(struct cam_eb *bus)
devq-send_openings--;
devq-send_active++;
- xpt_schedule_dev_sendq(bus, device);
if (work_ccb (work_ccb-ccb_h.flags CAM_DEV_QFREEZE) != 0){
/*
@@ -3170,6 +3197,13 @@ xpt_run_dev_sendq(struct cam_eb *bus)
*/
sim = work_ccb-ccb_h.path-bus-sim;
(*(sim-sim_action))(sim, work_ccb);
+
+ device-runs_token++;
+ if (device-runs_token = device-ccbq.queue.array_size) {
+ device-runs_token = 0;
+ break;
+ }
+ xpt_schedule_dev_sendq(bus, device);
Re: GSoC: EFI on intel
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 know if this is still a viable project proposal? I certainly | have the skills to undertake it, I just want to make sure that it stands | a chance of actually being selected. 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: http://wiki.freebsd.org/IdeasPage#EFI_support_for_FreeBSD.2BAC8-i386_and_FreeBSD.2BAC8-amd64_.28GSoC.29 Based on the feedback I've gotten, I've gone ahead and submitted the proposal. It should be available, and I can edit it up to the 6th. -- Eric McCorkle Computer Science Ph.D Student e...@shadowsun.net signature.asc Description: OpenPGP digital signature
Request: expresscard (PCIe hotplug) support
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 happen so much faster. :-) I'd be eternally grateful. Thanks! Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gpart and it's EBR confusion
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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Is there any modern alternative to pstack?
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 modified to use something like libunwind though or some other unwinder. And possibly it should use libelf instead of its own ELF-parsing code. I see pstack -1.2_1 failing even on i386: pstack: cannot read context for thread 0x1879f pstack: failed to read more threads Yes, threads don't work for modern binaries (newer than 4.x) without my changes to make it use libthread_db. You can find the patch I used for this at http://www.freebsd.org/~jhb/patches/pstack_threads.patch should be in ports? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
