Re: VM question (I hate Intel 810/815 chipsets...)
> What would be the best way to allocate:
>
> 1) a VM page whose physical address falls within a certain boundary, and
> 2) a VM object whose pages are contiguous in physical address space?
>
> Background:
> The !@*%^*!&#^%*&!#^$!@ Intel 810/815 graphics controller requires its
> instruction and hardware cursor buffers to reside within first 32MB and
> 512MB of *physical* memory space respectively. :( :( ;( The XFree86
> driver assumes the Linux memory model (virtual addr == physical addr),
> so it runs on Linux, but not always on FreeBSD.
You want to write a device driver to match this particular chip, which
uses the bus_dmamem functions to allocate a conforming memory region,
and then allow the userland process to mmap this region through your
device node.
It's nasty, but this sort of thing is just not normally done like this
in the *nix world. Here's a sample to give you an idea of what I'm
talking about wrt. allocating the memory.
size_t size; /* size of region */
bus_dma_tag_t tag;/* busdma goo */
bus_dma_map_t map;
void*mem; /* virtual pointer to region */
vm_offset_t physmem;/* physical pointer to region */
/* create a tag describing the memory you want */
bus_dma_tag_create(
NULL, /* inherit from nobody */
1, 0, /* alignment, boundary */
0, /* low address */
(32 * 1024 * 1024), /* high address */
NULL, NULL, /* filter and argument */
size, /* size of region */
1, /* maximum physical frags */
0, /* flags */
&tag);
/* allocate memory conforming to the tag */
mem = bus_dmamem_alloc(tag, &mem, BUS_DMA_NOWAIT, &map);
/* map the memory into bus-visible space */
bus_dmamap_load(tag, map, mem, size, helper, (void *)&physmem, 0);
...
/* unmap/free memory, free tag */
bus_dmamap_unload(tag, map);
bus_dmamam_free(tag, mem, map);
bus_dma_tag_destroy(tag);
/* save the physical address of the region */
void
helper(void *arg, bus_dma_segment_t *segs, int nseg, int error)
{
*(vm_offset_t *)arg = segs->ds_addr;
}
Note that this is the *only* correct way to do this (modulo bugs in
what I've just written here). Contigmalloc() is the wrong API, and
you should not use it.
Regards,
Mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: VM question (I hate Intel 810/815 chipsets...)
It sounds like the right approach to me. I'm assuming that you'll be writing a kernel driver for the memory, which has a mmap entry point in the cdevsw. The driver's mmap routine would just return the address of the contigmalloc region. I believe that the bktr driver has an example of this approach. -- Jonathan On Tue, Oct 09, 2001 at 06:08:41PM -0700, Eugene M. Kim wrote: > Thank you for the reply. > > I also found contigmalloc() shortly after I posted the original question > (what an embarrassment ;-p), then met another restriction: Because these > memory regions are to be accessed by a userland process (X server), they > have to be somehow mapped into the user space. So far it seems I would > have to do something similar to vm_mmap(), but I'm not sure if this is a > right direction. Do you have any suggestions? > > Cheers, > Eugene > > On Tue, Oct 09, 2001 at 07:37:41PM -0500, Jonathan Lemon wrote: > > > > > > In article [EMAIL PROTECTED]> >you write: > > >What would be the best way to allocate: > > > > > >1) a VM page whose physical address falls within a certain boundary, and > > >2) a VM object whose pages are contiguous in physical address space? > > > > > >Background: > > >The !@*%^*!&#^%*&!#^$!@ Intel 810/815 graphics controller requires its > > >instruction and hardware cursor buffers to reside within first 32MB and > > >512MB of *physical* memory space respectively. :( :( ;( The XFree86 > > >driver assumes the Linux memory model (virtual addr == physical addr), > > >so it runs on Linux, but not always on FreeBSD. > > > > You probably want contigmalloc(), which allocates a range of memory > > which is physically contiguous. (assuming this is a in-kernel driver) > > > > void * > > contigmalloc( > > unsigned long size, /* should be size_t here and for malloc() */ > > struct malloc_type *type, > > int flags, > > unsigned long low, > > unsigned long high, > > unsigned long alignment, > > unsigned long boundary) > > > > -- > > Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
wont reboot
after compiling a new kernel with only adding firewall support my thinkpad 760xd wont reboot all the way it just syncs disks and then hangs. someone know the right flags for this? the GENERIC kernel that ships with 4.4 and below seem to all work but a new kernel made with GENERIC dont. thanks. George
Re: VM question (I hate Intel 810/815 chipsets...)
Thank you for the reply. I also found contigmalloc() shortly after I posted the original question (what an embarrassment ;-p), then met another restriction: Because these memory regions are to be accessed by a userland process (X server), they have to be somehow mapped into the user space. So far it seems I would have to do something similar to vm_mmap(), but I'm not sure if this is a right direction. Do you have any suggestions? Cheers, Eugene On Tue, Oct 09, 2001 at 07:37:41PM -0500, Jonathan Lemon wrote: > > > In article [EMAIL PROTECTED]> you >write: > >What would be the best way to allocate: > > > >1) a VM page whose physical address falls within a certain boundary, and > >2) a VM object whose pages are contiguous in physical address space? > > > >Background: > >The !@*%^*!&#^%*&!#^$!@ Intel 810/815 graphics controller requires its > >instruction and hardware cursor buffers to reside within first 32MB and > >512MB of *physical* memory space respectively. :( :( ;( The XFree86 > >driver assumes the Linux memory model (virtual addr == physical addr), > >so it runs on Linux, but not always on FreeBSD. > > You probably want contigmalloc(), which allocates a range of memory > which is physically contiguous. (assuming this is a in-kernel driver) > > void * > contigmalloc( > unsigned long size, /* should be size_t here and for malloc() */ > struct malloc_type *type, > int flags, > unsigned long low, > unsigned long high, > unsigned long alignment, > unsigned long boundary) > > -- > Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SMC SMC9462TX GigE adapter, what performance should I expect?
Hi All, I just installed a couple of the SMC SMC9462TX adapters in two of my systems here and am playing around with them to see what kind of performance I can get from them (I have ordered a 8-port switch but won't get it for a couple of weeks). Both systems are running FreeBSD 4.4-stable, one is a 1.4 GHz Athlon and the other is a dual 1.2 GHz Athlon. Running netperf (the default test) over the link I get about 216 Mb/s. Frankly, I was hoping for more (perhaps double that number). Is that realistic? Do I need to do some configuration adjustments (all of my network paramemeters are at their defaults, including an MTU of 1500...though simply raising that didn't seem to help). Thanks for any help/advice, Bob -- Bob Willcox Putt's Law: [EMAIL PROTECTED]Technology is dominated by two types of people: Austin, TXThose who understand what they do not manage. Those who manage what they do not understand. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM question (I hate Intel 810/815 chipsets...)
In article [EMAIL PROTECTED]> you write: >What would be the best way to allocate: > >1) a VM page whose physical address falls within a certain boundary, and >2) a VM object whose pages are contiguous in physical address space? > >Background: >The !@*%^*!&#^%*&!#^$!@ Intel 810/815 graphics controller requires its >instruction and hardware cursor buffers to reside within first 32MB and >512MB of *physical* memory space respectively. :( :( ;( The XFree86 >driver assumes the Linux memory model (virtual addr == physical addr), >so it runs on Linux, but not always on FreeBSD. You probably want contigmalloc(), which allocates a range of memory which is physically contiguous. (assuming this is a in-kernel driver) void * contigmalloc( unsigned long size, /* should be size_t here and for malloc() */ struct malloc_type *type, int flags, unsigned long low, unsigned long high, unsigned long alignment, unsigned long boundary) -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
nfsd and mountd in the wrong place
I posted this to -arch and was met with (mostly) deafening silence. If someone could please take care of this, I would be most grateful. Since it requires a repo-copy, I guess Peter Wemm or JDP will need to be involved. -gordon -- Forwarded message -- Date: Tue, 2 Oct 2001 10:26:26 -0700 (PDT) From: Gordon Tetlow <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: nfsd and mountd in the wrong place I submitted a pr on this issue... http://www.freebsd.org/cgi/query-pr.cgi?pr=30972 -gordon On Sat, 29 Sep 2001, Gordon Tetlow wrote: > nfsd and mountd are in /sbin > rpcbind/portmap is in /usr/sbin > > nfsd and mountd aren't useful without rpcbind/portmap. And when was the > last time you needed nfsd and mountd to boot your system? I just checked, > NetBSD has already moved nfsd and mountd to /usr/sbin. > > Is there any reason why nfsd or mountd shouldn't be moved to /usr/sbin? > > -gordon > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
VM question (I hate Intel 810/815 chipsets...)
What would be the best way to allocate: 1) a VM page whose physical address falls within a certain boundary, and 2) a VM object whose pages are contiguous in physical address space? Background: The !@*%^*!&#^%*&!#^$!@ Intel 810/815 graphics controller requires its instruction and hardware cursor buffers to reside within first 32MB and 512MB of *physical* memory space respectively. :( :( ;( The XFree86 driver assumes the Linux memory model (virtual addr == physical addr), so it runs on Linux, but not always on FreeBSD. Cheers, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SEXWEB NO.1 .. MEGAWEB-SEX !
Dear Ladies & Gentlemen, Welcome to the GREATEST SEX SHOW on the ENTIRE NET ! We now offer you to ENTER the World´s No.1 voted SEX-SERVER on the WEB ! By far the largest and most incredible content of LIVE SEX is now served to users WORLDWIDE! EVERYTHING is offered 100% ANONOMOUSLY & you don´t need to sign-up or have a creditcard ... The way it should be ! TO PLUGIN and get access to something you with guarantee NEVER have seen before, use ANY of the servers listed below ! Enjoy the BEST! Yours truly, EROTICAWWW INC. To get EASY ACCESS & PLUGIN to the LARGEST CONTENT SEXSERVER on the NET, use any of the 2 SERVERS listed here: 1. http://superhits.onweb.cx 2. http://wwwap.to/superhits To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: calendar nit?
On Tue, 9 Oct 2001, Steve Ames wrote: > I was sending an e-mail to someone and wasn't sure what day Thanksgiving > was so I typed 'calendar -A 45' and saw the following: > > Nov 8* Thanksgiving Day (4th Thursday in November) > > Odd that... Is this tied to the missing days from 1753? Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
calendar nit?
I was sending an e-mail to someone and wasn't sure what day Thanksgiving was so I typed 'calendar -A 45' and saw the following: Nov 8* Thanksgiving Day (4th Thursday in November) Odd that... -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Message Passing
* Terry Lambert <[EMAIL PROTECTED]> [011009 14:37] wrote: > Matt Busigin wrote: > > For now, after looking at SVSV IPC, I am rewriting it so that the pointers > > are in the proc struct, and I am initialising them in kern_exec.c, but I > > am wishing/hoping there is a more elegant manner that I can do this > > completely in modules. > > Look at the KNOTE() code that notes to the proc. This mechanism > pretty much already exists, though no one has yet added support > for SVR4 message queues (it should be trivial) or arbitrary > messages (SVR4 shared memory or an mmaped file would end up > being the best transport). > > Not to be a wet blanket, or anything -- I've often bemoaned the > lack of this kind of thing in FreeBSD. Suggesting an easy to use method would probably get it coded for you. :) I was thinking about this problem and the quick and ugly fix would be to just have a linked list of containers hung off the proc struct or perhaps an array of pointers where each subsystem can allocate an index that it will use to hang off subsystem dependant data. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Message Passing
Matt Busigin wrote: > For now, after looking at SVSV IPC, I am rewriting it so that the pointers > are in the proc struct, and I am initialising them in kern_exec.c, but I > am wishing/hoping there is a more elegant manner that I can do this > completely in modules. Look at the KNOTE() code that notes to the proc. This mechanism pretty much already exists, though no one has yet added support for SVR4 message queues (it should be trivial) or arbitrary messages (SVR4 shared memory or an mmaped file would end up being the best transport). Not to be a wet blanket, or anything -- I've often bemoaned the lack of this kind of thing in FreeBSD. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Message Passing
Good morning fellow FreeBSDers: That was exciting. I couldn't post because my reverse DNS is buggered, so now I have to resort to using an American shell account for mail. Sloowww! :-) As a first experiment in hacking the FreeBSD kernel, I have written 'most' of a local message passing system as a kernel module. (I suppose it's not really a kernel hack, strictly speaking, then, is it? :) It is by no means fast, but because one can't change the 'proc' structure from within a kernel module, I had to store all of the messages, receiver and sender information in lists. Needless to say, it's slow, icky, and generally a bad idea. Handling inconsistencies is a pain in the arse. My questions are: 1/ Is there any better, more elegant way of storing the data that is closer to the process structure -- from within a module? 2/ Should I give up the module notion altogether, or at least artially couple the important bits (like pointers to the message queue in the struct proc definition) into the actual kernel source? I would appreciate any insight on the issue. If there is something I can read to gain enlightenment, I am quite happy to RTFM if someone can point out which manual to read. :-) For now, after looking at SVSV IPC, I am rewriting it so that the pointers are in the proc struct, and I am initialising them in kern_exec.c, but I am wishing/hoping there is a more elegant manner that I can do this completely in modules. Thank-you, Matt -- Matt Busigin - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Change to ldscript.i386
At 9:24 AM -0700 10/8/01, Peter Wemm wrote: >Using the same next address means that you dont have to put padding in the >file itself, and can simply double map the same page when loading >executables. Thanks for the explanation...it now makes sense why this was done (at least for userland executables). >Anyway, that is why it was done that way. What is or isn't good for >application executables doesn't necessarily apply to the kernel since it >isn't demand paged. > >In the kernel case the larger file size may actually end up using one less >page of actual memory for the kernel data segment. However, I seem to >recall Bruce telling me once that the 4MB page implementation breaks >something with the text read-only protection, so doing any roundup at all >is probably futile. Hmmm, I didn't get a strong sense of "do it" or "don't do it" for applying my patch. It sounds like applying it in the kernel ldscript (which is what I was looking at) wouldn't hurt. >Incidently, I have long been tempted to make a similar change to the >*userland* elf executable layout. I think this will significantly speed up >executable exec() times since we wont have to do the silly BSS pre-zero on >the bounary page, which will case an out-of-order page read. If the VM >system supported a "post faultin" callback hook we could avoid that. This sounds like something to put onto a project list for people to work on. Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: reading files from win
On Tue, Oct 02, 2001 at 09:14:56AM +0200, Martin Vana wrote: > hi, > is there any utility that can read a bsd FS from win/dos? > thank you None that I have heard of. If it's really important that you access the filesystem from Windows and you have a lot of CPU and memory to spare, you could run VMware [1] on Windows with FreeBSD running in a virtual machine. It's kind of a round-about way to do it, but it would probably work. -brian 1. http://www.vmware.com/ -- Brian O'Shea(408) 822-3249<[EMAIL PROTECTED]> 3.3.163(Pen) "Stare not too deeply into the Pen, lest the Pen stare back into you." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Debugging hard lockups, take 2.
I apologize for sending this twice, but I found out that my DNS was out all last night, meaning that anyone trying to reply during that period probably got a bounce with "no such domain". If you were such a person, DNS should be working again, so could you please try sending the reply again. Bleah, --- Begin Message --- I can generate hard lockups on my SMP box pretty easily. When locked, it fails to respond to anything - I can't even get into the kernel debugger to fire up. The lockups don't happen on UP machines under the same conditions, so I can't even see if console debugging would work, because I don't have a second SMP machine to run the kernel on. I'm running 4.4-stable, and I'm looking for suggestions on how to deal with this, other than "don't do that". Debugging kernel options, maybe? Thanks, http://www.mired.org/home/mwm/ Q: How do you make the gods laugh? A: Tell them your plans. --- End Message --- -- Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/ Q: How do you make the gods laugh? A: Tell them your plans.
Re: Heads up! My interview....
On 2001-10-08, Matt Dillon wrote: > OSNews interviewed me, it's up in today's page! I think it's a really > good interview but, of course, I am biased :-) > > http://osnews.com/story.php?news_id=153 Matt, in the interview you talk about > native process and device-level descriptor migration capability. any pointers to papers about this very interesting idea? thanks marco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Q] Information on fb/vesa mode programming
On Thu, Oct 04, 2001 at 09:11:52PM +0100, Jonathan Belson wrote: > Hiya > > > I've been trying to find out some information on programming the > fb/vesa interface, eg. set_video_mode() and friends. > > >From the few examples I've seen, it appears that you have to > muck about with banks rather than use a pointer to linear > frame buffer (logo_saver.c, splash.c). Is there no way to > access the fb linearly? In the GGI project (http://www.ggi-project.org), there's the vgl backend which is able to access the video fb when available throw libvgl. The S3 module in -current provide linear fb for most S3 cards even if they support only VESA1.2. You have: http://www.pegacity.it/Informatica/Case/1845/arch_eng.htm http://www.talula.demon.co.uk/freebe/index.html Enjoy! > Does anyone know of any resources giving more information > on fb programming? libvgl handles bank switching automagically if you use it's drawing routines. Nicolas -- Alcôve Technical Manager - [EMAIL PROTECTED] - http://www.alcove.com FreeBSD Developer - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
