Re: Kernel - Modules and Compiled in
On Sat, Sep 21, 2002 at 12:42:07AM -0600, M. Warner Losh wrote: > > this is false. If you load the module from the boot loader there > is no difference between that and having it be actually compiled > into the kernel in terms of resource allocation. > > However, this is true if you intend to load the drivers at some > time later than boot. > Maybe it helps to get an idea of what memory allocation sizes we are talking about for the NVIDIA driver. For every single OpenGL client in the system memory case (no AGP), the resource manager has to allocate ~1MB (in multiple chunks; 258, 1, 8 pages). > Actually, this issues get gross in a hurry, which is why no one > has done it. :-( > There is a similar interface on Linux, the bigphys patch; it is really only useful to set aside larger chunks of contiguous physical memory for special-case drivers rather than for daily life. Allocating dynamically from a static block of memory set aside a boot time would quickly grow into a major pain for this specific driver due to the numerous smaller allocations. This works well enough for AGP memory since all AGP allocations are much larger (258, 2304 pages) and sized in multiples of 1MB. Even in the AGP memory case, several pages of DMA memory need to be allocated from general system memory. -- christian zander [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Problem with Mapping System Memory to User Space (Re: Kernel - Modules and Compiled in)
On Sat, Sep 21, 2002 at 06:50:09AM +0200, Christian Zander wrote:
>
> Maybe it helps to get an idea of what memory allocation sizes we
> are talking about for the NVIDIA driver. For every single OpenGL
> client in the system memory case (no AGP), the resource manager
> has to allocate ~1MB (in multiple chunks; 258, 1, 8 pages).
>
> > Actually, this issues get gross in a hurry, which is why no one
> > has done it. :-(
> >
>
> There is a similar interface on Linux, the bigphys patch; it is
> really only useful to set aside larger chunks of contiguous
> physical memory for special-case drivers rather than for daily
> life. Allocating dynamically from a static block of memory set
> aside a boot time would quickly grow into a major pain for this
> specific driver due to the numerous smaller allocations. This
> works well enough for AGP memory since all AGP allocations are
> much larger (258, 2304 pages) and sized in multiples of 1MB.
>
> Even in the AGP memory case, several pages of DMA memory need to
> be allocated from general system memory.
>
I'm sorry, this is in reply of another issue I had meant to bring
up on freebsd-hackers, and that is related to memory allocations
for drivers designed similar to the NVIDIA graphics driver.
For architectural reasons, the NVIDIA driver relies on the ability
to allocate DMA memory in the kernel and to map it into user-space.
While the allocation is no problem, the FreeBSD mmap architecture
imposes limitations on the driver, since its implementation of the
mmap system call is called for individual ranges rather than for a
range of pages (as in the Linux implementation).
In order for the driver to be able to recognize any incoming offset
correctly, the mmap() offset passed to the kernel from user-space
must be the base of a range of addresses that is unique across the
system.
With AGP memory, this requirement is easily satisfied (*) since all
(possibly non-contiguous) allocations have a contiguous alias in the
AGP aperture. It is thus possible to provide the AGP base address of
an allocation as the mmap offset.
With general system memory, this is problematic, unless the driver
allocates the memory it requires as a contiguous block of physical
memory; this is feasable for very small memory allocations only.
In order to support large DMA memory buffers, the driver must thus
associate a contiguous range of addresses with the non-contiguous
pages it allocates from system memory. This alias won't be physical
(unlike AGP) and it won't permanently correspond to the pages.
Assuming the driver went ahead and allocated the memory it requires
from kernel virtual memory, this allocation's base address could be
used as a mmap offset; the driver would be able to recognize all of
the pages and retrieve their physical addresses correctly. This is
the approach taken by the NVIDIA driver at this point.
The problem with this lies with the assumption that any given mmap
offset will always correspond to the same physical address; having
retrieved the address for a given offset, dev_pager_getpages will
install a fake page and thus a cached offset-address mapping. If a
process allocates a piece of DMA memory (ioctl), it is returned an
offset corresponding to the allocation (its kernel virtual address)
and will use that as an offset to mmap. The first time around, this
will work as expected. Assuming that the driver might then free and
re-allocate the memory, however, it may happen that it will attempt
to map a set of different physical pages with the same offset.
Based on the fake page installed by dev_pager_getpages, vm_fault is
led to believe that the page in question is resident and returns the
cached, now outdated (incorrect) physical address for the offset.
The proposed workaround aims to be effective and non-intrusive; the
idea is to extend the msync system call to support invalidating of
cached pages for objects of type OBJT_DEVICE. This solutions appears
to work well, but I'm aware that there might be better solutions for
the problem, or concerns with this proposed solution.
(*) This is true for AGP core logics currently used in i386 systems,
but this may change with future implemtations of AGP 3.0. It is not
true on PPC or ia64, AGP chipsets such as the 460GX (Itanium) do not
translat CPU accesses to AGP memory through the aperture.
diff -ru nvidia/sys/4.5/vm/vm_map.c sys_/vm/vm_map.c
--- nvidia/sys/4.5/vm/vm_map.c Fri Mar 8 09:22:20 2002
+++ sys_/vm/vm_map.cWed Jun 12 18:45:45 2002
@@ -1775,14 +1775,17 @@
OFF_TO_IDX(offset),
OFF_TO_IDX(offset + size + PAGE_MASK),
flags);
- if (invalidate) {
- /*vm_object_pip_wait(object, "objmcl");*/
- vm_object_page_remove(object,
- OFF_TO_IDX(offset),
- OFF_TO_IDX(offset + size + PAGE_MASK),
- FALSE);
- }
VOP_UNLOCK(object->handle, 0, curproc);
+ vm_ob
Re: Direct video access
On Sat, 2002-09-21 at 16:44, Sean Hamilton wrote: > Which card would I be best off using? I currently have an nvidia geforce256, > but understand nvidia is fairly hush-hush about how their hardware works. I > know nvidia is about to release an xfree86 module, but I'm not too > interested in using xf86. I hear ATI is somewhat more open about the > technical details of their cards. 3d support for nVidia stuff is still 'in the works' :( ATI or Matrox are probably your best bet, though support for their latest cards lag behind. You could try looking at SDL which seems to be becoming the de-facto standard for doing multimedia/game type stuff. > For this card, where should I look to get details of the interface? I really > know nothing about talking directly to hardware, but am eager to learn. I am > assuming all cards have a standard set of commands to do things like set > video modes and possibly even things like hardware accelerated lines and > such, but I imagine things like matrix multiplications and transformations, > blitting, etc, are all proprietary. I know DOS uses a set of interrupts to > change video modes, and a static address for the framebuffer, but I'm > assuming this isn't the case with FreeBSD. If it *is* a static address, > would I then have to be running in kernel mode to access such an address? If I were you I'd look at the DRI etc. Skip all of that messy stuff for directly touching video hardware :) You can get a framebuffer mapping (DGA in X, or magic syscons calls) without having to talk to the video card directly. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel ICC
On Sat, 21 Sep 2002 12:57:05 +0900 Hiroharu Tamaru <[EMAIL PROTECTED]> wrote: > > Add "options CPU_ENABLE_SSE" and it should work (it seems only P4s > > have this problem). > > Oh, brilliant! > I'll reconfig the kernel and try it out as soon as I can have this > system down for maintenance. Thanks for the tip! > > Maintainer of icc port added to CC. A message in the post-install > target should be nice.. Here is the preceeding message for your > reference. ROTFL... Ok. I am the maintainer of the port, and I already added a message to post-install (together with an update to the latest icc version). It would be nice if you could send me the results of benchmarks (if permitted by your employer). Don't expect the multithreading to have a significant positive impact. A local computer magazin (http://www.heise.de/iX/) played a little bit around with it and the result was, that it isn't good for the kernel scheduler (better performance without multithreading). But it improves code with mixed integer/floating-point instructions (good speed improvements (+75%) if you run integer and floating-point code in parallel). Bye, Alexander. -- Actually, Microsoft is sort of a mixture between the Borg and the Ferengi. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel ICC
At Sat, 21 Sep 2002 13:16:04 +0200, Alexander Leidinger wrote: > Ok. I am the maintainer of the port, and I already added a message to > post-install (together with an update to the latest icc version). Pardon me, I should have looked more carefully. > It would be nice if you could send me the results of benchmarks (if > permitted by your employer). Yes, I have a plan to benchmark it to see if it improves my scientific numerical calculation programs. Your comment below is encouraging, since they are CPU intensive floating point and integer calculations that I assume are quite suitable for parallel execution. This is also a memory intesive calculation so I am planning to check out which is the bottle neck (and to help this I happen to have i845, i850, i845G, and also MPX760 Athlones :-) ) > Don't expect the multithreading to have a significant positive impact. A > local computer magazin (http://www.heise.de/iX/) played a little bit > around with it and the result was, that it isn't good for the kernel > scheduler (better performance without multithreading). But it improves > code with mixed integer/floating-point instructions (good speed > improvements (+75%) if you run integer and floating-point code in > parallel). -- Hiroharu Tamaru To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Direct video access
Daniel O'Connor wrote: > On Sat, 2002-09-21 at 16:44, Sean Hamilton wrote: > > Which card would I be best off using? I currently have an nvidia geforce256, > > but understand nvidia is fairly hush-hush about how their hardware works. I > > know nvidia is about to release an xfree86 module, but I'm not too > > interested in using xf86. I hear ATI is somewhat more open about the > > technical details of their cards. > > 3d support for nVidia stuff is still 'in the works' :( http://nvidia.netexplorer.org/news.html Actually nVidia just announced that they would be doing the work themselves. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Direct video access
On Sun, 2002-09-22 at 00:53, Terry Lambert wrote: > > 3d support for nVidia stuff is still 'in the works' :( > > http://nvidia.netexplorer.org/news.html > > Actually nVidia just announced that they would be doing the > work themselves. Yes, well maybe :) I hope so, but I wouldn't hold my breath. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: temperature monitoring
* Clark C. Evans ([EMAIL PROTECTED]) wrote: > This is probably common question, but I was wondering if there is any > temperature monitoring mechanisms out there; specifically for ABit > motherboard (KG7). sysutils/healthd? -- Thomas 'Freaky' Hurst - [EMAIL PROTECTED] - http://www.aagh.net/ - "If we were meant to fly, we wouldn't keep losing our luggage." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel ICC
On Sat, 21 Sep 2002 22:28:52 +0900 Hiroharu Tamaru <[EMAIL PROTECTED]> wrote: > > Ok. I am the maintainer of the port, and I already added a message > > to post-install (together with an update to the latest icc version). > > Pardon me, I should have looked more carefully. No problem. It was funny for me. > > It would be nice if you could send me the results of benchmarks (if > > permitted by your employer). > > Yes, I have a plan to benchmark it to see if it improves my > scientific numerical calculation programs. Your comment I'm especially interested how it compares to gcc (on a P4 and perhaps on the Athlon). > below is encouraging, since they are CPU intensive floating > point and integer calculations that I assume are quite > suitable for parallel execution. This is also a memory The -x parameter for icc doesn't always helps. It depends on the application. You may try to use some variations of -xiMKW (-xi, -xiM, -xM, -xiMK, ...). -parallel and -mt may be of use too (and the obvious parameters like -ipo, -tpp7, -O too). > intesive calculation so I am planning to check out which is > the bottle neck (and to help this I happen to have i845, i850, > i845G, and also MPX760 Athlones :-) ) This sounds like nice toys... icc also produces fast code for the Athlon (-tpp6). Bye, Alexander. -- Weird enough for government work. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
$BH~>/=wBg8T3+$-%m%j!<%?#D#V#D(J
}jAÈçâΫÌiµ¦Mû̶ãA
·®ÉÐÌ}Vª®«o·VXe
}U[yÑ}U[ÌLéX¾©çrfIEcucð
·®ÉvµÜ·B
ܽA±±ÉÐîµÄ¢È¢^CgXgð¨èµÜ·B
ÆÉ©²ÉÈÁÄê{©çÅà¨Cyɲ¶º³¢Ü·æ¤
Xµ¨è¢µÜ·B
http://japan.pinkserver.com/child1/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Activating a PCI function before driver probe?
On Wed, Aug 28, 2002 at 12:01:15AM +0200, Dan Larsson wrote: > While trying to get hardware monitoring to work on my computer I > found the below procedure to enable the smbus device. > > It didn't get me any closer to actually monitoring the hardware with > xbmon, lmmon or healthd. But the device is there. > > Can this probe/tweak be done during boot somehow? I'd gladly try out > patches:-) Please CC me as I'm not on the freebsd-hackers list. Your chipset should be supported by ichsmb(4). Doesn't your bios provide you the activation of the function? The ichsmb is not responsible for activating the function. This is a PCI hack that must be done before probe of devices/drivers. Any clue others? Nicolas -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
