Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD?
On Wed, Oct 01, 2008 at 02:29:12PM +0800, lhmwzy wrote: > That's it. > Since we don't have the skill,what we can do is wait. > > Waiting is such a bad thing... If this functionality is really something you want/need, you should consider finding a kernel programmer who would be willing to port it, for financial exchange (in English: you will be paying them $XX/hour to port it to FreeBSD). This has happened in the past for some key features. Like I said, it all depends on how much it matters to you. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD?
Yes,this is a way. I would do as you said if I need to do so. 2008/10/1 Jeremy Chadwick <[EMAIL PROTECTED]>: > On Wed, Oct 01, 2008 at 02:29:12PM +0800, lhmwzy wrote: >> That's it. >> Since we don't have the skill,what we can do is wait. >> >> Waiting is such a bad thing... > > If this functionality is really something you want/need, you should > consider finding a kernel programmer who would be willing to port it, > for financial exchange (in English: you will be paying them $XX/hour > to port it to FreeBSD). > > This has happened in the past for some key features. Like I said, it > all depends on how much it matters to you. > > -- > | Jeremy Chadwickjdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jails and mac_seeotheruids problems in 6-STABLE
Robert Watson wrote: On Tue, 30 Sep 2008, George Mamalakis wrote: It works like a charm! Thank you very much for your time and help, No problem -- I've gone ahead and committed that change to stable/6. If you're able to test 6.4RC1 when it comes out to confirm that the fix works there as desired, that would be most helpful. I will csup to 6.4RC1 when available, and will inform you of the outcome. Thanks again. Thanks, Robert N M Watson Computer Laboratory University of Cambridge regards, Robert Watson wrote: On Tue, 30 Sep 2008, George Mamalakis wrote: I have 3 servers in my lab. 2 of them are running 6-STABLE and one of them is running 7-STABLE. All three have services running in jails. I noticed a very peculiar behavior in 6-STABLE when I set the sysctl security.mac.seeotheruids.enabled=1. The root user in my jails was not able to see processes and sockets owned by other users of the same jail, whereas the root user of the host system could see every process (thank the Almighty). The same behavior does not apply on the server running 7-STABLE. In one sense it is more secure, since the root user in a jail is not as "strong" as the root user should be in a UNIX system. On the other hand, the root user looses its purpose of existence, which I suppose is a bug. Below are the security.mac sysctl settings of both 6 and 7-STABLE: Could you try modifying src/sys/security/mac_seeotheruids/mac_seeotheruids.c in a 6.x tree so that the call to suser_cred() in mac_seeotheruids_check() passes the SUSER_ALLOWJAIL flag rather than 0? This may correct the problem you're experiencing. Let me know and I can merge that change to 6.x. Robert N M Watson Computer Laboratory University of Cambridge 6-STABLE: security.mac.max_slots: 4 security.mac.enforce_network: 1 security.mac.enforce_pipe: 1 security.mac.enforce_posix_sem: 1 security.mac.enforce_suid: 1 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.enforce_vm: 1 security.mac.enforce_process: 1 security.mac.enforce_socket: 1 security.mac.enforce_system: 1 security.mac.enforce_kld: 1 security.mac.enforce_sysv_msg: 1 security.mac.enforce_sysv_sem: 1 security.mac.enforce_sysv_shm: 1 security.mac.enforce_fs: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 security.mac.portacl.rules: uid:80:tcp:80,uid:80:tcp:443 security.mac.portacl.port_high: 1023 security.mac.portacl.autoport_exempt: 1 security.mac.portacl.suser_exempt: 1 security.mac.portacl.enabled: 1 7-STABLE: security.mac.max_slots: 4 security.mac.version: 3 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.suser_privileged: 1 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 I would be very glad if someone could inform me whether I am doing something wrong; if not I think I should inform FreeBSD about this bug. Thank you guys in advance, -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs?
On 30 sep 2008, at 12:46, Jeremy Chadwick wrote: On Tue, Sep 30, 2008 at 12:08:48PM +0200, Holger Kipp wrote: - email (imap) I've had good experience with dovecot; I tend to stay away from Cyrus products (disgusting code with a history of security issues), and Courier (no interest). I had to disable mmap access in dovecot, or it would coredump periodically. (mmap_disable = yes in dovecot.conf) I found that to be a problem only on ZFS. I don't know if that's been fixed yet. Apart from that it works great. Ben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Request for testing - top 3.8b1 in the base system
On 2008-09-28 14:24:09 (+0200), Nikola Lečić <[EMAIL PROTECTED]> wrote: > On Sun, 28 Sep 2008 15:46:20 +1000 Edwin Groothuis <[EMAIL PROTECTED]> wrote: > > Please report any issues with it (compile time, run time) and a way to > > reproduce it (if possible). Thanks for your help! > > last pid: 70762; load avg: 1.22, 0.54, 0.33; up 0+16:48:11 14:08:01 > 177 threads: 11 running, 147 sleeping, 19 waiting > CPU: 27.6% user, 0.0% nice, 3.3% system, 0.7% interrupt, 68.4% idle > Kernel: 246626 ctxsw, 5063 trap, 362 intr, 354 soft, 5 fork, 4591 flt, 728 fr > Mem:891M Active, 774M Inact, 233M Wired, 89M Cache, 112M Buf, 3668K Free > Swap: 4096M Total, 4096M Free > > [...] > > Btw, an aesthetic observation, in H mode the USERNAME column shrinks > and expands if username has less or more than 9 characters. :-) Another aesthetic observation is the alignment of the CPU: line - it would be nice if the data all lined up nicely with Kernel/Mem/Swap below. Very minor point though. Thanks for making this work! - Philip -- Philip PaepsPlease don't Cc me, I am [EMAIL PROTECTED] subscribed to the list. Greebo's technique was unscientific and wouldn't have stood a chance against any decent swordmanship, but on his side was the fact that it is almost impossible to develop decent swordmanship when you seem to have run into a food mixer that is biting your ear off. -- (Terry Pratchett, Witches Abroad) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs?
On Wed, Oct 01, 2008 at 10:42:32AM +0200, Ben Stuyts wrote: > I had to disable mmap access in dovecot, or it would coredump > periodically. (mmap_disable = yes in dovecot.conf) I found that to be a > problem only on ZFS. I don't know if that's been fixed yet. Apart from > that it works great. This seems relevant to your problem: http://www.dovecot.org/list/dovecot/2008-March/029565.html HEAD had this problem fixed in rev 1.28, dated 2008/03/15. RELENG_7 had this problem fixed in rev 1.31.2.2, dated 2008/04/26. Here's the proper file in cvsweb so you can see it yourself: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Have you tried re-enabling mmap in dovecot on a system with a kernel build after those dates? If so, does it still randomly segfault? If so, have you reported this to [EMAIL PROTECTED] :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GELI partition mount on boot fails after 7.0 -> 7.1-PRERELEASE upgrade
On Tuesday 30 September 2008 20:32, Roland Smith wrote: > My GELI encrypted home partition works fine on amd64 7.1-PRERELEASE > (updated september 25th). I've been tracking stable since 7.0-RELEASE > without problems. > > My custom kernel includes GEOM_ELI, GEOM_LABEL, GEOM_MIRROR and > GEOM_PART_GPT and uses SCHED_ULE. Filesystem options are FFS, > SOFTUPDATES, UFS_ACL and UFS_DIRHASH. The ADAPTIVE_GIANT and VFS_AIO > options are also part of the kernel. > First, I get to the following: if you have GEOM_PART_BSD in the kernel alone, attaching GELI at the boot time works as expected. If you add GEOM_PART_MBR (so both GEOM_PART_BSD and GEOM_PART_MBR are in), you face the problem i've described. Second, i've tried to get kern.geom.confxml sysctl as Pawel suggested, but with no lack. First, the whole XML dump doesn't feet the console buffer, so i can't later extract it from dmesg; i've tried to dump it to some file, but due to the fact everything is mounted -ro at the point /etc/rc.d/geli is executed, i placed "mount -u -rw /" in the beginning of it. While that made a trick and i got the dump (see below), the GELI partition attached successfully (while instantly failed with "Cannot access ad0s1f (error=1)" without remounting / -rw), so I guess remounting / read-write changed something and such dump will be of no use: ACD acd0 1 r0w0e0 acd0 8796093020160 2048 MD ELI JOURNAL VOL_FFS VFS ffs.ad0s1a 4 r1w1e1 MBR msdosfs/WD Passport 4 r0w0e0 r0w0e0 msdosfs/WD Passports4 10924544 512 3 10924544 21337 714049363456 1394627663 73 da0s1 3 r0w0e0 r0w0e0 da0s1s4 10924544 512 3 10924544 21337 714049363456 1394627663 73 da0 2 r0w0e0 r0w0e0 da0s1 120031478784 512 0 120031478784 234436482 32256 63 12 ad0 2 r1w1e3 r1w1e2 ad0s1 40007729664 512 0 40007729664 78140097 32256 63 165 MBREXT BDE PART da0 2 MBR 4 63 234441647 63 255 r0w0e0 r0w0e0 da0s1 120031478784 512 1 !12 32256 120031478784 12 ad0s1 3 BSD 8 0 78140096 63 16 r1w1e2 r0w0e0 ad0s1f 5368709120 512 6 freebsd-ufs 1048576000 5368709120 7 r0w0e0 ad0s1e 734003200 512 5 freebsd-ufs 314572800 734003200 7 r0w0e0 ad0s1d 314572800 512 4 freebsd-ufs 0 314572800 7 r0w0e0 ad0s1b 402653184 512 2 freebsd-swap 6417285120 402653184 1 r1w1e1 ad0s1a 33187791360 512 1 freebsd-ufs 6819938304 33187791360 7 DISK cd0 1 r0w0e0
resource leak
Hello List, I am running into a strange problem that points to a resource leak. The problem manifests itself after one of our remote systems has been up around 100 days. The symptom is that it appears no new processes can be spawned. If I try to ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. Examining log files, like cron, etc show that when this happens no more entries are written into the cron log. The unit is acting as a firewall, router and vpn appliance these functions continue to work. We have a C application that is periodically started out of a shell script that reports various information about the system, it stops reporting, while vpns, ospf routing, and ipfilter firewalling continue to work and write into their logfiles. My question is how do I monitor the various resources in the system that could prevent the spawning of a new process? This is on FreeBSD 6.1, ipsec-tools-6.6, quagga-0.99.3 Any ideas or directions would be greatly appreciated. Thanks, Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: resource leak
On Wed, Oct 01, 2008 at 07:41:56AM -0400, Stephen Clark wrote: > Hello List, > > I am running into a strange problem that points to a resource leak. The > problem manifests itself after one of our remote systems has been up > around 100 days. > The symptom is that it appears no new processes can be spawned. If I try to > ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. > Examining log files, like cron, etc show that when this happens no more > entries > are written into the cron log. The unit is acting as a firewall, router > and vpn appliance these functions continue to work. We have a C > application that is periodically started out of a shell script that > reports various information about the system, it stops reporting, while > vpns, ospf routing, and ipfilter firewalling continue to work and write > into their logfiles. > > My question is how do I monitor the various resources in the system that could > prevent the spawning of a new process? Periodically logging "ps -auxw" output to a file would be useful, as ideally you'd gradually see the list get longer and longer over time; it's possible you have many zombie processes as a result of a parent which is not reaping its children (calling waitpid(2) or its friends). Other things that might come in useful are "fstat" and "vmstat -s". It sounds like your C program relies heavily on system() or execl() and fork(), which is why it's affected -- while the other programs are likely kernel-level. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: resource leak
Jeremy Chadwick wrote: On Wed, Oct 01, 2008 at 07:41:56AM -0400, Stephen Clark wrote: Hello List, I am running into a strange problem that points to a resource leak. The problem manifests itself after one of our remote systems has been up around 100 days. The symptom is that it appears no new processes can be spawned. If I try to ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. Examining log files, like cron, etc show that when this happens no more entries are written into the cron log. The unit is acting as a firewall, router and vpn appliance these functions continue to work. We have a C application that is periodically started out of a shell script that reports various information about the system, it stops reporting, while vpns, ospf routing, and ipfilter firewalling continue to work and write into their logfiles. My question is how do I monitor the various resources in the system that could prevent the spawning of a new process? Periodically logging "ps -auxw" output to a file would be useful, as ideally you'd gradually see the list get longer and longer over time; it's possible you have many zombie processes as a result of a parent which is not reaping its children (calling waitpid(2) or its friends). Other things that might come in useful are "fstat" and "vmstat -s". It sounds like your C program relies heavily on system() or execl() and fork(), which is why it's affected -- while the other programs are likely kernel-level. Thanks Jeremy, I have added those commands to a periodic daily script. Another thing I have noticed is that quite often the problem seems to start at 2am in the morning, right when the periodic daily script runs. But I think it is coincidence and that we have reached the edge of the resource limit and all the jobs that get spawned by the periodic daily scripts pushes us over the limit. The other thing is that having logged into some of the systems that have been up in the 80 day range, I don't see a lot/any zombies. I just wonder if it is and fd leak, the fstat should point that out. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: resource leak
On Wed, Oct 01, 2008 at 08:30:26AM -0400, Stephen Clark wrote: > Jeremy Chadwick wrote: >> On Wed, Oct 01, 2008 at 07:41:56AM -0400, Stephen Clark wrote: >>> Hello List, >>> >>> I am running into a strange problem that points to a resource leak. >>> The problem manifests itself after one of our remote systems has been >>> up around 100 days. >>> The symptom is that it appears no new processes can be spawned. If I try to >>> ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. >>> Examining log files, like cron, etc show that when this happens no more >>> entries >>> are written into the cron log. The unit is acting as a firewall, >>> router and vpn appliance these functions continue to work. We have a >>> C application that is periodically started out of a shell script that >>> reports various information about the system, it stops reporting, >>> while vpns, ospf routing, and ipfilter firewalling continue to work >>> and write into their logfiles. >>> >>> My question is how do I monitor the various resources in the system that >>> could >>> prevent the spawning of a new process? >> >> Periodically logging "ps -auxw" output to a file would be useful, as >> ideally you'd gradually see the list get longer and longer over time; >> it's possible you have many zombie processes as a result of a parent >> which is not reaping its children (calling waitpid(2) or its friends). >> >> Other things that might come in useful are "fstat" and "vmstat -s". >> >> It sounds like your C program relies heavily on system() or execl() and >> fork(), which is why it's affected -- while the other programs are >> likely kernel-level. >> > Thanks Jeremy, > > I have added those commands to a periodic daily script. > > Another thing I have noticed is that quite often the problem seems to > start at 2am in the morning, right when the periodic daily script runs. > > But I think it is coincidence and that we have reached the edge of the > resource limit and all the jobs that get spawned by the periodic daily > scripts pushes us over the limit. > > The other thing is that having logged into some of the systems that have > been up in the 80 day range, I don't see a lot/any zombies. I just wonder > if it is and fd leak, the fstat should point that out. You might find the below thread beneficial -- an individual came to the lists stating that they were running out of fds as a result of some Java software running amok on their systems. http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/thread.html#45383 http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045383.html -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: resource leak
Jeremy Chadwick wrote: On Wed, Oct 01, 2008 at 08:30:26AM -0400, Stephen Clark wrote: Jeremy Chadwick wrote: On Wed, Oct 01, 2008 at 07:41:56AM -0400, Stephen Clark wrote: Hello List, I am running into a strange problem that points to a resource leak. The problem manifests itself after one of our remote systems has been up around 100 days. The symptom is that it appears no new processes can be spawned. If I try to ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. Examining log files, like cron, etc show that when this happens no more entries are written into the cron log. The unit is acting as a firewall, router and vpn appliance these functions continue to work. We have a C application that is periodically started out of a shell script that reports various information about the system, it stops reporting, while vpns, ospf routing, and ipfilter firewalling continue to work and write into their logfiles. My question is how do I monitor the various resources in the system that could prevent the spawning of a new process? Periodically logging "ps -auxw" output to a file would be useful, as ideally you'd gradually see the list get longer and longer over time; it's possible you have many zombie processes as a result of a parent which is not reaping its children (calling waitpid(2) or its friends). Other things that might come in useful are "fstat" and "vmstat -s". It sounds like your C program relies heavily on system() or execl() and fork(), which is why it's affected -- while the other programs are likely kernel-level. Thanks Jeremy, I have added those commands to a periodic daily script. Another thing I have noticed is that quite often the problem seems to start at 2am in the morning, right when the periodic daily script runs. But I think it is coincidence and that we have reached the edge of the resource limit and all the jobs that get spawned by the periodic daily scripts pushes us over the limit. The other thing is that having logged into some of the systems that have been up in the 80 day range, I don't see a lot/any zombies. I just wonder if it is and fd leak, the fstat should point that out. You might find the below thread beneficial -- an individual came to the lists stating that they were running out of fds as a result of some Java software running amok on their systems. http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/thread.html#45383 http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045383.html Thanks, but after reading the thread is there a single place in the kernel that reports the how many fds are currently in use? Does the "no more fds" message get logged in /var/log/messages or only in the kernel log buffer, since I haven't seen that message in the messages file, and since we force to have a remote user reboot the box the kernel buffer is gone. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: resource leak
> Thanks, but after reading the thread is there a single place in the kernel > that reports the how many fds are currently in use? Does the "no more fds" > message get logged in /var/log/messages or only in the kernel log buffer, > since I haven't seen that message in the messages file, and since we force > to have a remote user reboot the box the kernel buffer is gone. Just a guess, but perhaps: vmstat -m | grep -E 'filedesc|Type' Regards, Josh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs?
On 1 okt 2008, at 12:12, Jeremy Chadwick wrote: On Wed, Oct 01, 2008 at 10:42:32AM +0200, Ben Stuyts wrote: I had to disable mmap access in dovecot, or it would coredump periodically. (mmap_disable = yes in dovecot.conf) I found that to be a problem only on ZFS. I don't know if that's been fixed yet. Apart from that it works great. RELENG_7 had this problem fixed in rev 1.31.2.2, dated 2008/04/26. Here's the proper file in cvsweb so you can see it yourself: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Have you tried re-enabling mmap in dovecot on a system with a kernel build after those dates? No, thanks for pointing that out. I have missed that. My 7-stable kernel is from July 16, so I will re-enable it and report back. Ben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system hangup - I'm lost
Jeremy Chadwick wrote: > P.S. -- You're the 2nd person I've encountered in under a week who's > using 440BX/GX-based hardware in present day. I would not be > surprised if the board is simply going bad/failing due to age. :-) I still have quite a few of these in active use. They are good workhorses. Sure, they don't have the raw computing power of newer servers, but for most of our tasks they get the job done. I also have a couple stacks of these in 2U cases sitting unused for spare parts and testing. They make great FreeBSD boxes, and handle low-moderate loads pretty well. We use them for all kinds of things: firewalls, personal/testing servers, SVN repos, monitoring and traffic graphing, name servers, you name it. To bring this back on topic, they might be old, but I have yet to encounter one single motherboard from that series that has failed on me in any way. (*knock on wood*) However, mine are all Intel L440GX boards with dual PIII CPUs in the 600-800MHz range. We try to squeeze every last bit of value out of the hardware we have. :-) Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Request for testing - top 3.8b1 in the base system
On Sun, Sep 28, 2008 at 03:46:20PM +1000, Edwin Groothuis wrote: > I have made an update for the top(1) utility in the FreeBSD base > system to get it from the 3.5b12 version to the 3.8b1 version. > > I have tried them on the amd64 architecture on FreeBSD -current and > FreeBSD 7.0 and on the i386 architecture on FreeBSD 7.0. > > The big new features are a line upper part with kernel statistics > (context-switches, traps, interrupts, faults etc) and the FLG table > (if you window is big enough) > > Some features specific to FreeBSD (dual display (press m)), threaded > processes, and jails have been ported to 3.8b1. > > The biggest fix (AFAICT) is the TIME and CPU table for threaded > processes, which are now calculated properly. > > The new code can be found on > http://www.mavetju.org/~edwin/freebsd-top-3.8b1-A.tar.gz > Go to 3.8b1/usr.sbin/top and run "make" there to produce the binary, > then run it via "./top". > > Please report any issues with it (compile time, run time) and a way > to reproduce it (if possible). Thanks for your help! > > Edwin I found another bug. The new top doesn't handle newlines in full commandlines correctly -- if there is a command whose commandline contains a newline, which is quite common while some compilation is in progress, it is just printed out as it is, breaking the one-process-per-line layout. -- (-K JohnNy alias Partial Derivative ∂ [home] http://johnny64.fixinko.sk/ [icq] 338328204 [abandoned] [jabber] [EMAIL PROTECTED] [skype] JohnNy64-konik [abandoned] pgplAb0PH6tDK.pgp Description: PGP signature
Re: system hangup - I'm lost
Hi, today I'd a crash again - I was not able to get a crash dump (thought a "panic" at the end of the kdb would do it but didn't - should have called dumpon before ;)) - so here now the information I was able to retrieve: Ok, what I've got so far is wrinting stuff out to the console when the system hangs up: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096 ... and now the debugger stuff: KDB: enter: manual escape to debugger [thread pid 40 tid 100048 ] Stopped at kdb_enter+0x30: leave db> sh locks exclusive sleep mutex Giant r = 0 (0xc07c73c0) locked @ /usr/src/sys/kern/kern_intr.c:681 db> sh alllocks Process 40 (irq1: atkbd0) thread 0xc4503a80 (100048) exclusive sleep mutex Giant r = 0 (0xc07c73c0) locked @ /usr/src/sys/kern/kern_intr.c:681 db> so there are no locks except the one I caused but anyhow: db> bt 100048 Tracing pid 40 tid 100048 td 0xc4503a80 kdb_enter(c077aee6,4,1,0,1,...) at kdb_enter+0x30 scgetc(c0842b60,2,de391c88,c05ad0b7,c4609340,...) at scgetc+0x575 sckbdevent(c0823740,0,c0842b60,c07c73c0,8,...) at sckbdevent+0x210 atkbd_intr(c0823740,0,de391cd8,c05695b8,c0823740,...) at atkbd_intr+0xa1 atkbdintr(c0823740,0,c076448a,2a9,8,...) at atkbdintr+0x21 ithread_execute_handlers(c460cc90,c4449680,c076448a,30e,c4503a80,...) at ithread_execute_handlers+0x108 ithread_loop (c45f66c0,de391d38,c07642ea,30c,0,...) at ithread_loop+0x64 fork_exit (c05696b0,c45f66c0,de391d38) at fork_exit+0x78 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xde391d6c, ebp = 0 --- db> sh pcpu cpuid= 0 curthread= 0xc4503a80: pid 40 "irq1: atkbd0" curpcb = 0xde391d90 fpcurthread = none idlethread = 0xc444c780: pid 11 "idle: cpu0" APIC ID = 1 currentldt = 0x50 spin locks held: and now the output of ps (beware, it is long, no idea why there are so many cron - maybe the crond still schedules but they don't get processed?) show lockedvnods follows afterwards db> ps pid ppid pgrp uid state wmesg wchancmd 57919 57918 692 0 SV ufs 0xc47857c8 cron 57918 692 692 0 S ppwait 0xc6e63a78 cron 57917 57916 692 0 SV ufs 0xc47857c8 cron 57916 692 692 0 S ppwait 0xc6e63c90 cron 57915 57914 692 0 SV ufs 0xc47857c8 cron 57914 692 692 0 S ppwait 0xc6eb3000 cron 57913 57912 692 0 SV ufs 0xc47857c8 cron 57912 692 692 0 S ppwait 0xc70a9430 cron 57911 57908 692 0 SV ufs 0xc47857c8 cron 57910 57907 692 0 SV ufs 0xc47857c8 cron 57909 57906 692 0 SV ufs 0xc47857c8 cron 57908 692 692 0 S ppwait 0xc6eb3648 cron 57907 692 692 0 S ppwait 0xc6eb3860 cron 57906 692 692 0 S ppwait 0xc6eb3a78 cron 57905 686 68625 S ufs 0xc4953388 sendmail 57904 57902 692 0 SV ufs 0xc47857c8 cron 57903 57901 692 0 SV ufs 0xc47857c8 cron 57902 692 692 0 S ppwait 0xc49a4430 cron 57901 692 692 0 S ppwait 0xc49a4648 cron 57900 57899 692 0 SV ufs 0xc47857c8 cron 57899 692 692 0 S ppwait 0xc49a4860 cron 57898 57897 692 0 SV ufs 0xc47857c8 cron 57897 692 692 0 S ppwait 0xc49a4a78 cron 57896 57895 692 0 SV ufs 0xc47857c8 cron 57895 692 692 0 S ppwait 0xc49a4c90 cron 57894 57893 692 0 SV ufs 0xc47857c8 cron 57893 692 692 0 S ppwait 0xc6b7c648 cron 57892 57891 692 0 SV ufs 0xc47857c8 cron 57891 692 692 0 S ppwait 0xc66bc430 cron 57890 57889 692 0 SV ufs 0xc47857c8 cron 57889 692 692 0 S ppwait 0xc6b7c860 cron 57888 57887 692 0 SV ufs 0xc47857c8 cron 57887 692 692 0 S ppwait 0xc66bc860 cron 57886 686 68625 S ufs 0xc4953388 sendmail 57885 57884 692 0 SV ufs 0xc47857c8 cron 57884 692 692 0 S ppwait 0xc66bca78 cron 57883 57882 692 0 SV ufs 0xc47857c8 cron 57882 692 692 0 S ppwait 0xc66bcc90 cron 57881 57880 692 0 SV ufs 0xc47857c8 cron 57880 692 692 0 S ppwait 0xc6a65000 cron 57879 57878 692 0 SV ufs 0xc47857c8 cron 57878 692 692 0 S ppwait 0xc6a65218 cron 57877 57876 692 0 SV ufs 0xc47857c8 cron 57876 692 692 0 S ppwait 0xc6a65430 cron 57875 57874 692 0 SV ufs 0xc47857c8 cron 57874 692 692 0 S ppwait 0xc6a65648 cron 57873 57872 692 0 SV ufs 0xc47857c8 cron 57872 692 692 0 S ppwait
Re: system hangup - I'm lost
Jeremy Chadwick wrote: > On Wed, Oct 01, 2008 at 06:53:09AM +0200, Oliver Lehmann wrote: > > Because it is a Server Board it offers a lot of managing features and > > other nice things like serial console at bootup and system monitoring > > features... but all unsupported withn FreeBSDs software ;) > > Really? That's interesting, because Charles Sprickman told me that > there is no hardware monitoring information in the BIOS if you go in > there. Most motherboards provide that in the BIOS as a centralised > place above all else. You are right - I could have sworn that there was such an screen in the BIOS but all I can see is for setting up stuff like enabling eventlog and posting it through a modem connection and so on - server specific stuff - but no display screen for "health information"... So you where right ;) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Request for testing - top 3.8b1 in the base system
On Sun, Sep 28, 2008 at 09:54:01PM +1000, Edwin Groothuis wrote: > On Sun, Sep 28, 2008 at 11:35:06AM +0200, V??clav Haisman wrote: > > > to reproduce it (if possible). Thanks for your help! > > Is this 7.0+ only? I run 6.3 and I see the following when I start it: > > > > last pid: -1077944144; loa 0.52, 0.28, 0.26; > > up 11+15:31:33 > > 11:33:05 > > 0 processes: > > CPU: 0.1% user, 0.6% nice, -0.7% system, -0.6% interrupt, -0.4% idle > > Kernel: 1 intr > > Mem:235M Active, 458M Inact, 219M Wired, 42M Cache, 111M Buf, 39M Free > > Swap: 3000M Total, 181M Used, 2819M Free, 6% Inuse > > sysctlnametomib: No such file or directory > > > > And no processes. > > I didn't expect it not to work on 6.x, I will play around with it > tomorrow to see if it makes sense. Actually, I'm seeing the same behaviour on 7.0: last pid: 0943900; loa 0.98, 0.94, 0.57; up 7+23:09:54 17:13:22 0 processes: CPU: 19.7% user, 0.0% nice, 40.0% system, 0.0% interrupt, 40.3% idle Kernel: 1687 ctxsw, 14864 trap, 6 intr, 204 soft, 235 fork, 14526 flt, 11718 fr Mem:78M Active, 690M Inact, 184M Wired, 29M Cache, 111M Buf, 11M Free Swap: 2048M Total, 136K Used, 2048M Free sysctl: Invalid argument PID USERNAME THR PRI NICE SIZE RES STATE FLG C TIMECPU COMMAND [no processes] |17:15:30|[EMAIL PROTECTED]:/home/buki/temp/3.8b1/usr.bin/top>uname -srmi FreeBSD 7.0-RELEASE-p2 i386 GENERIC > Edwin > > -- > Edwin Groothuis |Personal website: http://www.mavetju.org > [EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/ Buki -- PGP public key: http://dev.null.cz/buki.asc /"\ \ / ASCII Ribbon Campaign X Against HTML & Outlook Mail / \ http://www.thebackrow.net pgpLn1P7VU257.pgp Description: PGP signature
Re: resource leak
On Wed, Oct 01, 2008 at 04:50:46AM -0700, Jeremy Chadwick wrote: > On Wed, Oct 01, 2008 at 07:41:56AM -0400, Stephen Clark wrote: > > Hello List, > > > > I am running into a strange problem that points to a resource leak. The > > problem manifests itself after one of our remote systems has been up > > around 100 days. > > The symptom is that it appears no new processes can be spawned. If I try to > > ssh to the unit, I can see the 3-way tcp handshake and then no more traffic. > > Examining log files, like cron, etc show that when this happens no more > > entries > > are written into the cron log. The unit is acting as a firewall, router > > and vpn appliance these functions continue to work. We have a C > > application that is periodically started out of a shell script that > > reports various information about the system, it stops reporting, while > > vpns, ospf routing, and ipfilter firewalling continue to work and write > > into their logfiles. > > > > My question is how do I monitor the various resources in the system that > > could > > prevent the spawning of a new process? > > Periodically logging "ps -auxw" output to a file would be useful, as > ideally you'd gradually see the list get longer and longer over time; > it's possible you have many zombie processes as a result of a parent > which is not reaping its children (calling waitpid(2) or its friends). "ps alxw" may be of interest in addition to "ps auxw" as it displays what the processes are waiting on. It could conceivably be a problem of some kind at the filesystem level. I've seen situations before where a problem escalates to the point where "ls /" hangs, and at that point you're stuck with an unresponsive box. Regards, Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: resource leak
On Wed, 1 Oct 2008, Gary Palmer wrote: Periodically logging "ps -auxw" output to a file would be useful, as ideally you'd gradually see the list get longer and longer over time; it's possible you have many zombie processes as a result of a parent which is not reaping its children (calling waitpid(2) or its friends). "ps alxw" may be of interest in addition to "ps auxw" as it displays what the processes are waiting on. It could conceivably be a problem of some kind at the filesystem level. I've seen situations before where a problem escalates to the point where "ls /" hangs, and at that point you're stuck with an unresponsive box. If you want an even greater level of detail than ps -l, you can use procstat -k to generate kernel stack traces for all user/kernel threads. Wait channels are very useful, but they only tell you what the code that invoked the wait thinks it is for, not how that code was reached. A classic example is waiting on an exhausted UMA zone -- you get a uma wait channel, but no indication of what subsystem performed the memory allocation... This required FreeBSD 7.1 and higher, however. (Obviously, the same can be done easily using DDB, but that's hard on a box without a serial console, and requires interrupting the flow of the operating system, compiling with DDB, etc). 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: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1?
At 12:40 PM 10/1/2008, Fernan Aguero wrote: Thanks for the tip. Unfortunately, the PowerEdge SC1435 BIOS does not allow much options here ... I can set the embedded SATA to 'ATA mode' (corruption hell, tested with 7.1 BETA) or just turn it 'OFF' in which case the FreeBSD installer sees no disk present. This is on BIOS v1.1.2. A newer v1.4.4 is available and I'm now researching how to update the BIOS to see if that helps. Wow, thats too bad. Hopefully a newer BIOS will let you put the controller in SATA mode. > > Start with > ftp://ftp.freebsd.org//pub/FreeBSD/releases/i386/ISO-IMAGES/7.1/7.1-BETA-i386-disc1.iso I've used the amd64 version ... don't know if that makes any difference, though. It wont make a difference in terms of the SATA/PATA issue. However, once you get that fixes, you should be able to install the AMD64 image just fine. I would check the USB settings as well to make sure the "hand off mode" is disabled. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1?
> At 05:34 PM 9/30/2008, Fernan Aguero wrote: > >> I've been following the "HT1000 chipset errata saga" thread, and the >> commits by sos@ to CVS (around Jan 2008), but have not seen other more >> recent posts about this issue ... is it because it's already fixed and >> working fine for everyone? >> >> http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084272.html > > Yes, we ran into this yesterday on a fresh install using the 7.1 beta CD as > it was set to PATA mode by accident. Also, on some earlier BIOS revs, we > had to turn off "enable USB legacy mode" as well as "EHCI handoff". By > default we set those to disabled as it seems to sometimes create a high > interrupt load on the USB bus if its enabled. Thanks for the tip. Unfortunately, the PowerEdge SC1435 BIOS does not allow much options here ... I can set the embedded SATA to 'ATA mode' (corruption hell, tested with 7.1 BETA) or just turn it 'OFF' in which case the FreeBSD installer sees no disk present. This is on BIOS v1.1.2. A newer v1.4.4 is available and I'm now researching how to update the BIOS to see if that helps. > If you forget to set the mode to SATA, the dmesg will look like > > Sep 30 13:37:08 dev2 kernel: ad4: DMA limited to UDMA33, device found > non-ATA66 cable > Sep 30 13:37:08 dev2 kernel: ad4: 152627MB at > ata2-master UDMA33 > > and you will indeed get corruption > > Turning onto normal SATA mode in the BIOS, you should see > > Sep 30 16:14:15 dev2 kernel: ad4: 152627MB at > ata2-master SATA150 > > ... And everything works great. > > Start with > ftp://ftp.freebsd.org//pub/FreeBSD/releases/i386/ISO-IMAGES/7.1/7.1-BETA-i386-disc1.iso I've used the amd64 version ... don't know if that makes any difference, though. Fernan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1?
On Tuesday 30 September 2008 05:34:04 pm Fernan Aguero wrote: > Hi, > > I have a server (Dell PowerEdge SC1435, ServerWorks HT1000) on which > I'd like to try installing FreeBSD. I've already failed to make 7.0 > work on this box and was wondering if you have information about the > behavior of the upcoming 7.1 on this hardware. > > I've been following the "HT1000 chipset errata saga" thread, and the > commits by sos@ to CVS (around Jan 2008), but have not seen other more > recent posts about this issue ... is it because it's already fixed and > working fine for everyone? > > http://lists.freebsd.org/pipermail/freebsd-current/2007-December/081429.html > http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084272.html > > Thanks in advance for any update on this, Try http://www.freebsd.org/~jhb/patches/ata_ht1000.patch -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: proposed change to support policy for FreeBSD Releases
On Sep 25, 2008, at 9:32 AM, Lowell Gilbert wrote: I'm not clear on how this helps. We don't know if there will be a need to produce a 6.5 release, so there's no way to judge whether 6.4 should be designated "final" or not. The only logical answer is to do so, which leaves a substantial chance that there will end up being more than one "final" release on the 6.x line. That's not a particularly desirable situation. In fact, it's worse, because if 6.5 happens, it will probably be because there were problems with 6.4 serious enough that we'd rather people move to 6.5 anyway (at least for critical systems). You are exactly right. I am proposing that we stop trying to guess whether or not it is a final release. A release will be supported until the next release + N months (N is currently being debated I guess) or 24 months if there is no followup release. This effectively solves both of the problems you've very accurately named above. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD?
On Wed, Oct 1, 2008 at 12:13 AM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > On Wed, Oct 01, 2008 at 02:29:12PM +0800, lhmwzy wrote: >> That's it. >> Since we don't have the skill,what we can do is wait. >> >> Waiting is such a bad thing... > > If this functionality is really something you want/need, you should > consider finding a kernel programmer who would be willing to port it, > for financial exchange (in English: you will be paying them $XX/hour > to port it to FreeBSD). > > This has happened in the past for some key features. Like I said, it > all depends on how much it matters to you. Another big consideration, is is 'HAMMER' sufficiently 'finished' to be worth trying this yet? Anybody attempting a port is going to have enough to worry about with the VFS/VM semantics differences, locking differences etc between the two different kernels. Having to worry about following a moving target as well would add unneeded difficulty. To be honest, I've not looked at the state of HAMMER. Is it still under active development or is it in a state where you could easily work from a snapshot of the source for months and not have to worry about getting too far out of sync, or be in need of functionality or bug fixes? That was one of the things that made the ZFS port possible. It was possible to take a known-good, "complete", working snapshot as a base and focus on getting it working in the FreeBSD kernel. It wasn't necessary to wonder (that much) if the bug you're currently fighting is a porting bug or an underlying ZFS bug. Of course, there's a lot more to it than that, but having a solid starting point is very important. -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: resource leak
Robert Watson wrote: On Wed, 1 Oct 2008, Gary Palmer wrote: Periodically logging "ps -auxw" output to a file would be useful, as ideally you'd gradually see the list get longer and longer over time; it's possible you have many zombie processes as a result of a parent which is not reaping its children (calling waitpid(2) or its friends). "ps alxw" may be of interest in addition to "ps auxw" as it displays what the processes are waiting on. It could conceivably be a problem of some kind at the filesystem level. I've seen situations before where a problem escalates to the point where "ls /" hangs, and at that point you're stuck with an unresponsive box. If you want an even greater level of detail than ps -l, you can use procstat -k to generate kernel stack traces for all user/kernel threads. Wait channels are very useful, but they only tell you what the code that invoked the wait thinks it is for, not how that code was reached. A classic example is waiting on an exhausted UMA zone -- you get a uma wait channel, but no indication of what subsystem performed the memory allocation... This required FreeBSD 7.1 and higher, however. (Obviously, the same can be done easily using DDB, but that's hard on a box without a serial console, and requires interrupting the flow of the operating system, compiling with DDB, etc). Robert N M Watson Computer Laboratory University of Cambridge A big part of problem is this seems to take about 100 days of uptime to occur. We have some inhouse test boxes but have never seen the problem, probably because non of them have been up more than about 45 days. The units in the field, of which there is about 300, are headless and none are physically close. When the boxes are rebooted there are no error messages in any of the log files, only the absence of information that would normally be logged by new processes that would be spawned. We are getting ready to install a patch that will try to gather more information. I thought about writing an app the would try to fork a child periodically and record in a log file if there was an error. But EAGAIN is nonspecific as to the real reason the fork failed. I was looking for some way to periodically log the resources that would cause the fork failure. procstat -k looks like it would have been a good candidate but unfortunately we are running 6.1. Thanks for the response. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Request for testing - top 3.8b1 in the base system
2008/9/28 Edwin Groothuis <[EMAIL PROTECTED]>: > I have made an update for the top(1) utility in the FreeBSD base > system to get it from the 3.5b12 version to the 3.8b1 version. > > I have tried them on the amd64 architecture on FreeBSD -current and > FreeBSD 7.0 and on the i386 architecture on FreeBSD 7.0. > > The big new features are a line upper part with kernel statistics > (context-switches, traps, interrupts, faults etc) and the FLG table > (if you window is big enough) > > Some features specific to FreeBSD (dual display (press m)), threaded > processes, and jails have been ported to 3.8b1. > > The biggest fix (AFAICT) is the TIME and CPU table for threaded > processes, which are now calculated properly. > > The new code can be found on >http://www.mavetju.org/~edwin/freebsd-top-3.8b1-A.tar.gz > Go to 3.8b1/usr.sbin/top and run "make" there to produce the binary, > then run it via "./top". > > Please report any issues with it (compile time, run time) and a way > to reproduce it (if possible). Thanks for your help! > > Edwin > > -- > Edwin Groothuis > [EMAIL PROTECTED] > http://www.mavetju.org Hello. I have one issue, maybe not so important though. I've compiled top 3.8b1 on my 7.1-PRERELEASE and it looks like "t" hotkey (toggle displaying "top" process) don't work at all. (Sorry if somebody has pointed out that one already. I haven't read all thread so thoroughly. ) -- Best regards, Jeff. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD?
lhmwzy wrote: Yes,this is a way. I would do as you said if I need to do so. 2008/10/1 Jeremy Chadwick <[EMAIL PROTECTED]>: On Wed, Oct 01, 2008 at 02:29:12PM +0800, lhmwzy wrote: That's it. Since we don't have the skill,what we can do is wait. Waiting is such a bad thing... If this functionality is really something you want/need, you should consider finding a kernel programmer who would be willing to port it, for financial exchange (in English: you will be paying them $XX/hour to port it to FreeBSD). This has happened in the past for some key features. Like I said, it all depends on how much it matters to you. HAMMER seems good, but at this time, it is more important to finish ZFS integration in to FreeBSD. Fixing all known issues, more testing, wider audience and make it production ready. Not because ZFS is better, may be is worse - it does not metter. I think it is important to have one successful port finished than two filesystems in non-production state. FreeBSD is currently lag behind other operating systems in supported filesystems. UFS2 is insufficient for todays storage requirements. Once we have ZFS production ready, we can talk about another filesystems. I can't do any programming to port whatever filesystem, nor write patches. All I can do is testing and reporting - and I am doing it. I have some stresstests of ZFS. Currently I have one ZFS mount with 56 snapshots taken during heavy tasks like coping or removing large number of small files (mainly cp -R /usr/ports /tank/test/$i in loops plus taring / untaring tasks), some large files creation with dd on background etc. All is running fine on FreeBSD 7.0 amd64 with 4GB RAM and some kernel tunning. vm.kmem_size="1024M" vm.kmem_size_max="1024M" kern.maxvnodes="40" vfs.zfs.prefetch_disable="1" vfs.zfs.arc_min="16M" vfs.zfs.arc_max="64M" There are 53202511 inodes on ZFS partition. Zpool was created over two slices of two disks (mirror): capacity operationsbandwidth pool used avail read write read write -- - - - - - - tank 434G 10.5G 75 1.24K 618K 5.76M mirror 434G 10.5G 75 1.24K 618K 5.76M ad4s2 - - 13328 918K 5.76M ad6s2 - - 16326 1.09M 5.76M -- - - - - - - I have no crash of ZFS, but as I read in mailing lists, there are still some problems, so let it be fixed and settle down before porting another good filesystem. Just my €0.02 Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Anti-MDR1 antibody
Dear All: Has anybody tried the anti-MDR1 from Millipore, by any chance? http://www.millipore.com/catalogue/item/mab4161# I am looking for a reliable mouse anti-human antibody, targeting the extracellular epitope of P-glycoprotein. Any suggestion is extremely appreciated! Thank you in advance. Davide ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anti-MDR1 antibody
I'm really not into that anti-human movement and I think it's a pity that poor mouse has to suffer. I suggest you take three Valiums instead and call me in the morning... Davide Marini wrote: Dear All: Has anybody tried the anti-MDR1 from Millipore, by any chance? I am looking for a reliable mouse anti-human antibody, targeting the extracellular epitope of P-glycoprotein. Any suggestion is extremely appreciated! Thank you in advance. Davide ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Anti-MDR1: Apologies
Dear All: My apologies for sending this message to the wrong mailing list. I am indeed on the freebsd-stable list, as I use this OS, but the message was mistakenly sent to this forum. Sorry for disturbing your work. Let me take this opportunity to thank the developers for such a superb operating system. Best Regards, Davide -- Davide M. Marini, Ph.D. Research Fellow, Department of Cardiology Children's Hospital Boston | Harvard Medical School Enders 1306, 320 Longwood Avenue, Boston, MA 02115 Research Associate, Department of Materials Science Massachusetts Institute of Technology | Biomolecular Materials Group 77 Massachusetts Avenue, Room 16-244 Cambridge, MA 02139 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
