Practically missing cpio(1L) man page since Oct 22 2006
A few minutes ago I was extracting information about mass copying with pax(1) cpio(1L) on 6.2-PRERELEASE. I got information from pax(1) man page, but i found cpio(1L) man page to be rather lacking. (Yeah, I saw the pointer to info.) Is it possible to have a genuine cpio(1L) 2.6 man page available? I got curious when I tried my luck with FreeBSD man page index ... http://www.freebsd.org/cgi/man.cgi ... and got a genuine man page, (had FreeBSD 6.1-RELEASE selected per default). I found nothing in PR database about neutering the cpio man page; so went to cvsweb ... http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/cpio/doc/cpio.1 ... which was missing the substantial version in there. I did a second trip to man.cgi selected FreeBSD 6.1-STABLE, which showed the rather empty man page. Just to confirm that I turned to cvs- mailing list stored locally, and here I found ... delphij 2006-10-23 03:33:27 UTC ... 1.3.38.2 +0 -328src/contrib/cpio/cpio.1 (dead) ... 1.1.1.1.40.1 +0 -558src/contrib/cpio/cpio.texi (dead) ... 1.2.2.1 +41 -0 src/contrib/cpio/doc/cpio.1 (new) 1.2.2.1 +563 -0src/contrib/cpio/doc/cpio.texi (new) ... no wonder (NOW!) that cvsweb did not 330-some line version of man page as the path had been changed, and I did not happen to misplace my mind during world build install, along with some combination of entry in /etc/make.conf (yup, checked there too;). GNU, drown thyself with info! - Parv -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cached file read performance with 6.2-PRERELEASE
JoaoBR wrote:
I am not convinced that this kind of test is of any value for comparing
systems at all because there are too much factors involved - unless the
competitors are installed on identical hardware. On the other side I think it
is usefull to compare tweaked settings on a particular machine. For example
you may change fsize/bsize of the filesystem or any other and can compare
this results then.
Exactly, that's why I did the comparison - I think you missed the part
where I mentioned the 2 systems were *identical* with respect to cpus,
memory, mobo - in fact even the power supplies are identical too! the
only differences are that the Gentoo system has a different RAID
controller from the FreeBSD one (a cheaper one in fact), and the FreeBSD
system has larger capacity disks (slightly newer variants, same brand!)
given this comparison is about *cached* read rates, the RAID controllers
and disks are not significant I think.
Specifically:
Gentoo :
- Supermicro P3TDER
- 2xSL5QL 1.26 GHz PIII
- 2xKingston PC133 RCC Registered 1GB DIMMS
- Promise TX4000 4x Maxtor plus 8 ATA-133 7200 40G
FreeBSD
- Supermicro P3TDER
- 2xSL5QL 1.26 GHz PIII
- 2xKingston PC133 RCC Registered 1GB DIMM
- 3Ware 7506 4x Maxtor Plus 9 ATA-133 7200 80G
In fact, to indulge your skepticism ('cause I think this is a real issue
worth sorting out), I booted the FreeBSD system with a Gentoo livecd
and ran the same tests there... and guess what - identical results to
the installed Gentoo system...so... errm - *my* experimental method is
sound...so how about we just get together and see how to make FreeBSD
kick Gentoo eh?
Cheers
Mark
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possibility for FreeBSD 4.11 Extended Support
John Smith wrote: Support for FreeBSD 4.11 is going to end sometime in late January. Originally, FreeBSD 6.2 was supposed to be released back in October. This would have given everyone about 3 months to stress test everything and migrate all their boxes from 4.11 direct to 6.2. You've had three months to stress test 6.2-BETA1, 6.2-BETA2, 6.2-BETA3, and 6.2-RC1. We release these for a reason, you know. Now it is near the end of December, and FreeBSD 6.2 RC2 has yet to be seen anywhere. Chances are that FreeBSD 6.2 Release will come out earliest mid-January. This does not give much time for people to migrate to the newest FreeBSD release. I think it would be fair if support is extended for a few more months especially since 6.2 is so late in coming. Your opinion has been noted. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cached file read performance with 6.2-PRERELEASE
Pieter de Goeje wrote: On Wednesday 20 December 2006 11:38, Mark Kirkwood wrote: In fact if you note that the PIII HW *can* actually do 700MB/s, it suggests that your HW is capable of considerably more than 900MB/s - given that opteron's have excellent cpu to memory bandwidth, and the speed of your memory! Indeed! Copying /dev/zero to /dev/null yields more than 5GB/sec on a simple 2Ghz Athlon64. It imagine there are quite a few extra things done when copying a file from cache, because I can only manage to get one fifth (~1GB/sec) of the theoretical speed. (this is with a file that fills more than half of all memory) Fascinating, never thought of trying that! On my 2 (essentially) identical PIII systems, doing copy /dev/zero to /dev/null yields 4.1 GB/s (Gentoo) and 2.0GB/s (FreeBSD) - so yeah, clearly both do something special in that case... (growl... we - i.e FreeBSD - seem to be slower again...tho at that sort of rate, who cares!) Cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
DDB and -stable: show threads loops output with no end?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is it supposed to go on into infiniti? 102115 (0xff015f88a260) sched_switch() at sched_switch+0x11f 100979 (0xff0147d79000) sched_switch() at sched_switch+0x11f 100757 (0xff002f189260) sched_switch() at sched_switch+0x11f 100295 (0xff0136e46be0) sched_switch() at sched_switch+0x11f 101894 (0xff01496a9720) sched_switch() at sched_switch+0x11f 101309 (0xff01686c9be0) sched_switch() at sched_switch+0x11f 101904 (0xff0049d86980) sched_switch() at sched_switch+0x11f 102212 (0xff0038f90260) sched_switch() at sched_switch+0x11f 101995 (0xff0032daa720) sched_switch() at sched_switch+0x11f 100138 (0xff0140ad9260) sched_switch() at sched_switch+0x11f 102083 (0xff00c1306260) sched_switch() at sched_switch+0x11f 100132 (0xff0140c9a260) sched_switch() at sched_switch+0x11f 101481 (0xff0183356be0) sched_switch() at sched_switch+0x11f 101759 (0xff017a0b8260) sched_switch() at sched_switch+0x11f 100356 (0xff012e9db720) sched_switch() at sched_switch+0x11f 101201 (0xff007ba18be0) sched_switch() at sched_switch+0x11f 101637 (0xff004c7dc720) sched_switch() at sched_switch+0x11f I couldn't figure out how to break out of it, and the above is nowhere near all the output ... it just seemed to keep looping through the same values on the left column ... from a script session: io# grep 0xff004c7dc720 /vm/neptune 101637 (0xff004c7dc720) sched_switch() at sched_switch+0x11f 101637 (0xff004c7dc720) sched_switch() at sched_switch+0x11f io# grep 0xff007ba18be0 /vm/neptune 101201 (0xff007ba18be0) sched_switch() at sched_switch+0x11f 101201 (0xff007ba18be0) sched_switch() at sched_switch+0x11f I couldn't break out after I typed 'show threads' ... The server had hung, I broke into DDB ... I'll be surprised if the above means anything to anyone, but, unfortunately, by that point all I coudl do was power cycle :( - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFigoO4QvfyHIvDvMRAhEMAJ9X5LOzxWRY5KV4kb0JMQUsMj4cwACgj7H0 aT0kny4odfshY+22a/t8aNY= =Rlm2 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: negative runtime etc., the story continues
On Tue, Dec 19, 2006 at 11:49:43PM +0100, V??clav Haisman wrote: Hi, I wrote about how FreeBSD 6.1 RC1, with latest RELENG_6 kernel, prints loads of calcru: runtime went backwards... and calcru: negative runtime... messages when the FreeBSD runs as virtual server under Microsoft Virtual Server 2006 R2. When I wrote this I was compiling and installing lots of packages, setting up the OS. Now that it is idle I have noticed one quite bad thing. Any process that sleeps on timer or sleep() call will wake up much later than it should. For example, when I start top there should be two seconds delay between updates of the screen. It takes up to 20 seconds! But when there is compilation running or something else CPU intensive, the timer seems to work fine. I even tried setting different kern.timecounter.hardware (TSC, ACPI-safe, i8254) and kern.hz (to lower than the default 1000) but that did not help a bit. Is there anything I can do to get rid of the calcru messages apart from reinstalling to real hardware? Last time I was trying to run FreeBSD as a guest OS in MS VS, I found that TSC would work the best, but only if I made sure that the TSC frequency was correct. For some weird reason, the frequency initially detected by the kernel was totally bogus and changing from one boot to another, so I just estimated it from cpu-z output in the host OS, and it fairly worked. I still couldn't get rid of the annoying warnings, especially when under load. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Practically missing cpio(1L) man page since Oct 22 2006
The point of MFC'ing cpio(1) changes is that it has fixed some old bugs that can potentially damage user data. Personally I'd rather replace it with the BSD pax(1) found in the base system, if we had a proper GNU cpio(1) test suite to make sure that we did not break something. It might be interesting to do check the recent NetBSD/OpenBSD changes and apply the appropriate ones. Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: Cached file read performance with 6.2-PRERELEASE
On Wednesday 20 December 2006 07:38, Mark Kirkwood wrote: I was however trying to point out that as your machine is different from mine (opteron and ddr*400* as opposed to PIII and pc133), the fact that it is faster is not telling us anything about whether releng_6 performance on cached file reads could be improved! In fact if you note that the PIII HW *can* actually do 700MB/s, it suggests that your HW is capable of considerably more than 900MB/s - given that opteron's have excellent cpu to memory bandwidth, and the speed of your memory! I am not convinced that this kind of test is of any value for comparing systems at all because there are too much factors involved - unless the competitors are installed on identical hardware. On the other side I think it is usefull to compare tweaked settings on a particular machine. For example you may change fsize/bsize of the filesystem or any other and can compare this results then. -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acer Aspire 5102 WLMi with Turion 64 X2 dual-core TL-50 1.6 GHz on FreeBSD 6.2 ACPI problems
On 12/20/06, Abdullah Al-Marrie [EMAIL PROTECTED] wrote: Hello guys, I have problem with my new laptop Acer Aspire 5102 WLMi which has AMD Turion™ 64 X2 dual-core TL-50 1.6 GHz with 1.5 GB of ram. I'm running i386 6.2-RC1 upgraded to 6.2-PRELEASE via RELENG6 tag since I don't have more than 4 GB of ram. 1. The FreeBSD can't detect the builtin wlan chip which is Broadcom BCM 4318 Rev 2. You need to use the Windows NDIS driver to use the Broadcom Wireless adapter. You just need to download the driver from Acer's web site, and then use ndisgen to build the kernel module. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possibility for FreeBSD 4.11 Extended Support
Community support will continue on the freebsd-eol mailing list, fwiw. However, note that we have dropped the requirement for ports maintainers to make their ports work on 4.X, although many continue to do so. It is simply too much for the ports team to support 3 major branches and one development tree (as per previous discussions). mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re:resolved: if_sf problem, no i/o traffic
On Wednesday 20 December 2006 12:19, JoaoBR wrote: On Wednesday 20 December 2006 10:42, JoaoBR wrote: seems to be something wrong with the sf driver I have starfire 64bit cards (adaptec 1 and two port) on amd64 releng_6 the card is probed, recognize correctly the connection but no traffic i/o, arp either any idea? for whom might be interested: I tried with less memory and the cards started to work what brought me to disable the memory whole remapping in the BIOS what then resolved the issue. The cards are working fine now -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cached file read performance with 6.2-PRERELEASE
Mark Kirkwood wrote: Exactly, that's why I did the comparison - I think you missed the part where I mentioned the 2 systems were *identical* with respect to cpus, memory, mobo - in fact even the power supplies are identical too! So I assume your benchmark measured the performance of the zero and null devices under FreeBSD and Linux. This is a quote from the cstream docs: These special devices speed varies greatly among operating systems, redirecting from it isn't appropriate benchmarking and a waste of resources anyway. I suggest you try cstream (ports/misc/cstream) instead of dd. It supports built-in zero creation and data sink, so you don't have to use the zero and null devices at all, eliminating their overhead. It would be interesting how that will change your benchmark numbers. 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. Life is short (You need Python) -- Bruce Eckel, ANSI C++ Comitee member, author of Thinking in C++ and Thinking in Java ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acer Aspire 5102 WLMi with Turion 64 X2 dual-core TL-50 1.6 GHz on FreeBSD 6.2 ACPI problems
Abdullah Al-Marrie wrote: [snip]... 1. The FreeBSD can't detect the builtin wlan chip which is Broadcom BCM 4318 Rev 2. [snip]... Have you tried using ndisgen(8) and the Windows bcmwl5.[sys,inf] files to create the module bcmwl5_sys.ko? I have a Gateway with the Broadcom 4318, and that routine worked for me. You may have to try different .sys and .inf files (i.e. Broadcom, Dell, etc) to get it to work. If it does, then when you kldload(8) the module, you'll see something like this in dmesg(8); ndis0: Dell TrueMobile 1300 WLAN Mini-PCI Card mem 0xb8004000-0xb8005fff irq 17 at device 4.0 on pci6 ndis0: NDIS API version: 5.1 ndis0: Ethernet address: 00:14:a5:80:f5:c9 Good luck, Patrick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: (Seemingly) Spontaneous rebooting
It is really a bug. But in my case it seems to be the hardware problem after serval days fight with this crash. The old server even crashes before booting to the login prompt. :( I have to changes to another server now. 2006/12/20, Martin Blapp [EMAIL PROTECTED]: Hi, Maybe you are experiencing similar crashes as I did in the tty code. I had 8 ! crashes in 4 days on a busy server ... Fix: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/tty.c.diff?r1=1.266r2=1.267 I hope to commit this soon to RELENG_6_2 Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- -- Ma Jie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Block IP
Hi all, I'm using IPFW as my firewall. What's the easiest way to add an IP such as 80.192.49.213 to block it? Also how do I block out IPs after a certain number of invalid login attempts to prevent brute forcing? -- Regards, Suhail. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cached file read performance with 6.2-PRERELEASE
In response to Mark Kirkwood [EMAIL PROTECTED]:
JoaoBR wrote:
I am not convinced that this kind of test is of any value for comparing
systems at all because there are too much factors involved - unless the
competitors are installed on identical hardware. On the other side I think
it
is usefull to compare tweaked settings on a particular machine. For example
you may change fsize/bsize of the filesystem or any other and can compare
this results then.
Exactly, that's why I did the comparison - I think you missed the part
where I mentioned the 2 systems were *identical* with respect to cpus,
memory, mobo - in fact even the power supplies are identical too! the
only differences are that the Gentoo system has a different RAID
controller from the FreeBSD one (a cheaper one in fact), and the FreeBSD
system has larger capacity disks (slightly newer variants, same brand!)
given this comparison is about *cached* read rates, the RAID controllers
and disks are not significant I think.
Specifically:
Gentoo :
- Supermicro P3TDER
- 2xSL5QL 1.26 GHz PIII
- 2xKingston PC133 RCC Registered 1GB DIMMS
- Promise TX4000 4x Maxtor plus 8 ATA-133 7200 40G
FreeBSD
- Supermicro P3TDER
- 2xSL5QL 1.26 GHz PIII
- 2xKingston PC133 RCC Registered 1GB DIMM
- 3Ware 7506 4x Maxtor Plus 9 ATA-133 7200 80G
In fact, to indulge your skepticism ('cause I think this is a real issue
worth sorting out), I booted the FreeBSD system with a Gentoo livecd
and ran the same tests there... and guess what - identical results to
the installed Gentoo system...so... errm - *my* experimental method is
sound...so how about we just get together and see how to make FreeBSD
kick Gentoo eh?
I looks like your testing methodology is sound, and that you've
uncovered an issue worth pursuing.
I recommend starting this thread up on [EMAIL PROTECTED] The folks
on that list are more likely to jump all over this kind of thing.
You might also find helpful people on the current@ and hackers@ lists.
My gut tells me that any changes that can improve this will be large
enough that they'll have to go through CURRENT first, then get MFCed
back in to 6.
Keep in mind also that the holidays tend to slow things down, it might
be early January before you get a lot of people looking at this issue
seriously.
--
Bill Moran
Collaborative Fusion Inc.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Block IP
In response to Suhail Choudhury [EMAIL PROTECTED]: Hi all, I'm using IPFW as my firewall. What's the easiest way to add an IP such as 80.192.49.213 to block it? ipfw add deny all from 80.192.49.213 to me Although you need to take into consideration your existing IPFW rules, as this will not work if a previous rule allows the connection. Also how do I block out IPs after a certain number of invalid login attempts to prevent brute forcing? There are a number of ports that provide this functionality. I believe the most popular is called denyhosts. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possibility for FreeBSD 4.11 Extended Support
Colin Percival wrote: John Smith wrote: Support for FreeBSD 4.11 is going to end sometime in late January. Originally, FreeBSD 6.2 was supposed to be released back in October. This would have given everyone about 3 months to stress test everything and migrate all their boxes from 4.11 direct to 6.2. You've had three months to stress test 6.2-BETA1, 6.2-BETA2, 6.2-BETA3, and 6.2-RC1. We release these for a reason, you know. Now it is near the end of December, and FreeBSD 6.2 RC2 has yet to be seen anywhere. Chances are that FreeBSD 6.2 Release will come out earliest mid-January. This does not give much time for people to migrate to the newest FreeBSD release. I think it would be fair if support is extended for a few more months especially since 6.2 is so late in coming. Your opinion has been noted. Colin Percival I have to second the OP's opinion. :-) I think it is important to be able to stress test the *final* release before installing on production machines. There is little use in stress testing BETAs and then install a broken RELEASE. This happened with 6.1-RELEASE where the nfs server was suddenly unusable on amd64. Regards, ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possibility for FreeBSD 4.11 Extended Support
In response to Heinrich Rebehn [EMAIL PROTECTED]: Colin Percival wrote: John Smith wrote: Support for FreeBSD 4.11 is going to end sometime in late January. Originally, FreeBSD 6.2 was supposed to be released back in October. This would have given everyone about 3 months to stress test everything and migrate all their boxes from 4.11 direct to 6.2. You've had three months to stress test 6.2-BETA1, 6.2-BETA2, 6.2-BETA3, and 6.2-RC1. We release these for a reason, you know. Now it is near the end of December, and FreeBSD 6.2 RC2 has yet to be seen anywhere. Chances are that FreeBSD 6.2 Release will come out earliest mid-January. This does not give much time for people to migrate to the newest FreeBSD release. I think it would be fair if support is extended for a few more months especially since 6.2 is so late in coming. Your opinion has been noted. Colin Percival I have to second the OP's opinion. :-) I think it is important to be able to stress test the *final* release before installing on production machines. There is little use in stress testing BETAs and then install a broken RELEASE. This happened with 6.1-RELEASE where the nfs server was suddenly unusable on amd64. There is something about these please continue to support 4.x discussions that confuses me. The general argument has been that 4.11 support should continue because 6.2 is not at release status yet. Are the people making this argument unaware that 6.1 and 5.5 have been at release status for quite some time, and thus have been providing ample opportunity to upgrade for some time now? Or has this topic simply degraded to Troll bait? -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cached file read performance with 6.2-PRERELEASE
A few more tests with a slightly improved version of the program (attached): We (i.e FreeBSD) do noticeably better with bigger block sizes. Cheers Mark Gentoo - 2.6.18-gentoo-r3: --- $ ./readtest /data0/dump/file 8192 0 random reads: 10 of: 8192 bytes elapsed: 1.2698s io rate: 645155193 bytes/s $ ./readtest /data0/dump/file 8192 1 sequential reads: 10 of: 8192 bytes elapsed: 1.1329s io rate: 723129371 bytes/s $ ./readtest /data0/dump/file 32768 0 random reads: 25000 of: 32768 bytes elapsed: 1.1583s io rate: 707244595 bytes/s $ ./readtest /data0/dump/file 32768 1 sequential reads: 25000 of: 32768 bytes elapsed: 1.1178s io rate: 732838631 bytes/s $ ./readtest /data0/dump/file 65536 0 random reads: 12500 of: 65536 bytes elapsed: 1.1478s io rate: 713742417 bytes/s $ ./readtest /data0/dump/file 65536 1 sequential reads: 12500 of: 65536 bytes elapsed: 1.1012s io rate: 743921133 bytes/s FreeBSD - 6.2-PRERELEASE #7: Mon Nov 27 19:32:33 NZDT 2006 : $ ./readtest /data0/dump/file 8192 0 random reads: 10 of: 8192 bytes elapsed: 4.4477s io rate: 184186327 bytes/s $ ./readtest /data0/dump/file 8192 1 sequential reads: 10 of: 8192 bytes elapsed: 1.9797s io rate: 413804878 bytes/s $ ./readtest /data0/dump/file 32768 1 sequential reads: 25000 of: 32768 bytes elapsed: 1.7068s io rate: 479965034 bytes/s $ ./readtest /data0/dump/file 32768 0 random reads: 25000 of: 32768 bytes elapsed: 2.0076s io rate: 408040469 bytes/s $ ./readtest /data0/dump/file 65536 0 random reads: 12500 of: 65536 bytes elapsed: 1.7856s io rate: 458778279 bytes/s $ ./readtest /data0/dump/file 65536 1 sequential reads: 12500 of: 65536 bytes elapsed: 1.6611s io rate: 493158866 bytes/s ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cached file read performance with 6.2-PRERELEASE
Mark Kirkwood wrote: Pieter de Goeje wrote: It would be more interesting to see how random access to a (cached) file performs in Linux vs FreeBSD, which seems a more logical pattern for a database. Agreed, and good point, I'll knock up a simple program to do random and/or sequential access of a file and see what we get! Here's a (very) simple program that does block reads sequentially or randomly. It probably needs a little polishing, but seems to work ok for the size of files we are interested in: i.e a few GB (see attached): Results: Compiled with CFLAGS=-O2 -march=i686 Gentoo - 2.6.18-gentoo-r3: --- $ ./readtest /data0/dump/file 8192 0 random reads: 10 elapsed: 1.2646 io rate 647805551 bytes/s $ ./readtest /data0/dump/file 8192 1 sequential reads: 10 elapsed: 1.1267 io rate 727075854 bytes/s FreeBSD - 6.2-PRERELEASE #7: Mon Nov 27 19:32:33 NZDT 2006 : ./readtest /data0/dump/file 8192 0 random reads: 10 elapsed: 4.3669 io rate 187594060 bytes/s $ ./readtest /data0/dump/file 8192 1 sequential reads: 10 elapsed: 1.9679 io rate 416283642 bytes/s So looks like we get faster overall results than dd (I guess not needing to send output anywhere helps)...also we seem to be slower in the random case too :-(. I ran these programs several times, typical results shown. Cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Block IP
Suhail Choudhury [EMAIL PROTECTED] wrote: What's the easiest way to add an IP such as 80.192.49.213 to block it? Easy: # ipfw add deny ip from 80.192.49.213 to me Depending on your existing rules, you might have to specify a rule number, so the new rule is inserted at an appropriate position. Please refer to the ipfw(8) manual page for details. Also how do I block out IPs after a certain number of invalid login attempts to prevent brute forcing? In general that's not a good idea. If you do it wrong, it makes DoS attacks against your machine easier (i.e. a clever attacker might be able to lock yourself out of your own machine). And getting it right is not easy. The best way to prevent brute-forcing is to use good pass- words, or -- even better -- don't use passwords at all, but key authentication or OTP (SKey / OPIE). Another thing that you can do is to move the sshd to a non- standard port (i.e. something other than 22). Attackers who look for machines for brute-forcing usually scan networks for port 22 only. However, note that using a non-standard port does _not_ make your machine more secure (that would rather be security by obscurity). It only prevents your machine from appearing in standard ssh scans, so it gets rid of almost all of the ssh login failures in your daily run output which result from such attempts. 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. We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing. -- Mother Teresa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cached file read performance with 6.2-PRERELEASE
On Wednesday 20 December 2006 22:20, Mark Kirkwood wrote: Pieter de Goeje wrote: On Wednesday 20 December 2006 11:38, Mark Kirkwood wrote: In fact if you note that the PIII HW *can* actually do 700MB/s, it suggests that your HW is capable of considerably more than 900MB/s - given that opteron's have excellent cpu to memory bandwidth, and the speed of your memory! Indeed! Copying /dev/zero to /dev/null yields more than 5GB/sec on a simple 2Ghz Athlon64. It imagine there are quite a few extra things done when copying On second thought, this is wrong because /dev/zero isn't a real block of memory so these results say nothing about memory I/O speed because all data is in (cpu) cache. a file from cache, because I can only manage to get one fifth (~1GB/sec) of the theoretical speed. (this is with a file that fills more than half of all memory) Note that linux seems to play tricks (zero copy?) when doing dd if=/dev/zero of=/dev/null, because you can reach speeds which are way above the theoretical maximum. (30GB/sec on a P4 1,6Ghz ??? no way) In the context of databases, I think the speeds are limited by the processing done on the data, as long as the read speed stays above a certain limit. Yeah - typically it is creating tuples out of the blocks/pages just read, so for a big memory scan CPU appears to be the limiting factor! It would be more interesting to see how random access to a (cached) file performs in Linux vs FreeBSD, which seems a more logical pattern for a database. Agreed, and good point, I'll knock up a simple program to do random and/or sequential access of a file and see what we get! I'll check 'em out :) Cheers, Pieter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possibility for FreeBSD 4.11 Extended Support
On Dec 21, 2006, at 1:35 AM, Colin Percival wrote: Now it is near the end of December, and FreeBSD 6.2 RC2 has yet to be seen anywhere. Chances are that FreeBSD 6.2 Release will come out earliest mid-January. This does not give much time for people to migrate to the newest FreeBSD release. I think it would be fair if support is extended for a few more months especially since 6.2 is so late in coming. Your opinion has been noted. FreeBSD 6.1 is a very nice stable release and has been out for a long time. You could migrate to that, too. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possibility for FreeBSD 4.11 Extended Support
John Smith wrote: Support for FreeBSD 4.11 is going to end sometime in late January. Originally, FreeBSD 6.2 was supposed to be released back in October. This would have given everyone about 3 months to stress test everything and migrate all their boxes from 4.11 direct to 6.2. Now it is near the end of December, and FreeBSD 6.2 RC2 has yet to be seen anywhere. Chances are that FreeBSD 6.2 Release will come out earliest mid-January. This does not give much time for people to migrate to the newest FreeBSD release. I think it would be fair if support is extended for a few more months especially since 6.2 is so late in coming. As has been stated many times, the issue here is not one of fairness, or any other theoretical concern. The issue is one of resources, and the resources to continue supporting 4.11 are not there. That said, there is nothing preventing anyone that needs to from stress testing the RELENG_6_2 branch right now, in fact we encourage people to do so! The only thing going into that branch right now are small fixes, so you can be reasonably sure that what you're testing now will be very close to what 6.2-RELEASE will look like. Obviously it would be better if you tracked the -stable and cvs-src mailing lists while doing your testing, but if you're in the position you describe it's probably better that you do that anyway. hth, 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]
Re: Adaptec 2100, asr driver
On Thu, 14 Dec 2006, Marc G. Fournier wrote:
This kind of information (ie. options ASR_COMPAT) would be good to add to the
pkg_message for ports like this ... same thing trip'd me up the other day, and
someone let me know about it ...
and here's a patch... I guess I should send-pr it too... done... (but no
reference number has come back yet after 10 minutes)
Index: Makefile
===
RCS file: /usr/cvs/ports/sysutils/asr-utils/Makefile,v
retrieving revision 1.11
diff -w -u -b -r1.11 Makefile
--- Makefile30 Jul 2005 08:38:59 - 1.11
+++ Makefile20 Nov 2006 17:03:11 -
@@ -75,4 +75,6 @@
post-install:
@${INSTALL_MAN} ${WRKSRC}/raidutil.8 ${PREFIX}/man/man8/
+ @${CAT} ${PKGMESSAGE}
+
.include bsd.port.post.mk
===
New file: pkg-message
*
*** options ASR_COMPAT is required in your kernel ***
*** to use these tools on FreeBSD 5.x and higher ***
*
===
- Tim
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cached file read performance with 6.2-PRERELEASE
Pieter de Goeje wrote: Mark Kirkwood wrote: Pieter de Goeje wrote: Copying /dev/zero to /dev/null yields more than 5GB/sec on a simple 2Ghz Athlon64. It imagine there are quite a few extra things done when copying On second thought, this is wrong because /dev/zero isn't a real block of memory It _is_ a real block of memory. To be exact, it's called zbuf[] in src/sys/dev/null/null.c. It's the size of one page (4 KB or 8 KB, depending on architecture). When some program reads from the zero device, that block is copied repeatedly from kernel space to user space. so these results say nothing about memory I/O speed because all data is in (cpu) cache. That's true. The test rather benchmarks the CPU, the cache and the overhead involved when copying data between kernel and user space. 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]
Error with cli32 ARECA RAID command line tool.
Hello, folks. I am not sure where to go with this, but i have an error trying to execute ARECA RAID command line tool with PAE kernel with GENERIC kernel everything is allright: Fatal error 'Cannot allocate red zone for initial thread' at line ? in file /usr/src/lib/libc_r/uthread/uthread_init.c (errno = ?) [EMAIL PROTECTED]:~# kdump -f ktrace.out 52527 ktrace RET ktrace 0 52527 ktrace CALL execve(0xbf7fed0f,0xbf7fec10,0xbf7fec18) 52527 ktrace NAMI ./cli32 52527 cli32RET execve 0 52527 cli32CALL getpid 52527 cli32RET getpid 52527/0xcd2f 52527 cli32CALL fcntl(0,0x3,0) 52527 cli32RET fcntl 2 52527 cli32CALL fcntl(0x1,0x3,0) 52527 cli32RET fcntl 2 52527 cli32CALL fcntl(0x2,0x3,0) 52527 cli32RET fcntl 2 52527 cli32CALL pipe 52527 cli32RET pipe 3 52527 cli32CALL fcntl(0x3,0x3,0) 52527 cli32RET fcntl 2 52527 cli32CALL fcntl(0x3,0x4,0x6) 52527 cli32RET fcntl 0 52527 cli32CALL fcntl(0x4,0x3,0) 52527 cli32RET fcntl 2 52527 cli32CALL fcntl(0x4,0x4,0x6) 52527 cli32RET fcntl 0 52527 cli32CALL readlink(0x8099f94,0xbf7fea4c,0x3f) 52527 cli32NAMI /etc/malloc.conf 52527 cli32RET readlink -1 errno 2 No such file or directory 52527 cli32CALL mmap(0,0x1000,0x3,0x1002,0x,0,0,0) 52527 cli32RET mmap 671727616/0x2809c000 52527 cli32CALL break(0x80ae000) 52527 cli32RET break 0 52527 cli32CALL break(0x80af000) 52527 cli32RET break 0 52527 cli32CALL break(0x80b) 52527 cli32RET break 0 52527 cli32CALL break(0x80b1000) 52527 cli32RET break 0 52527 cli32CALL mmap(0xbfaff000,0x1000,0,0x1000,0x,0,0,0) 52527 cli32RET mmap -1 errno 12 Cannot allocate memory 52527 cli32CALL write(0x2,0xbf7fe9ec,0x83) 52527 cli32GIO fd 2 wrote 131 bytes Fatal error 'Cannot allocate red zone for initial thread' at line ? in file /usr/src/lib/libc_r/uthread/uthread_init.c (errno = ?) 52527 cli32RET write 131/0x83 52527 cli32CALL sigprocmask(0x3,0xbf7fe9ac,0) 52527 cli32RET sigprocmask 0 52527 cli32CALL getpid 52527 cli32RET getpid 52527/0xcd2f 52527 cli32CALL kill(0xcd2f,0x6) 52527 cli32RET kill 0 52527 cli32PSIG SIGIOT SIG_DFL 52527 cli32NAMI cli32.core -- == - Best regards, Nikolay Pavlov. --- == ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acer Aspire WLMi 5102 with AMD Turion 64 X2 system hanging with powerd on 6.2-RC1 and 6.2-PRERELEASE
On 12/20/06, Abdullah Al-Marrie [EMAIL PROTECTED] wrote: Hello guys, I have problem with my laptop Acer Aspire 5102 WLMi which has AMD Turion™ 64 X2 dual-core TL-50 1.6 GHz with 1.5 GB of ram. I'm running i386 6.2-RC1 upgraded to 6.2-PRELEASE via RELENG6 tag since I don't have more than 4 GB of ram. I have these lines add to my custom generic kernel options SMP device cpufreq device smbus I have this in my rc.conf powerd_enable=YES But the the laptop even doesn't boot some times, and if booted it hangs all the time, till I hashed out powerd_enable=YES hints? Had the same problem where powerd would hang my HP Pavilion dv8000 system. I worked arround the problem by using the following in rc.conf: powerd_enable=YES powerd_flags=-a maximum -b maximum Of course this makes powered do nothing when on battery. What I think is happening is that powered is too aggressive in downgrading the clock speed, that it eventually sets the clock to a value that is so low that the system stops responding. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
burncd 'blank' not terminating ?
just noticed, after upgrading to 6.2RC1, that luigi# burncd -f /dev/acd0 -v blank blanking CD, please wait.. stays there forever. Eventually i gave up and ctrl-C and the application terminates, and i was able to write to the disk a valid image, which probably means that the disk had been blanked. I browsed through the mailing lists and it seems to be an old problem, related to the driver not reporting the status info. Not sure if it is related to particular hardware, just in case here is what i have: ad0: 238475MB MAXTOR STM3250620A 3.AAD at ata0-master UDMA100 acd0: DVDR HL-DT-ST DVDRAM GSA-H10N/JL10 at ata0-slave UDMA33 note, if i kldload atapicam, and try the blank on /dev/cd0 i get this: luigi# burncd -f /dev/cd0 -v blank burncd: ioctl(CDRIOCGETBLOCKSIZE): Inappropriate ioctl for device Any ideas ? This old report says the problem is in the ioctl... http://www.freebsd.org/cgi/query-pr.cgi?pr=44803 cheers luigi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Error with cli32 ARECA RAID command line tool.
Hi Nikolay, On Thu, Dec 21, 2006 at 07:27:06PM +0200, Nikolay Pavlov wrote: Hello, folks. I am not sure where to go with this, but i have an error trying to execute ARECA RAID command line tool with PAE kernel with GENERIC kernel everything is allright: Fatal error 'Cannot allocate red zone for initial thread' at line ? in file /usr/src/lib/libc_r/uthread/uthread_init.c (errno = ?) Hmm, I do not think that PAE is supported by the Areca driver. Perhaps this is what is causing the problems? Does it work without PAE? -- Rink P.W. Springer- http://rink.nu It's you isn't it? THE BASTARD OPERATOR FROM HELL! In the flesh, on the phone and in your account... - BOFH #3 smime.p7s Description: S/MIME cryptographic signature
Re: Error with cli32 ARECA RAID command line tool.
On Thursday, 21 December 2006 at 19:45:33 +0200, Nikolay Pavlov wrote: On Thursday, 21 December 2006 at 18:33:26 +0100, Rink Springer wrote: Hi Nikolay, On Thu, Dec 21, 2006 at 07:27:06PM +0200, Nikolay Pavlov wrote: Hello, folks. I am not sure where to go with this, but i have an error trying to execute ARECA RAID command line tool with PAE kernel with GENERIC kernel everything is allright: Fatal error 'Cannot allocate red zone for initial thread' at line ? in file /usr/src/lib/libc_r/uthread/uthread_init.c (errno = ?) Hmm, I do not think that PAE is supported by the Areca driver. Perhaps this is what is causing the problems? Does it work without PAE? Yes. ARECA raid it self is working with this PAE kernel about three days and i do not see any issues with it. About 1TB of files was downloaded during this period of time. But i couldn't check RAID health with command line tool on PAE kernel. -- Rink P.W. Springer- http://rink.nu It's you isn't it? THE BASTARD OPERATOR FROM HELL! In the flesh, on the phone and in your account... - BOFH #3 -- == - Best regards, Nikolay Pavlov. --- == ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Error with cli32 ARECA RAID command line tool.
On Thursday, 21 December 2006 at 18:33:26 +0100, Rink Springer wrote: Hi Nikolay, On Thu, Dec 21, 2006 at 07:27:06PM +0200, Nikolay Pavlov wrote: Hello, folks. I am not sure where to go with this, but i have an error trying to execute ARECA RAID command line tool with PAE kernel with GENERIC kernel everything is allright: Fatal error 'Cannot allocate red zone for initial thread' at line ? in file /usr/src/lib/libc_r/uthread/uthread_init.c (errno = ?) Hmm, I do not think that PAE is supported by the Areca driver. Perhaps this is what is causing the problems? Does it work without PAE? Yes. -- Rink P.W. Springer- http://rink.nu It's you isn't it? THE BASTARD OPERATOR FROM HELL! In the flesh, on the phone and in your account... - BOFH #3 -- == - Best regards, Nikolay Pavlov. --- == ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cached file read performance with 6.2-PRERELEASE
Pieter de Goeje wrote: On Wednesday 20 December 2006 11:38, Mark Kirkwood wrote: In fact if you note that the PIII HW *can* actually do 700MB/s, it suggests that your HW is capable of considerably more than 900MB/s - given that opteron's have excellent cpu to memory bandwidth, and the speed of your memory! Indeed! Copying /dev/zero to /dev/null yields more than 5GB/sec on a simple 2Ghz Athlon64. It imagine there are quite a few extra things done when copying a file from cache, because I can only manage to get one fifth (~1GB/sec) of the theoretical speed. (this is with a file that fills more than half of all memory) Note that linux seems to play tricks (zero copy?) when doing dd if=/dev/zero of=/dev/null, because you can reach speeds which are way above the theoretical maximum. (30GB/sec on a P4 1,6Ghz ??? no way) In the context of databases, I think the speeds are limited by the processing done on the data, as long as the read speed stays above a certain limit. Yeah - typically it is creating tuples out of the blocks/pages just read, so for a big memory scan CPU appears to be the limiting factor! It would be more interesting to see how random access to a (cached) file performs in Linux vs FreeBSD, which seems a more logical pattern for a database. Agreed, and good point, I'll knock up a simple program to do random and/or sequential access of a file and see what we get! Cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd flipping between PLL and FLL mode
On Tue, Dec 19, 2006 at 12:51:43PM -0500, Michael Proto wrote: I made the change some time ago after combing newsgroups for this issue, so my memory is a little hazy, but I seem to remember something about the FLL/PLL switch being right at about 1024s. Check the Tuning section here: http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-s-algo.htm An interesting read. It doesn't give you an exact solution, but it does hint at what you've taken the time to point out above. I've set maxpoll 9 on each server entry, on each of our boxes. So far (48+ hours later), still no signs of FLL/PLL switching. Very cool. Thank you very much for this recommendation. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://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: Possibility for FreeBSD 4.11 Extended Support
In response to Michael R. Wayne [EMAIL PROTECTED]: Private reply. Not interested in trolling or becoming a troll... On Thu, Dec 21, 2006 at 09:58:11AM -0500, Bill Moran wrote: Are the people making this argument unaware that 6.1 and 5.5 have been at release status for quite some time, and thus have been providing ample opportunity to upgrade for some time now? 4.11 is rock solid. 5.5 and 6.1 both have problems to the point that we can NOT roll them out on production machines. EVERY machine we run those releases (or any 5.x or 6.x release) will hang or reboot at random. And it's not hardware - we take a machine that was happily running 4.11, upgrade it, suffer problems, reformat and reinstall 4.11 and the machine is one again solid. So, 4.11 is unsupported, 5.5 and 6.1 are simply unusable and 6.2 is not released. Is is any wonder we are begging for extended support on 4.11? If 6.2 is as bad as 6.1, we're screwed. Don't know why you sent this to me privately. First off, we're running 5.5, 6.1 and 6.2 all over the place and have zero stability problems. Secondly, how many PRs have you filed regarding these problems? If you've found legitimate issues with the OS, the _correct_ thing to do is help the developers resolve the issues, not clamour about why there aren't enough resources to maintain a system that's old, old, old. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Error with cli32 ARECA RAID command line tool.
I have an Areca card and the utility works 100% for me on 5.3, 5.4, 5.5, 6.1 and 6.2-BETA2 so I'm pretty sure it's a PAE issue. -Clay - Original Message - From: Rink Springer [EMAIL PROTECTED] To: Nikolay Pavlov [EMAIL PROTECTED]; freebsd-stable@freebsd.org; [EMAIL PROTECTED] Sent: Thursday, December 21, 2006 7:33 PM Subject: Re: Error with cli32 ARECA RAID command line tool. Hi Nikolay, On Thu, Dec 21, 2006 at 07:27:06PM +0200, Nikolay Pavlov wrote: Hello, folks. I am not sure where to go with this, but i have an error trying to execute ARECA RAID command line tool with PAE kernel with GENERIC kernel everything is allright: Fatal error 'Cannot allocate red zone for initial thread' at line ? in file /usr/src/lib/libc_r/uthread/uthread_init.c (errno = ?) Hmm, I do not think that PAE is supported by the Areca driver. Perhaps this is what is causing the problems? Does it work without PAE? -- Rink P.W. Springer- http://rink.nu It's you isn't it? THE BASTARD OPERATOR FROM HELL! In the flesh, on the phone and in your account... - BOFH #3 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cached file read performance with 6.2-PRERELEASE
On Thu, 2006-Dec-21 23:22:38 +1300, Mark Kirkwood wrote: Pieter de Goeje wrote: On Wednesday 20 December 2006 11:38, Mark Kirkwood wrote: In fact if you note that the PIII HW *can* actually do 700MB/s, it suggests that your HW is capable of considerably more than 900MB/s - given that opteron's have excellent cpu to memory bandwidth, and the speed of your memory! Indeed! Copying /dev/zero to /dev/null yields more than 5GB/sec on a simple 2Ghz Athlon64. It imagine there are quite a few extra things done when copying a file from cache, because I can only manage to get one fifth (~1GB/sec) of the theoretical speed. (this is with a file that fills more than half of all memory) Fascinating, never thought of trying that! On my 2 (essentially) identical PIII systems, doing copy /dev/zero to /dev/null yields 4.1 GB/s (Gentoo) and 2.0GB/s (FreeBSD) - so yeah, clearly both do something special in that case... (growl... we - i.e FreeBSD - seem to be slower again...tho at that sort of rate, who cares!) This appears to be a fairly meaningless test: I don't know of any applications that rely on /dev/zero read speed or /dev/null write speed. And I don't think we should fuss overly much about claims that Linux can do nothing twice as fast as FreeBSD. If this was really an important issue, we could patch our libc to recognize special filenames and avoid doing syscalls at all on I/O to /dev/zero or /dev/null - this would give us a totally meaningless performance boost. I agree that the FS cache read speed is an issue but the common code paths between filesystem reads and /dev/zero reads are copyout(9) and the generic system call overhead. Before claiming that they are the culprits, someone needs to get some more detailed performance figures (via hwpmc or kernel profiling) and find where the time is really spent. -- Peter Jeremy pgpwMiCYrtVYB.pgp Description: PGP signature
Duplicate IPFW rules
Hi, I have just noticed that ipfw list shows one rule twice. It could be that I have run a script that adds it twice: shell::root:~ ipfw list 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 01999 deny ip from table(1) to any 01999 deny ip from table(1) to any 65000 allow ip from any to any 65535 allow ip from any to any Shouldn't IPFW check before adding the same rule number again? This is FreeBSD 6.1 RC1 with quite recent kernel. -- Vaclav Haisman signature.asc Description: OpenPGP digital signature
Re: Block IP
On Thursday, 21. December 2006 17:33, Oliver Fromme wrote: Suhail Choudhury [EMAIL PROTECTED] wrote: What's the easiest way to add an IP such as 80.192.49.213 to block it? Easiest way to block any activity is to use /etc/hosts.allow file. Port: denyhosts-2.5 Path: /usr/ports/security/denyhosts Info: Script to thwart ssh attacks Maint: [EMAIL PROTECTED] B-deps: python-2.4.3 R-deps: python-2.4.3 WWW:http://denyhosts.sourceforge.net/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Duplicate IPFW rules
Kevin Downey wrote, On 21.12.2006 20:44: On 12/21/06, *Václav Haisman* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, I have just noticed that ipfw list shows one rule twice. It could be that I have run a script that adds it twice: shell::root:~ ipfw list 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 http://127.0.0.0/8 00300 deny ip from 127.0.0.0/8 http://127.0.0.0/8 to any 01999 deny ip from table(1) to any 01999 deny ip from table(1) to any 65000 allow ip from any to any 65535 allow ip from any to any Shouldn't IPFW check before adding the same rule number again? This is FreeBSD 6.1 RC1 with quite recent kernel. -- Vaclav Haisman its a feature, not a bug. Huh, really? How is it useful? Please, explain. -- VH signature.asc Description: OpenPGP digital signature
Re: Duplicate IPFW rules
On 12/21/06, Václav Haisman [EMAIL PROTECTED] wrote: Hi, I have just noticed that ipfw list shows one rule twice. It could be that I have run a script that adds it twice: shell::root:~ ipfw list 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 01999 deny ip from table(1) to any 01999 deny ip from table(1) to any 65000 allow ip from any to any 65535 allow ip from any to any Shouldn't IPFW check before adding the same rule number again? This is FreeBSD 6.1 RC1 with quite recent kernel. -- Vaclav Haisman its a feature, not a bug. -- The biggest problem with communication is the illusion that it has occurred. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Block IP
Oliver Fromme wrote: [ snip ] In general that's not a good idea. If you do it wrong, it makes DoS attacks against your machine easier (i.e. a clever attacker might be able to lock yourself out of your own machine). And getting it right is not easy. The best way to prevent brute-forcing is to use good pass- words, or -- even better -- don't use passwords at all, but key authentication or OTP (SKey / OPIE). Another thing that you can do is to move the sshd to a non- standard port (i.e. something other than 22). Attackers who look for machines for brute-forcing usually scan networks for port 22 only. However, note that using a non-standard port does _not_ make your machine more secure (that would rather be security by obscurity). It only prevents your machine from appearing in standard ssh scans, so it gets rid of almost all of the ssh login failures in your daily run output which result from such attempts. First, I want to second Oliver's advice. If it's at all possible switch to using public keys for authentication with ssh and disallow password authentication. This completely stops the brute forcing attacks from filling up your periodic security mail. Second, and I know that you are using ipfw, I use pf with the following config: table blackhole persist ## Allow people into the ssh server but if they are just wasting my time then ## blackhole them. block in quick from blackhole pass in on $ext_if proto tcp to $ext_if port 22 flags S/SA keep state \ (max-src-conn-rate 5/60, overload blackhole flush global) This automatically adds addresses to the blackhole table if they try to initiate connections to ssh at a rate of more than 5 connects per minute. Oliver's warning applies here also. Using spoofing, someone could force an arbitrary IP address into the blackhole table and make my life difficult. Awareness of that hole is an important part of using this tactic as a part of your security profile. -- Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Duplicate IPFW rules
Scott Ullrich wrote, On 21.12.2006 21:05: On 12/21/06, Václav Haisman [EMAIL PROTECTED] wrote: Huh, really? How is it useful? Please, explain. One example feature is to be able to delete many rules at once. If you know that a specific rule number holds rules (example: time based rules) then the script has less work to do. Now granted since sets where introduced this can be done via this method but this feature has been useful (at least to me) for years and years now. Scott Oh, I did not realise this use. Hmm...still, I thought that this is what tables are for :) -- VH signature.asc Description: OpenPGP digital signature
Re: Duplicate IPFW rules
Hi, Re-edit your script and on the first line at the following: ipfw -f fl This line flushes the firewall script that is currently loaded before loading your script. Can you keep me posted. Regards and a Merry Christmas, -- Rodrigo Galiano Celestino Internet System Consultant Celphone: +244 923 57 79 72 Václav Haisman escreveu: Hi, I have just noticed that ipfw list shows one rule twice. It could be that I have run a script that adds it twice: shell::root:~ ipfw list 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 01999 deny ip from table(1) to any 01999 deny ip from table(1) to any 65000 allow ip from any to any 65535 allow ip from any to any Shouldn't IPFW check before adding the same rule number again? This is FreeBSD 6.1 RC1 with quite recent kernel. -- Vaclav Haisman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Duplicate IPFW rules
On 12/21/06, Václav Haisman [EMAIL PROTECTED] wrote: Oh, I did not realise this use. Hmm...still, I thought that this is what tables are for :) Yep, thats another usage for tables. But tables have not been around for very long either. Considering that I have used IPFW since FreeBSD version 2 or something or another these fancy features have not always been around :) Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Duplicate IPFW rules
On Thu, Dec 21, 2006 at 08:53:07PM +0100, Václav Haisman wrote: Huh, really? How is it useful? Please, explain. I use the functionality you're questioning. Each of my rule numbers (well, not all of them, but most of them) are for specfic things; such as rule 3000 representing deny SSH attempts from any APNIC addresses, rule 3001 representing the same but for RIPE, etc. etc.. I have multiple deny entries *per rule number*. Thus, when I delete one of those rule numbers, I delete all entries in that rule (e.g. if I have 15 deny statements in rule 3000, if I delete rule 3000, I delete all 15 of those deny statements). So please, do not change this behaviour -- it's a useful feature. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://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: Duplicate IPFW rules
On 12/21/06, Václav Haisman [EMAIL PROTECTED] wrote: Huh, really? How is it useful? Please, explain. One example feature is to be able to delete many rules at once. If you know that a specific rule number holds rules (example: time based rules) then the script has less work to do. Now granted since sets where introduced this can be done via this method but this feature has been useful (at least to me) for years and years now. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acer Aspire WLMi 5102 with AMD Turion 64 X2 system hanging with powerd on 6.2-RC1 and 6.2-PRERELEASE
On Wed, 2006-Dec-20 15:04:31 -0800, Scot Hetzel wrote: Had the same problem where powerd would hang my HP Pavilion dv8000 system. I worked arround the problem by using the following in rc.conf: powerd_enable=YES powerd_flags=-a maximum -b maximum Of course this makes powered do nothing when on battery. You might as well have powerd_enable=NO What I think is happening is that powered is too aggressive in downgrading the clock speed, that it eventually sets the clock to a value that is so low that the system stops responding. I have an HP nx6125 that will randomly hang if powerd is enabled and if you search back through the mailing lists, there are a few other people with similar problems. I've done some experimenting and in my case, it's the clock speed transitions that cause a hang. The actual clock speed is irrelevant. I believe it's a race condition or a timing bug. -- Peter Jeremy pgpLYEeqY23X0.pgp Description: PGP signature
Re: Cached file read performance with 6.2-PRERELEASE
Has anyone tried these tests with 4.x? Well, i did, and i was surprised how good the performance is, it gave me the highest number of all tests, even compared to much faster HW. Although this is all different hardware, it seems like the performance drops the higher the version of FreeBSD is, specifically right after 6.1. Is there a possibility that there was some performance problem introduced around that time? All tests done with dd if=/dev/zero of=/tmp/file bs=8k count=3, a 234M file. --- FreeBSD 4.11-STABLE, Pentium(R) 4 CPU 2.60GHz, 512MB # dd of=/dev/null if=/tmp/file bs=8k 3+0 records in 3+0 records out 24576 bytes transferred in 0.298992 secs (821962015 bytes/sec) # dd of=/dev/null if=/tmp/file bs=32k 7500+0 records in 7500+0 records out 24576 bytes transferred in 0.221009 secs (990834 bytes/sec) FreeBSD 6.1-STABLE, Dual Core AMD Opteron(tm) Processor 170 (2009.27-MHz K8-class CPU), 1GB # dd of=/dev/null if=/tmp/file bs=8k 3+0 records in 3+0 records out 24576 bytes transferred in 0.289550 secs (848765132 bytes/sec) # dd of=/dev/null if=/tmp/file bs=32k 7500+0 records in 7500+0 records out 24576 bytes transferred in 0.243281 secs (1010190329 bytes/sec) FreeBSD 6.1-STABLE, Intel(R) Pentium(R) D CPU 3.20GHz (3118.91-MHz 686-class CPU), 1GB # dd of=/dev/null if=/tmp/file bs=8k 3+0 records in 3+0 records out 24576 bytes transferred in 0.354899 secs (692478377 bytes/sec) # dd of=/dev/null if=/tmp/file bs=32k 7500+0 records in 7500+0 records out 24576 bytes transferred in 0.285909 secs (859574388 bytes/sec) FreeBSD 6.2-PRERELEASE, AMD Athlon(tm) 64 Processor 3000+ (2002.58-MHz K8-class CPU), 512MB # dd of=/dev/null if=/tmp/file bs=8k 3+0 records in 3+0 records out 24576 bytes transferred in 0.354382 secs (693488872 bytes/sec) # dd of=/dev/null if=/tmp/file bs=32k 7500+0 records in 7500+0 records out 24576 bytes transferred in 0.356816 secs (688758249 bytes/sec) FreeBSD 6.2-PRERELEASE, Intel(R) Pentium(R) 4 CPU 1.80GHz (1796.94-MHz 686-class CPU), 512MB # dd of=/dev/null if=/tmp/file bs=8k 3+0 records in 3+0 records out 24576 bytes transferred in 0.483906 secs (507867448 bytes/sec) # dd of=/dev/null if=/tmp/file bs=32k 7500+0 records in 7500+0 records out 24576 bytes transferred in 0.390824 secs (628825123 bytes/sec) FreeBSD 7.0-CURRENT (all debugging off), AMD Athlon(tm) Processor (1410.21-MHz 686-class CPU), 512MB # dd of=/dev/null if=/tmp/file bs=8k 3+0 records in 3+0 records out 24576 bytes transferred in 0.846895 secs (290189464 bytes/sec) # dd of=/dev/null if=/tmp/file bs=32k 7500+0 records in 7500+0 records out 24576 bytes transferred in 0.794950 secs (309151516 bytes/sec) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cached file read performance with 6.2-PRERELEASE
Oliver Fromme wrote: Mark Kirkwood wrote: Exactly, that's why I did the comparison - I think you missed the part where I mentioned the 2 systems were *identical* with respect to cpus, memory, mobo - in fact even the power supplies are identical too! So I assume your benchmark measured the performance of the zero and null devices under FreeBSD and Linux. No - that was peripheral to the benchmark, and I should not have sent that message 'cause actually I've taken dev/zero and /dev/null *out* of the picture - check earlier messages with the .c prog attached, I'm using read(2) and lseek(2) to access a real file, that just happens (i.e. has been arranged) to be cached! This is a quote from the cstream docs: These special devices speed varies greatly among operating systems, redirecting from it isn't appropriate benchmarking and a waste of resources anyway. I suggest you try cstream (ports/misc/cstream) instead of dd. It supports built-in zero creation and data sink, so you don't have to use the zero and null devices at all, eliminating their overhead. It would be interesting how that will change your benchmark numbers. Thanks - I was suspicious of these special files, but had no evidence! Cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cached file read performance with 6.2-PRERELEASE
Bill Moran wrote:
In response to Mark Kirkwood [EMAIL PROTECTED]:
JoaoBR wrote:
I am not convinced that this kind of test is of any value for comparing
systems at all because there are too much factors involved - unless the
competitors are installed on identical hardware. On the other side I think it
is usefull to compare tweaked settings on a particular machine. For example
you may change fsize/bsize of the filesystem or any other and can compare
this results then.
Exactly, that's why I did the comparison - I think you missed the part
where I mentioned the 2 systems were *identical* with respect to cpus,
memory, mobo - in fact even the power supplies are identical too!
(snippage)
In fact, to indulge your skepticism ('cause I think this is a real issue
worth sorting out), I booted the FreeBSD system with a Gentoo livecd
and ran the same tests there... and guess what - identical results to
the installed Gentoo system...so... errm - *my* experimental method is
sound...so how about we just get together and see how to make FreeBSD
kick Gentoo eh?
I looks like your testing methodology is sound, and that you've
uncovered an issue worth pursuing.
I recommend starting this thread up on [EMAIL PROTECTED] The folks
on that list are more likely to jump all over this kind of thing.
Great - I'm not subscribed to -performance (that is easily fixed
tho...), so I'll set that up and follow your suggestion!
You might also find helpful people on the current@ and hackers@ lists.
My gut tells me that any changes that can improve this will be large
enough that they'll have to go through CURRENT first, then get MFCed
back in to 6.
Right, no worries there (I can upgrade to CURRENT on my test
machine...should be an interesting exercise in itself!)
Keep in mind also that the holidays tend to slow things down, it might
be early January before you get a lot of people looking at this issue
seriously.
Yeah - Merry Xmas to you all!
Cheers
Mark
P.s : JoaoBR, apologies for coming on a bit strong...it was merely my
enthusiasm to get to the bottom (or even the beginning...) of what is
going on here!
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possibility for FreeBSD 4.11 Extended Support
On Thu, 21 Dec 2006, Bill Moran wrote: In response to Heinrich Rebehn [EMAIL PROTECTED]: Colin Percival wrote: John Smith wrote: Support for FreeBSD 4.11 is going to end sometime in late January. Originally, FreeBSD 6.2 was supposed to be released back in October. This would have given everyone about 3 months to stress test everything and migrate all their boxes from 4.11 direct to 6.2. You've had three months to stress test 6.2-BETA1, 6.2-BETA2, 6.2-BETA3, and 6.2-RC1. We release these for a reason, you know. Now it is near the end of December, and FreeBSD 6.2 RC2 has yet to be seen anywhere. Chances are that FreeBSD 6.2 Release will come out earliest mid-January. This does not give much time for people to migrate to the newest FreeBSD release. I think it would be fair if support is extended for a few more months especially since 6.2 is so late in coming. Your opinion has been noted. Colin Percival I have to second the OP's opinion. :-) I think it is important to be able to stress test the *final* release before installing on production machines. There is little use in stress testing BETAs and then install a broken RELEASE. This happened with 6.1-RELEASE where the nfs server was suddenly unusable on amd64. There is something about these please continue to support 4.x discussions that confuses me. Personally, I understand it, but my perspective may be skewed. The general argument has been that 4.11 support should continue because 6.2 is not at release status yet. If I were to complain about 4.11 going away (and I'm not), this would be my argument: -5.x was never really for production use, in the same way 3.x never was. It was a release made to introduce new features and to beta test what will become a good 6.x release. In my mind, I always skip over 5.x. I would not shed a tear if support for 5.x was dropped before 4.11. -the 4.x branch was the most stable thing since 2.2.x, so many people are hanging on to it for dear life, much as in the windows world you'll still find people that prefer the (relative) stability of something like W2K over XP or Vista. It is a *compliment* to everyone that put all the effort into making the 4.x branch as good as it was that people want to keep using this functional and stable software. -many people run a ton of machines and are not doing any hardware swaps anytime soon. 4.11 runs well on there, and doing a full reinstall on dozens, hundreds or thousands of hosts might be more than they care to do *right now*. Again, a testament to the stability and quality of 4.11. -upgrades from 4.11 to 6.2 are not simple, and not doable without a fairly significant amount of downtime. Everywhere there are folks with a handful of boxes that shouldn't be a single point of failure, but are. Worse, some people have a mix of unique boxes where their first test of 6.x is going to be their only test of 6.x on that specific piece of hardware. -there certainly are plenty of new features and conveniences in 5/6, but for a 3 or 4 year old box that's happily humming along, new hardware support is not paramount, nor are things like the vastly improved wireless support. In any sort of large server farm there are likely homegrown solutions in place to augment 4.11 to the point where the lack of /etc/rc.d or other little convenience pieces just aren't compelling enough to start over. Are the people making this argument unaware that 6.1 and 5.5 have been at release status for quite some time, and thus have been providing ample opportunity to upgrade for some time now? Or has this topic simply degraded to Troll bait? Again, I think 5.x is probably the least used version of FreeBSD in history. As for 6.1, using a .1 release of something in production is gambling (not a knock on FreeBSD, I'd apply that to anything). People are just voicing their opinion. This is not a democracy, but that also does not preclude the userbase from expressing their views on the matter. If this were a democracy and this was a vote, I'd vote for extending 4.11 support until 6.3 comes out and dropping all support for 5.x tomorrow. :) FWIW, I have about 1/4 of the production boxes I manage up to 6.1 or 6.2-RC1 (mostly throwaway/redundant stuff like spam scanning). The rest are still at 4.11. I do look forward to the bonuses of moving to 6.2 or 6.3 on the rest; my short list of new stuff that would make my life easier: pf, the new rc stuff, jail improvements, support for more GigE interfaces, mysql almost working right/threads. Charles -- Bill Moran Collaborative Fusion Inc. ___ 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
Re: Possibility for FreeBSD 4.11 Extended Support
On 21/12/06, Charles Sprickman [EMAIL PROTECTED] wrote: On Thu, 21 Dec 2006, Bill Moran wrote: In response to Heinrich Rebehn [EMAIL PROTECTED]: Colin Percival wrote: John Smith wrote: Support for FreeBSD 4.11 is going to end sometime in late January. Originally, FreeBSD 6.2 was supposed to be released back in October. This would have given everyone about 3 months to stress test everything and migrate all their boxes from 4.11 direct to 6.2. You've had three months to stress test 6.2-BETA1, 6.2-BETA2, 6.2-BETA3, and 6.2-RC1. We release these for a reason, you know. Now it is near the end of December, and FreeBSD 6.2 RC2 has yet to be seen anywhere. Chances are that FreeBSD 6.2 Release will come out earliest mid-January. This does not give much time for people to migrate to the newest FreeBSD release. I think it would be fair if support is extended for a few more months especially since 6.2 is so late in coming. Your opinion has been noted. Colin Percival I have to second the OP's opinion. :-) I think it is important to be able to stress test the *final* release before installing on production machines. There is little use in stress testing BETAs and then install a broken RELEASE. This happened with 6.1-RELEASE where the nfs server was suddenly unusable on amd64. There is something about these please continue to support 4.x discussions that confuses me. Personally, I understand it, but my perspective may be skewed. The general argument has been that 4.11 support should continue because 6.2 is not at release status yet. If I were to complain about 4.11 going away (and I'm not), this would be my argument: -5.x was never really for production use, in the same way 3.x never was. It was a release made to introduce new features and to beta test what will become a good 6.x release. In my mind, I always skip over 5.x. I would not shed a tear if support for 5.x was dropped before 4.11. -the 4.x branch was the most stable thing since 2.2.x, so many people are hanging on to it for dear life, much as in the windows world you'll still find people that prefer the (relative) stability of something like W2K over XP or Vista. It is a *compliment* to everyone that put all the effort into making the 4.x branch as good as it was that people want to keep using this functional and stable software. -many people run a ton of machines and are not doing any hardware swaps anytime soon. 4.11 runs well on there, and doing a full reinstall on dozens, hundreds or thousands of hosts might be more than they care to do *right now*. Again, a testament to the stability and quality of 4.11. -upgrades from 4.11 to 6.2 are not simple, and not doable without a fairly significant amount of downtime. Everywhere there are folks with a handful of boxes that shouldn't be a single point of failure, but are. Worse, some people have a mix of unique boxes where their first test of 6.x is going to be their only test of 6.x on that specific piece of hardware. -there certainly are plenty of new features and conveniences in 5/6, but for a 3 or 4 year old box that's happily humming along, new hardware support is not paramount, nor are things like the vastly improved wireless support. In any sort of large server farm there are likely homegrown solutions in place to augment 4.11 to the point where the lack of /etc/rc.d or other little convenience pieces just aren't compelling enough to start over. Are the people making this argument unaware that 6.1 and 5.5 have been at release status for quite some time, and thus have been providing ample opportunity to upgrade for some time now? Or has this topic simply degraded to Troll bait? Again, I think 5.x is probably the least used version of FreeBSD in history. As for 6.1, using a .1 release of something in production is gambling (not a knock on FreeBSD, I'd apply that to anything). People are just voicing their opinion. This is not a democracy, but that also does not preclude the userbase from expressing their views on the matter. If this were a democracy and this was a vote, I'd vote for extending 4.11 support until 6.3 comes out and dropping all support for 5.x tomorrow. :) FWIW, I have about 1/4 of the production boxes I manage up to 6.1 or 6.2-RC1 (mostly throwaway/redundant stuff like spam scanning). The rest are still at 4.11. I do look forward to the bonuses of moving to 6.2 or 6.3 on the rest; my short list of new stuff that would make my life easier: pf, the new rc stuff, jail improvements, support for more GigE interfaces, mysql almost working right/threads. Charles -- Bill Moran Collaborative Fusion Inc. ___ 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
Re: sshfs/nfs cause server lockup - resolved
On 19/12/06, Kris Kennaway [EMAIL PROTECTED] wrote: On Tue, Dec 19, 2006 at 08:20:21PM +, Chris wrote: On 18/12/06, Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, Dec 18, 2006 at 12:39:13AM +, Chris wrote: On 14/12/06, Kris Kennaway [EMAIL PROTECTED] wrote: On Thu, Dec 14, 2006 at 01:28:48AM +, Chris wrote: It does make sense if thats the problem since the entire server even locally stops working properly, and it always follows a unexpected nfs/sshfs disconnection ie. network timeout. I am now running 6.2-RC that has the new file and currently at 1 day 11hrs uptime. OK, thanks for following part of the advice I gave a month ago ;) Let us know if the problems persist. Kris Early today the nfs hub was rebooted so had a unexpected disconnection also noted by the sshfs timeout prompt waiting for me in the terminal , was able to remount fine and no server lockup or other probolems. Current uptime is 5 days, 10:48 OK, good to know. Thanks, Kris Some bad news, I was offline for a day here, then I logged in today reattached to screen, and was greeted with a timeout message to the sshfs server, at this point server still functioning fine. When I ran the sshfs command again it locked, with only pings responding and had to hard reboot it. I will setup my local machne now so I can do proper debugging for you. OK, it's (still) probably an sshfs bug though. Kris Ok how to repeat the bug everytime. Works on sshfs and nfs. First. The server died again (hub having its own problems so causing lots of timeouts). This time instead of remounting I tried to ls the 2 mounts simply list empty dirs, first dir worked and 2nd dir caused lockup, so its some kind of problem with the filesystem nodes or something. With this in mind on my local box I yanked out the network cable causing a unexpected timeout, box hung, tried to do the ddb procedure but didnt work, I may have been doing it wrong. Booted local box again mounted nfs over internet and tried same thing yanked out network cable, same thing accessing the dir where nfs mount to hung server hard reboot needed. Local box using 6.2-RC as well. GENERIC kernel default make.conf. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possibility for FreeBSD 4.11 Extended Support
Charles Sprickman made many good point IMO, but one aluded to in
Chris's follow up concerns me:
there is also uneeded cost involved in piurchasing hardware capable of
running 6.x
Performance on old boxes stability interest me, eg the 486s
in scanners ( http://berklix.com/scanjet/ http://madole.net/scanjet/
) that have become servers, some of which may also be last islands of
secret BSD server sanity in companies that have fallen to the Suits
edict of Only boxes blessed by Mickey$oft ;-)
Sure, I can do cross compile ('cos local make world is Slow), but
when shipped if supporting other server loads, 6.x Might be a
problem on eg Am486DX2 66 MHz 16M Ram ? (I got the impression 4.11
to 6.x will slow by about 1.2 ?) Maybe most people are running
(like me on ~ 20 boxes) mostly 4.11 6.1, so perhaps that suggestion
to drop 5.x rather than 4.x makes numeric sense ?
Julian
--
Julian Stacey. BSD Unix C Net Consultancy, Munich/Muenchen http://berklix.com
Mail Ascii, not HTML. Ihr Rauch = mein allergischer Kopfschmerz.
http://berklix.org/free-software
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ral / ralink 2561 MFC of openbsd import / card=0x25611814 chip=0x03021814
On Thursday 21 December 2006 12:01, [EMAIL PROTECTED] wrote: I have a ral rt2561 I guess, which currently isn't support by the releng_6 branch. Is it possible to backport the driver from HEAD? There was a cal for testers a couple of days ago. Two FreeBSD comitters are looking at this, but they really need more testers. Could you possibly help? The patch to add the changes to RELENG_6 is here: http://samodelkin.net/~fjoe/if_ral.diff Ther patch applies to /usr/src/sys and will not link directly into the kernel; you must load it as a module using loader.conf. Apply the patch, cd to /usr/src/sys/modules and do make make install. So far we have tested Mini-PCI cards, the original RT2560, RT2561s and the MIMO-XR RT2661. Tests on Cardbus cards would be particularly useful. -- Matt Dawson. [EMAIL PROTECTED] MTD15-RIPE OpenNIC M_D9 MD51-6BONE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Duplicate IPFW rules
On Thu, 21 Dec 2006, Scott Ullrich wrote: On 12/21/06, Václav Haisman [EMAIL PROTECTED] wrote: Oh, I did not realise this use. Hmm...still, I thought that this is what tables are for :) Yep, thats another usage for tables. But tables have not been around for very long either. Considering that I have used IPFW since FreeBSD version 2 or something or another these fancy features have not always been around :) Perhaps worth noting that on FreeBSD 2 (and iirc, 3) 'ipfw delete $rule' only deleted the first of any set of same-numbered rules, ie you had to issue multiple delete commands. This behaviour changed somewhere in 4.x to a single delete command removing all same-numbered rules; I had to modify several scripts at the time to accomodate that (sensible) change. Cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /etc/rc.d/jail: losing IPs if jail_x_interface set and syntax error in jails /etc/rc?
Raphael H. Becker wrote:
Hi *,
I recently triggered an error when setting up a jail-host: I configured
the jail(s) like evry jail I set up in the past:
Yes, this is a bug in rc.d/jail and was introduced in this change:
http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/jail.diff?r1=1.31r2=1.32.
When a jail fails to start, in your case a broken rc.conf in the jail,
the jail is stopped and the ipaddr-alias is unconfigured from the
interface with the following command: ifconfig ${jail_interface} -alias
${jail_ip}
Unfortunately in the change above the variables were renamed to
_interface and _ip, this leads to ifconfig getting executed without a
specified ipaddr. and therefore the first alias is unconfigured, which
is in most cases the ipaddr. you are having access to the remote host.
${jail_interface} is only the correct interface out of luck, so it
should be changed to _interface too.
I think the correct way would be to call jail_stop() instead of doing
the cleanup by hand but in the current implementation this would leave
the ipaddr-alias configured on the interface.
I think I already mentioned once that I don't like this interface and
ipaddr. configuration feature in rc.d/jail at all.
Anyway, the quick fix is trivial and should be included in 6.2.
Otherwise we have a possible DoS security problem with the new release.
--- rc.d/jail.old Fri Dec 22 03:09:27 2006
+++ rc.d/jail Fri Dec 22 03:10:07 2006
@@ -228,8 +228,8 @@
echo ${_jail_id} /var/run/jail_${_jail}.id
else
jail_umount_fs
- if [ -n ${jail_interface} ]; then
- ifconfig ${jail_interface}
-alias ${jail_ip}
+ if [ -n ${_interface} ]; then
+ ifconfig ${_interface} -alias ${_ip}
fi
echo cannot start jail \${_jail}\:
tail +2 ${_tmp_jail}
greetings,
philipp
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possibility for FreeBSD 4.11 Extended Support
[EMAIL PROTECTED] writes: -5.x was never really for production use, in the same way 3.x never was. Why do people continue to say this? Many sites have used, are still using, and plan to continue to use, 5.x in production. ftp5/cvsup3 ran 5.x until a few months ago, and I have a netnews transit server and a Web server that still run 5.5. I'm slowly moving things off 5.x for the better support and performance of 6.x, but it's been stable for me in two fairly tough production applications for quite some time. -GAWollman -- Garrett A. Wollman | The real tragedy of human existence is not that we are [EMAIL PROTECTED]| nasty by nature, but that a cruel structural asymmetry Opinions not those | grants to rare events of meanness such power to shape of MIT or CSAIL. | our history. - S.J. Gould, Ten Thousand Acts of Kindness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Block IP
Christopher Hilton wrote: If it's at all possible switch to using public keys for authentication with ssh and disallow password authentication. This completely stops the brute forcing attacks from filling up your periodic security mail. Are you sure about that? I only allow PublickeyAuthentication ssh2 connections but I get lots of security mail messages like: Nov 16 01:44:08 maxwell sshd[70067]: Invalid user marcos from 202.54.49.7 Nov 16 01:44:23 maxwell sshd[70067]: reverse mapping checking getaddrinfo for 49-7.broadband.vsnl.net.in failed - POSSIBLE BREAKIN ATTEMPT! Graham ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acer Aspire WLMi 5102 with AMD Turion 64 X2 system hanging with powerd on 6.2-RC1 and 6.2-PRERELEASE
В сообщении от Пятница 22 декабря 2006 00:27 Peter Jeremy написал(a): On Wed, 2006-Dec-20 15:04:31 -0800, Scot Hetzel wrote: Had the same problem where powerd would hang my HP Pavilion dv8000 system. I worked arround the problem by using the following in rc.conf: powerd_enable=YES powerd_flags=-a maximum -b maximum Of course this makes powered do nothing when on battery. You might as well have powerd_enable=NO What I think is happening is that powered is too aggressive in downgrading the clock speed, that it eventually sets the clock to a value that is so low that the system stops responding. I have an HP nx6125 that will randomly hang if powerd is enabled and if you search back through the mailing lists, there are a few other people with similar problems. I've done some experimenting and in my case, it's the clock speed transitions that cause a hang. The actual clock speed is irrelevant. I believe it's a race condition or a timing bug. All this sounds strange, because i bought this very notebook for my wife 22 days ago, installed 6.2-PRE and it works totally stable for almost a month now. Here she is with this book: http://forum.allunix.ru/index.php?act=Attachtype=postid=4 Looks pretty happy, doesn't she? :-))) The only thing is that this book doesn't reboot or shut the power down when i tell him to 'reboot' or 'reboot -p'. It just syncs discs and hands with no explanations. But it works just fine. -- С уважением, Бачило Дмитрий Руководитель отдела системной интаграции ООО Компания Солинк -- With Best Regards, Bachilo Dmitry Head of systems integration dept Solink Company Ltd. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possibility for FreeBSD 4.11 Extended Support
On Thu, Dec 21, 2006 at 09:59:34PM -0500, Garrett Wollman wrote: [EMAIL PROTECTED] writes: -5.x was never really for production use, in the same way 3.x never was. Why do people continue to say this? Many sites have used, are still using, and plan to continue to use, 5.x in production. I'm going to copy a bit of mail that I sent to someone privately. FreeBSD 4.11 can survive a simple burn-in test. FreeBSD 5.X and 6.1 can not. Here's what I wrote earlier. Take a server. Configure for SMP, add quotas within jails and basic IPFW protection with a few hundred dummynet pipes for b/w throttling (less than 10,000 total IPFW lines). Load the machine a bit so that it constantly maintains a 3 digit load and run sufficient active processes to keep it in moderate swap state. The result of that minimal-effort test yields machines which can not maintain 30 days of uptime (most fail in under a week). And don't even THINK about snapshots in 6.1 or earlier. THAT is why people who run servers, with jails, quotas, ipfw and moderate load keep complaining about 5.X and 6.1 and begging for 4.11 support to be extended. Just because someone has a few FreeBSD boxes running light loads and not using the features that we NEED does not mean that any the port 4.11 releases to date are stable. /\/\ \/\/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: burncd 'blank' not terminating ?
On Thu, Dec 21, 2006 at 09:27:17AM -0800, Luigi Rizzo wrote: just noticed, after upgrading to 6.2RC1, that luigi# burncd -f /dev/acd0 -v blank blanking CD, please wait.. stays there forever. Eventually i gave up and ctrl-C and the application terminates, and i was able to write to the disk a valid image, which probably means that the disk had been blanked. I browsed through the mailing lists and it seems to be an old problem, related to the driver not reporting the status info. Not sure if it is related to particular hardware, just in case here is what i have: ad0: 238475MB MAXTOR STM3250620A 3.AAD at ata0-master UDMA100 acd0: DVDR HL-DT-ST DVDRAM GSA-H10N/JL10 at ata0-slave UDMA33 note, if i kldload atapicam, and try the blank on /dev/cd0 i get this: luigi# burncd -f /dev/cd0 -v blank burncd: ioctl(CDRIOCGETBLOCKSIZE): Inappropriate ioctl for device Any ideas ? This old report says the problem is in the ioctl... http://www.freebsd.org/cgi/query-pr.cgi?pr=44803 See my report: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/95344 And: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/104270 The last one contain a fix. Serg. P.S.: Don't use burncd. Use cdrecord! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
