Vinum problems in 5.3-BETA7?
Hi all! We have a production system that runs on a vinum system drive configured like this: cab# vinum l 2 drives: D b State: up /dev/ad1s1h A: 0/114494 MB (0%) D a State: up /dev/ad0s1h A: 0/114494 MB (0%) 4 volumes: V root State: up Plexes: 2 Size:256 MB V swap State: up Plexes: 2 Size: 3072 MB V usr State: up Plexes: 2 Size: 4096 MB V var State: up Plexes: 2 Size:104 GB 8 plexes: P root.p1 C State: up Subdisks: 1 Size:256 MB P swap.p1 C State: up Subdisks: 1 Size: 3072 MB P usr.p1 C State: up Subdisks: 1 Size: 4096 MB P var.p1 C State: up Subdisks: 1 Size:104 GB P root.p0 C State: up Subdisks: 1 Size:256 MB P swap.p0 C State: up Subdisks: 1 Size: 3072 MB P usr.p0 C State: up Subdisks: 1 Size: 4096 MB P var.p0 C State: up Subdisks: 1 Size:104 GB 8 subdisks: S root.p1.s0State: up D: bSize:256 MB S swap.p1.s0State: up D: bSize: 3072 MB S usr.p1.s0 State: up D: bSize: 4096 MB S var.p1.s0 State: up D: bSize:104 GB S root.p0.s0State: up D: aSize:256 MB S swap.p0.s0State: up D: aSize: 3072 MB S usr.p0.s0 State: up D: aSize: 4096 MB S var.p0.s0 State: up D: aSize:104 GB It's currently running fine with FreeBSD 5.2.1-RELEASE-p10. After upgrading to 5.3-BETA7, buildworld, buildkernel, installkernel and reboot the system stops: vinum: loaded vinum: no drives found That's it. Of course it complains that it can't mount /dev/vinum/root. The list of detected GEOM devices at the "mountroot> " prompt includes ad0s1h, ad1s1h, ad0s1, ad1s1, ad0, ad1 and some more partitions. Where do I go from here? Is this expected behaviour due to the ongoing GEOM changes or should I go read Greg's "how to debug vinum problems" document? I will do that, no problem. Just want to know if it makes sense at all, because now everyone might tell me "vinum is known broken in 5.3" or similar. Thanks, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.3-BETA7 ata problem with VIA 8235
Hi! Next test with the current beta: We have a system with a VIA chipset based mainboard, the ATA controller is reported to be a VIA 8235. This system has worked just fine with 5.1 then stopped working when the atang changes were commited. It wasn't that important to us (it's really cheap [tm] hardware), but since I'm doing some tests with the current beta anyway and there were various ata fixes announced: Boot from miniinst.iso: ... atapci0: port 0xdc00-0xdc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at deviec 17.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 ... ata0-master: FAILURE - ATA_IDENTTIFY timed out ... ata1-master: FAILURE - ATAPI_IDENTIFY timed out ... With most systems I tried before (5.2.1-RELEASE, previous 5.3-BETAs) the system just hung without a clear error message after loading md0. Any ideas? Thanks, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Packet passing performance study on exotic hardware.
The opportunity presented itelf for me to test packet passing ability on some fairly exotic hardware. The motherboard I really wanted to test not only had separate memory busses for each cpu, but also had two separate PCI-X busses (one slot each). To this, I added two intel pro/1000 gigabit ethernet cards (PCI-X versions). I had two sets of processors to test: two 246's and two 240's. The packets in this test are all minimal 64 byte UDP packets. My first goal was to determine the DDOS stability of FreeBSD 5.3, and Linux on this hardware. I was using amd64 binaries for both FreeBSD and linux. Right out of the box (with polling), Linux passed 550 kpps (kilo packets wer second). Full data rate would be 1.9 mpps. On linux, the 240 processors passed only 450 kppps (which is somewhat expected). Right out of the box, FreeBSD 5.3 (with polling) passed about 200 kpps. net.isr.enable=1 increased that without polling to about 220 kpps (although livelock ensued without polling as packet load increased). With excessive tuning, we got FreeBSD 5.3 to pass 270 kpps. This included polling, nmbclusters, net.isr, and some em patches. I can't see where to get more performance. To compare, we loaded FreeBSD-5.3 ia32 and achieved almost identical performance. Then, also to compare, we loaded FreeBSD-4.10 ia32 and it promptly passed 550 kpps (almost identical to the linux performance) (with polling). Some interesting things about 5.3(-BETA4) in this environment: - without polling, it definately livelocks. - with polling and excessive packets, it doesn't "receive" the full load of packets. In netstat -w, they show as input "errors" although the number of "errors" isn't strictly related to the number of dropped packets. It's just some large number that generally increases with the number of dropped packets. - With net.isr and not polling, both cpus are used (220 kpps) - With net.isr and polling, one cpu is used (270 kpps, one cpu free for other tasks) - It's worth noting that only FreeBSD 5.3 used two cpus to pass packets at any time. Neither linux nor 4.10 used the other cpu. - hz and polling tuning options didn't really change packets passed significantly. During the next week, I will continue testing with full simulated routing tables, random packets and packets between 350 and 550 bytes (average ISP out/in packet sizes). I will add to this report then. If anyone has tuning advice for FreeBSD 5.3, I'd like to hear it. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet passing performance study on exotic hardware.
David Gilbert wrote: The opportunity presented itelf for me to test packet passing ability on some fairly exotic hardware. The motherboard I really wanted to test not only had separate memory busses for each cpu, but also had two separate PCI-X busses (one slot each). To this, I added two intel pro/1000 gigabit ethernet cards (PCI-X versions). I had two sets of processors to test: two 246's and two 240's. The packets in this test are all minimal 64 byte UDP packets. My first goal was to determine the DDOS stability of FreeBSD 5.3, and Linux on this hardware. I was using amd64 binaries for both FreeBSD and linux. Right out of the box (with polling), Linux passed 550 kpps (kilo packets wer second). Full data rate would be 1.9 mpps. On linux, the 240 processors passed only 450 kppps (which is somewhat expected). Right out of the box, FreeBSD 5.3 (with polling) passed about 200 kpps. net.isr.enable=1 increased that without polling to about 220 kpps (although livelock ensued without polling as packet load increased). With excessive tuning, we got FreeBSD 5.3 to pass 270 kpps. This included polling, nmbclusters, net.isr, and some em patches. I can't see where to get more performance. To compare, we loaded FreeBSD-5.3 ia32 and achieved almost identical performance. Then, also to compare, we loaded FreeBSD-4.10 ia32 and it promptly passed 550 kpps (almost identical to the linux performance) (with polling). Some interesting things about 5.3(-BETA4) in this environment: - without polling, it definately livelocks. - with polling and excessive packets, it doesn't "receive" the full load of packets. In netstat -w, they show as input "errors" although the number of "errors" isn't strictly related to the number of dropped packets. It's just some large number that generally increases with the number of dropped packets. - With net.isr and not polling, both cpus are used (220 kpps) - With net.isr and polling, one cpu is used (270 kpps, one cpu free for other tasks) - It's worth noting that only FreeBSD 5.3 used two cpus to pass packets at any time. Neither linux nor 4.10 used the other cpu. - hz and polling tuning options didn't really change packets passed significantly. During the next week, I will continue testing with full simulated routing tables, random packets and packets between 350 and 550 bytes (average ISP out/in packet sizes). I will add to this report then. If anyone has tuning advice for FreeBSD 5.3, I'd like to hear it. Dave. Interesting results. One thing to note is that a severe bug in the if_em driver was fixed for BETA7. The symptoms of this bug include apparent livelock of the machine during heavy xmit load. You might want to update and re-run your tests. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet passing performance study on exotic hardware.
> "Scott" == Scott Long <[EMAIL PROTECTED]> writes: Scott> Interesting results. One thing to note is that a severe bug in Scott> the if_em driver was fixed for BETA7. The symptoms of this bug Scott> include apparent livelock of the machine during heavy xmit Scott> load. You might want to update and re-run your tests. Sorry. I should have made it clear that I applied the patches to the em from the tree by hand. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet passing performance study on exotic hardware.
David Gilbert wrote: The opportunity presented itelf for me to test packet passing ability on some fairly exotic hardware. The motherboard I really wanted to test not only had separate memory busses for each cpu, but also had two separate PCI-X busses (one slot each). To this, I added two intel pro/1000 gigabit ethernet cards (PCI-X versions). I had two sets of processors to test: two 246's and two 240's. The packets in this test are all minimal 64 byte UDP packets. My first goal was to determine the DDOS stability of FreeBSD 5.3, and Linux on this hardware. I was using amd64 binaries for both FreeBSD and linux. Right out of the box (with polling), Linux passed 550 kpps (kilo packets wer second). Full data rate would be 1.9 mpps. On linux, the 240 processors passed only 450 kppps (which is somewhat expected). Right out of the box, FreeBSD 5.3 (with polling) passed about 200 kpps. net.isr.enable=1 increased that without polling to about 220 kpps (although livelock ensued without polling as packet load increased). With excessive tuning, we got FreeBSD 5.3 to pass 270 kpps. This included polling, nmbclusters, net.isr, and some em patches. I can't see where to get more performance. To compare, we loaded FreeBSD-5.3 ia32 and achieved almost identical performance. Then, also to compare, we loaded FreeBSD-4.10 ia32 and it promptly passed 550 kpps (almost identical to the linux performance) (with polling). Some interesting things about 5.3(-BETA4) in this environment: - without polling, it definately livelocks. - with polling and excessive packets, it doesn't "receive" the full load of packets. In netstat -w, they show as input "errors" although the number of "errors" isn't strictly related to the number of dropped packets. It's just some large number that generally increases with the number of dropped packets. Have you used "sysctl hw.em0.stats=1" and/or "sysctl hw.em1.stats=1" before and after running the test to obtain snapshots of the detailed error statistics (they're logged by the kernel to /var/log/messages)? Perhaps those would be enlightening. The fixed bug in the em driver for BETA7 may significantly help (see Scott Long's response prior to mine). If you try BETA7 without polling but with SMP, do you get better results if you increase hw.em0.rx_int_delay and hw.em1.rx_int_delay above 0? Have you set sysctls kern.random.sys.harvest.ethernet=0 and kern.random.sys.harvest.interrupt=0? I don't know if it will have any effect in your situation, but have you increased net.inet.ip.intr_queue_maxlen? Hope this helps, Guy -- Guy Helmer, Ph.D., Principal System Architect, Palisade Systems, Inc. [EMAIL PROTECTED] http://www.palisadesys.com/~ghelmer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet passing performance study on exotic hardware.
David Gilbert wrote: During the next week, I will continue testing with full simulated routing tables, random packets and packets between 350 and 550 bytes (average ISP out/in packet sizes). I will add to this report then. If anyone has tuning advice for FreeBSD 5.3, I'd like to hear it. Three things: sysctl net.inet.ip.fastforwarding=1 Don't use SMP for packet forwarding. It doesn't help anything and introduces only locking overhead. Upgrade to the latest RELENG_5, there are a couple of fixes for things that may hurt you here. Especially there is a fix for the transmit queues on the em() driver. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Vinum problems in 5.3-BETA7?
On Fri, 2004-10-08 at 07:52, Patrick M. Hausen wrote: > We have a production system that runs on a vinum system drive > configured like this: [[Configuration omitted.]] > It's currently running fine with FreeBSD 5.2.1-RELEASE-p10. > > After upgrading to 5.3-BETA7, buildworld, buildkernel, installkernel > and reboot the system stops: > > vinum: loaded > vinum: no drives found > > That's it. Of course it complains that it can't mount /dev/vinum/root. > > The list of detected GEOM devices at the "mountroot> " prompt > includes ad0s1h, ad1s1h, ad0s1, ad1s1, ad0, ad1 and some more > partitions. > > > Where do I go from here? Is this expected behaviour due to the ongoing > GEOM changes or should I go read Greg's "how to debug vinum problems" > document? I will do that, no problem. Just want to know if it makes > sense at all, because now everyone might tell me "vinum is known broken in > 5.3" or similar. Vinum is known broken in 5.3. :-) You should be using geom_vinum instead. It will largely be a drop-in replacement for your above Vinum configuration. (I am using it on a similar root-on-vinum setup.) The main changes are these: 1) Load "geom_vinum" in /boot/loader.conf, e.g., add 'geom_vinum_load="YES"' to /boot/loader.conf. This will auto-detect your Vinum on-disk configuration during boot. You don't need any rc.conf glue with geom_vinum. 2) Change "vinum" to "gvinum" in /etc/fstab. E.g., use "/dev/gvinum/root" instead of "/dev/vinum/root" 3) The userland utility is "gvinum" instead of "vinum". I am using geom_vinum on a root-on-vinum configuration under 6-CURRENT since before RELENG_5 was branched, and I believe the same holds true for RELENG_5 and HEAD as far as the above three points are concerned. I don't know if there are plans to replace vinum entirely with gvinum (and drop the "g" prefix) for 5.3-RELEASE. Lukas Ertl would know. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet passing performance study on exotic hardware.
At 10:08 AM 08/10/2004, David Gilbert wrote: Right out of the box, FreeBSD 5.3 (with polling) passed about 200 kpps. net.isr.enable=1 increased that without polling to about 220 Did you have kern.polling.idle_poll at 0 or 1 ? In my tests a few weeks ago this seemed to make a difference, but the load avg gets messed up. Also, HZ does seem to make a difference at least in my tests on BETA5. ---Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Vinum problems in 5.3-BETA7?
Paul Mather wrote: > Vinum is known broken in 5.3. :-) You should be using geom_vinum > instead. It will largely be a drop-in replacement for your above Vinum > configuration. (I am using it on a similar root-on-vinum setup.) The > main changes are these: What I need to know is whether the raid5 support in gvinum is solid, yet. I would dearly love to move my desktop system from 4-stable to RELENG_5, but I have two rather large vinum raid5 filesystems that I really need to keep. Is anyone actually using raid5 with gvinum on RELENG_5? If so, how stable is it? (The last I heard, there were still potential data corruption problems, but I'm hoping that those have been fixed by now.) -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Packet passing performance study on exotic hardware.
David Gilbert wrote: > Right out of the box, FreeBSD 5.3 (with polling) passed about 200 > kpps. Was this with debug.mpsafenet enabled and all debugging (WITNESS and such) turned off? /Daniel Eriksson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet passing performance study on exotic hardware.
> "Guy" == Guy Helmer <[EMAIL PROTECTED]> writes: Guy> The fixed bug in the em driver for BETA7 may significantly help Guy> (see Scott Long's response prior to mine). As I replied, I hand-applied these patches. They reduced live lock (or what my tech calls "chunkyness" --- almost live lock), but they didn't increase performance. Guy> If you try BETA7 without polling but with SMP, do you get better Guy> results if you increase hw.em0.rx_int_delay and Guy> hw.em1.rx_int_delay above 0? These had little effect. tx_int_delay had some small effect. rx_int_delay didn't seem to affect things ... or was slightly negative in effect above 0. Tried various values as high as 1000 for these parameters. Tried values like 1,2,5,10,25,64, etc. No substantial effect. Guy> Have you set sysctls kern.random.sys.harvest.ethernet=0 and Guy> kern.random.sys.harvest.interrupt=0? I did not. We will try those next week. Guy> I don't know if it will have any effect in your situation, but Guy> have you increased net.inet.ip.intr_queue_maxlen? No. We did increase a number of queues. According to the net.isr code, almost no packets were being queued. I gather this means they're being delivered to destination by the thread that picks them up. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet passing performance study on exotic hardware.
> "Mike" == Mike Tancsa <[EMAIL PROTECTED]> writes: Mike> At 10:08 AM 08/10/2004, David Gilbert wrote: >> Right out of the box, FreeBSD 5.3 (with polling) passed about 200 >> kpps. net.isr.enable=1 increased that without polling to about 220 Mike> Did you have kern.polling.idle_poll at 0 or 1 ? In my tests a Mike> few weeks ago this seemed to make a difference, but the load avg Mike> gets messed up. Also, HZ does seem to make a difference at Mike> least in my tests on BETA5. I can confirm the HZ not making a sizable difference (although I believe it cuts polling latency under ligher load, so we used 1 by default and we tested 1000). Idle_poll is default 1, I'm not positive we tested 0. I don't think there is much idle time here. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Packet passing performance study on exotic hardware.
> "Daniel" == Daniel Eriksson <[EMAIL PROTECTED]> writes: Daniel> David Gilbert wrote: >> Right out of the box, FreeBSD 5.3 (with polling) passed about 200 >> kpps. Daniel> Was this with debug.mpsafenet enabled and all debugging Daniel> (WITNESS and such) turned off? mpsafenet on and all witness and other junk off. I b elieve this to be default in BETA4 anyways, but I remember reading about mpsafenet and checking it. I'm positive that WITNESS is off as are INVARIANTS. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
vnode_pager_putpages errors and DOS?
Howdy! FreeBSD 4-10 I have some machines that run customers cgi stuff. These machines have started to hang and become unresponsive. At first I thought it was a hardware issue, but I discovered in a cyclades log the following stuff that got logged to the console which explains the cause of the system hangs/failures. vnode_pager_putpages: residual I/O 65536 at 347 vnode_pager_putpages: I/O error 28] vnode_pager_putpages: residual I/O 65536 at 285] Zillions of them. The only way to recover the machine is to power cycle it. From what I can tell from google etc.. and someone elses experience it is probably the consequence of someone filling up /var/tmp or something. Should a non root user program be able to DOS a machine like this? or What is the cause and/or fix for this? thanx - steve "The age of the Internet has a right to its own music." http://www.linuxsuite.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet passing performance study on exotic hardware.
David Gilbert wrote: "Scott" == Scott Long <[EMAIL PROTECTED]> writes: Scott> Interesting results. One thing to note is that a severe bug in Scott> the if_em driver was fixed for BETA7. The symptoms of this bug Scott> include apparent livelock of the machine during heavy xmit Scott> load. You might want to update and re-run your tests. Sorry. I should have made it clear that I applied the patches to the em from the tree by hand. there are also changes in B4->B7 that ar related to scheduling the packet delivery mechanisms.. They may not make much of a difference but... It's good that we are finally getting the functionality to a point where we can start to worry about performance again :-) Dave. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet passing performance study on exotic hardware.
At 12:18 PM 08/10/2004, David Gilbert wrote: Idle_poll is default 1, I'm not positive we tested 0. I don't think there is much idle time here. Actually, on RELENG_5, I think the default is now zero. With a releng_5 BETA7 box in between 2 other hosts, with idle_poll set to the default on zero, using /usr/local/netperf/netperf -l 30 -H 10.10.10.1 -i 10,2 -I 99,10 -t UDP_STREAM -- -m 1000 -s 32768 32768 I see about 483Mb. If I set it to 1, I get just over 500Mb. This was with an HZ of 1000 ---Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet passing performance study on exotic hardware.
> "Julian" == Julian Elischer <[EMAIL PROTECTED]> writes: Julian> David Gilbert wrote: Julian> there are also changes in B4->B7 that ar related to scheduling Julian> the packet delivery mechanisms.. They may not make much of a Julian> difference but... I will endevour to do cvsup and retest, then. BTW, is there a kernel profiling howto out there? Or would someone like to help with it? Before the hardware goes into production, I'd like to siphon out as much data as possible. Julian> It's good that we are finally getting the functionality to a Julian> point where we can start to worry about performance again :-) Amen. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet passing performance study on exotic hardware.
> "Mike" == Mike Tancsa <[EMAIL PROTECTED]> writes: Mike> At 12:18 PM 08/10/2004, David Gilbert wrote: >> Idle_poll is default 1, I'm not positive we tested 0. I don't >> think there is much idle time here. Mike> Actually, on RELENG_5, I think the default is now zero. checked, tho. We did set it to 1 in sysctl.conf. Mike> With a releng_5 BETA7 box in between 2 other hosts, with Mike> idle_poll set to the default on zero, using Mike> /usr/local/netperf/netperf -l 30 -H 10.10.10.1 -i 10,2 -I 99,10 Mike> -t UDP_STREAM -- -m 1000 -s 32768 32768 Mike> I see about 483Mb. If I set it to 1, Mike> I get just over 500Mb. This was with an HZ of 1000 This is well below the doubling I want to see, but I will add this to the test suite. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3-BETA7 ata problem with VIA 8235
[ current@ cc'ed, as is still the best place for 5.x ] On Fri, 8 Oct 2004 14:17:13 +0200 (CEST) "Patrick M. Hausen" <[EMAIL PROTECTED]> wrote: > Hi! > > Next test with the current beta: > > We have a system with a VIA chipset based mainboard, the ATA > controller is reported to be a VIA 8235. > This system has worked just fine with 5.1 then stopped working when > the atang changes were commited. It wasn't that important to us > (it's really cheap [tm] hardware), but since I'm doing some tests > with the current beta anyway and there were various ata fixes > announced: > > Boot from miniinst.iso: > > ... > atapci0: port > 0xdc00-0xdc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at deviec 17.1 on pci0 > ata0: channel #0 on atapci0 > ata1: channel #1 on atapci0 > ... > ata0-master: FAILURE - ATA_IDENTTIFY timed out > ... > ata1-master: FAILURE - ATAPI_IDENTIFY timed out > ... atapci0: port 0xe000-0xe00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 17.1 on pci0 + WDC WD1600JB-00EVA0/15.05R15 works; So please post also HDD vendor, model, firmware -- IOnut Unregistered ;) FreeBSD "user" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vnode_pager_putpages errors and DOS?
On Thu, Jan 01, 1970 at 12:00:00AM +, Steve Shorter wrote: > Howdy! > > FreeBSD 4-10 > > I have some machines that run customers cgi stuff. > These machines have started to hang and become unresponsive. > At first I thought it was a hardware issue, but I discovered in > a cyclades log the following stuff that got logged to the > console which explains the cause of the system hangs/failures. > > vnode_pager_putpages: residual I/O 65536 at 347 > vnode_pager_putpages: I/O error 28] > vnode_pager_putpages: residual I/O 65536 at 285] Aha! also at the same time I get in syslog /kernel: pid 6 (syncer), uid 0 on /chroot/tmp: file system full Whats happening? Can a full filesystem bring the thing down? Ideas? Fixes? thanx - steve > > Zillions of them. > > The only way to recover the machine is to power cycle > it. > > From what I can tell from google etc.. and someone elses > experience it is probably the consequence of someone filling > up /var/tmp or something. > > Should a non root user program be able to DOS > a machine like this? or What is the cause and/or fix for this? > > > thanx - steve > > > > > > > "The age of the Internet has a right to its own music." > > http://www.linuxsuite.org > > - End forwarded message - > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Promise TX2 SATA controllers
Jean-Francois Dockes writes: | Just in case it may help someone (this information is not very easily | accessible in the archives): | | - I have a Promise TX2 controller with a PCI ID of 0x3375105a . It works |for me in 4.10 by adding the new PCI ID everywhere that you'll find the |other/old one (0x3371105a) in the patch (see next paragraph) or kernel |source under dev/ata. Don't blame me if you lose your data, I will not |take responsibility, but this is weakly supported by the the two |controllers appearing to be handled just the same in -current. I added it to my local tree and it be in the next patch set. I need to add soft error recovery (ie. if one drive has a read error automatically recovery from the other drive) and a little more graceful addition of a failed drive back into the RAID. I also fixed a raid bug in ar_rw which could lead to a panic on on I/O error. Thanks, Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cp -Rp broken in RELENG_4? 'Operation not permitted' while copying directory permissions
On Thu, Oct 07, 2004 at 09:49:45PM +0300, Ruslan Ermilov wrote: > On Thu, Oct 07, 2004 at 12:38:42PM -0400, Vlad wrote: > > FreeBSD 4.10-STABLE #3: Thu Sep 30 > > > > $ id > > uid=65534(nobody) gid=65534(nobody) groups=65534(nobody) > > > > $ mkdir test > > > > $ chmod 770 test > > > > $ cp -Rp test test2 > > cp: chmod: test2: Operation not permitted > > > > $ ls -al > > drwxrwx--- 2 nobody nobody 512 Oct 7 11:29 test > > drwxr-x--- 2 nobody nobody 512 Oct 7 11:29 test2 > > > > $ chmod 770 test2 > > > > $ ls -al > > drwxrwx--- 2 nobody nobody 512 Oct 7 11:29 test > > drwxrwx--- 2 nobody nobody512 Oct 7 11:29 test2 > > > > cp taken from 4.9 works just fine. Am I'm missing something? > > > Give me a few hours to fix it, it's probably my fault. > Fixed in src/bin/cp/cp.c,v 1.24.2.8. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpwTBirRO1Fu.pgp Description: PGP signature
freebsd upgrade
hi there, i've got my system reinstalled today with freebsd 4.9-release. i installed cvsup-without-gui by ports, typed cvsup stable.sup, waited for that finish, cd /usr/src and make buildworld. and then BOOM! it drop. whats the big deal? i'm tired doing this on MANY others servers, at home, on others data-centers without any problem. (stable.sup file) # #cvsup stable-supfile *default tag=. *default host=cvsup2.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs tag=RELENG_4 *default delete use-rel-suffix *default compress src-all (end stable.sup file) here goes the log from my "make buildworld" [EMAIL PROTECTED] /usr/src]# make buildworld -- >>> Rebuilding the temporary build tree -- rm -rf /usr/obj/usr/src/i386 mkdir -p /usr/obj/usr/src/i386/usr/bin mkdir -p /usr/obj/usr/src/i386/usr/lib/compat/aout mkdir -p /usr/obj/usr/src/i386/usr/games mkdir -p /usr/obj/usr/src/i386/usr/libdata/ldscripts mkdir -p /usr/obj/usr/src/i386/usr/libexec/elf mkdir -p /usr/obj/usr/src/i386/usr/sbin mkdir -p /usr/obj/usr/src/i386/usr/share/misc mkdir -p /usr/obj/usr/src/i386/usr/share/dict mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devX100 mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devX100-12 mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devX75 mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devX75-12 mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devascii mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devcp1047 mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devdvi mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devhtml mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devkoi8-r mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devlatin1 mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devlbp mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devlj4 mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devps mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devutf8 mkdir -p /usr/obj/usr/src/i386/usr/share/tmac/mdoc mkdir -p /usr/obj/usr/src/i386/usr/share/tmac/mm mkdir -p /usr/obj/usr/src/i386/usr/include/arpa mkdir -p /usr/obj/usr/src/i386/usr/include/dev mkdir -p /usr/obj/usr/src/i386/usr/include/fs mkdir -p /usr/obj/usr/src/i386/usr/include/g++/std mkdir -p /usr/obj/usr/src/i386/usr/include/isc mkdir -p /usr/obj/usr/src/i386/usr/include/isofs mkdir -p /usr/obj/usr/src/i386/usr/include/libmilter mkdir -p /usr/obj/usr/src/i386/usr/include/objc mkdir -p /usr/obj/usr/src/i386/usr/include/openssl mkdir -p /usr/obj/usr/src/i386/usr/include/protocols mkdir -p /usr/obj/usr/src/i386/usr/include/readline mkdir -p /usr/obj/usr/src/i386/usr/include/rpc mkdir -p /usr/obj/usr/src/i386/usr/include/rpcsvc mkdir -p /usr/obj/usr/src/i386/usr/include/security mkdir -p /usr/obj/usr/src/i386/usr/include/ufs ln -sf /usr/src/sys /usr/obj/usr/src/i386 -- >>> stage 1: bootstrap tools -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/i386 DESTDIR= INSTALL="sh /usr/src/tools/install.sh" make -f Makefile.inc1 -DBOOTSTRAPPING -DNOHTML -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -DNO_WERROR bootstrap-tools echo "===> games/fortune/strfile"; cd /usr/src/games/fortune/strfile; make DIRPRFX=games/fortune/strfile/ obj; make DIRPRFX=games/fortune/strfile/ depend; make DIRPRFX=games/fortune/strfile/ all; make DIRPRFX=games/fortune/strfile/ DESTDIR=/usr/obj/usr/src/i386 install ===> games/fortune/strfile /usr/obj/usr/src/i386/usr/src/games/fortune/strfile created for /usr/src/games/fortune/strfile rm -f .depend mkdep -f .depend -a -D__FBSDID=__RCSID /usr/src/games/fortune/strfile/strfile.c echo strfile: /usr/lib/libc.a >> .depend cc -O -pipe -Wall -D__FBSDID=__RCSID -c /usr/src/games/fortune/strfile/strfile.c cc -O -pipe -Wall -D__FBSDID=__RCSID -static -o strfile strfile.o sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 strfile /usr/obj/usr/src/i386/usr/games echo "===> usr.bin/yacc"; cd /usr/src/usr.bin/yacc; make DIRPRFX=usr.bin/yacc/ obj; make DIRPRFX=usr.bin/yacc/ depend; make DIRPRFX=usr.bin/yacc/ all; make DIRPRFX=usr.bin/yacc/ DESTDIR=/usr/obj/usr/src/i386 install ===> usr.bin/yacc /usr/obj/usr/src/i386/usr/src/usr.bin/yacc created for /usr/src/usr.bin/yacc rm -f .depend mkdep -f .depend -a -D__FBSDID=__RCSID /usr/src/usr.bin/yacc/closure.c /usr/src/usr.bin/yacc/error.c /usr/src/usr.bin/yacc/lalr.c /usr/src/usr.bin/yacc/lr0.c /usr/src/usr.bin/yacc/main.c /usr/src/usr.bin/yacc/mkpar.c /usr/src/usr.bin/yacc/output.c /usr/src/usr.bin/yacc/reader.c /usr/src/usr.bin/yacc/skeleton.c /usr/src/usr.bin/yacc/symtab.c /usr/src/usr.bin/yacc/verbose.c /usr/src/usr.bin/yacc/warshall.c echo yacc: /usr/lib/libc.a >> .depend cc -O -pipe -D__FBSDID=__RCSID -c /usr/src/usr.bin/yacc/closure.c cc -O -pipe -D__FBSDID=
