On Mon, May 21, 2012 at 11:20 AM, Ian Lepore
wrote:
> On Fri, 2012-05-18 at 16:13 +0200, Svatopluk Kraus wrote:
>> On Thu, May 17, 2012 at 10:07 PM, Ian Lepore
>> wrote:
>> > On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote:
>> >> Hi,
>> >>
>> >> I'm working on DMA bus implementation for
On Thu, May 17, 2012 at 8:20 AM, 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
On Mon, Apr 16, 2012 at 8:21 AM, Mark Tinguely 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
d 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"
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
25
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
> wrote:
>
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
9 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
ame 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 &
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"
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.bi
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"
reebsd.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
__
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 (ma
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.
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"
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
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 gl
s 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"
ds 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
panic("swap_pager_getpages: object mismatch %p/%p",
putpages
--Mark Tinguely.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-h
inguely/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]"
PIC 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-ha
on 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]"
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]"
ystem 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]"
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
> 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 pag
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
ot 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 "unsubscr
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
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
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
ally 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
a 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
> 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 *)
t 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
erate 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
ng 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
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
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_enc
S() 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
sum 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
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
d 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
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
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?
-
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 [
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
x27;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 &quo
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
> 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
> >
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
> 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
autom
> 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 y
exitted.
Is your memory/CPU peaks periodic enough to watch with top(1) or
other diagnostic tool. Something is eating your memory (like a run-away
CGI).
--mark tinguely.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
> Worse, pmap_pid_dump() is undocumented, and I don't
> understand what for(i=0;i<1024;i++) for(j=0;j<1024;j++) {} loop there is
> supposed to do... :-(
>
> I'd appreciate if someone would explain this to me.
the process' virtual memory is mapped into physical memory with page
directory ta
time.
There is a third mode of addressing using 2MB pages (simular to the
4MB page addressing mode for the 32 bit addressing scheme) that will
only give a process access to 4GB of memory (not segmentable to
a larger space, but can address physical memory located above the 4GB
address).
--mark ti
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
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
> I wish to forward broadcast packets from one subnet to another via a FreeBSD
> box.
> Both subnets are on the same Ethernet interface. Is this possible?
You should not do this in a routed environment, but is required in a
bidged enviroment. the kernel bridge(4) support should allow you to
> "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
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
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
> When you trying to establish connection from one peer (local) to another
> (remote), you sent a CONF_REQ message to the remote peer. The remote peer
> should answer with a CONF_ACK message. In the code of the sppp driver
> (net/if_spppsubr.c, lines 1321 - 1357) you can see that the remote p
(deletes and edits)
> But, in the later case, the control messages are queued to
> the control queue (sp->pp_cpq) which the if_start functions
> doesn't have access to.
in the ISDN (sys/i4b/driver) code, the interface target of the
if_start(), there is a call to sppp_dequeue() which gets the top
> 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:
# ro
> 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:
# r
> 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
> 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
(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 a
71 matches
Mail list logo
