vm: kvm_free max_wired
Is this telling me I should be able to set kmem_size to around 740MiB before the kernel panics during boot? Any runtime issues with doing that? # sysctl hw.physmem hw.realmem vm.kvm_size vm.kvm_free vm.kmem_size hw.physmem: 1055293440 hw.realmem: 1072627712 vm.kvm_size: 1073737728 vm.kvm_free: 205516800 vm.kmem_size: 536870912 # sysctl -d hw.physmem vm.kvm_size vm.kvm_free vm.kmem_size hw.physmem: hw.realmem: vm.kvm_size: Size of KVM vm.kvm_free: Amount of KVM free vm.kmem_size: Size of kernel memory This doesn't seem to autosize. Is that expected? Should one care about this sysctl? vm.max_wired: System-wide limit to wired page count vm.max_wired: 83211 83211*4096/2^20 = ~325 Also, these are obviously broken / curious: debug.boothowto: -2147481598 net.inet.tcp.inflight.max: 1073725440 Running RELENG_8. ___ 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: SB7xx watchdog: new driver for review and testing
on 19/10/2009 18:47 Rui Paulo said the following: > On 19 Oct 2009, at 16:41, Andriy Gapon wrote: > >> >> I have put updated version of the driver (C file only) here: >> http://people.freebsd.org/~avg/amdsbwd.c > > Looks good to me. Thank you for the review and the help! I have now produced a diff against the main tree for full integration of this driver: http://people.freebsd.org/~avg/amdsbwd.diff -- Andriy Gapon ___ 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"
FreeBSD DAQ Card Facility [DCF]
Hi folks, some time ago, I decided to start working on an FreeBSD implementation for data acquisition support. Now I've published a very first Pre-Alpha version of the project. To become a more precisely overview take a look at http://freebsd-dcf.sourceforge.net/ Please notice that the project -as already mentioned- is in an early development stage. For that reason, we've only a skeleton driver which gives a guide about the ``DCF based'' low-level driver development. The ``DCF core'' source code needs a cleanup -I'll do that time permitting. The projects website needs also an update, especially the documentation part. In the foreseeable future I plan to add two USB drivers for two (DAQ) USB plug-in boards. But at this time the main focus is that the DCF project becomes a usable form. I hope that all this would be useful to our beloved FreeBSD =) It would be great to hear about some of other people's opinions. Thanks, Manuel Gebele -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ 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: Make process title - % complete
On Mon, Oct 19, 2009 at 05:51:42PM +0200, Ivan Voras wrote: > 2009/10/19 Alex Kozlov : > > On Mon, Oct 19, 2009 at 04:35:08PM +0200, Ivan Voras wrote: > >> >> if nobody objects, I'll commit it :) > >> > > >> > I seem to recall that setproctitle() is quite expensive to call; perhaps > >> > it would make sense offer a flag to prevent make(1) from calling it? [1] > >> > > >> > Anyway, the feature looks nice! I'd like to have it... > >> > > >> > [1] I'm unsure how expensive it is compared to fork(1)-ing etc; I'd > >> > expect it's negligable but who knows... > >> > >> The loop it's called in is not processed bazillion times per second > >> (though it *is* called surprisingly often; small, fast jobs can result > >> in somewhere in the order of magnitude of 100 iterations per second on > >> a fast CPU). As you said - I expect it's negligable compared to fork() > >> and the work jobs themselves do. > > How about add this statistic to make info handler? > You mean SIGINFO? Yes -- Adios ___ 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: Make process title - % complete
2009/10/19 Alex Kozlov : > On Mon, Oct 19, 2009 at 04:35:08PM +0200, Ivan Voras wrote: >> >> if nobody objects, I'll commit it :) >> > >> > I seem to recall that setproctitle() is quite expensive to call; perhaps >> > it would make sense offer a flag to prevent make(1) from calling it? [1] >> > >> > Anyway, the feature looks nice! I'd like to have it... >> > >> > [1] I'm unsure how expensive it is compared to fork(1)-ing etc; I'd >> > expect it's negligable but who knows... >> >> The loop it's called in is not processed bazillion times per second >> (though it *is* called surprisingly often; small, fast jobs can result >> in somewhere in the order of magnitude of 100 iterations per second on >> a fast CPU). As you said - I expect it's negligable compared to fork() >> and the work jobs themselves do. > How about add this statistic to make info handler? You mean SIGINFO? ___ 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: SB7xx watchdog: new driver for review and testing
On 19 Oct 2009, at 16:41, Andriy Gapon wrote: I have put updated version of the driver (C file only) here: http://people.freebsd.org/~avg/amdsbwd.c Looks good to me. -- Rui Paulo ___ 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: SB7xx watchdog: new driver for review and testing
I have put updated version of the driver (C file only) here: http://people.freebsd.org/~avg/amdsbwd.c Please let me know how it looks now. Thank you! -- Andriy Gapon ___ 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: Make process title - % complete
On Mon, Oct 19, 2009 at 04:35:08PM +0200, Ivan Voras wrote: > >> if nobody objects, I'll commit it :) > > > > I seem to recall that setproctitle() is quite expensive to call; perhaps > > it would make sense offer a flag to prevent make(1) from calling it? [1] > > > > Anyway, the feature looks nice! I'd like to have it... > > > > [1] I'm unsure how expensive it is compared to fork(1)-ing etc; I'd > > expect it's negligable but who knows... > > The loop it's called in is not processed bazillion times per second > (though it *is* called surprisingly often; small, fast jobs can result > in somewhere in the order of magnitude of 100 iterations per second on > a fast CPU). As you said - I expect it's negligable compared to fork() > and the work jobs themselves do. How about add this statistic to make info handler? -- Adios ___ 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: Make process title - % complete
Ivan Voras wrote: I have a small patch that makes "make" display percentage complete in process title, which can be retrieved in "top" in the form of: 71466 root 1 760 7008K 5696K select 0 0:00 0.00% make: 95% (55 more targets out of 1360) (make) Also: is there someone here more familiar with "make" who can tell me if the "current" top level target (i.e. the one taken from the command line) is kept track of somewhere? For example "clean" in "make clean install". ___ 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: Make process title - % complete
2009/10/19 Rink Springer : > Hi Ivan, > > On Mon, Oct 19, 2009 at 03:52:30PM +0200, Ivan Voras wrote: >> if nobody objects, I'll commit it :) > > I seem to recall that setproctitle() is quite expensive to call; perhaps > it would make sense offer a flag to prevent make(1) from calling it? [1] > > Anyway, the feature looks nice! I'd like to have it... > > [1] I'm unsure how expensive it is compared to fork(1)-ing etc; I'd > expect it's negligable but who knows... The loop it's called in is not processed bazillion times per second (though it *is* called surprisingly often; small, fast jobs can result in somewhere in the order of magnitude of 100 iterations per second on a fast CPU). As you said - I expect it's negligable compared to fork() and the work jobs themselves do. ___ 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: Make process title - % complete
Hi Ivan, On Mon, Oct 19, 2009 at 03:52:30PM +0200, Ivan Voras wrote: > if nobody objects, I'll commit it :) I seem to recall that setproctitle() is quite expensive to call; perhaps it would make sense offer a flag to prevent make(1) from calling it? [1] Anyway, the feature looks nice! I'd like to have it... [1] I'm unsure how expensive it is compared to fork(1)-ing etc; I'd expect it's negligable but who knows... -- Rink P.W. Springer- http://rink.nu "Beauty often seduces us on the road to truth." - Dr. Wilson ___ 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"
Make process title - % complete
I have a small patch that makes "make" display percentage complete in process title, which can be retrieved in "top" in the form of: 71466 root 1 760 7008K 5696K select 0 0:00 0.00% make: 95% (55 more targets out of 1360) (make) The patch is here and I'm inviting reviews and suggestions: http://people.freebsd.org/~ivoras/diffs/make.c.patch if nobody objects, I'll commit it :) ___ 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: namei (via firmware_get(9)) from taskq in 7.x
Kostik Belousov wrote: It seems that you want a merge of r178042,183614,184842,188057 (one of Yes, I finally figured this out on Fri. I probably should have posted a response to this thread to avoid others wasting time on this. Drew ___ 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: SB7xx watchdog: new driver for review and testing
on 19/10/2009 14:17 Rui Paulo said the following: > On 18 Oct 2009, at 21:10, Andriy Gapon wrote: > >> Please review and/or test a new driver for watchdog driver included >> into AMD SB7xx: >> http://people.freebsd.org/~avg/amdsbwd.tgz >> I have tested this driver only with SB700 on Gigabyte GA-MA780G-UD3H >> motherboard. >> >> ichwd driver was used as a starting point for this driver. This can be >> seen from >> some function names, general code organization and some small code >> snippets. >> Many thanks to ichwd authors and maintainers! >> >> Right now I have infrastructure only for building this driver as a >> module. >> >> Things for which that I need the most feedback/ideas: >> 1. If the driver actually works on your hardware and the hardware >> description. >> The driver can be tested by loading the driver and doing 'watchdog -t >> > number>'. Having debug.bootverbose=1 may provide additional useful info. >> And better to test this from single-user mode with filesystems mounted >> r/o. >> >> 2. Better name for the driver. amdsbwd stands for "AMD S(outh)B(ridge) >> WatchDog", but this abbreviation could be cryptic to decipher. >> >> 3. Proper location for this driver. >> At least on my system this driver needs resources (I/O ports and MEM >> range) that >> are claimed by ACPI, thus I've made it a child of acpi bus. But this >> driver >> doesn't have anything else ACPI-ish in it, so I decided that it >> doesn't belong >> under acpica/ or acpi_support/. Am I correct about this? >> >> Anything else you would like to report or comment or advise to me. >> Thank you very much for your help. > > The driver looks good in general. A few questions: > - Can you make the magic numbers a define ? Where did they come from ? Yes, will do this. The numbers are from register definitions in AMD SB700/710/750 Register Reference Guide: http://developer.amd.com/assets/43009_sb7xx_rrg_pub_1.00.pdf I will add a link to the document too. > - Are you missing a device_set_desc() call ? Yes, I missed this. Thanks! > - If this is what you want to commit, C++ comments are not allowed > per-style Those lines were a result of quick hacking. I will remove them altogether, -- Andriy Gapon ___ 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: SB7xx watchdog: new driver for review and testing
On 18 Oct 2009, at 21:10, Andriy Gapon wrote: Please review and/or test a new driver for watchdog driver included into AMD SB7xx: http://people.freebsd.org/~avg/amdsbwd.tgz I have tested this driver only with SB700 on Gigabyte GA-MA780G-UD3H motherboard. ichwd driver was used as a starting point for this driver. This can be seen from some function names, general code organization and some small code snippets. Many thanks to ichwd authors and maintainers! Right now I have infrastructure only for building this driver as a module. Things for which that I need the most feedback/ideas: 1. If the driver actually works on your hardware and the hardware description. The driver can be tested by loading the driver and doing 'watchdog - t number>'. Having debug.bootverbose=1 may provide additional useful info. And better to test this from single-user mode with filesystems mounted r/o. 2. Better name for the driver. amdsbwd stands for "AMD S(outh)B(ridge) WatchDog", but this abbreviation could be cryptic to decipher. 3. Proper location for this driver. At least on my system this driver needs resources (I/O ports and MEM range) that are claimed by ACPI, thus I've made it a child of acpi bus. But this driver doesn't have anything else ACPI-ish in it, so I decided that it doesn't belong under acpica/ or acpi_support/. Am I correct about this? Anything else you would like to report or comment or advise to me. Thank you very much for your help. The driver looks good in general. A few questions: - Can you make the magic numbers a define ? Where did they come from ? - Are you missing a device_set_desc() call ? - If this is what you want to commit, C++ comments are not allowed per- style Regards, -- Rui Paulo ___ 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"