Re: ARM + CACHE_LINE_SIZE + DMA
On Mon, May 21, 2012 at 11:20 AM, Ian Lepore free...@damnhippie.dyndns.org wrote: On Fri, 2012-05-18 at 16:13 +0200, Svatopluk Kraus wrote: On Thu, May 17, 2012 at 10:07 PM, Ian Lepore free...@damnhippie.dyndns.org wrote: On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote: Hi, I'm working on DMA bus implementation for ARM11mpcore platform. I've looked at implementation in ARM tree, but IMHO it only works with some assumptions. There is a problem with DMA on memory block which is not aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent. Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. Then first cache line associated with the buffer can be divided into two parts, A and B, where A is a memory we know nothing about it and B is buffer memory. The same stands for last cache line associatted with the buffer. We have no problem if a memory is coherent. Otherwise it depends on memory attributes. ... My suggestion of making a temporary writable mapping was the answer to how to correctly change memory attributes on a page which is in use, at least in the existing code, which is for a single processor. You don't need, and won't even use, the temporary mapping. You would make it just because doing so invokes logic in arm/arm/pmap.c which will find all existing virtual mappings of the given physical pages, and disable caching in each of those existing mappings. In effect, it makes all existing mappings of the physical pages DMA_COHERENT. When you later free the temporary mapping, all other existing mappings are changed back to being cacheable (as long as no more than one of the mappings that remain is writable). I don't know that making a temporary mapping just for its side effect of changing other existing mappings is a good idea, it's just a quick and easy thing to do if you want to try changing all existing mappings to non-cacheable. It could be that a better way would be to have the busdma_machdep code call directly to lower-level routines in pmap.c to change existing mappings without making a new temporary mapping in the kernel pmap. The actual changes to the existing mappings are made by pmap_fix_cache() but that routine isn't directly callable right now. Also, as far as I know all of this automatic disabling of cache for multiple writable mappings applies only to VIVT cache architectures. I'm not sure how the pmap code is going to change to support VIPT and PIPT caches, but it may no longer be true that making a second writable mapping of a page will lead to changing all existing mappings to non-cacheable. -- Ian We don't want to carry the VIVT cache fixing code to VIPT/PIPT. I like the x86 approach of marking the page with a cache type (default/device/uncached/etc). The page mapping routines (for example pmap_qenter() on a clustered write) will honor that cache type in all future mappings. It is easy to implement. Other allocations, such as page tables, can benefit from an attributed allocation too. I also like having a separate allocator for the sub-page bus_dmamem_alloc() requests that want uncached buffers. These entries can stick around for a long time. If we just malloced the entries, then the other threads that happen to allocate data from the same page are penalized with uncached buffers too. --Mark. ___ 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: ARM + CACHE_LINE_SIZE + DMA
On Thu, May 17, 2012 at 8:20 AM, Svatopluk Kraus onw...@gmail.com wrote: Hi, I'm working on DMA bus implementation for ARM11mpcore platform. I've looked at implementation in ARM tree, but IMHO it only works with some assumptions. There is a problem with DMA on memory block which is not aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent. Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. Then first cache line associated with the buffer can be divided into two parts, A and B, where A is a memory we know nothing about it and B is buffer memory. The same stands for last cache line associatted with the buffer. We have no problem if a memory is coherent. Otherwise it depends on memory attributes. 1. [no cache] attribute No problem as memory is coherent. 2. [write throught] attribute The part A can be invalidated without loss of any data. It's not problem too. 3. [write back] attribute In general, there is no way how to keep both parts consistent. At the start of DMA transaction, the cache line is written back and invalidated. However, as we know nothing about memory associated with part A of the cache line, the cache line can be filled again at any time and messing up DMA transaction if flushed. Even if the cache line is only filled but not flushed during DMA transaction, we must make it coherent with memory after that. There is a trick with saving part A of the line into temporary buffer, invalidating the line, and restoring part A in current ARM (MIPS) implementation. However, if somebody is writting to memory associated with part A of the line during this trick, the part A will be messed up. Moreover, the part A can be part of another DMA transaction. To safely use DMA with no coherent memory, a memory with [no cache] or [write throught] attributes can be used without problem. A memory with [write back] attribute must be aligned on CACHE_LINE_SIZE. However, for example mbuf, a buffer for DMA can be part of a structure which can be aligned on CACHE_LINE_SIZE, but not the buffer itself. We can know that nobody will write to the structure during DMA transaction, so it's safe to use the buffer event if it's not aligned on CACHE_LINE_SIZE. So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and we want to avoid bounce pages overhead, we must support additional information to DMA transaction. It should be easy to support the information about drivers data buffers. However, what about OS data buffers like mentioned mbufs? The question is following. Is or can be guaranteed for all or at least well-known OS data buffers which can be part of DMA access that the not CACHE_LINE_SIZE aligned buffers are surrounded by data which belongs to the same object as the buffer and the data is not written by OS when given to a driver? Any answer is appreciated. However, 'bounce pages' is not an answer. Thanks, Svata Sigh. A several ideas by several people, but a good answer has not been created yet. SMP will make this worse. To make things worse, there are drivers that use memory from the stack as DMA buffers. I was hoping that mbufs are pretty well self-contained, unless you expect to modify them while DMA is happening. This is on my to-do list. --Mark. ___ 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] [ARM] arm cleanup - my own proposal
On Mon, Apr 16, 2012 at 8:21 AM, Mark Tinguely marktingu...@gmail.com wrote: ... There is a lot of ARM work going on in the shadows. I know of other things, but will let them say what they are doing. ... Correction to my posting. I am not removing pv_entrys but removing the flag of attributes ( pvh_attrs which hold PVF_xxx values). The ARMv7 and ARMv8 have some OS bits in the page table entries. --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] [ARM] arm cleanup - my own proposal
On Sat, Apr 14, 2012 at 1:37 PM, Damjan Marion dmar...@freebsd.org wrote: On Apr 14, 2012, at 6:02 PM, Ian Lepore wrote: It's been my growing impression for about a year that the arm support in FreeBSD has atrophied to the point where it can barely be said that it's supported at all. Now I see this morning that marius@ has committed a set of style cleanups to the at91 code (r234281), so maybe it's not quite as dead as I feared. Hi Ian, Are you aware of projects/armv6[1] in svn? Due to big changes in architecture introduced with ARMv6 we have separate tree where all ongoing development is happening. Hopefully we will be able to merge back changes to HEAD soon. We have (partially) working support for recent Marvel SoC and some TI boards (PandaBoard/OMAP4, Beaglebone/AM335x). There is also OMAP3 code waiting to be integrated. Also Andrew is working on moving to ARM EABI[2] which will allow us to use llvm/clang and all new ARM goodies which are not supported in our aged gcc. Any help is welcome... Damjan [1] http://svnweb.freebsd.org/base/projects/armv6/ [2] http://svnweb.freebsd.org/base/projects/arm_eabi There is a lot of ARM work going on in the shadows. I know of other things, but will let them say what they are doing. I am doing an experimental implementation using the ARMv7 hardware features on the pandaboard getting ready for ARMv8. As of this weekend, the ARMv7 experimental pmap/support is booting multi-user. There is a lot of improvements, fixing, tweeking, and polishing. (I am taking out domains shared level1 pagetables, remove the pv_entry. I will eventually start doing the 64 bit extended address support, etc). I eventually want to change the boot (fold chunks of initarm() into pmap/machdep because they are constant for every platform. --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 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: 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
Re: Porting FreeBSD to Raspberry Pi
On 11/4/2011 11:02 AM, Lev Serebryakov wrote: Hello, Arnaud. You wrote 4 ноября 2011 г., 19:48:29: $89, 700MHz Cortex A8, 256MB DRR2, micro-SD. However, do not expect being able to run FreeBSD on it before a few years :) What is so special about A8? It is the consumer technology of today. The best people can afford without being in ARM's RD centers. Let me tell you what is going to happen. ARM11 has been around for years, it will take you a year or two to complete the project, nice, hacker thrill, you did it. However, by the time you release it, the Raspberry Pi will be sold-out and will be replaced by an ARMv7 core, smaller, faster, eventually cheaper. By that time, the current technology will be a 64bits MP-core ARMv8, And you will be in the exact same situation as today, FreeBSD lagging one or two generation behind Linux, keep up. I am sure people will be running ARM9 (ARMv5) for a long time. Your point that they will not be available as consumer products is well taken. As I'm not a ARM specialist, I have several questions. Does porting to ARM11 (ARVv6, am I right?) will make porting to ARMv7 (Cortex) easier? You see, i486 adds some nice commands, tricks and configuration registers to i386, but porting to i486 after you have working port to i386/Protected mode is almost trivial. Or it is completely different architectures, which doesn't have anything in common? ARMvX is only a core, as far as I understand. How much different are implementations from different vendors? MMU? Bus? Configuration space? We can run ARMv6/ARMv7using the ARMv5 model. But it would not be very efficient. The ARMv6/7 new features can improve how things run. For example we have hardware assisted atomic commands, we can remove all the VIVT cache fixing code, and we can share the kernel address space in each memory map. But IMO, there are enough new features in the ARMv7 that finally make something pv_entrys un-necessary. The Cortex-A15 will be out next year with a whole new memory model. (40 bit physical, 32 bit virtual kernel, 40 bit hypervisor virtual). It will have an AMBA change that can shed some bus mastering problems. Besides the core new features, we always have all the different peripherals for each SoC... Why do you think, porting to different ARMs should go sequentially? :) Yes, we (FreeBSD) doesn't have a lot of resources, but as nobody could be forced to do what he don't want, it is better, IMHO, to have ARM11 port, that to not have any ARM port at all. But I agree, that port to Cortex-A8/A9 looks more interesting :) The Cortex-A9 pandaboard is $174. The Cortex-A8 and A9 have some differences, but they are more alike than the ARM11 and the Cortex-A8. It will be tough to stay current with the hardware advances without some kind of sponsorship. --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: Kernel Space Memory Allocation
On 10/27/2011 3:31 AM, Daniel Grech wrote:
Hi,
I am allocating memory from a device driver in the kernel and passing it on
to another driver. In the other driver it is neccessary for me to determine
whether the address passed is from user space or kernel space as this driver
can also be called from user space. I am currently using the following check
to determine if the address is in kernel space or userspace :
if ( ( (char *) VM_MIN_KERNEL_ADDRESS= address) (address= (char *)
VM_MAX_KERNEL_ADDRESS) )
{
KERNEL SPACE
}
else
{
USER SPACE
}
However, this does not always work. Sometimes although I allocate memory in
the kernel using the malloc macro, this returns an address which is not in
the above range. Is there any workaround for this problem?
Thanks in advance for your help.
Daniel
___
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
Be careful if using user virtual addresses in DMA POST commands, because
the interrupt handler may not have the the same address space as the
caller. For example: BUS_DMASYNC_POSTREAD copying a bounce buffer to a
user VA.
--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: mmap performance and memory use
On 10/11/2011 11:12 AM, Alan Cox wrote: On 10/10/2011 16:28, Wojciech Puchar wrote: is it possible to force VM subsystem to operate on superpages when possible - i mean swapping in 2MB chunks? Currently, no. For some applications, like the Sun/Oracle JVM, that have code to explicitly manage large pages, there could be some benefit in the form of reduced overhead. So, it's on my to do list, but no where near the top of that list. Alan Am I correct in remembering that super-pages have to be aligned on the super-page boundary and be contiguous? If so, in the mmap(), he may want to include the 'MAP_FIXED' flag with an address that is on a super-page boundary. Right now, the VMFS_ALIGNED_SPACE that does the VA super-page alignment is only used for device pagers. Similarly, if the allocated physical pages for the object are not contiguous, then MAP_PREFAULT_READ will not result in a super-page promotion. --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: 8.2R i386 bassed md root, doesn't like all machines
On 9/1/2011 8:17 AM, rank1see...@gmail.com wrote: Works excellent! I boot it from USB stick. Now I added ~150 MB of ports to it. From that point on, it doesn't boot on all machines. Booting 2 times in a row on laptop with 4 gb ram: http://www.starforce.biz/md_root_1.jpg http://www.starforce.biz/md_root_2.jpg Without ports, it did booted fine! Then I plug it in desktop with 2 GB of ram and booted it and it works! I've did it again, just to be sure. Back to my laptop and same fail again. 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 This must be a 32 bit i386 kernel. From the vm_thread_new() error messages, your kernel virtual memory map is depleted. The OS uses KVA for a physical page attribute table. Therefore the 4GB machine will use more KVA than a 2GB. Apparently this difference is a enough to cause you problems. Either increase your KVA (KVA_PAGES setting in your kernel configuration file; see sys/i386/include/pmap.h look for values) or decrease your KVA use (memory drive?). --Mark ___ 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] Timeconter Performance Improvements
On 3/27/2011 5:32 PM, Warner Losh wrote:
On Mar 26, 2011, at 8:43 AM, Jing Huang wrote:
Hi,
Thanks for you all sincerely. Under your guidance, I read the
specification of TSC in Intel Manual and learned the hardware feature
of TSC:
Processor families increment the time-stamp counter differently:
• For Pentium M processors (family [06H], models [09H, 0DH]); for Pentium 4
processors, Intel Xeon processors (family [0FH], models [00H, 01H, or 02H]);
and for P6 family processors: the time-stamp counter increments with every
internal processor clock cycle.
• For Pentium 4 processors, Intel Xeon processors (family [0FH],
models [03H and
higher]); for Intel Core Solo and Intel Core Duo processors (family [06H], model
[0EH]); for the Intel Xeon processor 5100 series and Intel Core 2 Duo processors
(family [06H], model [0FH]); for Intel Core 2 and Intel Xeon processors (family
[06H], display_model [17H]); for Intel Atom processors (family [06H],
display_model [1CH]): the time-stamp counter increments at a constant rate.
Maybe we would implement gettimeofday as fellows. Firstly, use cpuid
to find the family and models of current CPU. If the CPU support
constant TSC, we look up the shared page and calculate the precise
time in usermode. If the platform has invariant TSCs, and we just
fallback to a syscall. So, I think a single global shared page maybe
proper.
I think that the userspace portion should be more like:
int kernel_time_type) SECTION(shared);
struct tsc_goo tsc_time_data SECTION(shared);
switch (kernel_time_type) {
case 1:
/* code to use tsc_time_data to return time */
break;
default:
/* call the kernel */
}
I think we should avoid hard-coding lists of CPU families in userland. The
kernel init routines will decide, based on the CPU type and other stuff if this
optimization can be done. This would allow the kernel to update to support new
CPU types without needing to churn libc.
Warner
P.S. The SECTION(shared) notation above just means that the variables are in
the shared page.
On Sat, Mar 26, 2011 at 10:12 PM, John Baldwinj...@freebsd.org wrote:
On Saturday, March 26, 2011 08:16:46 am Peter Jeremy wrote:
On 2011-Mar-25 08:18:38 -0400, John Baldwinj...@freebsd.org wrote:
For modern Intel CPUs you can just assume that the TSCs are in sync across
packages. They also have invariant TSC's meaning that the frequency
doesn't change.
Synchronised P-state invariant TSCs vastly simplify the problem but
not everyone has them. Should the fallback be more complexity to
support per-CPU TSC counts and varying frequencies or a fallback to
reading the time via a syscall?
I think we should just fallback to a syscall in that case. We will also need
to do that if the TSC is not used as the timecounter (or always duplicate the
ntp_adjtime() work we do for the current timecounter for the TSC timecounter).
Doing this easy case may give us the most bang for the buck, and it is also a
good first milestone. Once that is in place we can decide what the value is
in extending it to support harder variations.
One thing we do need to think about is if the shared page should just export a
fixed set of global data, or if it should export routines. The latter
approach is more complex, but it makes the ABI boundary between userland and
the kernel more friendly to future changes. I believe Linux does the latter
approach?
--
John Baldwin
___
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
___
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
If a user process can perform a rfork(2) or rfork_thread(3) with RFMEM
option, then can't the same page table be active on multiple processors?
Mapping per CPU page(s) to a fixed user addess(es) would only hold the
last switched cpu's information.
x86 architectures use a segment pointer to keep the kernel per cpu
information current.
--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: DMA controller on Northbridge?
On 3/22/2011 12:11 PM, Matthew Fleming wrote: How can I tell if the Northbridge on a machine has a built-in DMA controller? And if it does, what device would I use to control it? I ask because I'm working with a PCI card that has a 36-bit physical address limit, and that means bounce buffers when using more than 64GB of memory. I'd prefer not to use bounce buffers, and since the card's memory that I'm using is mapped into the physical space of the FreeBSD host, the entire address space of the card that I care about is available to FreeBSD. So while pio to the card's memory is too slow to be useful, if there was a way to use a DMA controller on the motherboard to get data into and out of the card, that may be preferable to using the card's DMAC with the limited address space. But all that's just theory -- I have no idea how to tell whether the mobo has a DMAC, and if it does, how to control it. Help? :-) Attached is the boot dmesg; I can also run pciconf commands, etc., to help out with figuring out what I have. Thanks, matthew ___ 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 Sounds like you are referring to IOMMU: http://software.intel.com/en-us/blogs/2009/03/02/intels-virtualization-for-directed-io-aka-iommu-part-1/ --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: FreeBSD 6 vs 8.1
On 3/18/2011 3:35 AM, Mats Lindberg wrote: So - after a while I've made some observations. My problem is actually connected to arp. My config is very static so basically I want to turn off arp requests. Somewhere in the startup scripts I did sysctl -w net.link.ether.inet.max_age=2147483647 (max accepted value) Which on freebsd-6.x worked fine. In freebsd-8.1 this makes the kernel arp functionality go bezerk - probably an integer overflow somewhere. arp requests were sent countinously from my freebsd-8.1 node to others, flooding the network. I tried to lower this value and found that 5s works fine 10s does not. 5s is OK to me so I won't try to narrow it down more. The reason I was suspecting swapping problems was that after a while with the flooding going on I got a kernel panic saying 'page fault', which I would guess is a another bug, but, with a sensible setting on the arp timeout the kernel panic does not show itself any longer. I've googled for my arp-setting problem but not found anything on it. So - maybe I'm the first to see this. Should I enter a bug report somewhere? I guess this forum is not the place. /Mats Did your HZ (timer interrupts per second) increase from 100 on FreeBSD-6 to 1000 on FreeBSD-8.1? This must be a 32 bit computer / OS because that variable is multiplied to hz: canceled = callout_reset(la-la_timer, hz * V_arpt_keep, arptimer, la); and: #definecallout_reset(c, on_tick, fn, arg)\ callout_reset_on((c), (on_tick), (fn), (arg), (c)-c_cpu) where: int callout_reset_on(struct callout *, int , void (*ftn)(void *), void *, int) I would guess that you are wrapping with 32 bit arithmetic to a small value. Both the hz==100 and hz==1000 will wrap to about the same number (a negative number). I did not look at the FreeBSD 6.x callout, but I think in the FreeBSD 8 callout, negative on_tick will be immediately called on the next tick.. A page fault panic is a kernel access to a non-mapped VA (a bad pointer). The panic message would have the VA and instruction address information. --Mark ___ 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: bus_dmamap_load_uio() and user data
Ahh. I think bus_dmamap_load_uio() doesn't do deferred callbacks (i.e. mandates BUS_DMA_NOWAIT), and probably is always invoked from curthread. Even in the case of aio, the thread's vmspace is the effective one at the time bus_dmamap_load_uio() would be invoked, so in practice it is safe. I ran into ?this? problem with bus_dmamap_sync and bounce buffers while trying to do a BUS_DMASYNC_POSTREAD in interrupt context. The sync code was trying to copy from bounce buffer to the UVA without proper context - SEGFAULT. I tried to move the sync to the ioctl context that is used by the userland to figure out which part of the buffer is ready ... this /kind of/ worked, but lead to DMA problems in ata (which I didn't yet investigate) when trying to write the buffer to disk. I meanwhile moved to exporting a kernel buffer instead, using OBJT_SG - which is a bit more work and eats KVA, but at least on amd64 there is no shortage of that. -- Max Thank-you for the information. If it is possible for the user context to be inactive in the DMA routines, (as you pointed out the interrupt context) then I was thinking we would have to: 1) include the pmap in the bounce buffer structures in busdma_load_buffer(). 2) if pmap is not kernel pmap, and not equal to the current pmap then a) map physical page in current pmap b) copy from buffer using the new mapping unfortunately, it is possible one of the L2 cache is VIPT which will introducing page color issue and requiring every color KVAs. we have the same situation in the bus dma sync routine. I will see if those with this hardware would put a test case for inactive user pmap into the code. We would see it more often in cache syncing than just happen to trip over bounce buffer situation. --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: bus_dmamap_load_uio() and user data
You should use the pmap from the thread in the uio structure. Similar to
this from the x86 bus_dma code:
if (uio-uio_segflg == UIO_USERSPACE) {
KASSERT(uio-uio_td != NULL,
(bus_dmamap_load_uio: USERSPACE but no proc));
pmap = vmspace_pmap(uio-uio_td-td_proc-p_vmspace);
} else
pmap = NULL;
Later when doing VA - PA conversions the code does this:
if (pmap)
paddr = pmap_extract(pmap, vaddr);
else
paddr = pmap_kextract(vaddr);
We do that, but I notice that all the architecture that implement
bounce buffers assume the VA is in the current map. Most of the
addresses are KVA, but bus_dmamap_load_uio() can be in the user space.
I was wondering about the sequence:
bus_dmamap_load_uio() user space
dma_load_buffer()
add bounce page save UVA (in caller user map)
later:
bus_dma_sync
copies bounce buffer from saved UVA. - here is my concern. The user pmap
is not remembered use current pmap.
Since the bounce buffer copy routines have been running in other architectures
for years without corruption, I was wondering we can safely assume that the
dma sync is running in the same thread/address space as the bus_dmamap_load_uio
call. I was hoping you would say, don't worry the scheduler would always
reload the same thread to execute the dma sync code ...
Thank-you,
--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
bus_dmamap_load_uio() and user data
In the user space case of bus_dmamap_load_uio(), the calling thread is stored in uio-uio_td, in which the user's pmap can be determined. The ARM processor, with the possible exception of the ARMv7 MPcore with snoop control unit, needs to make the caches consistent before DMA. I noticed that the routine, _bus_dmamap_sync(), copies data into the bounce buffer using current pmap. Can/should we assume the uio sent from to bus_dmamap_load_uio() is always in the same address space as thread that is executing the _bus_dmamap_sync()? --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: Help debugging: Fatal kernel mode data abort: 'External Linefetch Abort (P)'
I don't know anything about the code other than what I read today ... It appears from you boot traces the owin[0].owin_xlate_[lo | hi] values should be fine in iq80321.c - an VERBOSE_INIT_ARM would confirm it. You might want to test if the sc pointer in iq80321.c has the same value as the global i80321_softc pointer. You can add those print statements to an VERBOSE_INIT_ARM. It will tell you if something changed the global pointer or if something overwrote the owin values in the structure. If global pointer or owin was changed before the pci attach code, you can put the appropriate test into the earlier (obio, uart, itimer, iopwdtimer) attach. None of these attaches use the global i80321_softc pointer. --Mark. ___ 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: understanding of PTD symbol
Hello all, I am having doubts in understanding the usage of the symbol PTD. Could anyone pls explain the usage of PTD in the FreeBSD kernel?? In pmap_growkernel when we execute the following instruction wht is returned by pdir_pde ? Is it the physical address of a page table for KVA addressing?? while (pdir_pde(PTD, kernel_vm_end)) When I used objdump on the kernel executable i found the address of PTD symbol to be 0xBFEFF000 , I could not understand this , as in a virtual memory with 1G/3G split the kernel addressing must be between the addresses 0xC000 and 0x. Regards, Mehul On the i386/amd64, the page table sits just below the kernel virtual memory. The recursive virtual address reference to the page table is inside this address. Assume i386 with 4 byte pointers and 4GB virtual address space with the 3GB user vm and 1GB kernel vm: the PTmap will start at 0xbfc0 (which is one 4MB entry below the KVA). the PTD page directory descripters for the page table descripter will be 0xdeff000 which is 767 4K entries into the page table. Note: 768 is the 3G mark, so 767 is one less than 3/4 into the page table. PTDpde is the page table descriptor the the page table. It is PTD + 767 * 4 I found it easier to draw the various layouts and the page table itself. The i386 in 32 bit mode is 10 bits for the page directory, 10 bits for the page table and 12 bits for the physical page. The ARM processor is funner with 12/8/12 bits. --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: copy-on-write anonymous memory?
Teemu Rinta-aho wrote (some edits): I have created a kernel module that stores references to memory objects. I.e. when a process makes a syscall to the module, it will create a snapshot of the memory area, and after that the writes from the process to that memory area should create a shadow object. The next syscall should again store a pointer to the current topmost shadow object and then the next write creates yet another shadow object. Etc... When the snapshots are removed, the shadow chains may collapse normally. Here's an illustration of what I want (first syscall OK, second one not): * Legend: U/u = userspace K/k = kernel * * U:vm_map_entry_u - object * || * SYSCALL * || * \/ * U:vm_map_entry_u - object_shadow - object * / * K:vm_map_entry_k * || * SYSCALL * || * \/ * U:vm_map_entry_u - object_shadow - object_shadow - object * // * K:vm_map_entry_k / * K:vm_map_entry_k Now, the problem is that the first snapshot works as it should. However, the second one doesn't, and the write goes to the one and same shadow object, even if I restore MAP_ENTRY_COW and MAP_ENTRY_NEEDS_COPY manually in my handler function which is storing the snapshot. Any ideas? Usually, a fork() creates the inheritance between parent and child COW memory space. Start: vm_map_entry - object_shadow - object fork(): vm_map_entry - object_shadow -\ |- (object_shadow*) - object vm_map_entry - object_shadow -/ This is slightly different from your description/drawing, in the way changes are inherited; for example: process 1 is created, process 1 writes page 0. process 2 is created. process 1 writes p1 (or p0 again). Your description/drawing implies that process 2 see this change from process 1. You are not forking over a COW memory area. Sounds like the syscall will have manually create the inheritance. You can manually link the object_shadows the way you want to get the desired inheritance. Process removals should collapse the shadows automatically. Matt Dillion wrote a brief VM description (http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-design/). The book, The Design and Implementation of the 4.4BSD Operating System is another great reference. Mark Tinguely ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: indefinite wait buffer patch
Since eyeballs are in swap_page.c - is the putpages panic string mislabeled:
swap_pager_putpages(vm_object_t object, vm_page_t *m, int count,
boolean_t sync, int *rtvals)
{
int i;
int n = 0;
if (count m[0]-object != object) {
panic(swap_pager_getpages: object mismatch %p/%p,
putpages
--Mark Tinguely.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM / FreeBSD Install problem
John Baldwin [EMAIL PROTECTED] says: APIC IDs are not programmable (well, they are on I/O APICs, but not local=20 APICs). However, I am working on patches to support all valid APIC IDs for= =20 both mptable and MADT. Bumping up NLAPICS as a temporary workaround should= =20 suffice for now. =2D-=20 John Baldwin IMO, the quick solution also requires that MAX_APICID in [amd64/amd64 | i386/i386]/local_apic.c needs to be changed because lapic_create() checks if the passed apic_id MAX_APICID. Also in [amd64/amd64 | i386/i386]/mp_machdep.c checks in cpu_add() if the passed apic_id = MAXCPU. There are a couple other checks in mp_machdep.c before converting to use the cpu_apic_ids[] array. I was curious, and wrote up a patch file with the potential minor changes for -current at http://www.casselton.com/~tinguely/acpicid.patch . I saw one more change needed to use on FreeBSD 6.2-RELEASE. --Mark Tinguely ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM / FreeBSD Install problem
If you can either install without ACPI, or remove two of the CPUs
during installation, this should be fairly easy to fix: change the
definition of NLAPICS in /usr/src/sys/{amd64,i386}/acpica/madt.c and
rebuild your kernel, then boot with ACPI enabled and report back to
us.
DES
--=20
Dag-Erling Sm=F8rgrav - [EMAIL PROTECTED]
I suggested that in email too, but looking closer, I think the MAXCPU
needs to be increased because the cpu number uses the apic_id. Or could
that be changed with a logical CPU to APIC ID lookup?
Isn't the APIC IDs programmable? not that I am suggesting that, I
can think of headaches of all the places (like interrupt tables)
where it needs to be changed, not to mention the worry that the
lower APIC IDs were assigned to IOAPICs.
--Mark Tinguely
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: contigmalloc() and mmap()
I browsed kernel tree, I found those drivers which use contigmalloc() and contigfree() always call these two kernel interfaces in _attach() and _detach(), but in my driver, I call contigmalloc() in ioctl(), and call contigfree() in a callout function which is set by callout_reset(). What I want to know is if contigmalloc() and contigfree() can only be used under some conditions? Allocating early prevents unfullfilled requests due to fragmentation of the physical memory. I believe starting in FreeBSD 5.x, contigmalloc() started to fill physical memory requests from the higher memory locations to help with fragmentation. FreeBSD 5/6 has a Unified Meory Allocator that helps allocate/free cycles. And recently, I modified my driver, I allocated a big chunk of contiguous physical memory using contigmalloc() in the driver's _attach() function, and I use a simple first-fit algorithm to manage this memory myself, which mean in ioctl() I use my allocate/deallocate functions instead of contigmalloc(), in _detach() function contigfree() is called to free the big chunk of memory, no panic again, but sometimes, process cannot get the correct data from the mmaped memory. I don't know why. Are you sure that you are allocating page length request on page boundaries? Are you checking the success/failure of the allocation? Your page faults before implementing your own allocation sounds like you did not check the return status from contigmalloc() and were dereferencing a pointer on page 0. --Mark Tinguely. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 4.11-RELEASE SACK
There was a posting to a FreeBSD mailing list (I believe -net, check the archives) within the last couple months with the FreeBSD 4.x SACK difference. Warning: There have been some serious fixes to SACK on FreeBSD current since that posting. I did not try the SACK changes because of the fixes that were, at that time, forthcoming. --Mark Tinguely. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: KVA space problems?
This has been seen before and there is at least one open problem report
that the kernel malloc() unexpectantly returns NULL in WAITOK situations.
http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/53382
---
I think malloc returns before your patch, namely around line 199:
va = (caddr_t) kmem_malloc(kmem_map, (vm_size_t)ctob(npg), flags
);
if (va == NULL) {
splx(s);
return ((void *) NULL);
}
Although, I agree that the kernel malloc() should not do this, if KVM
is depleted or fragmented to this point, I suspect your changes of simply
retrying again will cause an infinite loop in malloc().
If malloc() sleeps waiting for KVM to be freed, my guess this will lead to
the processes to hang for a long time if not forever.
I think this because people are bumping the MBUFs numbers up and not
changing the KVM size, once the KVM is depleted/fragmented it shouldn't
come down for a long time.
---
The pre 5.x VM assumes KVM will not be depleted. contigmalloc() used to leak
physical pages if the KVM got depleted. I was told the system will panic
soon anyway, why put them back.
--Mark Tinguely
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing KVA_PAGES and broken pthreads
Intel x86 hardware allows windows of 4GB of virtual memory even if you have the PSE-36 and the PAE extensions with more the 4GB of physical memory. Sound a little like Intel's 64KB windows, but if I remember correctly, the 4GB does not have to be contiguous. It would require a true MMU such as those in the 64 bit architectures (AMD opteron, Intel ia64, sparc64) to simulataneously be able to use more than 4GB of RAM. So far the thought it is better to go with a true 64 MMU than take and get a flat address space than take the performance hit (, plus the memory loss for the much larger page table without much benefit) than try to shuffle in the 4GB windows. Check the thread on this topic in the archives. --Mark Tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bus_dmamem_alloc failing
since the allocated space is larger that a physical page (65536 4096), bus_dmamem_alloc() allocates physical contiguous memory. After repeated allocations and frees, the physical memory pages will fragment and the allocation will fail. You may need to rethink your allocation strategy, such as hold some memory allocations static between unloads and loads if your device can take non-physical contiguous memory chunks, use another allocation technique or other imaginative tricks. --Mark Tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bus_dmamem_alloc failing
On Fri, Nov 15, 2002 at 10:36:18AM -0600, mark tinguely wrote: since the allocated space is larger that a physical page (65536 4096), bus_dmamem_alloc() allocates physical contiguous memory. After repeated allocations and frees, the physical memory pages will fragment and the allocation will fail. deleted text Chuck Tuffli asks: When the driver frees the memory with bus_dmamem_free(), can other drivers or the kernel not use this memory? The memory is avaliable to the kernel/drivers when bus_dmamem_free() is called. The problem for you is that someone else does allocate a page within the 16 page chunk making it unable to reallocatable by you, so the next bus_dmamem_alloc() looks for the next 16 page contiguous chunk. This continues until there is no more 16 page contiguous chunks available and the bus_dmamem_alloc() fails. FreeBSD does not have a physical memory defragmenter. --Mark Tinguely To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Supporting HW_WDOG?
Is there any documentation, or source code, demonstrating how to implement a hardware watchdog for FreeBSD using the HW_WDOG kernel option? the HW_WDOG option attempts to keep the watchdog from expiring while the core memory is being dumped to a IDE drive. The SCSI dadump() does not use wdog_tickler. your hardware watchdog driver will have to set the varible wdog_tickler to your watch dog tickler routine, or a generic routine if multiple watchdog timers could be supported in one machine. --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: More dynamic KVA_SPACE
Another interesting processor family is the AMD x86-64 ClawHammer. I do not know the progress the FreeBSD/x86-64 project. I would imagine the major difficulty will be getting a running compiler. I just wish AMD added an 8K page size so the Page Table Maps did not eat so much memory. --mark tinguely To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: broadcast packets not reaching sender on if_hwassist capable interfaces
Summary: FreeBSD 4.3 Broadcast IP datagrams not looping on Broadcom GigE card. Also, why is the decision to loop the packet back made in ether_output rather than in ip_output? Off the top of my head I can't see any particular advantage, but perhaps there is. The disadvantage is that I will have to disable hardware assist for broadcast packets to make things work right. the bge sets the interface output to be ether_output() which is called from the ip_output() after all thse flags have been set.. Are these packets that fail part of a IP fragment? m_copy does not copy the hwassist flags. we see the same problem with multicast packets. Bill Fenner wrote a simular multicast patch before FreeBSD 4.5-RELEASE, but even that fix has not been included into the tree yet either. In ip_output, we should either we need to copy the hwassist flag in _copy or in the code that follows a m_copy, or force the checksum calculations. if your packets are not part of a fragment, then let me know. --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 4.6-RC, Dell PowerEdge 4600, PCI boot-time bus walk
4.6-RC (which I am assuming is release candidate) still doesn't walk the entire PCI bus and find all devices for a Dell Poweredge 4600. found- vendor=0x1044, dev=0xa500, revid=0x02 class=06-04-00, hdrtype=0x01, mfdev=1 subordinatebus=1secondarybus=1 found- vendor=0x1044, dev=0xa501, revid=0x02 class=0e-00-01, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 intpin=a, irq=5 map[10]: type 1, range 32, base fa00, size 25 could it be this unknown class on the DPT board that stops the PCI bus traversal? Is this board removable? --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: quotactl issues
No replies on this. Nobody has any ideas? Nobody has seen it until now. SOMEbody did - that's why they hacked edquota.c! See code fragment below. I tried to replicate the problem with DDB and QUOTA compiled into the kernel but could not. Grasping at straws, I am wondering if he has some kind of corruption in the quota file. But even corruption in the quota file should not make quotactl() return a EINVAL (besides the documented bad command, or type, that would be from a low driver with a bad unit number). Since this is not generically reproducable, could you add DDB to the kernel and trace a run through the quoactl() routine to see why the EINVAL is generated? --mark tinguely To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory management bug in FreeBSD 4.5 RELEASE
int i = 32;
int
main(){ while (1) malloc(i); }
As long as i is in between 1 and 32, all memory is used up and all swap is used up,
and then the process is killed.
Again, when i 32, all seems well.
dirty at least a byte of the data:
main(){ while (1) { char *p (char *) malloc(i); *p=0; }
if the memory has not been dirtied, the system does not need to remember
it when physical memory has been depleted.
--mark.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Memory management bug in FreeBSD 4.5 RELEASE
But why does this not happen after i = 32 ? I hardly see any increase in memory usage after that. I think you are backstoring pages that hold the allocated memory bucket pointers, not the data itself. in the i 32 you run out of these pages of pointers to buckets before you hit your data size VM limit. After 32 bits, you are allocating bigger, using fewer buckets, and therefore few pointers to the buckets. you hit your data size VM limit before you exceed the back store of these pointers. you do not check the return code from you malloc, so after you exceed your data size VM limit, your program is just spinning, no more pages of pointers will be squeeze out to swap backstore. dirty a byte in your malloc block to push out all of the allocated data. --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DMA memory allocation/deallocation
I am having some memory allocation woes in my FreeBSD kernel device driver. I allocate DMAable memory with something like: retval = bus_dma_tag_create ... (1 20), 1, (1 20), ... which seems to succeed/work. But when I attempt to release the allocated memory like this: bus_dmamap_unload(memtag, memmap); bus_dmamem_free(memtag, (void *) vaddr, memmap); bus_dmamap_destroy(memtag, memmap); bus_dma_tag_destroy(memtag); there was a contig_free bug that was squashed between 4.4 and 4.5, by Matt Dillon. If I remember correctly there is a slight leak if the contig_malloc failed, but that would not be your problem. it is possible that something else on the system is allocating at least single block in that now freed, but perfect sized chunk. as a result, the new allocation can no longer use that memory and has to search higher in RAM. try a few back to back bus_dmamem_alloc() and bus_dmamem_free() without any other operations and if that is sliding up in RAM there is a(nother) problem in the contiguous free...my guess it will operate normally and the problem is related to someone allocating a block and breaking up that nice contiguous chunk. --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DMA memory allocation/deallocation
Thanks for the reply Mark, I tracked my problem down. In 'bus_dmamem_alloc', 'contigmalloc' is used if the size is greater than PAGE_SIZE. However, in 'bus_dmamem_free' the same PAGE_SIZE check is performed, but nothing is done for the case where the size is greater than PAGE_SIZE. So I then called contigfree explicitly in my code, and the memory is released. you may want a bugreport. Another problem though, I am allocating a large DMAable buffer ~300MB. I get to allocate this and free this twice on our system (512MB memory). However, when I try a third time to load my device driver and allocate the memory, it fails. Subsequent attempts also fail. It seems that something is allocating in the middle of my nice big free buffer. Does 'contigalloc' do anything sensible like shuffling arround of pages in physical memory to make room for the requested amount of space? It tries to squeeze out pageable memory, but it is not always successful. no other re-arranging is done because we don't know all the pointers and devices that are using that memory. but since most allocations are done by grabbing the first available chunk that works, you can try the trick of allocating the big things towards the end of the memory range and work your way backwards, unfortunately that would mean bypassing the politically correct way of allocating the buffer by using bus_dmamem_alloc(). Evenually that trick will fail too. You can make that memory static, by not really releasing it. Of course no one else can use it either. the contig allocation leak I alluded to was if you have lots of physical memory, but did not expand the kernel virtual map. then we don't put back the contiguous memory back into the available array. since you should have a kernel virtual of at least 1GB and only physical of 512MB, you are not hitting this situation. --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ARP and AX.25 (help needed)
I am working on implementation of AX.25 protocol. My code also needs ARP and I was wondering if there is a way to use existing ARP code, or do I need to duplicate code and use my arp structure instead original one? I need arp to resolve HAM addresses to IP addresses. HAM address has seven u_chars (6 for callsign one one for SSID). Now if anyone has any idea how could I solve this without duplicating same code, I would be very thankful. the arp code has been modified for ARCNET (which uses 1 byte of link level addressing) by [EMAIL PROTECTED] from the ARCNET code in NetBSD. In this version they changed the passed parameter in the kernel stack arpcom pointer to the ifnet pointer, and reference from the fixed ethernet LLA of 6 octect is changed to if_addrlen. A new arpcom like structure is needed for the AX.25. There are some changes to ifconfig(8) if you plan to soft set the LLA. I made some changes to the above mentioned ARP changes to be more ethernet-like, in that the link level address is stored in both the arccom as well as the ifnet structure to make getting the value easier and making the soft-changing of the link level address compatiable with ethernet. To answer your question, the foot work has been done for you. --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: UDP checksum error after encapsulating multicast packet
the UDP checksum should not change before encapsulation. re-displaying your packets: 18:27:12.968167 192.9.200.127.1399 224.2.3.4.1234: [udp sum ok] udp 16 (ttl 16, id 38554, len 44) 4500 002c 969a 1011 a897 c009 c87f ^^ ttl ipcksm e002 0304 0577 04d2 0018 22c5 udpcksm ea02 0400 3c0f 4401 0001 3145 c7c6 data 18:27:12.968185 192.9.200.127 150.9.120.183: 192.9.200.127.1399 224.2.3.4.1234: [bad udp cksum bb7!] udp 16 (ttl 15, id 38554, len 44) (ttl 64, id 38555, len 64) 4500 0040 969b 4004 4cd5 c009 c87f 9609 78b7 ip-ip ecap (not use in the below UDP checksum) 4500 002c 969a 0f11 a997 c009 c87f ^^ ttl ipcksm e002 0304 0577 04d2 0018 6bb9 udpcksm ea02 0400 3c0f 4401 0001 3145 c7c6 the only thing that changes from the first calculation of the UDP checksum to the final calculation of the UDP checksum is the decrement of the TTL and the adjustment of the IP header checksum these changes will not change the UDP checksum (they cancel out). My best guess is that someone has the UDP src, dst and ports in host order not net order and on Intel arch. this causes a UDP checksum error. It may have something to do with this being the originating host, and wee have a copy of the packet before the net byte order was restored. --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: UDP checksum error after encapsulating multicast packet
In bad taste to reply to myself...I said: My best guess is that someone has the UDP src, dst and ports in host order not net order and on Intel arch. this causes a UDP checksum error. It may have something to do with this being the originating host, and wee have a copy of the packet before the net byte order was restored. it apprears from tcp_output.c that the offset and length fields are in host order at the time that mforward is called, not the src, dst, port like I speculated above. in sys/netinet/ip_mroute.c, before you calculate the cksum, you need to use HTONS() or htons() to place these fields in network order. If you need a diff, I can give you one, I unfortunately cannot test it for you. --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: UDP checksum error after encapsulating multicast packet
the len and offset have been put in net order, but the len is then assumed to be in host order: in sys/netinet: --- ip_mroute.c.origThu Jul 19 01:37:26 2001 +++ ip_mroute.c Thu Dec 6 12:26:25 2001 @@ -1595,6 +1595,7 @@ */ ip = (struct ip *)((caddr_t)ip_copy + sizeof(multicast_encap_iphdr)); --ip-ip_ttl; +len = ip-ip_len; HTONS(ip-ip_len); HTONS(ip-ip_off); ip-ip_sum = 0; @@ -1605,7 +1606,7 @@ if (vifp-v_rate_limit == 0) tbf_send_packet(vifp, mb_copy); else - tbf_control(vifp, mb_copy, ip, ip_copy-ip_len); + tbf_control(vifp, mb_copy, ip, len); } /* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: UDP checksum error after encapsulating multicast packet
ignore that patch, it is completely wrong. sorry. --mark. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: contiguous memory of a buffer
I am wondering whether we need contiguous memory for a PHYSICAL buffer to perform the DMA I/O. yes. The DMA request should either not cross a physical page or if the request does cross a physical page, those pages must be contiguous. the exception to this is if your DMA card has a memory management unit, and you are sharing the same virtual to physical map with the MMU and the host memory allocation space (for a driver, the kernel physical map). --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: meteor driver problems
i've been experiencing weird problems with the Meteor device driver.. on two machines of the seven we've installed, the METEOR_CAP_SINGLE ioctl locks up the process once in a while (every few hours). [deletion] the original metoer card's PCI chipset had a known and uncorrectable hardware incompatibility with PCI 2.0 chipsets that caused lockup. Matrox had to change the components on the next generation of cards and at the time Matrox was not too generous with documentation, so the multimedia developers switched to the Brooktree 848 video capture chipset based cards. My guess every computer that you used to test the card uses the PCI 2.x chipset (a safe guess since it has been a long time since a manufacturer used a PCI 1.x chipset). --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: contigfree, free what?
I have a potentially silly question about contigmalloc1(), if the very unlikely occurance that the kernel VM space ran out, (the vm_map_findspace() failed) wouldn't we want to return the chunk of contiguous physical space back on the free queue before we return an allocation failure? --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: contigfree, free what?
Assuming we are using Thomas' patch that already removed the vm_page_wire()
from the earlier for loop, then at the point of this VM space allocation
failure, we haven't done anything too serious to the vm_page nor to the pmap,
nor are they in any object. We should be able to simply place it back to the
colored free list, something as easy as:
*** vm_page.c Mon Oct 15 10:26:14 2001
--- vm_page.c.new Mon Oct 15 11:32:46 2001
***
*** 1934,1939
--- 1934,1942
* above available.
*/
vm_map_unlock(map);
+ for (i = start; i (start + size / PAGE_SIZE); i++) {
+ (void)vm_add_new_page(VM_PAGE_TO_PHYS(pga[i]));
+ }
splx(s);
return (NULL);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: contigfree, free what?
Patrick Cipiere [EMAIL PROTECTED] says: :We are currently working with FreeBSD 4.3 and we found out that :kldloading/kldunloading modules working with contigmalloc()/contigfree() :like if_xl.ko produces a memory leak. : :This is due to the contigfree() function which seems to uncompletely release :the memory ressource allocated in vm_page_array. : :When contigmalloc() steps in vm_page_array, it does not find back :the pages previously released by contigfree() :The loop vm/vm_page.c is this one: In FreeBSD 4.4 (and I do not think there is any change from 4.3), I placed the contigmalloc/free using the if_xl.c structures in a new PCI probe routine so it gets called several times in a boot process. I also placed some checks on vm_map_delete to see if the range of map gets modified (and therefore some pages are not freed. Everything works correctly; the correct amount is free, and the entry that this map is found in is completely the amount of the contigmalloc. Most of the time, I get the very same range, but as I started adding drivers and reserving memory, the start of contigmalloc creaps up, as expected. I think you are hitting the problem that contigmalloc cannot be guarrenteed to work once the physical memory becomes used and there is no range large enough for your new contigmalloc. That is why large contigmallocs are done at boot time. I did not try this with a loadable module, so I can't say if there is or is not a feature of the loading/unloading of the module that allocates memory that fills part of your contiguous range. Do you wish patches to VM code to verify that the free is done completely? --mark tinguely To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: contigfree, free what?
I can allocate the same memory block, back to back by contigmailloc and contigfree using the same if_xl structures in a PCI probe (actually I do contigmalloc/contigfree per probe call. The PCI probe gets called for each PCI device. I will print up the trace that shows the blocks are freed. I think the module load process takes a block in that contig range and the allocate can not longer be satisfied. --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: contigfree, free what?
apologies, as soon as I sent that mail, I realized that I was looking at the virtual address -- duh, mark. Patrick was pointed in the right direction that the entry's object is no longer the kernel_map but is NULL, changing the release path. --mark tinguely To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: VM Documentation
on Sun, Aug 05, 2001 at 12:20:36PM, Nik Clayton [EMAIL PROTECTED] points out: http://www.daemonnews.org/21/freebsd_vm.html That got pulled in to the documentation project a while ago, and can be found at http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-design/index.html This makes it pretty easy for us (you) to keep it up to date as you change FreeBSD's VM system. . . (I hope Nik does not mind me rebroadcasting his -hacker reply). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: arcnet support for FreeBSD (request for review)
On Wed, Sep 26, 2001 at 12:59:01PM -0500, mark tinguely wrote: There is nothing like raising a topic that was last seen several months ago, but ... Has there been any serious consideration to committing the arcnet code that mentioned on 20 Jul 2001 (http://iclub.nsu.ru/~fjoe/arcnet/)? yes, I am working on this I noticed that the hooks for the netgraph and BRIDGE code is missing. I guess this is why I would like to see it committed so that there is not a constant catchup of new features. I also noticed that the outputed packet get bpf_mtap in two places, once for the complete packet arc_output(), and again in the outputting of the fragments (in the device driver). I wonder if the bpf_mtap in the arc_output() should be removed. I am not able to test yet, but I am willing to help. --mark tinguely To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: arcnet support for FreeBSD (request for review)
There is nothing like raising a topic that was last seen several months ago, but ... Has there been any serious consideration to committing the arcnet code that mentioned on 20 Jul 2001 (http://iclub.nsu.ru/~fjoe/arcnet/)? I guess I should ask if anyone else has tried the code. I will most likely have another driver for arcnet in a couple months if the customer goes ahead with the project. --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: CAN bus
it is quite standard in industrial environments and still popular (at least in europe) but existant installations slowly get replaced with ethernet based (100baseFX) or industrial ethernet (10Mbit) transceivers. I believe it was designed for noisy environments and is still used in automotive and large equipment (farm tractors, combines, etc). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: memory + apache
Yeah that is what I am thinking to. My guess is some large array allocated in the php code maybe or a sql query taking to long to finish eating up all the ram. That is kind of interesting to know. you said that the CPU usage spikes also at the time of the memory depletion? I wonder if you have some fork storm. If you had process accounting enabled and match it up with the web log file and vmstat activity you may be able to narrow your search. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
BIOS reading physical RAM
Does anyone have a reference to the values of type field in the Intel BIOS physical system RAM mapping? I am curious why we are using only entries of type 0x01. --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: find and quota find different amounts of files
sometimes quota counts do go off (for example if you quotacheck an active filesystem). another possiblity is that the files have been opened, unlinked, but not yet closed. These files are still open, and correctly counted by the quota system, but not found by find. The only way to test for either case is to go into single user mode. --mark tinguely To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DMA in drivers?
"This register is used to establish the PCI address for data moving from the the Host Computer Memory to the card. It consists of a 30 bit counter with the low-order 2 bits hardwired as zeros. The address stored may be any nonzero byte length that is a multiple of 8, since 8 bytes are required to make up a DES encryption block. The Source Address Register is continually updated during the transfer process and will always be pointing to the next unwritten location." What do I need to do to get a memory address for the source and destination data for the DMA transfers? It sounds as if these memory addresses must have the last three bits zeros, will this happen automatically? Right now I am stuck on how this DMA stuff is working and any help would be appreciated. Oh yeah, I am targeting this driver for a FreeBSD 3.x system. sounds to be that it wants the buffers to be long-word aligned (multiple of 4 bytes) and not greater than 1 GB (address 0x3ffc). the source data must be null padded so that the length is a multiple of 8 bytes. other gotchas, the addresses you specified must be the PHYSICAL address, not the kernel virtual address. use the vtophys(mtr-bigbuf) routine to get the physical address. The physical page should be wired down, so it does not get paged out to swap between the time you set up the DMA and the DMA finish. be sure the data does not cross into another physical page unless the two pages are contiguous. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
UNIXREVIEW.com
FYI: (blatently stolen from UNIXREVIEW.COM EXTRA! Volume 1, Issue 11) UNIXREVIEW.COM Call for Papers unixreview.com is looking for contributors to write feature articles. See the list below for suggested topics, or contact us with your own article ideas. * FreeBSD * Storage Area Networks * Linux performance tuning * Java * Open Source Development * Systems Management * Web Security Issues * Embedded Linux * Comparison of window managers * Comparison of the main X servers for UNIX on Intel Contact Christi Bear ([EMAIL PROTECTED]) with proposals for articles, press releases, or general questions about the publication process. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI Specification !!!
is the PCI Specification avaialable on the web? i tried a couple of search engines, couldn't find it. The PCI Specification is published by the PCI Special Interest Group. The PCI Local Bus Specification Revision 2.0 cost about $20-25 a few years ago, and I see from the web order page: http://www.pcisig.com/tech/index.html that the price for the PCI Local Bus Specification Revision 2.2 is still in that ballpark. --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP address caching bug?
It seems that an interface configured with an address, which is then deleted, and then set to a different address on the same network, the machine continues to use the original address although all evidence of it is gone. delete any static routes before adding a new address: # route flush most of the time these routes were automatically learned with normal net use. FreeBSD has behaved like this for a long time. --mark. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
This is why people should start emailing asking for a dual-license that would support incorporation into FreeBSD. good luck, the SGI crowd are very Linux-oriented. --mark. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
This is why people should start emailing asking for a dual-license that would support incorporation into FreeBSD. good luck, the SGI crowd are very Linux-oriented. --mark. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Number of TUN devices
(discussion moved from -questions to -hackers; bits included) On Thursday, 20 May 1999 at 9:13:12 -0500, Mark Tinguely wrote: FYI: I am playing with the idea of a direct-insert PPP for future SONET/ATM/DSL PPP connections. here compression/ACCM are not a concern but higher data rates make the kernel/user space copying (x2 once on each device inteface) and the prcessing copying can be a concern for throughput. I am not bad mouthing the tun driver; it is an excellent driver for serial devices that needs to PROCESS the packets from/to the PPP link. In the SONET/ATM/DSL world, the PDUs will already be in mbufs from the device driver. The MRU/MTU can be much larger. The data packets do not need to compressed/encrypted/ACCM-ed, so the for those opened NCPs, the data packets can be placed directly into the appropriate kernel protocol stacks. the diagnostic, and control packets can still be processed in user space via a protocol socket. Have you experimented what kind of through-put the NOS-TUN can handle? I suspect that this model would be good enough for DSL speeds. Why are you thinking of using user PPP for this? As you say, at the data rates you're thinking of, it's not an optimal solution. no, only the LCP, NCP, authenication, dignostic messages for debugging is done in user space. this is small traffic to setup/maintain/tear down the connections, especially when you consider we are talking PVC in most cases. the network traffic will be either directly forwarded to the appropriate network stack, quietly discarded, or sent back to the originator depending on the state of the link/network protocol. again, I am dealing with a situation where the packets do not have to be processed, unlike the serial PPPs. and on the downside, I lose the alias feature found in user PPP (which hopefully natd could fill in). This is also probably material for -hackers. moved. --mark. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
