Re: contiguous memory allocation problem
On Saturday 01 July 2006 21:44, David Malone wrote: On Sat, Jul 01, 2006 at 10:44:54AM +0200, Hans Petter Selasky wrote: The latest concensus seems to be that the USB system should make use of the scatter-gather facilities in the hardware to avoid the need to allocate large contiguous memory chunks. iedowse@ had mostly finished implementing this in mid May. Yes, but scatter and gather will add extra complexity to the driver, and maybe an extra memory copy in most cases. The idea is to allocate less than or equal to a page of memory, and then avoid the problem? I believe the USB drivers in -current grew scatter/gather support about a month ago. See the commit message below. Is this likely to help? I see. But there is one problem, that has been overlooked, and that is High speed isochronous transfers, which are not supported by the existing USB system. I don't think that the EHCI specification was designed for scatter and gather, when you consider this: 8 transfers of 0xC00 bytes has to fit on 7 pages. If this is going to work, and I am right, one page has to contain two transfers. (see page 43 of ehci-r10.pdf) Currently the PAGE_SIZE is 0x1000, right? As you can see (0xC00 * 2) 0x1000. So is it possible to change the PAGE_SIZE ? --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVIDIA FreeBSD kernel feature requests
On Thu, 29 Jun 2006 13:12:31 +0200 Christian Zander [EMAIL PROTECTED] wrote: Hi, I just saw an article on OSNews about this, seems I missed it. NVIDIA has been looking at ways to improve its graphics driver for the FreeBSD i386 platform, as well as investigating the possibility of adding support for the FreeBSD amd64 platform, and identified a number of obstacles. Some progress has been made to resolve them, and NVIDIA would Yes, I'll tell you what the obstacle is: Lack of documentation. If you guys released the specs of your hardware this wouldn't be a problem. Maybe not for the latest GPUs but I'm sure a lot people would be happy if they could use not-so-new NVidia hardware on FreeBSD/amd64. I built and AMD64 box from scratch with the sole purpose of running FreeBSD/amd64 on it. When it came time to choose the gfx card the choice was obvious: Ati Radeon 9250. I know that a lot of FreeBSDers are more than happy to have proprietary drivers which I personlly won't touch with the proverbial 10 foot pole :) So please, do tell, is there any _real_ problem with releasing a register spec doc for last year's hardware so amd64 users can hope to have more than a framebuffer some day? How about the proprietary nforce4 chipset? Cheers. -- Miguel Mendez [EMAIL PROTECTED] http://www.energyhq.be PGP Key: 0xDC8514F1 pgpgMdsD8IL9p.pgp Description: PGP signature
Re: contiguous memory allocation problem
In message [EMAIL PROTECTED], Hans Petter Selasky writes: But there is one problem, that has been overlooked, and that is High speed isochronous transfers, which are not supported by the existing USB system. I don't think that the EHCI specification was designed for scatter and gather, when you consider this: 8 transfers of 0xC00 bytes has to fit on 7 pages. If this is going to work, and I am right, one page has to contain two transfers. (see page 43 of ehci-r10.pdf) I haven't looked into the details, but the text in section 3.3.3 seems to suggest that EHCI is designed to not require physically contiguous allocations here either, so the same approach of using bus_dmamap_load() should work: This data structure requires the associated data buffer to be contiguous (relative to virtual memory), but allows the physical memory pages to be non-contiguous. Seven page pointers are provided to support the expression of 8 isochronous transfers. The seven pointers allow for 3 (transactions) * 1024 (maximum packet size) * 8 (transaction records) (24576 bytes) to be moved with this data structure, regardless of the alignment offset of the first page. Ian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: contiguous memory allocation problem
On Sunday 02 July 2006 14:05, Ian Dowse wrote: In message [EMAIL PROTECTED], Hans Petter Selasky writes: But there is one problem, that has been overlooked, and that is High speed isochronous transfers, which are not supported by the existing USB system. I don't think that the EHCI specification was designed for scatter and gather, when you consider this: 8 transfers of 0xC00 bytes has to fit on 7 pages. If this is going to work, and I am right, one page has to contain two transfers. (see page 43 of ehci-r10.pdf) I haven't looked into the details, but the text in section 3.3.3 seems to suggest that EHCI is designed to not require physically contiguous allocations here either, so the same approach of using bus_dmamap_load() should work: This data structure requires the associated data buffer to be contiguous (relative to virtual memory), but allows the physical memory pages to be non-contiguous. Seven page pointers are provided to support the expression of 8 isochronous transfers. The seven pointers allow for 3 (transactions) * 1024 (maximum packet size) * 8 (transaction records) (24576 bytes) to be moved with this data structure, regardless of the alignment offset of the first page. 3 * 1024 bytes = 0xC00 bytes 8 * 0xC00 = 0x6000 bytes maximum According to this you need 6 EHCI pages, because 6 * 0x1000 = 0x6000. The seventh EHCI page is just there to allow one to start at any page offset. There is no eight EHCI page. The only solution I see, is to have a double layer ITD. The first layer have the 4 first transfers activated, and the second layer have the 4 last transfers activated. A little more complicated, but not impossible. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: contiguous memory allocation problem
In message [EMAIL PROTECTED], Hans Petter Selasky writes: On Sunday 02 July 2006 14:05, Ian Dowse wrote: This data structure requires the associated data buffer to be contiguous (relative to virtual memory), but allows the physical memory pages to be non-contiguous. Seven page pointers are provided to support the expression of 8 isochronous transfers. The seven pointers allow for 3 (transactions) * 1024 (maximum packet size) * 8 (transaction records) (24576 bytes) to be moved with this data structure, regardless of the alignment offset of the first page. 3 * 1024 bytes = 0xC00 bytes 8 * 0xC00 = 0x6000 bytes maximum According to this you need 6 EHCI pages, because 6 * 0x1000 = 0x6000. The seventh EHCI page is just there to allow one to start at any page offset. There is no eight EHCI page. The only solution I see, is to have a double layer ITD. The first layer have the 4 first transfers activated, and the second layer have the 4 last transfers activated. A little more complicated, but not impossible. The trick is that if the 0x6000 bytes are contiguous in virtual memory then they never span more than 6 pages so one iTD is enough. i.e. you can just do malloc(0x6000) and you don't need multi-page physically contiguous buffers or extra memory-memory copies regardless of how the virtual buffer maps to physical pages. This seems to be the general extent of scatter-gather support offered by the various USB host controllers (modulo various caveats such as assuming pages are = 4k, handling physical addresses 4GB on non-IOMMU hardware and UHCI's lack of support for mid-packet non-contiguous page boundaries). Ian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Sat, 01-Jul-2006 at 10:35:47 +0200, Matthias Andree wrote: Pat Lashley [EMAIL PROTECTED] writes: BUT, that said, the safest and most portable coding practice would be: // The C standard does not require malloc(0) to return NULL; // but whatever it returns MUST NOT be dereferenced. ptr = ( size == 0 ) ? NULL : malloc( size ) ; Safest (avoiding null derefence) would instead be: ptr = malloc(size ? size : 1); I hacked malloc.c to do exactly this automatically, just for testing. 15 Minutes after rebooting (and after doing a lot of desktop switching and opening and closing of windows) the X-server ran out of memory :-). I assume there are lots of programs out there which do malloc(0) but only firefox (and apparently seamonkey) dereference the returned non-NULL pointer and crash therefore. -Andre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Fri, 30-Jun-2006 at 12:15:21 -0400, Pat Lashley wrote: I went wandering through the C Working Group archives for the heck of it, and apparently a lot of people were confused over this, thinking either as you did or that unique meant it would a value unique to the usage of malloc(0). It's been clarified recently (and will be in the next revision of the standard) to the meaning you understood. ... This is wandering into -standards territory, though. In any case, the answer to thread's original question is mozilla should fix its code to not assume malloc(0)==NULL. Agreed. (With the usual observation that they, too, are a mainly volunteer-based project; and would probably appreciate the inclusion of a patch Well, I was unsure of the correct behaviour. That's why I came here:-). From all what I've read so far, I can summarize: - Returning a non-NULL value from malloc(0) is completely legal. - We return a non-NULL value which, when dereferenced, always make the application crash (as a warning). See the commit message of rev. 1.60 of malloc.c: snip -- phkmalloc-evilchecks++; If zero bytes are allocated, return pointer to the middle of page-zero (which is protected) so that the programme will crash if it dereferences this illgotten pointer. Inspired Urged by:Theo de Raadt [EMAIL PROTECTED] snap -- - What we do isn't 100% perfect since we always return the same value for each malloc(0). - It was firefox' fault to crash. - The manpage is heavily misleading. Firefox must be fixed but some stuff can be done in FreeBSD as well: - If we keep our current behaviour we have to change the manpage. (As I said before, I could do that if someone will commit it later.) - We could reverse the meaning of the V-flag (or, introduce a new flag to avoid confusion). This would mean that by default a malloc(0) will return NULL in future. The new flag can be used to change this behaviour to the way it was done before: We hand out the value which, when dereferenced, make the programme crash as a warning to the author. We note in the manpage that it is not 100% legal since we always use the same value. with the bug report. And, of course, that the original poster of this thread should file a bug report with the Mozilla project.) Please see: https://bugzilla.mozilla.org/show_bug.cgi?id=343283 It wasn't me who created this PR but the author of the extension which actually revealed the bug. -Andre -- UNIX is an operating system, OS/2 is half an operating system, Windows is a shell, and DOS is a bootsector virus. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: contiguous memory allocation problem
In message [EMAIL PROTECTED], Ian Dowse writes: The trick is that if the 0x6000 bytes are contiguous in virtual memory then they never span more than 6 pages so one iTD is enough. Sorry, I meant of course 6 page boundaries, which means no more than 7 pages. This is why the 7 physical address slots in the iTD is always enough for 8 x 3k transaction records if the 24k buffer is contiguous in virtual memory. Ian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: contiguous memory allocation problem
- Original Message -
From: Peter Jeremy [EMAIL PROTECTED]
To: Randall Hyde [EMAIL PROTECTED]
Sent: Saturday, July 01, 2006 11:10 PM
Subject: Re: FLEX, was Re: Return value of malloc(0)
The following compiles without error:
%{
typedef int YYSTYPE;
typedef int YYLTYPE;
/*
** Allow for a recursive version of Bison parser.
*/
#undef YY_DECL
#define YY_DECL int yylex( YYSTYPE *yylval, YYLTYPE *yylloc)
%}
%%
. ECHO;
%%
I'll accept that you are having a problem getting HLA to build. No-one
else is reporting problems. If you want assistance from other people
then you are going to need to help by either providing a test case to
reproduce the failure you are seeing or you are going to need to provide
the pre-processed context where the error occurs.
Uh, is the above *not* the test case you are asking for?
Does this particular code snippet compile for you? If so, then I've
definitely got some configuration problems with GCC on my machine.
BTW, if I haven't made myself clear, the problem with the code above is a
GCC error, not a FLEX error. That is, FLEX happily produces the yy.lex.c
output file, GCC under FreeBSD rejects the source code it produces. Yet that
*same exact* source code compiles just fine under Linux with GCC, Windows
with Borland C++, and Windows with VC++.
Creating a recursive lexer is a documented feature of FLEX. Indeed, I used
the example present in the FLEX documentation to pull this off. And I've
been using this code for about eight years on Windows and about four years
on Linux. Perhaps FreeBSD types have never tried to create a recursive
parser/lexer and haven't had to deal with this issue, but as you can see
from the code snippet above, this really has nothing to do with HLA, per se,
other than the fact that it uses a recursive lexer/parser.
And the fact remains, the code compiles just fine under Windows and Linux.
The compilation uses a documented feature of FLEX. There *is* a problem with
the implementation of GCC under FreeBSD (or header files under FreeBSD).
It's not specific to HLA. And I can't imagine how to give you a better test
case than the code above.
Cheers,
Randy Hyde
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: contiguous memory allocation problem
On Sun, Jul 02, 2006 at 09:00:07AM -0700, Randall Hyde wrote:
- Original Message -
From: Peter Jeremy [EMAIL PROTECTED]
To: Randall Hyde [EMAIL PROTECTED]
Sent: Saturday, July 01, 2006 11:10 PM
Subject: Re: FLEX, was Re: Return value of malloc(0)
The following compiles without error:
%{
typedef int YYSTYPE;
typedef int YYLTYPE;
/*
** Allow for a recursive version of Bison parser.
*/
#undef YY_DECL
#define YY_DECL int yylex( YYSTYPE *yylval, YYLTYPE *yylloc)
%}
%%
. ECHO;
%%
I'll accept that you are having a problem getting HLA to build. No-one
else is reporting problems. If you want assistance from other people
then you are going to need to help by either providing a test case to
reproduce the failure you are seeing or you are going to need to provide
the pre-processed context where the error occurs.
Uh, is the above *not* the test case you are asking for?
Carefully, read what Peter wrote. The code above compiles
on FreeBSD. As does the 37 *.y files under /usr/src
(excluding the 30 *.y under /usr/src/contrib which may
or may not be used during compilation).
Does this particular code snippet compile for you?
Yes, it does.
If so, then I've definitely got some configuration problems
with GCC on my machine.
What version of FreeBSD, and did you upgrade from a previous
version? Perhaps, you have some stale header files. Did
you install a different version of gcc under /usr/local
(or other directory) that appears early in your path?
--
Steve
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: contiguous memory allocation problem
On Sunday 02 July 2006 17:20, Ian Dowse wrote: In message [EMAIL PROTECTED], Ian Dowse writes: The trick is that if the 0x6000 bytes are contiguous in virtual memory then they never span more than 6 pages so one iTD is enough. Sorry, I meant of course 6 page boundaries, which means no more than 7 pages. This is why the 7 physical address slots in the iTD is always enough for 8 x 3k transaction records if the 24k buffer is contiguous in virtual memory. Ok. So the solution to my problem is to use scatter and gather. I will see about updating my USB system to do it like that. But there is one thing I do not understand yet. When you load a page that physically resides above 4GB, because a computer has more than 4GB of memory, how does bus_dmamap_load() move that page down below 4GB, so that the 32-bit USB host controllers can reach it? --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: contiguous memory allocation problem
In message [EMAIL PROTECTED], Hans Petter Selasky writes: Ok. So the solution to my problem is to use scatter and gather. I will see about updating my USB system to do it like that. But there is one thing I do not understand yet. When you load a page that physically resides above 4GB, because a computer has more than 4GB of memory, how does bus_dmamap_load() move that page down below 4GB, so that the 32-bit USB host controllers can reach it? What should happen is that bus_dma allocates a bounce buffer and performs copies as required from within the bus_dmamap_sync() calls. This is something I haven't been able to verify yet with the USB code though, so there could easily be bugs there. BTW, as far as I know bus_dma is also missing support for multi-segment allocations, so for example if you ask it to allocate 16k in at most 4 segments below the 4GB mark, it will actually attempt a physically contiguous allocation. If this was fixed it could be used by usbd_alloc_buffer() to give directly usable buffers without contiguous allocations. Ian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVIDIA FreeBSD kernel feature requests
Miguel Mendez wrote: On Thu, 29 Jun 2006 13:12:31 +0200 Christian Zander [EMAIL PROTECTED] wrote: Hi, I just saw an article on OSNews about this, seems I missed it. NVIDIA has been looking at ways to improve its graphics driver for the FreeBSD i386 platform, as well as investigating the possibility of adding support for the FreeBSD amd64 platform, and identified a number of obstacles. Some progress has been made to resolve them, and NVIDIA would Yes, I'll tell you what the obstacle is: Lack of documentation. If you guys released the specs of your hardware this wouldn't be a problem. I think that this reaction wasn't called for. Modern GPUs are extraordinarily complex HW and to write a decent driver will take appropriate effort. I understand that open source infected people (like me) prefer having the detailed HW documentation but we shouldn't refuse the vendor's efforts to provide good driver to us. I haven't understood much of Mr. Zander's questions but I am pretty sure some readers did and probably have been talking to him off-list. I also tend to believe that his requests for features were based on good understanding of FreeBSD kernel internals (better that mine and probably also yours) and if we add the features or help him effectively use what's there everyone will benefit. Maybe not for the latest GPUs but I'm sure a lot people would be happy if they could use not-so-new NVidia hardware on FreeBSD/amd64. I built and AMD64 box from scratch with the sole purpose of running FreeBSD/amd64 on it. When it came time to choose the gfx card the choice was obvious: Ati Radeon 9250. I know that a lot of FreeBSDers are more than happy to have proprietary drivers which I personlly won't touch with the proverbial 10 foot pole :) So please, do tell, is there any _real_ problem with releasing a register spec doc for last year's hardware so amd64 users can hope to have more than a framebuffer some day? How about the proprietary nforce4 chipset? They well may have reasons not to disclose everything. There is probably lot of their market success hidden in the full specs. I bet that Mr. Zanders can't answer the question (and definitely can't decide to give the specs) anyway. And - again - it will probably take a couple of very skilled programmers' years' time to write good driver from scratch. Cheers. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVIDIA FreeBSD kernel feature requests
On Sun, 2 Jul 2006, Michal Mertl wrote: And - again - it will probably take a couple of very skilled programmers' years' time to write good driver from scratch. It took someone far less than that http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_nfe.c http://www.openbsd.org/cgi-bin/man.cgi?query=nfesektion=4 Nvidia don't want to give out docs. That's their commercial decision - as a result, if you their cards, you may end up with a particularly expensive paperweight the day they decide you need to buy a new card for your new version of freebsd which has different internals; or someone finds bugs in their drivers that they wont fix. it's not like there aren't plenty of other vendors who are more willing to help the developers with documentation in an open manner. Regards Sam -- Procrastination: Hard work often pays off after time. Laziness pays off now ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: contiguous memory allocation problem
Ian Dowse wrote: In message [EMAIL PROTECTED], Hans Petter Selasky writes: But there is one problem, that has been overlooked, and that is High speed isochronous transfers, which are not supported by the existing USB system. I don't think that the EHCI specification was designed for scatter and gather, when you consider this: 8 transfers of 0xC00 bytes has to fit on 7 pages. If this is going to work, and I am right, one page has to contain two transfers. (see page 43 of ehci-r10.pdf) I haven't looked into the details, but the text in section 3.3.3 seems to suggest that EHCI is designed to not require physically contiguous allocations here either, so the same approach of using bus_dmamap_load() should work: This data structure requires the associated data buffer to be contiguous (relative to virtual memory), but allows the physical memory pages to be non-contiguous. Seven page pointers are provided to support the expression of 8 isochronous transfers. The seven pointers allow for 3 (transactions) * 1024 (maximum packet size) * 8 (transaction records) (24576 bytes) to be moved with this data structure, regardless of the alignment offset of the first page. yes, as long as the beffers are contiguous in some virtual space then the maximum number of pages they can need is 7. (they actually fit into 6 but they may start part way through the first page and may therefore overflow into a 7th). Ian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVIDIA FreeBSD kernel feature requests
That's their commercial decision - as a result, if you their cards, you may end up with a particularly expensive paperweight the day they decide you need to buy a new card for your new version of freebsd which has different internals; or someone finds bugs in their drivers that they wont fix. This is the relatively benign scenario. In the less benign one that convenient binary driver that you loaded into the kernel would contain a silent security vulnerability. Google for Sony DRM rootkit. it's not like there aren't plenty of other vendors who are more willing to help the developers with documentation in an open manner. True. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVIDIA FreeBSD kernel feature requests
In message: [EMAIL PROTECTED] Kip Macy [EMAIL PROTECTED] writes: : IIRC lack of per instance cdevs also limits Freebsd to one vmware instance. Can you describe the proper semantics here? A cdev is a cdev, and when we do things like dup we just copy the reference to that cdev. This has also traditionally been resisted on layering violations grounds (since the data we have doesn't map easily back to the fd at the time we call the cdev methods). Warner : On 6/29/06, Oleksandr Tymoshenko [EMAIL PROTECTED] wrote: : Christian Zander wrote: : Hi all, :# Task:implement mechanism to allow character drivers to : maintain per-open instance data (e.g. like the Linux : kernel's 'struct file *'). : Motivation: allows per thread NVIDIA notification delivery; also : reduces CPU overhead for notification delivery : from the NVIDIA kernel module to the X driver and to : OpenGL. : Priority:should translate to improved X/OpenGL performance. : Status: has not been started. : I've stumbled across this issue a while ago. Actually it can : be partially solved using EVENTHANDLER_REGISTER of dev_clone event with : keeping state structure in si_drv1 or si_drv2 fields. I'm not sure it's : the best solution but it works for me though it smells like hack, and : looks like hack :) Anyway, having legitimate per-open instance data : structures of cdevs is a great assistance in porting linux drivers to : FreeBSD. Just my $0.02. : : -- : Sincerely, : : Oleksandr Tymoshenko : PBXpress Communications, Inc. : http://www.pbxpress.com : Tel./Fax.: +1 866 SIP PBX1 Ext. 656 : ___ : freebsd-hackers@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-hackers : To unsubscribe, send any mail to [EMAIL PROTECTED] : : ___ : freebsd-hackers@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-hackers : To unsubscribe, send any mail to [EMAIL PROTECTED] : ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVIDIA FreeBSD kernel feature requests
In message: [EMAIL PROTECTED] Christian Zander [EMAIL PROTECTED] writes: : This summary makes an attempt to describe the kernel interfaces needed by : the NVIDIA FreeBSD i386 graphics driver to achieve feature parity with : the Linux/Solaris graphics drivers, and/or required to make support for : the FreeBSD amd64 platform feasible. It also describes some of the : technical difficulties encountered by NVIDIA during the FreeBSD i386 : graphics driver's development, how these problems have been worked around : and what could be done to solve them better. Thank you for taking the time to let us know how we might make the system better. :The NVIDIA graphics driver needs to be able to create uncached kernel :and user mappings of I/O memory, such as NVIDIA GPU registers. The :FreeBSD kernel does not currently provide the interfaces necessary to :specify the memory type when creating such mappings, which makes it :difficult for the NVIDIA graphics driver to guarantee that the correct :memory type is selected. Is this via the bus_alloc_resource interface? Is uncached kernel memory different than non-prefetchable memory? If so, please specify how it is different. If not, then we have an interface that will do what you want, except it is only implemented for cardbus and would need to be implemented for pci pci and pci host bridges. Would having better functionality here help? I noticed it wasn't on the task list... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
