Re: using get_system_info() - obtaining system load averages
--- Dan Nelson [EMAIL PROTECTED] wrote: In the last episode (Jan 09), kamal kc said: dear everybody, i want to use the routine get_system_info() to get the load averages of the cpu. i found it that top uses it. get_system_info is just a function /in/ top itself that gets the CPU usage. It uses the vm.loadavg sysctl to get the load average. A simpler way is to just call the getloadavg() function; see its manpage for more info. thanks i tried getloadavg() it worked. but when i tried to put it in the kernel the kernel failed to link. i also looked at sysctl(3) and i guess it is also for user based programs. so i looked at the sys/sysctl.h and found that there was sysctl_find_oid() that was defined for kernel. but i don't know how to use it. i could not get any info on the web. the function declaration was :: int sysctl_find_oid(int *name, u_int namelen, struct sysctl_oid **noid, int *nindx, struct sysctl_req *req); isn't it the function i should be using to retrieve the sysctl value ??? how should i use it ?? any demo on using it would be immensely helpful for me. thanks, kamal __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010
On Mon, Jan 09, 2006 at 08:21:16PM +0900, Daichi GOTO wrote: I have updated the patches: For 7-current patch: http://people.freebsd.org/~daichi/unionfs/unionfs-p3.diff For 6.x patch: http://people.freebsd.org/~daichi/unionfs/unionfs6-p3.diff changes from -p2 to -p3: - fixed problem of attribute associated with shadow dir - fixed lock/unlock problem (-p2 is not enought of this) - fixed initial treatment problem of some componentnames Please do the unionfs test with above new patch. I think that on sys/fs/unionfs/union_vfsops.c, line 116, done should be size_t, to have unionfs compiled on amd64 (and probably other !32bit archs) Best Regards -- Matteo Riondato FreeBSD Volunteer (http://freebsd.org) G.U.F.I. Staff Member (http://www.gufi.org) FreeSBIE Developer (http://www.freesbie.org) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: using get_system_info() - obtaining system load averages
On Mon, 2006-Jan-09 23:59:10 -0800, kamal kc wrote: thanks i tried getloadavg() it worked. but when i tried to put it in the kernel the kernel failed to link. You didn't mention the kernel bit before. To access the load average in the kernel, you just access averunnable (see sys/resource.h). Note that you cannot do floating point arithmetic in the kernel so the load averages are stored as fixed point numbers. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010
Matteo Riondato wrote: I think that on sys/fs/unionfs/union_vfsops.c, line 116, done should be size_t, to have unionfs compiled on amd64 (and probably other !32bit archs) Best Regards Yes, you are correct. Danny have pointed out the same problem. It is a careless mistake, so sorry. Please try the latest patch as follow: For 7-current patch: http://people.freebsd.org/~daichi/unionfs/unionfs-p4.diff For 6.x patch: http://people.freebsd.org/~daichi/unionfs/unionfs6-p4.diff -- ONGS Inc. Masanori OZAWA ([EMAIL PROTECTED]) WWW: http://www.ongs.co.jp/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: using get_system_info() - obtaining system load averages
--- Peter Jeremy [EMAIL PROTECTED] wrote: On Mon, 2006-Jan-09 23:59:10 -0800, kamal kc wrote: thanks i tried getloadavg() it worked. but when i tried to put it in the kernel the kernel failed to link. You didn't mention the kernel bit before. To access the load average in the kernel, you just access averunnable (see sys/resource.h). Note that you cannot do floating point arithmetic in the kernel so the load averages are stored as fixed point numbers. thanks , it worked i used the ldavg[] and fscale of averunnable to get the system load. you people are great .. kamal __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
pxeboot and serial console
I can't tell when this broke, but compiling pxeboot with BOOT_PXELDR_PROBE_KEYBOARD set would redirect the console to the serial port if no keyboard was detected. This no longer works, which explains the problems i had with the serial port on my intel 1U servers. the relevant code is in /sys/boot/i386/pxeldr/pxeldr.S. compiling with BOOT_PXELDR_ALWAYS_SERIAL works as expected, so IMHO the test: testb $KEYBOARD_BIT, MEM_BIOS_KEYBOARD # keyboard present? is failing, but i have no idea why any ideas? danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pxeboot and serial console
On Tuesday 10 January 2006 09:11 am, Danny Braniss wrote: I can't tell when this broke, but compiling pxeboot with BOOT_PXELDR_PROBE_KEYBOARD set would redirect the console to the serial port if no keyboard was detected. This no longer works, which explains the problems i had with the serial port on my intel 1U servers. the relevant code is in /sys/boot/i386/pxeldr/pxeldr.S. compiling with BOOT_PXELDR_ALWAYS_SERIAL works as expected, so IMHO the test: testb $KEYBOARD_BIT, MEM_BIOS_KEYBOARD # keyboard present? is failing, but i have no idea why any ideas? USB keyboards? Actually, it sounds in your case as if the BIOS is always claiming a keyboard is present. Perhaps your BIOS is just being lame, but that single test isn't the greatest test to use either. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 - amount of total visible memory is decreasing in time
Since no-one else has offered any input... On Sun, 2006-Jan-08 03:04:44 +0300, Ilya E Veretenkin wrote: Problem: Total amount of visible memory is decreasing while system is running (total amount = sum of all memory fields in 'top' utility output, in other words: Active+Inact+Wired+Cache+Buf+Free) This information is also available in sysctl variables (note units): Active: vm.stats.vm.v_active_count (pages) Inact: vm.stats.vm.v_inactive_count (pages) Wired: vm.stats.vm.v_wire_count (pages) Cache: vm.stats.vm.v_cache_count (pages) Buf:vfs.bufspace (bytes) Free: vm.stats.vm.v_free_count (pages) Unfortunately, the manipulation of these variables does not lend itself to easy understanding. There's also a 7th category unmanaged which is not directly reported. Active, inactive, cache and free pages are all managed via page queues (vm_page_queues) whilst wired pages, buffers and other other unmanaged pages don't exist on any queue. Two possibilities are: 1) There's a leak where pages are becoming unmanaged over time. Presumably there's a path where pages are being released without being returned to the free page queue. 2) There's a bug where pages are being placed onto page queues without the associated queue size variable being incremented. Unfortunately,I can't suggest a fix offhand. Note that since these counters are all managed independently and there's no locking when you access them from userland, you could expect to see some noise when adding them all up (rounding errors as you've noted). OS: FreeBSD 6 Server: 2xAmd64bit, 4GB memory, tyan motherboard I presume you're running an amd64 kernel. Are you in a position to check if the problem still exists with the i386 kernel or with a non-SMP kernel? Are you in a position to build a kernel with INVARIANTS enabled (which will impact kernel performance somewhat)? If you're interested in kernel hacking, you could write a kernel module that regularly scans vm_page_array and checks the number of pages on each page queue with the number reported for that queue, as well as reporting the number of unmanaged pages compared to the buffer space and wired pages. This would at least provide a pointer to where to look next. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: using get_system_info() - obtaining system load averages
--- Tofik Suleymanov [EMAIL PROTECTED] wrote: kamal kc wrote: --- Peter Jeremy [EMAIL PROTECTED] wrote: thanks i tried getloadavg() it worked. but when i tried to put it in the kernel the kernel failed to link. You didn't mention the kernel bit before. To access the load average in the kernel, you just access averunnable (see sys/resource.h). Note that you cannot do floating point arithmetic in the kernel so the load averages are stored as fixed point numbers. thanks , it worked i used the ldavg[] and fscale of averunnable to get the system load. you people are great .. kamal Just a curiosity: why use kernel-space functions to get system load ? Isn't it better to use sysctls in user-space ? actually the thing is , i have put some code in the bridge.c routine that attempts to compress/decompress ip packets. i don't know if it was a good idea since i am just a beginner in programming in the kernel and have a little knowledge regarding it. after i put my code i got a very high amount of interrupts (irq 21: xl1 interrupts) that overloads the cpu withing seconds if i pump about 4Mbps traffic through it. so i thought as a temp solution that i could turn off the compression if ever the cpu gets overloaded and that's it. But after a second thought-- the very idea of putting the large compression routine in the bridge code now seems awkward to me. since the compression takes time and putting the code in the bridge may be causing high interrupts i now think if i can do the compression stuffs in separate thread/process than in the bridge process itself. but right now i don't know how do i create a separate process/thread, what are the routines that i need to implement for this.. and also how to dispatch control from the bridge process to a new process without blocking. i am looking into these stuffs and hope i find something from the sources but it is getting really difficult ... maybe you people could have something to say, any advice on whether i am doing the right stuffs would be greatly helpful to me .. thanks, kamal __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: using get_system_info() - obtaining system load averages
kamal kc wrote: actually the thing is , i have put some code in the bridge.c routine that attempts to compress/decompress ip packets. i don't know if it was a good idea since i am just a beginner in programming in the kernel and have a little knowledge regarding it. after i put my code i got a very high amount of interrupts (irq 21: xl1 interrupts) that overloads the cpu withing seconds if i pump about 4Mbps traffic through it. so i thought as a temp solution that i could turn off the compression if ever the cpu gets overloaded and that's it. But after a second thought-- the very idea of putting the large compression routine in the bridge code now seems awkward to me. since the compression takes time and putting the code in the bridge may be causing high interrupts i now think if i can do the compression stuffs in separate thread/process than in the bridge process itself. but right now i don't know how do i create a separate process/thread, what are the routines that i need to implement for this.. and also how to dispatch control from the bridge process to a new process without blocking. i am looking into these stuffs and hope i find something from the sources but it is getting really difficult ... maybe you people could have something to say, any advice on whether i am doing the right stuffs would be greatly helpful to me .. you could bridge through a userland process using netgraph. I've done it.. it does work. (doing other things than compression) check out netgraph bridging.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: using get_system_info() - obtaining system load averages
On Tue, 2006-Jan-10 17:55:04 -0800, kamal kc wrote: after i put my code i got a very high amount of interrupts (irq 21: xl1 interrupts) that overloads the cpu withing seconds if i pump about 4Mbps traffic through it. so i thought as a temp solution that i could turn off the compression if ever the cpu gets overloaded and that's it. Load average isn't a good way of doing this. averunnable.ldavg[0] represents an exponential decay average of the run queue length that is updated (roughly) every 5 seconds with a 1 minute period. This is useless at measuring short-term CPU load. cp_time[] is probably a better choice for you - it uses statclock to report the CPU utilisation (every statclock interval, one element of the array is incremented) so you can (fairly) immediately detect if you have overloaded the CPU (for some definition of overload). -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
typo in src/sys/coda/coda_vfsops.c ??
Hi, I was just browsing the source tree, and came along a possible typo in src/sys/coda/coda_vfsops.c rev 1.60: #define MARK_ENTRY(op) (coda_vfsopstats[op].entries++) #define MARK_INT_SAT(op) (coda_vfsopstats[op].sat_intrn++) #define MARK_INT_FAIL(op) (coda_vfsopstats[op].unsat_intrn++) #define MRAK_INT_GEN(op) (coda_vfsopstats[op].gen_intrn++) The last MRAK should probably be MARK, as it is called that way a few times later in the code Hugo Meiland ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Driver for a 3G mobile phone.
In message [EMAIL PROTECTED], M. Warner Losh wrote: takawata-san, I have looked over this patch, and it looks good to me. Will you have time to commit it soon, or would you like someone else to commit for you? I'll commit it soon. Thanks. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Polling for devices other than NICs [patch]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ed Maste wrote: In addition, the current polling algorithm breaks down when you get to very high CPU utilization by the stack (e.g. if acting as a high bandwidth router). This happens because it adds one count per tick if the polling did not run longer than one hardclock interval, but brings it down to 7/8ths if it did. This ends up producing a sawtooth effect in the amount of work done by the polling handlers. Andre Oppermann is performing some high-perf stack testing, and he ran into this effect; in polling mode the maximum packet rate was achieved while there was still idle CPU time. Interesting. My (simple) work on this has been on low powered CPU machines (such as the Soekris single board systems): http://memberwebs.com/nielsen/freebsd/slow-cpu-routers.html I have a proof of concept patch that modifies the polling feedback algorithm to measure the amount of time spent in the polling handlers, and then attempt to schedule an appropriate amount of work to fill out the time slot. Andre is going to be testing it out shortly. Don't get me wrong, I think your patch is a step in the right direction, but we do have more work to do in order to completely generalize the polling code. Agreed. And sometime in the future, we should probably work towards implementing auto-switching between polling and interrupts: http://www.stanford.edu/class/cs240/readings/mogul.pdf Cheers, Nate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDwwfte/sRCNknZa8RAnMAAJ0de3eQELrbEgp5NF56wFtR2poYBACbBetq p/ZLh5bY6dbdPiIkIJMsCEM= =RADi -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: using get_system_info() - obtaining system load averages
kamal kc wrote: --- Peter Jeremy [EMAIL PROTECTED] wrote: On Mon, 2006-Jan-09 23:59:10 -0800, kamal kc wrote: thanks i tried getloadavg() it worked. but when i tried to put it in the kernel the kernel failed to link. You didn't mention the kernel bit before. To access the load average in the kernel, you just access averunnable (see sys/resource.h). Note that you cannot do floating point arithmetic in the kernel so the load averages are stored as fixed point numbers. thanks , it worked i used the ldavg[] and fscale of averunnable to get the system load. you people are great .. kamal __ Yahoo! DSL – Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] Just a curiosity: why use kernel-space functions to get system load ? Isn't it better to use sysctls in user-space ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ricoh PCI to SD device?
In message: [EMAIL PROTECTED] Brooks Davis [EMAIL PROTECTED] writes: : On Mon, Jan 09, 2006 at 03:35:51PM -0500, David Gilbert wrote: : Brooks == Brooks Davis [EMAIL PROTECTED] writes: : : Brooks On Mon, Jan 09, 2006 at 11:12:30AM -0500, David Gilbert wrote: : Has anyone had a look at the following: : : [EMAIL PROTECTED]:1:2: class=0x080501 card=0x01aa1028 chip=0x08221180 : rev=0x17 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'SD Bus Host : Adapter' class = base peripheral : : This shows up on my new Dell XPS-170 laptop. Since there is no USB : attachment for the SD card reader, I can only surmise that this is : it. Is someone looking at this, or is this completely new? : : Brooks People are looking at it, but there are no docs available. : Brooks Apparently, there is some work being done to reverse engineer : Brooks it. Linux doesn't support it either. : : Wasn't there a disk extension to project evil? : : It's been discussed, but I don't know of any actual work on it. I've seen some work on it. However, the interface isn't as easy to emulate as the network layer... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ricoh PCI to SD device?
In message: [EMAIL PROTECTED] Brooks Davis [EMAIL PROTECTED] writes: : On Mon, Jan 09, 2006 at 11:12:30AM -0500, David Gilbert wrote: : Has anyone had a look at the following: : : [EMAIL PROTECTED]:1:2: class=0x080501 card=0x01aa1028 chip=0x08221180 rev=0x17 hdr=0x00 : vendor = 'Ricoh Co Ltd' : device = 'SD Bus Host Adapter' : class= base peripheral : : This shows up on my new Dell XPS-170 laptop. Since there is no USB : attachment for the SD card reader, I can only surmise that this is : it. Is someone looking at this, or is this completely new? : : People are looking at it, but there are no docs available. Apparently, : there is some work being done to reverse engineer it. Linux doesn't : support it either. It does support the SDA Standard SD Host Adapter Interface. However, The standard costs $1000 (if you are a member of the SD Association, which I think is $1800 a year), and comes with an NDA so restrictive that you'll be lucky to release a binary only version of your driver. I'm working on a port of FreeBSD to an embedded platform. For that platform, we'll need to read data from MMC/SD cards. To do that, we'll need a mmc/sd disk driver, a mmc/sd bus and a mmc/sd bridge. This should give us a fairly good architecture to write a bridge driver for the SDA Standard SD Host Adapter Interface should someone ever figure out the interface. Tantalizing clues are available for the dilligent searcher on the web (the wikipedia entry for SD cards is especially enlightening). I have no plans to implement a the standard SD interface. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Ricoh PCI to SD device?
From: Brooks Davis On Mon, Jan 09, 2006 at 11:12:30AM -0500, David Gilbert wrote: Has anyone had a look at the following: [ Ricoh SD Bus Host Adapter, PCI ID 0x08221180 ] People are looking at it, but there are no docs available. Apparently, there is some work being done to reverse engineer it. Linux doesn't support it either. That's odd, because Ricoh provides technical documentation upon request via the LSI Contact Us[1] page on their website. 1: http://www.ricoh.com/LSI/mail.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ricoh PCI to SD device?
In message: [EMAIL PROTECTED] Darren Pilgrim [EMAIL PROTECTED] writes: : From: Brooks Davis : On Mon, Jan 09, 2006 at 11:12:30AM -0500, David Gilbert wrote: : Has anyone had a look at the following: : : [ Ricoh SD Bus Host Adapter, PCI ID 0x08221180 ] : : People are looking at it, but there are no docs available. Apparently, : there is some work being done to reverse engineer it. Linux doesn't : support it either. : : That's odd, because Ricoh provides technical documentation upon request via : the LSI Contact Us[1] page on their website. : : 1: http://www.ricoh.com/LSI/mail.html Are you sure they provide technical documentation sufficent to write the driver? The last time I asked, I got a nice document that said that it implemented the sds standard sd host interface, but didn't document what that was. TI and winbond chips datasheets are the same way. Prove me wrong. I'd love it :-) Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
