Memory management
Hello there, I have a computer running FreeBSD 6.1. As time passing by, the memory fills up. When the machine starts, memory is occupied to 30 %, and after two or three weeks memory is occupied to 100 % and it begins to use swap. It is inactive pages that fills up the memory. I tried to restart every process, but memory usage does not decrease. Only a reboot can fix that. And I'm not able to see which process leaks. I was not able to find a correct definition of what inactive memory is. First, I would like to know what are these kind of pages : wired, active, inactive, cache and free. Is that normal that inactive memory usage grows ? What should I do ? Do you have any tools to monitor memory usage of processes ? Many thanks, regards, ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory management
On Wed, 2006-Jul-26 11:26:34 +0200, Stephane Dupille wrote: As time passing by, the memory fills up. When the machine starts, memory is occupied to 30 %, and after two or three weeks memory is occupied to 100 % and it begins to use swap. How are you monitoring memory usage? Do you mean 'swap' or 'page'? A level of page-in's is normal because text and data areas for processes are loaded by paging them in. I was not able to find a correct definition of what inactive memory is. First, I would like to know what are these kind of pages : wired, active, inactive, cache and free. Wired pages are pages that the kernel has wired to RAM so they cannot be paged out. Active pages are being mapped by virtual memory and in use by running processes. Inactive pages are not currently mapped but the kernel knows their contents and can re-map them without needing to retrieve them from disk - they may be dirty. Cache pages are similar to active pages but aren't dirty and are higher-priority candidates for being freed. Free pages have no useful content and will be used to fulfil page-in requests. Is that normal that inactive memory usage grows ? Yes. 'Free' memory is basically wasted and so the kernel tries to limit it, subject to having sufficient free memory to meet page-faults. Most of your RAM should be wired, active or inactive. Inactive memory will start at 0 and grow as active pages are released. What should I do ? Nothing. Why do you think you have a problem? Do you have any tools to monitor memory usage of processes ? ps(1) -- Peter Jeremy pgpYlM6L9c5ab.pgp Description: PGP signature
Re: Memory management
On Wed, 26 Jul 2006, Stephane Dupille wrote: I have a computer running FreeBSD 6.1. As time passing by, the memory fills up. When the machine starts, memory is occupied to 30 %, and after two or three weeks memory is occupied to 100 % and it begins to use swap. It is inactive pages that fills up the memory. I tried to restart every process, but memory usage does not decrease. Only a reboot can fix that. And I'm not able to see which process leaks. I was not able to find a correct definition of what inactive memory is. First, I would like to know what are these kind of pages : wired, active, inactive, cache and free. Is that normal that inactive memory usage grows ? What should I do ? Do you have any tools to monitor memory usage of processes ? You can find an article discussing some of the FreeBSD VM system design here: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-design/article.html This document is gradually aging, and doesn't cover certain elements of the design, including some recent optimizations, SMP behavior, etc, but still makes quite a good read. It could be that you have applications leaking memory, but it's more likely that the VM system is simply being efficient. Free memory is, in effect, wasted memory, since it's not being used. FreeBSD will agressively cache file system data, and either drop or page out unused pages (depending on whether they are dirty) in order to maximize the amount of memory available for actively used data. This means it will swap out dirty pages allocated by a process if the process isn't using them, rather than keep them in memory preventing that memory from being used by processes that need it. The result is that at any given moment, an active system should have almost no free memory, and instead should be providing as much memory as possible to active pages, and the largest possible file system cache. This may seem counter-intuitive compared to some other systems where a premium is placed on free pages as representing the resources available to run additional applications. We consider memory floating around unused to be a waste of memory that could be used to improve system performance. systat -vmstat 1 is a good tool to monitor the VM system, as it will let you monitor memory use, in particular, the vnode and swap paging rates. You can use ps(1) with various parameters to inspect process memory use. A popular combination is aux, which views all processes and displays, among other things, their virtual and resident sizes. The resident size is the figure you want to look at, as it represents the number of pages actually in memory, rather than pages that could be paged in. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory management
Peter Jeremy [EMAIL PROTECTED] écrit : As time passing by, the memory fills up. When the machine starts, memory is occupied to 30 %, and after two or three weeks memory is occupied to 100 % and it begins to use swap. How are you monitoring memory usage? Using top, mainly. And ps, swapinfo, vmstat... Do you mean 'swap' or 'page'? swap. A level of page-in's is normal because text and data areas for processes are loaded by paging them in. OK for that, but when I have 700 MB of inactive memory, and free memory reaching zero, the system begins to use the swap : swapinfo says that swap is used (paged out). Is that normal ? Wired pages are pages that the kernel has wired to RAM so they cannot be paged out. Active pages are being mapped by virtual memory and in use by running processes. Inactive pages are not currently mapped but the kernel knows their contents and can re-map them without needing to retrieve them from disk - they may be dirty. Cache pages are similar to active pages but aren't dirty and are higher-priority candidates for being freed. Free pages have no useful content and will be used to fulfil page-in requests. OK, thanks for the definitions. Why there is two states inactive and cache, if they are so similar ? (it's just curiosity, my questions have answers now.) Yes. 'Free' memory is basically wasted and so the kernel tries to limit it, subject to having sufficient free memory to meet page-faults. Most of your RAM should be wired, active or inactive. Inactive memory will start at 0 and grow as active pages are released. OK, sounds clear. What should I do ? Nothing. Why do you think you have a problem? As long as I was not sure what inactive means, I was not sure of what to think. My first guess was that inactive memory are like active memory but was not accessed for some time, and as such have more priority to be pages out to swap than active memory. So i tried to search for the real definition of what inactive memory is, and what I found was a little bit fuzzy. Do you have any tools to monitor memory usage of processes ? ps(1) ps(1) is ok to check snapshots of process states, but not the evolution of the memory usages. I looked for a tool mainly to find processes with memory leaks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Filesystem full: out of inodes - possibly ataraid bug?
Hi all, I'm seeing a strange problem on two of my servers (both 6.0-RELEASE). Both seem to have corrupted their filesystems in such a way that no more files can be created because they are apparently out of inodes, even though df -i suggests otherwise... A reboot doesn't fix this: system1: system1# touch /usr/test /usr: create/symlink failed, no inodes free touch: /usr/test: No space left on device system1# uptime 12:42PM up 6 mins, 1 user, load averages: 0.00, 0.07, 0.05 system1# df -i Filesystem 1K-blocks UsedAvail Capacity iused ifree %iused Mounted on /dev/ar0s1a594926 64174 48315812% 931 761231% / devfs 1 10 100% 0 0 100% /dev /dev/ar0s1h 47164554 4 43391386 0% 2 60999640% /spare /dev/ar0s1d507630 22 466998 0% 11 657790% /tmp /dev/ar0s1g 15231278 322924 13689852 2% 18411 19599551% /usr /dev/ar0s1f 6090094 1626 5601262 0% 158 8006080% /var /dev/ar0s1e 2026030 6 1863942 0% 3 2826190% /var/tmp system1# tail -20 /var/log/messages Jul 26 12:42:03 system1 kernel: pid 539 (touch), uid 0 inumber 2 on /usr: out of inodes system1# uname -a FreeBSD xxx 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Wed Nov 2 19:07:38 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 system2: [EMAIL PROTECTED]:/root# touch /test /: create/symlink failed, no inodes free touch: /test: No space left on device [EMAIL PROTECTED]:/root# df -i / Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ar0s1a495726 132474 32359429%1519 627352% / [EMAIL PROTECTED]:/root# uname -a FreeBSD xxx 6.0-RELEASE-p5 FreeBSD 6.0-RELEASE-p5 #3: Thu Mar 2 18:26:48 GMT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/XXX i386 The only connection between these two systems is that both are mirrored using ataraid - system1 uses FreeBSD PseudoRAID which is currently running in DEGRADED mode (another disk is on order), and system2 has an Adaptec 1200A soft-RAID card (Promise chipset), which lost a disk (but has since been repaired) at some point in the past. With system2, the problems started at the same time as the disk replacement, I have no idea if the times correlate with system1 though. I run many FreeBSD machines without ataraid, and several with ataraid that have never lost a disk, and none of these systems have had any issues. Hence me wondering if some aspect of ataraid is flawed when it comes to handling degraded arrays. With system1, background fscks during reboot fail with: Jul 21 10:24:23 system1 kernel: pid 525 (fsck_ufs), uid 0 inumber 3 on /usr: out of inodes A full fsck (by setting background_fsck=NO and fsck_y_enable=YES in /etc/rc.conf and reboot) fixed the problems. I can't take system2 down to perform a full fsck at the moment. At the moment, system2 can't be taken to 6.1-R due to the NFS slowdown bug. I will take system1 to 6.1-R, although I guess it won't make any difference as presumably the damage is already done. I can provide dumps and images of the affected filesystems to trusted developers. Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory management
Stephane Dupille [EMAIL PROTECTED] wrote: Peter Jeremy [EMAIL PROTECTED] écrit : As time passing by, the memory fills up. When the machine starts, memory is occupied to 30 %, and after two or three weeks memory is occupied to 100 % and it begins to use swap. How are you monitoring memory usage? Using top, mainly. And ps, swapinfo, vmstat... Do you mean 'swap' or 'page'? swap. Note that it is normal that processes get swapped out if they haven't been in the run queue for a very long time and free memory has reached near zero (which is also normal). That's a feature, because it improves efficiency in most situations, because more RAM is available to processes which really need it. For example, if you use X11 and don't log into syscons' virtual terminals (/dev/vty*), you will notice that the getty(8) processes will be swapped out after some time when there is not many free memory left: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 382 root 3 0 996K 0K ttyin 0:00 0.00% 0.00% getty 383 root 3 0 996K 0K ttyin 0:00 0.00% 0.00% getty 384 root 3 0 996K 0K ttyin 0:00 0.00% 0.00% getty 385 root 3 0 996K 0K ttyin 0:00 0.00% 0.00% getty 386 root 3 0 996K 0K ttyin 0:00 0.00% 0.00% getty If you want to check whether there's a _real_ shortage of RAM (or a memory leak somewhere), a good way is to watch the po and sr columns in the output of vmstat 5: procsmemorypagedisksfaults cpu r b w avm fre flt re pi po fr sr ad0 da0 in sy cs us sy id 1 0 0 39960 44944 62 0 0 0 61 3 0 0 157 6 36 2 1 97 0 0 0 39960 44944 2 0 0 0 0 0 0 0 1132 19 8 0 0 100 0 0 0 39960 44944 1 0 0 0 0 0 0 1 1132 19 8 0 0 100 0 0 0 34300 44944 1 0 0 0 0 0 0 0 1132 23 9 0 0 100 The po (page-out) column indicates paging activity, i.e. data is moved to the swap. The sr (scan-rate) column measures the speed at which inactive pages are scanned for becomeing cache or free pages; this number is a good measure of the pressure on the VM system. If both numbers are almost always near zero, you don't have to worry at all. If the numbers are constantly high, you either have a leak somewhere that you need to discover, or you need to add more RAM to your machine. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.1 Tor issues (Once More, with Feeling)
Fabian Keil [EMAIL PROTECTED] wrote: Peter Thoenen [EMAIL PROTECTED] wrote: To you have pf running? If so can you turn it off for a bit a see if you still crash. On my box I was getting all sorts of witness kbd backtraces on pf and since turning pf off (maybe a week ago), haven't crashed yet. Going to let it keep running unmetered for another 2 weeks and see if I crash or not. How is it going, Peter, still running? I'm running Tor jailed and use PF for NAT, port forwarding and filtering: http://tor.fabiankeil.de/pf-stats/ So far I didn't see a single PF related complaint from witness, but I'll try disabling PF in a few days anyway. It took a little longer than I thought, but I finally disabled PF today and switched to natd. At the moment I'm still testing if enabling polling really increases the uptime. I'm still not sure, however polling made it possible to use fxp0 without acpi, the hangs still occur and the serial console still becomes unresponsive though. On another wild guess I switched Tor's threading library from libpthread to libthr. While it doesn't seem to affect the uptime, it makes Tor's cpu usage visible in top, so maybe it would be a good default for tor-devel? Fabian -- http://www.fabiankeil.de/ signature.asc Description: PGP signature
Re: scan stuck with if_iwi(4)
On Thu, Jul 20, 2006 at 04:01:20PM -0700, Sam Leffler wrote: The basic problem is your card is losing sync w/ the ap. I don't know what the local conditions are but I've seen this a lot w/ iwi; there's nothing we can do in the driver if you want to be able to roam. Update: this was just fixed in iwi(4) in -CURRENT (by increasing the beacon miss threshold for the iwi(4) driver from 7 to 10). Should 10 not be enough, it is now also possible to set the beacon miss threshold using ifconfig. Thanks to Sam for helping and for applying my patches to -CURRENT. This functionality should be MFC'd in two weeks. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpv5kuFIG9T8.pgp Description: PGP signature
Re: scan stuck with if_iwi(4)
Henrik Brix Andersen wrote: On Thu, Jul 20, 2006 at 04:01:20PM -0700, Sam Leffler wrote: The basic problem is your card is losing sync w/ the ap. I don't know what the local conditions are but I've seen this a lot w/ iwi; there's nothing we can do in the driver if you want to be able to roam. Update: this was just fixed in iwi(4) in -CURRENT (by increasing the beacon miss threshold for the iwi(4) driver from 7 to 10). Should 10 not be enough, it is now also possible to set the beacon miss threshold using ifconfig. Thanks to Sam for helping and for applying my patches to -CURRENT. This functionality should be MFC'd in two weeks. Thanks for your help but understand this is not necessarily a solution; just the addition of a knob. The linux driver already used 7 consecutive beacon misses to trigger roaming so I'm not sure why 10 is an improvement but given that adding 300ms (typical) lag makes you happy I wasn't going to argue :) Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
On Tue, Jul 25, 2006 at 11:51:25AM -0400, Mike Jakubik wrote: I need to be able to get the cpu and fan information from my motherboard, however none of the monitoring utilities in the ports seems to support my motherboard (Supermicro PDSMi, Intel E7230 (Mukilteo) Chipset). On my older VIA based motherboards and some Nvidia, i can get this information using ACPI and the hw.acpi.thermal sysctl. This however is not available on this motherboard. Would this be a shortcoming of the motherboards ACPI implementation, or a lack of support by freebsd? Does this one support IPMI? -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scan stuck with if_iwi(4)
On Wed, Jul 26, 2006 at 09:10:03AM -0700, Sam Leffler wrote: Thanks for your help but understand this is not necessarily a solution; just the addition of a knob. I know. The linux driver already used 7 consecutive beacon misses to trigger roaming so I'm not sure why 10 is an improvement but given that adding 300ms (typical) lag makes you happy I wasn't going to argue :) Actually, it seems the linux driver uses a threshold of 8 missed beacons for roaming and a threshold of 24 for disassociation. But you're correct - this only solves the issue of being disassociated every 3 minutes; it doesn't solve the problem behind scan stuck, but this problem is not present here anymore since the station is not disassociated all the time. I'll try to address the scan stuck problem when I find some more time. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpSfwF9fbvoh.pgp Description: PGP signature
Re: filesystem full error with inumber
Feargal Reilly presumably uttered the following on 07/24/06 11:48: On Mon, 24 Jul 2006 17:14:27 +0200 (CEST) Oliver Fromme [EMAIL PROTECTED] wrote: Nobody else has answered so far, so I try to give it a shot ... The filesystem full error can happen in three cases: 1. The file system is running out of data space. 2. The file system is running out of inodes. 3. The file system is running out of non-fragmented blocks. The third case can only happen on extremely fragmented file systems which happens very rarely, but maybe it's a possible cause of your problem. I rebooted that server, and df then reported that disk at 108%, so it appears that df was reporting incorrect figures prior to the reboot. Having cleaned up, it appears by my best calculations to be showing correct figures now. kern.maxfiles: 2 kern.openfiles: 3582 Those have nothing to do with filesystem full. Yeah, that's what I figured. Looking again at dumpfs, it appears to say that this is formatted with a block size of 8K, and a fragment size of 2K, but tuning(7) says: [...] Reading this makes me think that when this server was installed, the block size was dropped from the 16K default to 8K for performance reasons, but the fragment size was not modified accordingly. Would this be the root of my problem? I think a bsize/fsize ratio of 4/1 _should_ work, but it's not widely used, so there might be bugs hidden somewhere. Such as df not reporting the actual data usage, which is now my best working theory. I don't know what df bases it's figures on, perhaps it either slowly got out of sync, or more likely, got things wrong once the disk filled up. I'll monitor it to see if this happens again, but hopefully won't keep that configuration around for too much longer anyway. Thanks, -fr. One of my machines that I recently upgraded to 6.1 (6.1-RELEASE-p3) is also exhibiting df reporting wrong data usage numbers. Notice the negative Used numbers below: df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/da0s1a496M 63M393M14%/ devfs 1.0K1.0K 0B 100%/dev /dev/da0s1e989M -132M1.0G -14%/tmp /dev/da0s1f 15G478M 14G 3%/usr /dev/da0s1d 15G -1.0G 14G-8%/var /dev/md0 496M228K456M 0%/var/spool/MIMEDefang devfs 1.0K1.0K 0B 100%/var/named/dev Sven ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scan stuck with if_iwi(4)
Henrik Brix Andersen wrote: On Wed, Jul 26, 2006 at 09:10:03AM -0700, Sam Leffler wrote: Thanks for your help but understand this is not necessarily a solution; just the addition of a knob. I know. Sure, it was for others. The linux driver already used 7 consecutive beacon misses to trigger roaming so I'm not sure why 10 is an improvement but given that adding 300ms (typical) lag makes you happy I wasn't going to argue :) Actually, it seems the linux driver uses a threshold of 8 missed beacons for roaming and a threshold of 24 for disassociation. Which version are you looking at? The numbers in iwi are from the code in linux-2.6.17; maybe it's been changed again in the code on sourceforge? The one thing the linux driver does differently is scan for a new ap _before_ roaming which the current net80211 code cannot do. Unfortunately the code to do that has been sitting outside the tree for a long time and it's unclear if it'll ever come in... But you're correct - this only solves the issue of being disassociated every 3 minutes; it doesn't solve the problem behind scan stuck, but this problem is not present here anymore since the station is not disassociated all the time. I'll try to address the scan stuck problem when I find some more time. Thank you. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
Bruno Ducrot wrote: On Tue, Jul 25, 2006 at 11:51:25AM -0400, Mike Jakubik wrote: I need to be able to get the cpu and fan information from my motherboard, however none of the monitoring utilities in the ports seems to support my motherboard (Supermicro PDSMi, Intel E7230 (Mukilteo) Chipset). On my older VIA based motherboards and some Nvidia, i can get this information using ACPI and the hw.acpi.thermal sysctl. This however is not available on this motherboard. Would this be a shortcoming of the motherboards ACPI implementation, or a lack of support by freebsd? Does this one support IPMI? ASUS A8N32-SLI Deluxe not ... ipmi driver in kernel installed, but finds no device. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scan stuck with if_iwi(4)
On Wed, Jul 26, 2006 at 11:07:36AM -0700, Sam Leffler wrote: Sure, it was for others. Ah :) Which version are you looking at? The numbers in iwi are from the code in linux-2.6.17; maybe it's been changed again in the code on sourceforge? I was looking in the ipw2200.h header file from ipw2200-1.1.2 - but the values are the same in version 1.1.1 of the driver, which is present in linux-2.6.17. #define IPW_MB_ROAMING_THRESHOLD_DEFAULT8 #define IPW_MB_DISASSOCIATE_THRESHOLD_DEFAULT 3*IPW_MB_ROAMING_THRESHOLD_DEFAULT The one thing the linux driver does differently is scan for a new ap _before_ roaming which the current net80211 code cannot do. Unfortunately the code to do that has been sitting outside the tree for a long time and it's unclear if it'll ever come in... Oh? Sounds interesting, where can I find these patches? Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpoFWY6qokxS.pgp Description: PGP signature
wine: ld-elf.so.1 not found
I'm having a very strange problem with Wine. It apparently refuses to see ld when starting: escaflowne/p7 (72 ~): wine ELF interpreter /libexec/ld-elf.so.1 not found Even though it's obviously on the system: escaflowne/p7 (74 ~): ls /libexec ld-elf.so.1 ld-elf.so.1.old Ktrace doesn't really provide much of anything helpful since even ld won't start: escaflowne/p7 (77 ~): ktrace wine ELF interpreter /libexec/ld-elf.so.1 not found [1]90037 abort ktrace wine escaflowne/p7 134 (78 ~): kdump 90037 ktrace RET ktrace 0 90037 ktrace CALL execve(0xbfbfe170,0xbfbfe698,0xbfbfe6a0) 90037 ktrace NAMI /bin/wine 90037 ktrace RET execve -1 errno 2 No such file or directory 90037 ktrace CALL execve(0xbfbfe170,0xbfbfe698,0xbfbfe6a0) 90037 ktrace NAMI /sbin/wine 90037 ktrace RET execve -1 errno 2 No such file or directory 90037 ktrace CALL execve(0xbfbfe170,0xbfbfe698,0xbfbfe6a0) 90037 ktrace NAMI /usr/bin/wine 90037 ktrace RET execve -1 errno 2 No such file or directory 90037 ktrace CALL execve(0xbfbfe170,0xbfbfe698,0xbfbfe6a0) 90037 ktrace NAMI /usr/games/wine 90037 ktrace RET execve -1 errno 2 No such file or directory 90037 ktrace CALL execve(0xbfbfe170,0xbfbfe698,0xbfbfe6a0) 90037 ktrace NAMI /usr/sbin/wine 90037 ktrace RET execve -1 errno 2 No such file or directory 90037 ktrace CALL execve(0xbfbfe170,0xbfbfe698,0xbfbfe6a0) 90037 ktrace NAMI /usr/local/bin/wine 90037 ktrace NAMI /libexec/ld-elf.so.1 I'm a bit behind on the releases, but this just seem so odd regardless: escaflowne/p7 (79 ~): uname -a FreeBSD escaflowne.ceyah.org 6.0-RELEASE FreeBSD 6.0-RELEASE #1: Tue Jun 20 11:19:53 EDT 2006 [EMAIL PROTECTED]:/backup/obj/data/src/sys/ESCAFLOWNE i386 Recompiling Wine makes no difference, and it is the only application on my system that appears to be affected. I'm using Wine 0.9.17,1. I'm really stumped as to what the problem is. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
On Jul 26, 2006, at 11:09 AM, Bruno Ducrot wrote: On Tue, Jul 25, 2006 at 11:51:25AM -0400, Mike Jakubik wrote: I need to be able to get the cpu and fan information from my motherboard, however none of the monitoring utilities in the ports seems to support my motherboard (Supermicro PDSMi, Intel E7230 (Mukilteo) Chipset). On my older VIA based motherboards and some Nvidia, i can get this information using ACPI and the hw.acpi.thermal sysctl. This however is not available on this motherboard. Would this be a shortcoming of the motherboards ACPI implementation, or a lack of support by freebsd? Does this one support IPMI? Yes, the Supermicro PDSMi supports the IPMI 2.0 module and I can confirm that it works with the IPMI ported driver from current on 6.1. The module is optional so you will have to purchase one for the system, around 0. You will also need the latest BIOS loaded on the motherboard for it to work. http://www.supermicro.com/products/accessories/addon/AOC-IPMI20-E.cfm -- DaveD
Re: filesystem full error with inumber
On Wed, 2006-Jul-26 13:07:19 -0400, Sven Willenberger wrote: One of my machines that I recently upgraded to 6.1 (6.1-RELEASE-p3) is also exhibiting df reporting wrong data usage numbers. What did you upgrade from? Is this UFS1 or UFS2? Does a full fsck fix the problem? -- Peter Jeremy pgpzljAGgFapT.pgp Description: PGP signature
Re: filesystem full error with inumber
Peter Jeremy presumably uttered the following on 07/26/06 15:00: On Wed, 2006-Jul-26 13:07:19 -0400, Sven Willenberger wrote: One of my machines that I recently upgraded to 6.1 (6.1-RELEASE-p3) is also exhibiting df reporting wrong data usage numbers. What did you upgrade from? Is this UFS1 or UFS2? Does a full fsck fix the problem? This was an upgrade from a 5.x system (UFS2); a full fsck did in fact fix the problem (for now). Thanks, Sven ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
O. Hartmann wrote: I need to be able to get the cpu and fan information from my motherboard, however none of the monitoring utilities in the ports seems to support my motherboard (Supermicro PDSMi, Intel E7230 (Mukilteo) Chipset). On my older VIA based motherboards and some Nvidia, i can get this information using ACPI and the hw.acpi.thermal sysctl. This however is not available on this motherboard. Would this be a shortcoming of the motherboards ACPI implementation, or a lack of support by freebsd? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Similar problem to me here with a ASUS A8N32-SLI Deluxe. The older versions of this motherboard type like A8N-SLI Deluxe and maybe A8N-SLI Premium had thermal zones in ACPI output, but not the A8N32-SLI. No temperature, no fanspeed, no thermal zones. ASUS P800 SE i865e chipset - problems too. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scan stuck with if_iwi(4)
Henrik Brix Andersen wrote: On Wed, Jul 26, 2006 at 11:07:36AM -0700, Sam Leffler wrote: Sure, it was for others. Ah :) Which version are you looking at? The numbers in iwi are from the code in linux-2.6.17; maybe it's been changed again in the code on sourceforge? I was looking in the ipw2200.h header file from ipw2200-1.1.2 - but the values are the same in version 1.1.1 of the driver, which is present in linux-2.6.17. #define IPW_MB_ROAMING_THRESHOLD_DEFAULT8 #define IPW_MB_DISASSOCIATE_THRESHOLD_DEFAULT 3*IPW_MB_ROAMING_THRESHOLD_DEFAULT If I recall the first is used to trigger a bg scan to look for a better ap. If that fails and the 2nd number is seen then the driver shuts down. So I guess this amounts to disconnecting from the current ap on the 2nd number but I'm not sure how you can do the bg scan and still get the firmware to keep counting up to the larger number (it resets it's internal counter on channel change from what I recall). But it's been a while. Regardless you've got a knob now so you can set it to whatever you want. You shouldn't be missing beacons in such large numbers; it's a likely indicator of some other problem but since we don't know what exactly a bmiss means it's hard to say (e.g. the firmware may report a bmiss when the rssi of the received beacon frame is below a threshold in which case there may be a problem with the threshold setting). The one thing the linux driver does differently is scan for a new ap _before_ roaming which the current net80211 code cannot do. Unfortunately the code to do that has been sitting outside the tree for a long time and it's unclear if it'll ever come in... Oh? Sounds interesting, where can I find these patches? The work has always been in perforce.freebsd.org; look in the sam_wifi branch. The code will not hit head until folks show up to fix legacy drivers that use net80211. I got stuck holding the bag when I committed the wpa support and it ain't going to happen again. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scan stuck with if_iwi(4)
On Wed, Jul 26, 2006 at 01:28:12PM -0700, Sam Leffler wrote: Henrik Brix Andersen wrote: Oh? Sounds interesting, where can I find these patches? The work has always been in perforce.freebsd.org; look in the sam_wifi branch. The code will not hit head until folks show up to fix legacy drivers that use net80211. I got stuck holding the bag when I committed the wpa support and it ain't going to happen again. Do you have a list of drivers that are stalling this? Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
Bruno Ducrot wrote: On Tue, Jul 25, 2006 at 11:51:25AM -0400, Mike Jakubik wrote: I need to be able to get the cpu and fan information from my motherboard, however none of the monitoring utilities in the ports seems to support my motherboard (Supermicro PDSMi, Intel E7230 (Mukilteo) Chipset). On my older VIA based motherboards and some Nvidia, i can get this information using ACPI and the hw.acpi.thermal sysctl. This however is not available on this motherboard. Would this be a shortcoming of the motherboards ACPI implementation, or a lack of support by freebsd? Does this one support IPMI? Yes, but with an optional $54 add-on card. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
MFC of kern_resource.c (calru changes)
Are there any plans to MFC the last few commits to kern_resource.c to -STABLE? I have a number of machines which flood the logs with calcru: negative runtime messages every time w, ps or top is used, so im hoping these may fix the issue. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
David Duchscher wrote: On Jul 26, 2006, at 11:09 AM, Bruno Ducrot wrote: Does this one support IPMI? Yes, the Supermicro PDSMi supports the IPMI 2.0 module and I can confirm that it works with the IPMI ported driver from current on 6.1. The module is optional so you will have to purchase one for the system, around 0. You will also need the latest BIOS loaded on the motherboard for it to work. http://www.supermicro.com/products/accessories/addon/AOC-IPMI20-E.cfm I don't want to spend $50 extra per system, just so i can read the temperature, and not even use any of the IPMI functions. I need a simple and scriptable way to get the values, acpi sysctls are ideal for this. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: filesystem full error with inumber
Sven Willenberger wrote: Feargal Reilly presumably uttered the following on 07/24/06 11:48: On Mon, 24 Jul 2006 17:14:27 +0200 (CEST) Oliver Fromme [EMAIL PROTECTED] wrote: Nobody else has answered so far, so I try to give it a shot ... The filesystem full error can happen in three cases: 1. The file system is running out of data space. 2. The file system is running out of inodes. 3. The file system is running out of non-fragmented blocks. The third case can only happen on extremely fragmented file systems which happens very rarely, but maybe it's a possible cause of your problem. I rebooted that server, and df then reported that disk at 108%, so it appears that df was reporting incorrect figures prior to the reboot. Having cleaned up, it appears by my best calculations to be showing correct figures now. kern.maxfiles: 2 kern.openfiles: 3582 Those have nothing to do with filesystem full. Yeah, that's what I figured. Looking again at dumpfs, it appears to say that this is formatted with a block size of 8K, and a fragment size of 2K, but tuning(7) says: [...] Reading this makes me think that when this server was installed, the block size was dropped from the 16K default to 8K for performance reasons, but the fragment size was not modified accordingly. Would this be the root of my problem? I think a bsize/fsize ratio of 4/1 _should_ work, but it's not widely used, so there might be bugs hidden somewhere. Such as df not reporting the actual data usage, which is now my best working theory. I don't know what df bases it's figures on, perhaps it either slowly got out of sync, or more likely, got things wrong once the disk filled up. I'll monitor it to see if this happens again, but hopefully won't keep that configuration around for too much longer anyway. Thanks, -fr. One of my machines that I recently upgraded to 6.1 (6.1-RELEASE-p3) is also exhibiting df reporting wrong data usage numbers. Notice the negative Used numbers below: Negative isnt an example of programming error, just that the system is now using the last bit only root can use. for insight try for example man tunefs reboot boot -s tunefs -m 2 /dev/da0s1e then decide what level of m you want default is 8 to 10 I recall. df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/da0s1a496M 63M393M14%/ devfs 1.0K1.0K 0B 100%/dev /dev/da0s1e989M -132M1.0G -14%/tmp /dev/da0s1f 15G478M 14G 3%/usr /dev/da0s1d 15G -1.0G 14G-8%/var /dev/md0 496M228K456M 0%/var/spool/MIMEDefang devfs 1.0K1.0K 0B 100%/var/named/dev Sven -- Julian Stacey. Consultant Unix Net Sys. Eng., Munich. http://berklix.com Mail in Ascii, HTML=spam. Ihr Rauch = mein allergischer Kopfschmerz. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: filesystem full error with inumber
From Julian H. Stacey [EMAIL PROTECTED], Thu, Jul 27, 2006 at 01:45:16AM +0200: Negative isnt an example of programming error, just that the system is now using the last bit only root can use. for insight try for example man tunefs reboot boot -s tunefs -m 2 /dev/da0s1e then decide what level of m you want default is 8 to 10 I recall. df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/da0s1a496M 63M393M14%/ devfs 1.0K1.0K 0B 100%/dev /dev/da0s1e989M -132M1.0G -14%/tmp /dev/da0s1f 15G478M 14G 3%/usr /dev/da0s1d 15G -1.0G 14G-8%/var /dev/md0 496M228K456M 0%/var/spool/MIMEDefang devfs 1.0K1.0K 0B 100%/var/named/dev Sven Julian: if you looked more closely you would see that the negative numbers appear not in the available category but in the 'USED'. This has nothing to do with root reserve. It may have something to do with background fsck though but it is rather inconsistent. 989 - (-132) == 1G 15G - (-1.0G) != 14G ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
On 7/27/06, Mike Jakubik [EMAIL PROTECTED] wrote: I don't want to spend $50 extra per system, just so i can read the temperature, and not even use any of the IPMI functions. I need a simple and scriptable way to get the values, acpi sysctls are ideal for this. What about using SMBus? Is it available on your system? xmbmon reads temperatures off the SMBus IIRC. Jiawei Ye -- Without the userland, the kernel is useless. --inspired by The Tao of Programming ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MFC of kern_resource.c (calru changes)
Mike Jakubik wrote: Are there any plans to MFC the last few commits to kern_resource.c to -STABLE? I have a number of machines which flood the logs with calcru: negative runtime messages every time w, ps or top is used, so im hoping these may fix the issue. Well, one way to help make sure that happens is to test it yourself, and report to the developers. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
