Re: Kernel timers infrastructure
Hello again,
it seems that uprintf needs a tty to put output to.
I tried your code with printf instead of uprintf and got
output to root-console ttyu0 every second.
HTH,
Marc
Original-Nachricht
> Datum: Mon, 12 Sep 2011 11:58:37 +0200
> Von: Filippo Sironi
> An: "Marc Lörner"
> CC: freebsd-hackers@freebsd.org
> Betreff: Re: Kernel timers infrastructure
> This is how I modified the module:
>
> #include
> #include
> #include
> #include
>
> static struct callout timer_callout;
>
> static void
> timer_function(void *arg)
> {
> uprintf("timer_function() begin\n");
> if (callout_reset(&timer_callout, hz, timer_function, NULL))
> uprintf("callout_reset() != 0\n");
> uprintf("Hello, World!\n");
> uprintf("timer_function() end\n");
> }
>
> static int
> timer_event_handler(struct module *mod, int cmd, void *arg)
> {
> uprintf("timer_event_handler() begin\n");
> switch (cmd) {
> case MOD_LOAD:
> uprintf("MOD_LOAD\n");
> callout_init(&timer_callout, CALLOUT_MPSAFE);
> if (callout_reset(&timer_callout, hz, timer_function, NULL))
> uprintf("callout_reset() != 0\n");
> break;
> case MOD_UNLOAD:
> uprintf("MOD_UNLOAD\n");
> callout_drain(&timer_callout);
> break;
> case MOD_SHUTDOWN:
> uprintf("MOD_SHUTDOWN\n");
> break;
> default:
> return EOPNOTSUPP;
> }
> uprintf("timer_event_handler() end\n");
> return 0;
> }
>
> static struct moduledata timer_moduledata = {
> "timer",
> timer_event_handler,
> NULL
> };
>
> DECLARE_MODULE(timer, timer_moduledata, SI_SUB_DRIVERS, SI_ORDER_MIDDLE);
>
> and this is the output of load and unload operations:
> freebsd# kldload ./timer.ko
> timer_event_handler() begin
> MOD_LOAD
> timer_event_handler() end
> freebsd# kldunload timer.ko
> timer_event_handler() begin
> timer_event_handler() begin
> MOD_UNLOAD
> timer_event_handler() end
>
> I don't know why "timer_event_handler() begin" is printed twice on unload
> but the timer doesn't start... and of course it is set on 1 second but I
> left the module load for 1 minute or so just to be sure. ;)
>
> Thanks again for your help,
> Filippo
>
> On 12/set/2011, at 11:48, Marc Lörner wrote:
>
> > Hello,
> > what about changing order of callout_reset and uprintf?
> > And your timeout isn't 1minute, it's one second!
> >
> > Regards,
> > Marc
> > --
> > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
>
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
___
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: Re: Kernel timers infrastructure
Hello, what about changing order of callout_reset and uprintf? And your timeout isn't 1minute, it's one second! Regards, Marc >I already did that to ensure timer_event_handler would be called correctly. > >The result follows: > >freebsd# kldload ./timer.ko >timer_event_handler() with MOD_LOAD > >freebsd# kldunload ./timer.ko >timer_event_handler() with MOD_UNLOAD > >and I maintained the module load for about 1 minute so the timer printing >>"Hello, World!" should have been run. > >Filippo > >On 12/set/2011, at 11:24, Adrian Chadd wrote: > >> How about adding some printfs() to the functions to ensure they're being >> called? >> >> Adrian > >___ >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" -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ 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: how to do page level mem alloc in freebsd kernel?
Hello, what about using contigmalloc(9), there you can specify alignment and boundary. HTH, Marc >Hi, > >I want to allocate one (or more) pages in kernel space. >I'm not sure what is the api in freebsd (something which >is similar to __get_free_pages() of linux). > >Would malloc(4096, ...) guarantee that the returned >address is aligned on page boundary? > >Thanks and regards, >-Kalash -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl ___ 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: ide with DMA and ram > 4GB
On Thursday 13 November 2008 21:02, John Baldwin wrote: > On Wednesday 12 November 2008 12:23:14 pm Marc Lörner wrote: > > Hello, > > I just stepped over a problem with my IDE disk running in DMA-mode > > and having more than 4GB of RAM. > > It seems that the whole way down GEOM, ata-disk, ata-dma never is checked > > whether physical address of buffer is less than 4GB an so fits in 32bits. > > => when PRD is set the address is rigorously truncated to fit into 32bit, > >with buffer < 4GB all is quite fine. > > bus_dmamap_load() in ata-dma.c should result in bounce pages being > allocated and having the data copied to pages below 4GB and having those > addresses passed to the callback and stored in the PRD. Thanks for pointing this out! So it seems that bounce-pages are counted with helper-function run_filter. But this function does never return 1 with dma-pages not lying in range (e.g. paddr > 4GB) but being aligned. Did nobody else have problems on 64bit ide-dma, or is it already working, but I didn't grasp functionality, yet? For now, I came around this by adding a flag in "/sys/bus_dma.h" and setting this flag on tag-creation. So I now can check in run_filter whether I'm doing an ide-dma, relying on this and on check whether I got paddr > 4GB, I then can tell bus_dmamap_load to use bounce-pages. Any thoughts or comments? Regards, Marc Loerner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ide with DMA and ram > 4GB
Hello, I just stepped over a problem with my IDE disk running in DMA-mode and having more than 4GB of RAM. It seems that the whole way down GEOM, ata-disk, ata-dma never is checked whether physical address of buffer is less than 4GB an so fits in 32bits. => when PRD is set the address is rigorously truncated to fit into 32bit, with buffer < 4GB all is quite fine. So what do you recommend: - Easiest way (but not performantest) is to turn DMA for ide off and use PIO instead - Harder way: Bugfix ide-dma! When doing this, where do you recommend to put code? I tried to do a simple (but not performant) patch in in ata-disk functions ad_strategy and ad_done with using another aligned, with right boundary and physical address < 4GB and copying data from an to it from bp->b_data (or request->data). At least this one works, but copying from one to another buffer is not quite elegant and the code doesn't really belong there. So I thought of putting something into busdma_machdep, but right now I have now clue to where to hook in, because this function cannot modify buffer given from vfs_bio => geom => ata. Regards, Marc Loerner P.S.: I'm using kernel-sources from 7.0-RELEASE-p3 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: question on asymmetric mtx_[un]lock_sleep
On Wednesday 10 September 2008 20:09, John Baldwin wrote: > On Wednesday 10 September 2008 04:19:30 am Marc Lörner wrote: > > On Tuesday 09 September 2008 21:38, John Baldwin wrote: > > > On Thursday 04 September 2008 08:00:04 am Marc Lörner wrote: > > > > Hello, > > > > I just read through the code of mutexes and turnstiles > > > > and it seems to me that _mtx_lock_sleep and _mtx_unlock_sleep > > > > are some kind of asymmetric when turning SMP and adaptive mutexes > > > > on in kernel-configuration. > > > > > > > > On locking the mutex, we try to "quick" obtain the lock. > > > > If we can't do this, we look, whether some other thread, that's > > > > running, holds the lock and spin until either lock is freed or thread > > > > is not running anymore. In that case we try again to obtain the lock > > > > "quick". If the thread only stopped running but still holds the lock, > > > > we use > > > > > > turnstiles > > > > > > > to wake us up, when the thread unlocks the mutex. > > > > => That seems to be fine and quite symmetric with _mtx_unlock_sleep!! > > > > > > > > But if we're spinning and the other thread gave the mutex free, > > > > we quick-lock the mutex and don't set up a turnstile. > > > > > > > > Now on mtx_unlock_sleep: > > > > - in FreeBSD6/until revision 1.200 turnstiles were tested on > > > > existence. => if turnstile_lookup return NULL we only released the > > > > lock quick. > > > > > > > > - But now, it's never tested if turnstile exists instead we > > > > broadcast/wakeup all threads pending on the turnstile. If this > > > > turnstile is NULL => we > > > > > > access > > > > > > > wrong memory. > > > > > > > > Now my question is: Why can we be sure (in new source) that > > > > turnstile_lookup always returns a valid pointer to an turnstile and > > > > can use returned pointer to call turnstile_broadcast? Am I missing > > something? > > > > > Because it seems that following scenario may occur: > > > > - on locking same scenario as above (=> thread1 now holds the lock) > > > > - thread1 is put off the runqueue > > > > - thread2 now tries to quick unlock mutex and sees that thread1 holds > > > > it => call to mtx_unlock_sleep > > > > - now we try to use turnstile-mechanism and call turnstile_lookup => > > > > returns NULL because no thread waits for wakeup => we call > > > > turnstile_broadcast and crash. > > > > > > Newer locks don't set the CONTESTED flag unless they are actually going > > > to go to sleep. If they succeed in setting CONTESTED or it is already > > > set when they test for it, then they will block on the turnstile. The > > > turnstile chain lock will prevent a concurrent unlock from grabbing the > > > turnstile until the blocking thread is fully asleep. > > > > I see the setting of CONTESTED in case of sleeping in mtx_lock_sleep! > > But there is still the possibility that mtx_lock_sleep "just" obtains the > > lock > > > and doesn't set contested-bit! See described case above (we reach first > > continue in mtx_lock_sleep and test on obtain_lock ends while-loop). > > In that case the lock won't have a turnstile, so mtx_unlock_sleep() will > never be called. > > > Why is this bit not tested in mtx_unlock_sleep? > > If the bit is clear the first attempt to unlock the mutex will succeed, and > mtx_unlock_sleep() won't be called. > > > I think, it's still possible that turnstile_lookup returns NULL. > > And we still have "MPASS(ts != NULL);" in mtx_unlock_sleep that is not > > turned on for GENERIC-kernel (no INVARIANTS support). > > It won't return NULL. > > > And I'm still wondering why the former test on "ts != NULL" went away? > > As I mentioned, previously when a thread used to do an adaptive spin, it > would set the CONTESTED flag before spinning. This could result in the > case that a mutex would have CONTESTED set, but not have an associated > turnstile. Now that the adaptive spinning happens earlier before setting > CONTESTED, mutexes can no longer get into that state. That is, if > CONTESTED is set, the mutex always has an assigned turnstile. If CONTESTED > isn't set, then the first attempt to unlock a mutex will succeed, and > mtx_unlock_sleep() won't be called at all. I got an Page-Not-Present fault on my itanium machine and thought this error is coming from the mutex and turnstile functions. Because when checking on NULL in mtx_unlock_sleep the fault went away. But I was wrong. A little more research resulted in the error lying in the architecture-dependent part of the pcpu.h-macros. So after a thread switched cores he may use the old address of pcpu and curthread that now doesn't hold the right tid anymore. Thanks for your explanations and sorry for the noise! Marc Loerner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: question on asymmetric mtx_[un]lock_sleep
On Tuesday 09 September 2008 21:38, John Baldwin wrote: > On Thursday 04 September 2008 08:00:04 am Marc Lörner wrote: > > Hello, > > I just read through the code of mutexes and turnstiles > > and it seems to me that _mtx_lock_sleep and _mtx_unlock_sleep > > are some kind of asymmetric when turning SMP and adaptive mutexes > > on in kernel-configuration. > > > > On locking the mutex, we try to "quick" obtain the lock. > > If we can't do this, we look, whether some other thread, that's running, > > holds the lock and spin until either lock is freed or thread is not > > running anymore. In that case we try again to obtain the lock "quick". > > If the thread only stopped running but still holds the lock, we use > > turnstiles > > > to wake us up, when the thread unlocks the mutex. > > => That seems to be fine and quite symmetric with _mtx_unlock_sleep!! > > > > But if we're spinning and the other thread gave the mutex free, > > we quick-lock the mutex and don't set up a turnstile. > > > > Now on mtx_unlock_sleep: > > - in FreeBSD6/until revision 1.200 turnstiles were tested on existence. > > => if turnstile_lookup return NULL we only released the lock quick. > > > > - But now, it's never tested if turnstile exists instead we > > broadcast/wakeup all threads pending on the turnstile. If this turnstile > > is NULL => we > > access > > > wrong memory. > > > > Now my question is: Why can we be sure (in new source) that > > turnstile_lookup always returns a valid pointer to an turnstile and can > > use returned pointer to call turnstile_broadcast? Am I missing something? > > > > Because it seems that following scenario may occur: > > - on locking same scenario as above (=> thread1 now holds the lock) > > - thread1 is put off the runqueue > > - thread2 now tries to quick unlock mutex and sees that thread1 holds it > > => call to mtx_unlock_sleep > > - now we try to use turnstile-mechanism and call turnstile_lookup => > > returns NULL because no thread waits for wakeup => we call > > turnstile_broadcast and crash. > > Newer locks don't set the CONTESTED flag unless they are actually going to > go to sleep. If they succeed in setting CONTESTED or it is already set > when they test for it, then they will block on the turnstile. The > turnstile chain lock will prevent a concurrent unlock from grabbing the > turnstile until the blocking thread is fully asleep. I see the setting of CONTESTED in case of sleeping in mtx_lock_sleep! But there is still the possibility that mtx_lock_sleep "just" obtains the lock and doesn't set contested-bit! See described case above (we reach first continue in mtx_lock_sleep and test on obtain_lock ends while-loop). Why is this bit not tested in mtx_unlock_sleep? I think, it's still possible that turnstile_lookup returns NULL. And we still have "MPASS(ts != NULL);" in mtx_unlock_sleep that is not turned on for GENERIC-kernel (no INVARIANTS support). And I'm still wondering why the former test on "ts != NULL" went away? Regards, Marc Loerner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
question on asymmetric mtx_[un]lock_sleep
Hello, I just read through the code of mutexes and turnstiles and it seems to me that _mtx_lock_sleep and _mtx_unlock_sleep are some kind of asymmetric when turning SMP and adaptive mutexes on in kernel-configuration. On locking the mutex, we try to "quick" obtain the lock. If we can't do this, we look, whether some other thread, that's running, holds the lock and spin until either lock is freed or thread is not running anymore. In that case we try again to obtain the lock "quick". If the thread only stopped running but still holds the lock, we use turnstiles to wake us up, when the thread unlocks the mutex. => That seems to be fine and quite symmetric with _mtx_unlock_sleep!! But if we're spinning and the other thread gave the mutex free, we quick-lock the mutex and don't set up a turnstile. Now on mtx_unlock_sleep: - in FreeBSD6/until revision 1.200 turnstiles were tested on existence. => if turnstile_lookup return NULL we only released the lock quick. - But now, it's never tested if turnstile exists instead we broadcast/wakeup all threads pending on the turnstile. If this turnstile is NULL => we access wrong memory. Now my question is: Why can we be sure (in new source) that turnstile_lookup always returns a valid pointer to an turnstile and can use returned pointer to call turnstile_broadcast? Am I missing something? Because it seems that following scenario may occur: - on locking same scenario as above (=> thread1 now holds the lock) - thread1 is put off the runqueue - thread2 now tries to quick unlock mutex and sees that thread1 holds it => call to mtx_unlock_sleep - now we try to use turnstile-mechanism and call turnstile_lookup => returns NULL because no thread waits for wakeup => we call turnstile_broadcast and crash. Regards, Marc Loerner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: forcefsck on booting stage
On Monday 28 July 2008 15:00, Jeremy Chadwick wrote: > On Mon, Jul 28, 2008 at 04:11:49PM +0400, sam wrote: > > Hello, > > > > How to make 'fsck -f' on booting stage of remote system? > > I believe by setting background_fsck="no" in /etc/rc.conf? That's the > only way I know of, besides booting single user and doing it manually. Doesn't this only disable background fsck support? By creating file "/forcefsck" you can force an fsck at next reboot, because some scripts test for existence. HTH, Marc Loerner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: reading a file in kernelmode
Hello David! On Thursday 17 July 2008 01:46, David wrote: > Hello, > > > > I'm developing a FreeBSD kernel module and I'm searching for a good > solution to open/read/close a file. > > My goal is to generate a MD5-Hash of a given file (path). > > > > Open-Syscall seems to be improper. > > > > Any ideas/solutions/examples? > Look at file kern/kern_ktrace.c at the use of vn_open in function ktrace(td, uap) and VOP_WRITE in function ktr_writerequest(struct thread *td, struct ktr_request *req) I think reading is done quite analogue to writing in case above. HTH, Marc ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to get a kthread ID?
On Thursday 25 October 2007 11:02, Sergey Matveychuk wrote: > Is there a possibility to get a kthread ID inside a kthread? > Just like pthread_self(3). In function kthread_exit there you see that you can obtain the thread-structure with curthread. And then in this thread-structure is the field td_tid. HTH, Marc ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Writing a plain text file to disk from kernel space
Hello Lawrence, in file kern/vfs_syscalls.c you can see the kern_open function that uses vn_open to open a file/vnode. There are more vn_* functions like vn_rdwr for reading and writing to a vnode or vn_close to close a vnode. To see how theses functions work, I suggest you grep for them in the kernel-files. BTW, you can get an thread-struct pointer from curthread (c.f. sys/pcpu.h). HTH, Marc Lörner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Usage of kern_* functions in kernel
On Thursday 26 April 2007 19:49, John Baldwin wrote: > On Thursday 26 April 2007 08:08:19 am Marc Lörner wrote: > > Hello, > > I googled but found nothing about the usage of the kern_* functions > > (kern_open, kern_close, kern_pwritev, kern_preadv) that are located in > > vfs_syscalls.c > > > > When I use kern_open to open a file within the kernel, I get an error. > > When I use the normal vn_open function instead, all works well. > > > > So my question is which functions are recommended by you kernel-hackers > > for use within kernelspace? > > > > And here a second question: Is it possible to open/use the console driver > > in kernelspace within the functions mentioned above? > > If not, can you give me some pointers on where I can find this > > information! > > kern_XXX are generally used by system calls such as alternative ABIs, etc. so, you would recommend using the vn_* functions instead? -- Marc ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Usage of kern_* functions in kernel
Hello, I googled but found nothing about the usage of the kern_* functions (kern_open, kern_close, kern_pwritev, kern_preadv) that are located in vfs_syscalls.c When I use kern_open to open a file within the kernel, I get an error. When I use the normal vn_open function instead, all works well. So my question is which functions are recommended by you kernel-hackers for use within kernelspace? And here a second question: Is it possible to open/use the console driver in kernelspace within the functions mentioned above? If not, can you give me some pointers on where I can find this information! Regards, Marc ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: i am facing these issues after my FreeBSD 6.2 installation.
> Hi, > > I've recently installed FreeBSD release 6.2 successfully except that the > following things that i need importantly dont work. How should i do these? > > 1. I am using PPP over Ethernet (PPPoE). I am running FreeBSD on Vmware and > i set the network connection as "Bridged" on Vmware. I configured my > Ethernet device with the correct IP, Gateway, Netmask, DNS but i dont know > how to start my internet on FreeBSD. All i do to connect to the internet on > Windows is give my username and password. I also read the PPPoE chapter on > the FreeBSD manual but of no use. How should i start PPoE on FreeBSD? > dunno > 2. I need Vim. I dont want to use Vi. I searched in my CD-1 and CD-2. But i > could not find the package "vim" inside it. Since i am not able to connect > to the internet is there any other way to install Vim ? maybe you put the vim package from internet on a floppy or cd-iso image then mount this image and tell vmware to use it. > > 3. How should i configure FreeBSD to start in X mode directly. Currently i > have to do startx to start X on my machine. change the entry in /etc/ttys starting with ttyv8... to: ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm on secure > > 4. I want to make "bash" as the default shell instead of "csh". Where is > that configured? in a shell type "chsh" then change the entry starting with "Shell:" according to the shell you want to have. > > 5. Where are the kernel sources located? I need it because i want to do > kernel network programming? Is having kernel sources sufficient or there > are other dependencies also? /usr/src/sys > > 6. How do developers usually keep their kernel sources in sync with the > main Central Kernel source? Do we use CVS or Subversion for this? dunno > > Thanks & Regards, > Ajay. > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" HTH, Marc -- Freundliche Gruesse, Marc Lörner Tel.: +49 (0)9103-715-30046 Fax.: +49 (0)9103-715-271 Internet: http://www.hob.de E-Mail: [EMAIL PROTECTED] HOB GmbH & Co. KG Schwadermühlstraße 3 90556 Cadolzburg Geschaeftsfuehrer Klaus Brandstaetter - Franz Wiedenmann AG Fuerth HRA 5180 Steuer-Nr. 218/163/00107 USt-ID-Nr. DE 132747002 Komplementaerin HOB electronic BeteiligungsGmbH AG Fuerth HRB 3416 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Allocate aligned memory
On Friday 15 December 2006 10:19, Hans Petter Selasky wrote: ... > > My suggestion is to make the your high limit (currently 1 << 22) MUCH > > higher, if possible. Also, getting rid of the 1MB boundary might help. > > PS: contigmalloc is on the way out. Please use "man bus_dma" instead. For > an example see: > > http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_subr >.c > > And the function "usbd_mem_alloc_sub()". Thanks for the help, I finally got contigmalloc working! Next step is converting to bus_dmamem_alloc, but AFAICS this function still uses contigmalloc. So what are the main improvements on using these new functions? Kind regards, Marc ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Allocate aligned memory
Hello all, I want to allocate 120KB of memory thats aligned to 32KB. I already saw/found the function contigmalloc, now my question is, why following functioncall never does return with an resulting address, instead null is returned? unsigned long *p = (unsigned long*) contigmalloc(120*1024, M_DEVBUF, M_WAITOK, 0, (1<<22), 32*1024, 1024*1024); Thanks in advance, Marc P.S.: I'm already aware that contigmalloc doesn't support M_WAITOK! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
