Re: atkbd: changing flags at boot time
from /boot/loader.conf: userconfig_script_load=YES from /boot/kernel.conf: flags atkbd0 0 quit That works, many thanks! (I haven't used FreeBSD 4 for a while, but the place I'm currently working hasn't yet decided to move to 5 or 6...) Regards, Brian. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Jails that won't die...
Hi, I have, since upgrading to 5.x and updating my management tools, seen a number of problems relating to stopping jails. I'm maintaining several hosts with a number of full-featured jails (i.e. full virtual FreeBSD installations in each jail), and in general this works fine. However, whenever I stop a jail using 'jexec id kill -SIGNAL -1' or 'jexec id /bin/sh /etc/rc.shutdown' (in various combinations), jails have a tendency to stick around for minutes or hours - according to 'jls'. Often I see an entry in 'netstat -a' indicating that there is one or more sockets in FIN_WAIT state, preventing the jail from coming down. Taking the virtual network interface (alias) down does not help. All I can do at this point is wait. I normally use 'jls' to determine whether or not a jail can be restarted (i.e. it's not running), but this is pretty useless in such cases. And right now I have a case where 'netstat -a' shows me nothing pertaining to the jail, though it has no processes running. I have therefore force-started the jail again, which seems to work nicely, but now 'jls' gives me two entries for this jail, with different JIDs. What am I doing wrong here? /Eirik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD -STABLE servers repeatedly crashing.
On Mon, Jun 27, 2005 at 07:58:18PM -0400, Matt Juszczak wrote: M Can you please build kernel with debugging and obtain a crashdump? M M High activity on the box today caused us to be able to crash it again M within 9 hours. I configured all steps per the developers handbook, but M when I went to do savecore, it said no dumps. M M It appears the machine is completely locked up when it does a kernel trap. M The keyboard is non-responsive, and the machine hangs and doesn't reboot. Please try out this patch to aid the above problem with hang instead of dump: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/i386/trap.c.diff?r1=1.275r2=1.276 -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
# [EMAIL PROTECTED] / 2005-06-21 16:51:10 +0200: For accurate measurements and comparisons, you have to make sure to use _exactly_ the same physical location on the disk. No you don't. You want to make a side-by-side comparison of two products, and if one of them underperforms, it just underperforms. You cannot use a poor location selection strategy in the driver as an excuse for poor operation. In all honesty, I'm getting somewhat irritated by all the dd is meaningless performance measurement tool, use something real and similar arguments: dd is a real command for real work, and if it shows abysmal performance of sequential writes, then there's a problem. But then again -- as others have already mentioned, serial write speed is not the most important factor for database performance (although the WAL journal files of advanced transactional databases like PostgreSQL are written in a sequential way), so the usefulness of this benchmark is very debatable. Well, how about a few GB large table physically ordered (clustered) on a column, that goes through repeated sequential scans? This *is* a real-world situation, and every bit of speed counts (the live server I'm talking about has the database on SCSI disks, but development machines frequently differ). -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
On recent crashes
Hello! Can anyone enlighten me, if recent crashes are on STABLE only or 5.4-RELEASE is affected as well? I'm going to upgrade SMP Intel box (PIIIs) and it can make hard time if it will become unstable. -- Alex Povolotsky [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Tue, 28 Jun 2005 18:51, Roman Neuhauser wrote: No you don't. You want to make a side-by-side comparison of two products, and if one of them underperforms, it just underperforms. You cannot use a poor location selection strategy in the driver as an excuse for poor operation. Why not? It's not a side-by-side comparison if the underlying hardware is different.. I don't think ascribing ALL the poor performance to being on the wrong part of the disk is putting your head in the sand, but it DOES make a difference. In all honesty, I'm getting somewhat irritated by all the dd is meaningless performance measurement tool, use something real and similar arguments: dd is a real command for real work, and if it shows abysmal performance of sequential writes, then there's a problem. dd is a useful start, but you shouldn't read too much into the results since, in general, dd doesn't reflect real world usage patterns. There are some people who seem to want to ignore the results and shoot them down with bland assertions about how poorly the tests have been run. There are also people doing crappy tests, however there IS a middle ground where I think most reasonable people are sitting - they want decent tests, and have a good attitude to fixing the problems. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp44ZGHL3pRO.pgp Description: PGP signature
Re: On recent crashes
Alex Povolotsky wrote: Hello! Can anyone enlighten me, if recent crashes are on STABLE only or 5.4-RELEASE is affected as well? What crashes? ;) I'm going to upgrade SMP Intel box (PIIIs) and it can make hard time if it will become unstable. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: On recent crashes
Alex Povolotsky wrote: Hello! Can anyone enlighten me, if recent crashes are on STABLE only or 5.4-RELEASE is affected as well? I'm going to upgrade SMP Intel box (PIIIs) and it can make hard time if it will become unstable. I have Dual PIII on Intel ServerWorks motherboard with 3Ware 8608 SATA RAID-5 setup and all works fine except not so good RAID-5 performance on _very_ large Courier-IMAP folders, but I have moved these archive folders to SCSI harddisks and all fine now. So, what crashes? :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
# [EMAIL PROTECTED] / 2005-06-28 19:04:18 +0930: On Tue, 28 Jun 2005 18:51, Roman Neuhauser wrote: No you don't. You want to make a side-by-side comparison of two products, and if one of them underperforms, it just underperforms. You cannot use a poor location selection strategy in the driver as an excuse for poor operation. dd is a useful start, but you shouldn't read too much into the results since, in general, dd doesn't reflect real world usage patterns. Huh? Various people have reacted to the dd doesn't reflect real world with but I *do* use dd in real world. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portinstall .vs. make install clean
# [EMAIL PROTECTED] / 2005-06-26 19:29:27 +0100: On Sunday 26 June 2005 19:12, Maher Mohamed wrote: can some tell me what is the difference bitween portinstall and make install clean, and in which way should one portupgrade its ports? portinstall is a ruby program which comes with portupgrade which you can use to build and install ports. It can do some things which you can't do with a simple 'make install'. For example, I often use portinstall to create packages for a port and its dependancies. As in (make package-recursive)? That's not to say that portinstall isn't useful, I use it most of the time, FWIW. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Roman Neuhauser wrote: In all honesty, I'm getting somewhat irritated by all the dd is meaningless performance measurement tool, use something real and similar arguments: dd is a real command for real work, and if it shows abysmal performance of sequential writes, then there's a problem. There _is_ something strange with dd as sequential block reads with bonnie (and vfs.read_max=16) is faster than reading direct from the device with dd! RAID0 7*36GB Maxtor 10K4, MegaRAID 320-2E default newfs ---Sequential Output ---Sequential Input-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- 5.4 2048 106839 84.7 115268 32.1 30204 9.0 78264 80.2 136833 21.5 5.4v2048 105996 84.4 114560 32.2 29208 8.8 81671 84.7 227416 39.4 v = vfs.read_max=16 I don't have exact numbers at hand but dd if=/dev/amrd0 of=/dev/null bs=1024k count=1024 gave about ~120MB/s not anywhere near 227MB! /Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Tue, 28 Jun 2005 20:43, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-28 19:04:18 +0930: On Tue, 28 Jun 2005 18:51, Roman Neuhauser wrote: No you don't. You want to make a side-by-side comparison of two products, and if one of them underperforms, it just underperforms. You cannot use a poor location selection strategy in the driver as an excuse for poor operation. dd is a useful start, but you shouldn't read too much into the results since, in general, dd doesn't reflect real world usage patterns. Huh? Various people have reacted to the dd doesn't reflect real world with but I *do* use dd in real world. Read what I said.. ... IN GENERAL ... -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpNXPS8a6siL.pgp Description: PGP signature
Re: FreeBSD MySQL still WAY slower than Linux
Hi, i wouldn't start a principal discussion, but i have too? I have one Machine! and on this machine with identical Hardware, identical real! not same not side by side, real the same disk, processor, ram, board.. -- read my other postings, it's recommendet. on this machine i have made 4 installations on same disk, of 4 types/Versions of Os'es 1: RELENG_4 2: RELENG_5 3: Drangonfly_REL_1.2 4: GENTOO_2005_02 The disk was alway same partitioning: first 1G for Swap rest for system then i login in the system and made: # cd /; /usr/bin/time dd if=/dev/zero bs=1024 count=1024k of=zerofile; rm zerofile then i install the next system from a dump on same disk so that i can compare the time-consumption on these 4 systems. i think dd ist not the best for performace-tests or something else, but dd is a handy tool for quick test what's going on with your system write/read-speedness. so other people have suggested me that dd was not everytime writes to the same parts of diske, while the underlying fs-drivers made other steps on other systems ( and other fs-types) I would only compare the performace from 2 Versions of FreeBSD, while i mean that the performance from RELENG_5 is more slower than under GENTOO and it is double as slow as under RELENG_4. i would not test the performance of my system, i would only compare. best regards michael 2005/6/28, Daniel O'Connor [EMAIL PROTECTED]: On Tue, 28 Jun 2005 20:43, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-28 19:04:18 +0930: On Tue, 28 Jun 2005 18:51, Roman Neuhauser wrote: No you don't. You want to make a side-by-side comparison of two products, and if one of them underperforms, it just underperforms. You cannot use a poor location selection strategy in the driver as an excuse for poor operation. dd is a useful start, but you shouldn't read too much into the results since, in general, dd doesn't reflect real world usage patterns. Huh? Various people have reacted to the dd doesn't reflect real world with but I *do* use dd in real world. Read what I said.. ... IN GENERAL ... -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Data corruption in cd9660 on FreeBSD 4.11?
I haven't finished all the suggested tests, but since I'm taking so long to do so, I thought I should send what I have so far. On Saturday, 25th June 2005, Peter Jeremy wrote: On Fri, 2005-Jun-24 22:31:06 +1000, Stephen McKay wrote: I'm experiencing data corruption when reading CDs and DVDs on FreeBSD 4.11. ... So, can anyone suggest any more tests I could try? Or is there a kind of hardware fault that could cause this substitution of whole blocks read from CDs without causing any other problems? You might like to post the relevant sections of a verbose boot - the ATA and CD probes. I've appended it to this messages, so that the flow is not ruined. Note that I am not currently using ATAPI-CAM for my tests. I am using /dev/acd0a and /dev/acd1a to mount the CDs in the DVD-ROM and DVD-R respectively. Also the non-ATA66 cable thing is true; it is a plain ATA33 cable. Are you running the CD/DVD drives in PIO or UDMA modes? I normally run both DVD drives at UDMA33. My test runs normally fail every 2nd or 3rd run. I've seen it do 5 OK runs in a row once though, so I don't yet have a very good test. I tested with PIO4 and ran 12 consecutive test runs without error. It was a little slower at 150 seconds per run instead of the normal 135, possibly because 75% to 80% of the cpu was dedicated to interrupt handling (doing pio, I assume). It seems that either DMA or ATA interrupts (or maybe both) are required to cause the problem. Also, I tried some tests with the noclusterr mount option on the CD. The test ran much slower (approx 232 seconds instead of 135) but I also saw no failures (with only 6 test runs though as I was pressed for time). The noclusterr option is interesting because it defeats read clustering resulting in the ATA driver issuing only 2K reads instead of up to 64K at a time. I assume that the 64K reads would require scatter-gather DMA, so maybe this is relevant to the problem. Oddly, I noticed that a fixed value of 65534 is found in atapi-all.c as a request size limit. No, not 65536 = 2^16, but 2 bytes less. Puzzling. Have you tried anything other than ISO9660 filesystems on a physical CD? I have not tried anything but cd9660 file systems on CDs and DVDs. I will see if I can build a UFS file system to test with, when I get a chance. What happens if you just dd the CD-ROM? When I dd the CD-ROM it seems to work correctly. I have done this only infrequently however, so I may just be lucky to not have had a failure. I've now done 6 consecutive dd reads of my test CD-ROM in UDMA33 mode with no errors. It only takes 125 seconds, so it's a bit faster than comparing directory trees. Only 6 tests isn't many, so I'll do more later, this time with other system activity. What happens if you use a vnode mount (see vnconfig(8)) of an ISO filesystem sitting in a UFS filesystem? I'll test this when I get a chance. Anything unusual in your kernel config file? Nothing too unusual. I'm running a uni-processor kernel with HTT disabled. I skimmed through my config and this is the only interesting thing: HZ=500 I don't think that's too dangerous. On the other hand, it does increase the rate of interrupts, and if there's a race somewhere, it may make it worse. Have you tried building a kernel with WITNESS and/or DIAGNOSTIC? I'm now running with INVARIANTS, INVARIANT_SUPPORT, and DIAGNOSTIC on 4.11. No change in the failure rate and no significant slowdown either. Any chance of you repeating the tests with a 5.x system? Maybe on a spare small partition or using a 5.4-RELEASE disk1 as a live filesystem. I was experimenting with current in late April, so I installed that drive for testing. So far, I have not been able to reproduce the failure on April's current though I've only had time for a quick run of 6 repetitions. Current takes the same time (135 seconds, on average) to read and compare the CD. That seems good, considering all the debugging is still enabled. I'm pretty sure that ATA MK III is in this kernel. Sadly, it panics immediately if I run atacontrol mode 1 so I'm just assuming it is running in DMA mode by the speed of it. (And I have hw.ata.atapi_dma=1 in /boot/loader.conf). That's where I'm up to so far in stress testing. Right now I'm trying to understand some unusual looking code in ata_dmasetupd_cb() in 4.11's ata-dma.c. The attached comment is A maximum segment size was specified for bus_dma_tag_create, but some busdma code does not seem to honor this, so fix up if needed. The fix-up code seems to be gone in current, so it looks suspicious to me. When I work out what it does, I'll report back. Stephen. -- Verbose boot of 4.11-p10 (the ata related parts, at least): atapci0: Intel ICH5 ATA100 controller port 0xfc00-0xfc0f,0-0x3,0-0x7,0-0x3,0-0x7 irq 0 at device 31.1 on pci0 ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xfc00 ata0: mask=03 ostat0=50 ostat2=00 ata0-master: ATAPI 00 00
Re: FreeBSD MySQL still WAY slower than Linux
Michael Schuh wrote: # cd /; /usr/bin/time dd if=/dev/zero bs=1024 count=1024k of=zerofile; I would only compare the performace from 2 Versions of FreeBSD, while i mean that the performance from RELENG_5 is more slower than under GENTOO and it is double as slow as under RELENG_4. Let me guess: Intel ICH5 or 6300ESB south bridge and ATA disk (Seagate Barracuda 7200.7)? There is something wrong in the RELENG_5 ATA driver that makes this combination perform really slow on writes (~16MB/s). When connecting a nearly identical SATA drive to the machine it performs as expected with ~55MB/s sequential writes. RELENG_4 performs as expected and I think ATA mkIII in CURRENT also works. /Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kpdf crashes with LIBPTHREAD_SYSTEM_SCOPE set (Was: Re: FreeBSD MySQL still WAY slower than Linux)
On Tuesday, 28. June 2005 06:43, Daniel Eischen wrote: I can't reproduce it in -current. -bash-2.05b$ uname -a FreeBSD orion 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Thu May 5 13:29:41 EDT 2005 Yeah, you already said that before. So where do we go from here? Should I try to get a backtrace of the crash? With gdb? Ktrace? Should I compile libpthread of other parts of the system with special debug flags? Should I report this on freebsd-threads instead? Or should I just let the issue go? -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgplrvZCQCI9J.pgp Description: PGP signature
Re: kpdf crashes with LIBPTHREAD_SYSTEM_SCOPE set (Was: Re: FreeBSD MySQL still WAY slower than Linux)
On Tue, 28 Jun 2005, Michael Nottebrock wrote: On Tuesday, 28. June 2005 06:43, Daniel Eischen wrote: I can't reproduce it in -current. -bash-2.05b$ uname -a FreeBSD orion 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Thu May 5 13:29:41 EDT 2005 Yeah, you already said that before. So where do we go from here? Should I try to get a backtrace of the crash? With gdb? Ktrace? Should I compile libpthread of other parts of the system with special debug flags? Should I report this on freebsd-threads instead? Or should I just let the issue go? What CFLAGS did you use to build your ports/system? Run it under gdb and see what you get. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD -STABLE servers repeatedly crashing.
Gleb Smirnoff wrote: On Mon, Jun 27, 2005 at 01:01:09AM -0400, Matt Juszczak wrote: M About three weeks ago, I upgraded my 5.3-RELEASE boxes to 5.4-RELEASE. M I also turned on procmail globally on our mail server. Here is our M current FreeBSD server setup: M M URANUS - primary ldap M CALIBAN - secondary ldap M ORION - primary mail M M Orion was the first one to crash, about three weeks ago. Orion is M constantly talking to uranus, because uranus is our primary ldap server M (we have a planet scheme), and caliban is our secondary ldap server. I M ran an email flood test on orion to see if I could crash it again. This M time, the high requests on Uranus caused Uranus to crash. With two M different servers on two different hardware setups crashing, I had to M start thinking of what could be causing the problem. M M Memory tests on both servers came back OK. Orion had some ECC errors M which it was able to fix. I wasn't able to catch orion's first crash, M but I was able to catch uranus's first crash: M M http://paste.atopia.net/126 Can you please build kernel with debugging and obtain a crashdump? Ever since I setup the debug kernel the machine is now crashing every 12 hours. I think I have to switch to OpenBSD or 4.11 FreeBSD because this box can't keep crashing. It refuses to do a crash dump. -Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Jails that won't die...
On Tue, Jun 28, 2005 at 10:37:29AM +0200, Eirik Øverby wrote: Hi, I have, since upgrading to 5.x and updating my management tools, seen a number of problems relating to stopping jails. I'm maintaining several hosts with a number of full-featured jails (i.e. full virtual FreeBSD installations in each jail), and in general this works fine. However, whenever I stop a jail using 'jexec id kill -SIGNAL -1' or 'jexec id /bin/sh /etc/rc.shutdown' (in various combinations), jails have a tendency to stick around for minutes or hours - according to 'jls'. Often I see an entry in 'netstat -a' indicating that there is one or more sockets in FIN_WAIT state, preventing the jail from coming down. Taking the virtual network interface (alias) down does not help. All I can do at this point is wait. I normally use 'jls' to determine whether or not a jail can be restarted (i.e. it's not running), but this is pretty useless in such cases. And right now I have a case where 'netstat -a' shows me nothing pertaining to the jail, though it has no processes running. I have therefore force-started the jail again, which seems to work nicely, but now 'jls' gives me two entries for this jail, with different JIDs. What am I doing wrong here? You could just use ps to check for jailed processes and check their respective jails using the procfs status entry (at least according to the ps manpage...) -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD -STABLE servers repeatedly crashing.
On Tue, 2005-06-28 at 10:49 -0400, Matt Juszczak wrote: Gleb Smirnoff wrote: On Mon, Jun 27, 2005 at 01:01:09AM -0400, Matt Juszczak wrote: M About three weeks ago, I upgraded my 5.3-RELEASE boxes to 5.4-RELEASE. M I also turned on procmail globally on our mail server. Here is our M current FreeBSD server setup: M M URANUS - primary ldap M CALIBAN - secondary ldap M ORION - primary mail M M Orion was the first one to crash, about three weeks ago. Orion is M constantly talking to uranus, because uranus is our primary ldap server M (we have a planet scheme), and caliban is our secondary ldap server. I M ran an email flood test on orion to see if I could crash it again. This M time, the high requests on Uranus caused Uranus to crash. With two M different servers on two different hardware setups crashing, I had to M start thinking of what could be causing the problem. M M http://paste.atopia.net/126 Can you please build kernel with debugging and obtain a crashdump? Ever since I setup the debug kernel the machine is now crashing every 12 hours. I think I have to switch to OpenBSD or 4.11 FreeBSD because this box can't keep crashing. It refuses to do a crash dump. OK, when it crashes next and is sat at the db prompt, type tr and press enter to get a trace. Copy this down (or have a serial console to capture the output). Also, try typing call doadump() and see if that succeeds in generating a crash dump. How were you trying to generate one before? Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in RELENG_5 UMA - two new stack traces
Gleb,
Thank you very much for your reply.
I spent the day yesterday trying to reproduce the crash that I posted
last week and you kindly replied to. This is due to the fact that I
stupidly managed to overwrite the kernel.debug that I used to generate
the stack trace. Sadly I could not cause the system to crash again with
the same sb* errors.
I did however remove both the Berkley Packet Filter and IPFilter from my
custom kernel to try and isolate the problem. This has caused the crash
to occur in a different and more reproducible form. I have both
INVARIANTS and WITNESS enabled, as you can see from my kernel conf.
which is included at the end of this e-mail.
Below are the latest stack traces (using bge and then fxp NICs), kernel
conf. and dmesg. Any help would be appreciated. This time I have a copy
of both the core files and corresponding kernel.debug so I can hopefully
provide you with any info you need.
d5# uname -a
FreeBSD d5.bidx.com 5.4-RELEASE FreeBSD 5.4-RELEASE #12: Tue Jun 28
09:19:34 EDT 2005
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/DB-DUAL-AMD64-RAID5 amd64
Here is a stack trace when I am using the bge NIC driver (which I've had
reports on the freebsd-amd64 list as being unstable under load):
d5# kgdb kernel.debug.20 vmcore.20
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd.
#0 doadump () at pcpu.h:167
167 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt full
#0 doadump () at pcpu.h:167
No locals.
#1 0x80241dc9 in boot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:410
_ep = (struct eventhandler_entry *) 0x0
_el = (struct eventhandler_list *) 0xff829e00
first_buf_printf = 1
#2 0x8024185b in panic (
fmt=0x803b35a8 Duplicate free of item %p from zone %p(%s)\n)
at /usr/src/sys/kern/kern_shutdown.c:566
bootopt = 260
newpanic = 0
ap = {{gp_offset = 32, fp_offset = 48,
overflow_arg_area = 0xb3431ad0,
reg_save_area = 0xb34319f0}}
buf = Duplicate free of item 0xff00d318bb00 from zone
0xff00f3fe46c0(Mbuf)\n, '\0' repeats 178 times
#3 0x8031f2e8 in uma_dbg_free (zone=0xff00f3fe46c0,
slab=0xff00d318bf50, item=0xff00d318bb00)
at /usr/src/sys/vm/uma_dbg.c:301
keg = 0xff00f3fde000
freei = 11
#4 0x8031d720 in uma_zfree_arg (zone=0xff00f3fe46c0,
item=0xff00d318bb00, udata=0x0) at /usr/src/sys/vm/uma_core.c:2273
keg = 0xff00f3fde000
cache = 0xff00f3fe4740
bucket = 0x9
bflags = 0
skip = SKIP_DTOR
#5 0x8027f5d1 in m_freem (mb=0x0) at uma.h:304
No locals.
#6 0x801d424e in bge_intr (xsc=0x0)
at /usr/src/sys/dev/bge/if_bge.c:2862
sc = (struct bge_softc *) 0x80843000
status = 0
#7 0x8022c899 in ithread_loop (arg=0xff022300)
at /usr/src/sys/kern/kern_intr.c:547
ih = (struct intrhand *) 0xffa1eb80
p = (struct proc *) 0xff00ec16f8b8
count = 0
warming = 0
warned = 0
__func__ = ithread_loop
#8 0x8022b8d3 in fork_exit (
callout=0x8022c7c0 ithread_loop, arg=0xff022300,
frame=0xb3431c50) at /usr/src/sys/kern/kern_fork.c:791
p = (struct proc *) 0xff00ec16f8b8
#9 0x8032879e in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:296
No locals.
#10 0x in ?? ()
No symbol table info available.
#11 0x in ?? ()
No symbol table info available.
#12 0x0001 in ?? ()
No symbol table info available.
#13 0x in ?? ()
No symbol table info available.
#14 0x in ?? ()
No symbol table info available.
#15 0x in ?? ()
No symbol table info available.
#16 0x in ?? ()
No symbol table info available.
#17 0x in ?? ()
No symbol table info available.
#18 0x in ?? ()
No symbol table info available.
#19 0x in ?? ()
No symbol table info available.
#20 0x in ?? ()
No symbol table info available.
#21 0x in ?? ()
No symbol table info available.
#22 0x in ?? ()
No symbol table info available.
#23 0x in ?? ()
No symbol table info available.
#24 0x in ?? ()
No symbol table info available.
#25 0x in ?? ()
No symbol table info available.
#26
Re: FreeBSD -STABLE servers repeatedly crashing.
Gavin Atkinson wrote: On Tue, 2005-06-28 at 10:49 -0400, Matt Juszczak wrote: Gleb Smirnoff wrote: On Mon, Jun 27, 2005 at 01:01:09AM -0400, Matt Juszczak wrote: M About three weeks ago, I upgraded my 5.3-RELEASE boxes to 5.4-RELEASE. M I also turned on procmail globally on our mail server. Here is our M current FreeBSD server setup: M M URANUS - primary ldap M CALIBAN - secondary ldap M ORION - primary mail M M Orion was the first one to crash, about three weeks ago. Orion is M constantly talking to uranus, because uranus is our primary ldap server M (we have a planet scheme), and caliban is our secondary ldap server. I M ran an email flood test on orion to see if I could crash it again. This M time, the high requests on Uranus caused Uranus to crash. With two M different servers on two different hardware setups crashing, I had to M start thinking of what could be causing the problem. M M http://paste.atopia.net/126 Can you please build kernel with debugging and obtain a crashdump? Ever since I setup the debug kernel the machine is now crashing every 12 hours. I think I have to switch to OpenBSD or 4.11 FreeBSD because this box can't keep crashing. It refuses to do a crash dump. OK, when it crashes next and is sat at the db prompt, type tr and press enter to get a trace. Copy this down (or have a serial console to capture the output). Also, try typing call doadump() and see if that succeeds in generating a crash dump. How were you trying to generate one before? Gavin I can't type anything. The machine locks up. See: http://paste.atopia.net/126 After CPUID: 1, the machine locks cold and nothing else is printed to the screen. -Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD -STABLE servers repeatedly crashing.
Matt Juszczak wrote: Ever since I setup the debug kernel the machine is now crashing every 12 hours. I think I have to switch to OpenBSD or 4.11 FreeBSD because this box can't keep crashing. It refuses to do a crash dump. -Matt Matt, Does it refuse to crash dump or is it that you can't get the core file back? Make sure you have enough disk space in /var/crash for capturing the dump. You need at least as much free disk as you have memory configured. There was a post saying that fsck may be trashing core files if it starts using swap. To maximize the chances of recovering the core file boot into single user after the crash and do the following: fsck -y # or fsck and read every question, if you're paranoid mount -f / # remounts root read/write mount /var savecore /var/crash exit Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Tue, 2005-06-28 at 11:21 +0200, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-21 16:51:10 +0200: For accurate measurements and comparisons, you have to make sure to use _exactly_ the same physical location on the disk. No you don't. You want to make a side-by-side comparison of two products, and if one of them underperforms, it just underperforms. You cannot use a poor location selection strategy in the driver as an excuse for poor operation. The point people are making is that location can have a significant effect on performance, and so should not be dismissed out of hand. Here is what I get when I run diskinfo on one of the (somewhat elderly) disks I use in my desktop system (this is a drive I use for data, and it is idle): zappa# diskinfo -tv /dev/ad4 /dev/ad4 512 # sectorsize 25590620160 # mediasize in bytes (24G) 49981680# mediasize in sectors 49585 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke: 250 iter in 5.159189 sec = 20.637 msec Half stroke: 250 iter in 4.206125 sec = 16.825 msec Quarter stroke: 500 iter in 7.151951 sec = 14.304 msec Short forward:400 iter in 2.794380 sec =6.986 msec Short backward: 400 iter in 4.135579 sec = 10.339 msec Seq outer: 2048 iter in 0.332711 sec =0.162 msec Seq inner: 2048 iter in 0.363152 sec =0.177 msec Transfer rates: outside: 102400 kbytes in 7.677977 sec =13337 kbytes/sec middle:102400 kbytes in 9.151475 sec =11189 kbytes/sec inside:102400 kbytes in 14.345492 sec = 7138 kbytes/sec Note how the transfer rate for the outside is almost twice that of the inside. Suppose I run tests on two different operating systems, one of which resides in a partition on the inside portion and the other in one on the outside portion. (Note that however good or bad it may be, the location selection strategy in the driver can only lay out data within the confines of the partition.) Now, I do a dd test and find that the outside OS is almost twice as fast as the other. Would it be wise to conclude that the slower OS is woefully inefficient compared to the faster one? Suppose both tests turn out to take roughly the same time. Should I conclude that the OS residing on the inside is just as efficient as the other OS? 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: On recent crashes
On Jun 28, 2005, at 5:20 AM, Alex Povolotsky wrote: Can anyone enlighten me, if recent crashes are on STABLE only or 5.4-RELEASE is affected as well? I have three boxes running 5.4-RELEASE. one is a mediumly-loaded web server, and two are very heavily loaded database servers. none of them ever crash. Vivek Khera, Ph.D. +1-301-869-4449 x806
libstdc++ version bump.
I just got bitten by an upgrade from 5.2.1 to 5.4 where my apps linked with c++ stopped working. The solution I had to do was to copy an old 5.2.1 libstdc++ over my 5.4 one. My question is, why wasn't the library version bumped for this incompatible change? Can we bump it? How can we bump it? Even if it doesn't solve 100% of people's problems, it appears to solve some of mine. So can we do it? thank you, -- - Alfred Perlstein - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD -STABLE servers repeatedly crashing.
fsck -y# or fsck and read every question, if you're paranoid mount -f /# remounts root read/write mount /var savecore /var/crash exit Gary Gary: After it crashes, it locks up and hangs, no keyboard response, etc. When I reboot, I go into single user mode and do: fsck -p mount -a -t ufs savecore /var/crash /dev/da0s1b (which is my swap) It says no dump available. These instructions are from the handbook. I just got sent a patch a little while ago which apparently will help the system not lock up. I'm going to try it later today and see where it gets me. Thanks, Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: On recent crashes
Vivek Khera wrote: On Jun 28, 2005, at 5:20 AM, Alex Povolotsky wrote: Can anyone enlighten me, if recent crashes are on STABLE only or 5.4-RELEASE is affected as well? I have three boxes running 5.4-RELEASE. one is a mediumly-loaded web server, and two are very heavily loaded database servers. none of them ever crash. Other people I've seen complain seem to be running SMP Not sure if that has anything to do with it but its the only similiarity I can pull out from any responses I've gotten. -Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: On recent crashes
Vivek, When stress testing I never had any issues with the bge NIC on our AMD64 Tyan S2882 system. Of course within a day of putting it in production it crashed. Switching to the fxp NIC did not fix the crash, although it crashed differently. If you have a spare server you don't mind crashing, can you try running 20-60 instances of the following script: #!/bin/sh while : do arp -d some valid IP /dev/null 21 ping -c 1 -t 1 the same valid IP /dev/null 21 done Thanks, Gary Vivek Khera wrote: On Jun 28, 2005, at 5:20 AM, Alex Povolotsky wrote: Can anyone enlighten me, if recent crashes are on STABLE only or 5.4-RELEASE is affected as well? I have three boxes running 5.4-RELEASE. one is a mediumly-loaded web server, and two are very heavily loaded database servers. none of them ever crash. Vivek Khera, Ph.D. +1-301-869-4449 x806 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: On recent crashes
On Jun 28, 2005, at 11:50 AM, Matt Juszczak wrote: I have three boxes running 5.4-RELEASE. one is a mediumly-loaded web server, and two are very heavily loaded database servers. none of them ever crash. Other people I've seen complain seem to be running SMP Not sure if that has anything to do with it but its the only similiarity I can pull out from any responses I've gotten. My web server is a Xeon with HT enabled. My db servers are dual opterons with RAID controllers. So SMP is not a problem here. Vivek Khera, Ph.D. +1-301-869-4449 x806
Re: On recent crashes
Vivek Khera wrote: On Jun 28, 2005, at 5:20 AM, Alex Povolotsky wrote: Can anyone enlighten me, if recent crashes are on STABLE only or 5.4-RELEASE is affected as well? I have three boxes running 5.4-RELEASE. one is a mediumly-loaded web server, and two are very heavily loaded database servers. none of them ever crash. Matt Juszczak wrote: Other people I've seen complain seem to be running SMP Not sure if that has anything to do with it but its the only similiarity I can pull out from any responses I've gotten. I have 5 modestly powered i386 boxes on 5.4-RELEASE and the only time I have had any complaints regarding system stability, is when running an SMP kernel AND Nagios (which is a known problem - I think it's with Nagios rather than FreeBSD). Otherwise, I'm almost completely happy. ChrisP ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: On recent crashes
Chris Phillips wrote: Vivek Khera wrote: On Jun 28, 2005, at 5:20 AM, Alex Povolotsky wrote: Can anyone enlighten me, if recent crashes are on STABLE only or 5.4-RELEASE is affected as well? I have three boxes running 5.4-RELEASE. one is a mediumly-loaded web server, and two are very heavily loaded database servers. none of them ever crash. Matt Juszczak wrote: Other people I've seen complain seem to be running SMP Not sure if that has anything to do with it but its the only similiarity I can pull out from any responses I've gotten. I have 5 modestly powered i386 boxes on 5.4-RELEASE and the only time I have had any complaints regarding system stability, is when running an SMP kernel AND Nagios (which is a known problem - I think it's with Nagios rather than FreeBSD). Otherwise, I'm almost completely happy. Nagios remotely or locally? I have nagios remotely that PINGS these machines constantly for uptime/downtime checks, but nagios isn't actually running on them as a process... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: On recent crashes
Matt Juszczak wrote: Chris Phillips wrote: Vivek Khera wrote: On Jun 28, 2005, at 5:20 AM, Alex Povolotsky wrote: Can anyone enlighten me, if recent crashes are on STABLE only or 5.4-RELEASE is affected as well? I have three boxes running 5.4-RELEASE. one is a mediumly-loaded web server, and two are very heavily loaded database servers. none of them ever crash. Matt Juszczak wrote: Other people I've seen complain seem to be running SMP Not sure if that has anything to do with it but its the only similiarity I can pull out from any responses I've gotten. I have 5 modestly powered i386 boxes on 5.4-RELEASE and the only time I have had any complaints regarding system stability, is when running an SMP kernel AND Nagios (which is a known problem - I think it's with Nagios rather than FreeBSD). Otherwise, I'm almost completely happy. Nagios remotely or locally? I have nagios remotely that PINGS these machines constantly for uptime/downtime checks, but nagios isn't actually running on them as a process... The main Nagios process, was running on the server that died. It was responsible for checking itself the other hosts (and others not within my responsibility, but equally important). I'll be retrying running them Nagios on the SMP server, sometime soon (like in a minute or two). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libstdc++ version bump.
This note in the 5-CURRENT UPDATING file (when -CURRENT was 5.x), indicates you'll need to rebuild all 5.x executables made after this change (20041001 entry). http://www.freebsd.org/cgi/cvsweb.cgi/src/UPDATING.diff?r1=1.366r2=1.367f=h /lib/libm.so.2 - libm.so.3 /lib/libreadline.so.4 - libreadline.so.5 /usr/lib/libhistory.so.4 - libhistory.so.5 /usr/lib/libopie.so.2 - libopie.so.3 /usr/lib/libpcap.so.2 - libpcap.so.3 Are you sure that the problem is with libstdc++ and not the above libraries? Was there any changes to libstdc++ between 5.4 5.3? Scot On 6/28/05, Alfred Perlstein [EMAIL PROTECTED] wrote: I just got bitten by an upgrade from 5.2.1 to 5.4 where my apps linked with c++ stopped working. The solution I had to do was to copy an old 5.2.1 libstdc++ over my 5.4 one. My question is, why wasn't the library version bumped for this incompatible change? Can we bump it? How can we bump it? Even if it doesn't solve 100% of people's problems, it appears to solve some of mine. So can we do it? thank you, -- - Alfred Perlstein - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- 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: FreeBSD MySQL still WAY slower than Linux
Yes, i know that and i agree with them. that was the reason, why my disk is tiled on first physical Gigabyte for Swap, and the rest for the system my target was to compare 2 Versions not 2 Os-Types like FreeBSD and Linux, but FreeBSD and FreeBSD, in cases RELENG_4 with RELENG_5. so that the little difference between the different places for files, remember i install everytime at the beginning of second Gig on disk, should be flawlessy and not make the results so big, that the RELENG_4 has the double of speed from RELENG_5! best regards michael 2005/6/28, Paul Mather [EMAIL PROTECTED]: On Tue, 2005-06-28 at 11:21 +0200, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-21 16:51:10 +0200: For accurate measurements and comparisons, you have to make sure to use _exactly_ the same physical location on the disk. No you don't. You want to make a side-by-side comparison of two products, and if one of them underperforms, it just underperforms. You cannot use a poor location selection strategy in the driver as an excuse for poor operation. The point people are making is that location can have a significant effect on performance, and so should not be dismissed out of hand. Here is what I get when I run diskinfo on one of the (somewhat elderly) disks I use in my desktop system (this is a drive I use for data, and it is idle): zappa# diskinfo -tv /dev/ad4 /dev/ad4 512 # sectorsize 25590620160 # mediasize in bytes (24G) 49981680# mediasize in sectors 49585 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke: 250 iter in 5.159189 sec = 20.637 msec Half stroke: 250 iter in 4.206125 sec = 16.825 msec Quarter stroke: 500 iter in 7.151951 sec = 14.304 msec Short forward:400 iter in 2.794380 sec =6.986 msec Short backward: 400 iter in 4.135579 sec = 10.339 msec Seq outer: 2048 iter in 0.332711 sec =0.162 msec Seq inner: 2048 iter in 0.363152 sec =0.177 msec Transfer rates: outside: 102400 kbytes in 7.677977 sec =13337 kbytes/sec middle:102400 kbytes in 9.151475 sec =11189 kbytes/sec inside:102400 kbytes in 14.345492 sec = 7138 kbytes/sec Note how the transfer rate for the outside is almost twice that of the inside. Suppose I run tests on two different operating systems, one of which resides in a partition on the inside portion and the other in one on the outside portion. (Note that however good or bad it may be, the location selection strategy in the driver can only lay out data within the confines of the partition.) Now, I do a dd test and find that the outside OS is almost twice as fast as the other. Would it be wise to conclude that the slower OS is woefully inefficient compared to the faster one? Suppose both tests turn out to take roughly the same time. Should I conclude that the OS residing on the inside is just as efficient as the other OS? 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: On recent crashes
Chris Phillips wrote: Matt Juszczak wrote: Chris Phillips wrote: Vivek Khera wrote: On Jun 28, 2005, at 5:20 AM, Alex Povolotsky wrote: Can anyone enlighten me, if recent crashes are on STABLE only or 5.4-RELEASE is affected as well? I have three boxes running 5.4-RELEASE. one is a mediumly-loaded web server, and two are very heavily loaded database servers. none of them ever crash. Matt Juszczak wrote: Other people I've seen complain seem to be running SMP Not sure if that has anything to do with it but its the only similiarity I can pull out from any responses I've gotten. I have 5 modestly powered i386 boxes on 5.4-RELEASE and the only time I have had any complaints regarding system stability, is when running an SMP kernel AND Nagios (which is a known problem - I think it's with Nagios rather than FreeBSD). Otherwise, I'm almost completely happy. Nagios remotely or locally? I have nagios remotely that PINGS these machines constantly for uptime/downtime checks, but nagios isn't actually running on them as a process... The main Nagios process, was running on the server that died. It was responsible for checking itself the other hosts (and others not within my responsibility, but equally important). I'll be retrying running them Nagios on the SMP server, sometime soon (like in a minute or two). OK, update on this... I've re-instated my Nagios config on the 5.4 server (http://nagios.rainbow-it.net/) will let you know if it still falls over again. Fingers crossed :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
# [EMAIL PROTECTED] / 2005-06-28 11:38:44 -0400: Note how the transfer rate for the outside is almost twice that of the inside. Suppose I run tests on two different operating systems, one of which resides in a partition on the inside portion and the other in one on the outside portion. Which is not the case according to the OP... (Note that however good or bad it may be, the location selection strategy in the driver can only lay out data within the confines of the partition.) Now, I do a dd test and find that the outside OS is almost twice as fast as the other. Would it be wise to conclude that the slower OS is woefully inefficient compared to the faster one? Suppose both tests turn out to take roughly the same time. Should I conclude that the OS residing on the inside is just as efficient as the other OS? ... rendering this completely irrelevant. I have seen people come to a freebsd list with completely flawed comparisons or benchmarks: OSs installed on different partitions side by side, not taking VM cache into account, whatever, and be told that their numbers are flawed. I have also seen people test a specific subsystem (dd), and be told that their numbers don't reflect real world. And I have seen people test real world performance (install FreeBSD, install MySQL, run a stress test, reformat, install Linux, install MySQL, run a stress test) and get responses that try to make up reasons why the bad results are the testers fault). Heck, if installing an operating system, a database, and running it isn't a real world test, I don't know what is. Even if the bug is FreeBSD puts /var/db/mysql in the wrong part of the disk (then it's still a problem in FreeBSD, not in the messenger). I just wish people here were less defensive, that's all. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libstdc++ version bump.
On Tuesday, 28. June 2005 18:21, Scot Hetzel wrote: Are you sure that the problem is with libstdc++ and not the above libraries? Yes, it's a well known-fact. In fact there might have been a break of ABI backwards-compatibility between gcc 3.3 and 3.4, too, but I'm not sure. Was there any changes to libstdc++ between 5.4 5.3? No. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpsX0HPTyYqs.pgp Description: PGP signature
Re: libstdc++ version bump.
No, it's not that. It's just that when we decided to upgrade gcc/g++ in the 5.2.1 era someone didn't bump the library version for libstdc++. It would have been a two second change, but instead it appears that it was decided that early adopters REALLY needed to be put in their place for being stupid enough... to be early adopters. So the library wasn't bumped and people are stuck having to do source upgrades from 5.2.1-5.3+ instead of the right thing. There's not much choice at this point because the decision was made so long ago, if we did a bump now, we'd basically lose a lot of package compatibility between 5.3+ and 6.x. (Oh dear, losing package compat between current (where things are supposed to break) and 5.x... ) Although the relative worth of that versus actually doing the right thing and giving people stuck with 5.2.1 and prior room to breath is something that is very debatable. -Alfred * Scot Hetzel [EMAIL PROTECTED] [050628 09:22] wrote: This note in the 5-CURRENT UPDATING file (when -CURRENT was 5.x), indicates you'll need to rebuild all 5.x executables made after this change (20041001 entry). http://www.freebsd.org/cgi/cvsweb.cgi/src/UPDATING.diff?r1=1.366r2=1.367f=h /lib/libm.so.2 - libm.so.3 /lib/libreadline.so.4 - libreadline.so.5 /usr/lib/libhistory.so.4 - libhistory.so.5 /usr/lib/libopie.so.2 - libopie.so.3 /usr/lib/libpcap.so.2 - libpcap.so.3 Are you sure that the problem is with libstdc++ and not the above libraries? Was there any changes to libstdc++ between 5.4 5.3? Scot On 6/28/05, Alfred Perlstein [EMAIL PROTECTED] wrote: I just got bitten by an upgrade from 5.2.1 to 5.4 where my apps linked with c++ stopped working. The solution I had to do was to copy an old 5.2.1 libstdc++ over my 5.4 one. My question is, why wasn't the library version bumped for this incompatible change? Can we bump it? How can we bump it? Even if it doesn't solve 100% of people's problems, it appears to solve some of mine. So can we do it? thank you, -- - Alfred Perlstein - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. -- - Alfred Perlstein - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
# [EMAIL PROTECTED] / 2005-06-28 18:29:59 +0200: 2005/6/28, Paul Mather [EMAIL PROTECTED]: On Tue, 2005-06-28 at 11:21 +0200, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-21 16:51:10 +0200: For accurate measurements and comparisons, you have to make sure to use _exactly_ the same physical location on the disk. No you don't. You want to make a side-by-side comparison of two products, and if one of them underperforms, it just underperforms. You cannot use a poor location selection strategy in the driver as an excuse for poor operation. The point people are making is that location can have a significant effect on performance, and so should not be dismissed out of hand. Yes, i know that and i agree with them. that was the reason, why my disk is tiled on first physical Gigabyte for Swap, and the rest for the system my target was to compare 2 Versions not 2 Os-Types like FreeBSD and Linux, but FreeBSD and FreeBSD, in cases RELENG_4 with RELENG_5. so that the little difference between the different places for files, remember i install everytime at the beginning of second Gig on disk, should be flawlessy and not make the results so big, that the RELENG_4 has the double of speed from RELENG_5! I can feel your pain. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Tue, 2005-06-28 at 18:39 +0200, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-28 11:38:44 -0400: Note how the transfer rate for the outside is almost twice that of the inside. Suppose I run tests on two different operating systems, one of which resides in a partition on the inside portion and the other in one on the outside portion. Which is not the case according to the OP... (Note that however good or bad it may be, the location selection strategy in the driver can only lay out data within the confines of the partition.) Now, I do a dd test and find that the outside OS is almost twice as fast as the other. Would it be wise to conclude that the slower OS is woefully inefficient compared to the faster one? Suppose both tests turn out to take roughly the same time. Should I conclude that the OS residing on the inside is just as efficient as the other OS? ... rendering this completely irrelevant. ...especially when you've cut out the context of my reply. :-) My apologies if it wasn't clear, but I was responding to your apparent assertion that location does not matter in disk performance benchmarks. If I had been responding to a specific aspect of the OP's benchmark (or indeed anything the OP has said), I'm sure I would have quoted that to make the context clear. I have seen people come to a freebsd list with completely flawed comparisons or benchmarks: OSs installed on different partitions side by side, not taking VM cache into account, whatever, and be told that their numbers are flawed. I have also seen people test a specific subsystem (dd), and be told that their numbers don't reflect real world. And I have seen people test real world performance (install FreeBSD, install MySQL, run a stress test, reformat, install Linux, install MySQL, run a stress test) and get responses that try to make up reasons why the bad results are the testers fault). Heck, if installing an operating system, a database, and running it isn't a real world test, I don't know what is. Even if the bug is FreeBSD puts /var/db/mysql in the wrong part of the disk (then it's still a problem in FreeBSD, not in the messenger). I just wish people here were less defensive, that's all. What you see as being defensive I see as being rigorous. If someone is making a claim based upon a performance benchmark, people will quiz the person conducting the benchmark to ascertain exactly how it has been undertaken. To put any stock in a benchmark result, it is important to be able to convince yourself it is a meaningful result. Well, at least most people I've encountered believe that to be the case. As it says in the BUGS section of the diskinfo man page: There are in order of increasing severity: lies, damn lies, statistics, and computer benchmarks. ;-) 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
(Note that however good or bad it may be, the location selection strategy in the driver can only lay out data within the confines of the partition.) Now, I do a dd test and find that the outside OS is almost twice as fast as the other. Would it be wise to conclude that the slower OS is woefully inefficient compared to the faster one? Suppose both tests turn out to take roughly the same time. Should I conclude that the OS residing on the inside is just as efficient as the other OS? ... rendering this completely irrelevant. I have seen people come to a freebsd list with completely flawed comparisons or benchmarks: OSs installed on different partitions side by side, not taking VM cache into account, whatever, and be told that their numbers are flawed. I have also seen people test a specific subsystem (dd), and be told that their numbers don't reflect real world. And I have seen people test real world performance (install FreeBSD, install MySQL, run a stress test, reformat, install Linux, install MySQL, run a stress test) and get responses that try to make up reasons why the bad results are the testers fault). Heck, if installing an operating system, a database, and running it isn't a real world test, I don't know what is. Even if the bug is FreeBSD puts /var/db/mysql in the wrong part of the disk (then it's still a problem in FreeBSD, not in the messenger). When one does the dd-test (on identical hardware), one should think that half the time FreeBSD would have the highest throughput, and the rest of the time Linux will, if the location of the partition that the test is performed on, is indeed located at a random location which should be the case when the test is performed often enough. When several people does this test and draws the conclusion that Linux (and FreeBSD 4.11) does this faster than 5.4/6, either only those who see this pattern post their numbers to this list, or Linux (and 4.11 to some degree) is indeed faster at this particular operation. And the test itself doesn't tell the complete story, but it does give an indication of what lies ahead. Arguing that the placement of the partion where the test is performed on is relevant, but then sometimes FreeBSD 5/6 should be faster. regards Claus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
# [EMAIL PROTECTED] / 2005-06-28 13:03:04 -0400: On Tue, 2005-06-28 at 18:39 +0200, Roman Neuhauser wrote: My apologies if it wasn't clear, but I was responding to your apparent assertion that location does not matter in disk performance benchmarks. We seem to have a misunderstaning, I didn't mean anything like that. I just wish people here were less defensive, that's all. What you see as being defensive I see as being rigorous. If someone is making a claim based upon a performance benchmark, people will quiz the person conducting the benchmark to ascertain exactly how it has been undertaken. To put any stock in a benchmark result, it is important to be able to convince yourself it is a meaningful result. Well, at least most people I've encountered believe that to be the case. Say I install FreeBSD (using default partitions), install MySQL from a package on the CD, run a stress test, collect numbers, then repeat the process with a Linux installed over the previous FreeBSD installation, and find out that FreeBSD allows the MySQL server process 1/3 queries less, what (if anything) will be wrong in my claim that MySQL/FreeBSD is slower than MySQL/Linux? -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: On recent crashes
On Jun 28, 2005, at 11:53 AM, Gary Mu1der wrote: If you have a spare server you don't mind crashing, can you try running 20-60 instances of the following script: #!/bin/sh while : do arp -d some valid IP /dev/null 21 ping -c 1 -t 1 the same valid IP /dev/null 21 done all copies pinging the same remote IP or different remote IP's? Vivek Khera, Ph.D. +1-301-869-4449 x806
Re: On recent crashes
Vivek Khera wrote: If you have a spare server you don't mind crashing, can you try running 20-60 instances of the following script: #!/bin/sh while : do arp -d some valid IP /dev/null 21 ping -c 1 -t 1 the same valid IP /dev/null 21 done all copies pinging the same remote IP or different remote IP's? Different, as the FreeBSD systems I was pinging were rate-limiting the pings. Here's excatly what I'm doing: d5# cat arping.sh #!/bin/sh while : do arp -d 192.168.4.$1 /dev/null 21; ping -c 1 -t 1 192.168.4.$1 /dev/null 21; done # for X in 13 4 101 44 13 4 101 44 13 4 101 44 13 4 101 44 13 4 101 44 13 4 101 44 13 4 101 44 13 4 101 44; do ./arping.sh $X done Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: On recent crashes
___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: FreeBSD -STABLE servers repeatedly crashing
Please try out this patch to aid the above problem with hang instead of dump: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/i386/trap.c.diff?r1=1.275r2=1.276 This box is now crashing once every 12 hours. I can't apply this patch :-(. Does anyone have any suggestions on how I can work around this? Some have said its an SMP problem and some have said its a 4 GB RAM problem and some have said its an IPF problem if I disabled all three of those things would that help this box be stable until code could be fixed? Thanks, Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libstdc++ version bump.
On Tue, Jun 28, 2005 at 08:46:27AM -0700, Alfred Perlstein wrote: I just got bitten by an upgrade from 5.2.1 to 5.4 where my apps linked with c++ stopped working. The solution I had to do was to copy an old 5.2.1 libstdc++ over my 5.4 one. My question is, why wasn't the library version bumped for this incompatible change? Because 5.2.1 was 5-CURRENT. Not until 5.3 did we make any ABI stability cares or guarantees. It was a conscientious decision the release management team made. I'm sure one could have built a 5.2.1 kernel module (.ko) that is broken on 5.3-RELEASE and 5-STABLE. -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libstdc++ version bump.
On Tue, Jun 28, 2005 at 06:44:02PM +0200, Michael Nottebrock wrote: On Tuesday, 28. June 2005 18:21, Scot Hetzel wrote: Are you sure that the problem is with libstdc++ and not the above libraries? Yes, it's a well known-fact. In fact there might have been a break of ABI backwards-compatibility between gcc 3.3 and 3.4, too, but I'm not sure. There was. 3.3 could support either the C++ ABI of GCC 3.2, in which there was an implementation bug; or the fixed ABI of 3.4. I had hoped we had gone with the fixed ABI rather than being G++ 3.2 compatible, but that is what users wanted at the time. -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Tue, 2005-06-28 at 19:17 +0200, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-28 13:03:04 -0400: What you see as being defensive I see as being rigorous. If someone is making a claim based upon a performance benchmark, people will quiz the person conducting the benchmark to ascertain exactly how it has been undertaken. To put any stock in a benchmark result, it is important to be able to convince yourself it is a meaningful result. Well, at least most people I've encountered believe that to be the case. Say I install FreeBSD (using default partitions), install MySQL from a package on the CD, run a stress test, collect numbers, then repeat the process with a Linux installed over the previous FreeBSD installation, and find out that FreeBSD allows the MySQL server process 1/3 queries less, what (if anything) will be wrong in my claim that MySQL/FreeBSD is slower than MySQL/Linux? To make the specific claim above, it would be okay, at least in my book. To make a more general claim, pedantically speaking, you should, e.g., replicate your benchmark using various different hardware combinations, to rule out the possibility of a pathological case affecting one or other OS (e.g., where one OS has much better driver support for some specific hardware aspect than the other). Also, you would need to be careful how you stated your claim. For example, it would be better to say something like untuned MySQL/Particular-FreeBSD-Version on a default install is slower than untuned MySQL/Particular-Linux-Distribution on a default install. If you test many Linux distributions and find they beat out all the FreeBSDs, then a more general MySQL/FreeBSD and MySQL/Linux might be appropriate. Similarly, if no amount of tuning lets FreeBSD MySQL compete with Linux, I'd say your original statement would be defensible. However, if some combinations of MySQL and FreeBSD tuning perform better than some well-tuned MySQL/Linux distributions, then it's not so straightforward to claim MySQL/FreeBSD is slower than MySQL/Linux. (It may be that default tunings favour one or the other. I'm sure the Linux people would gripe that you're using filesystem X instead of filesystem Y, which would give better performance.:) If you just want to make a benchmark statement about untuned installs on default distributions, that's fine, but I'm not sure how illuminating that is for the real world given that production systems are normally tuned for performance. Although this might seem like splitting hairs to the extreme, I guess the point I'm making is that benchmarks can be highly subjective. Unless you learn the context and point of view in which it was performed, you can't really tell if the results apply to you. In fact, even a very good benchmark may not yield the expected performance in the real world when run in an environment containing other systems (e.g., Apache, Squid, Postfix, etc.) that interact and contend for resources and affect performance in a way not measured when the systems are benchmarked in isolation. I guess the preferred colour for the consumers of benchmarks is black and white, when in reality what you get are subtle shades of grey. :-) 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
smbfs
Good Afternoon. After upgrading my system from FreeBSD 4.10 to FreeBSD 5.3, I found mount_smbfs -N broken. The error message is mount_smbfs: unable to open connection: syserr = Authentication error. However, the keyboard interactive password works normally. The problem still persists in 5.4p2. I need this feature strongly because of running automatic backup procedures. Is there any solution? -- Maxim Kizik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD -STABLE servers repeatedly crashing
Matt, Sadly the FreeBSD guys will need more info before a fix is possible. I would suggest you revert back to FreeBSD 5.3, if you can. Even if you get a patch you'd want to do a whole lot of regression testing before putting it in production as it might break something else. Gary, Do you know what the chances are that this problem I'm experiencing is SMP related? I don't mind turning off SMP, and I guess I could for now to see if that runs stable. Otherwise, I think we're going to switch to OpenBSD, because these crashes are occuring so frequently (twice a day)... and as far as the patch and regression testing, if someone sent me a patch right now I would put it on the server, because the server already crashes daily, so a faulty patch wouldn't change much :-(. I appreciate your response. I'm going to do a little more research today before i make my decision on a platform switch. -Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libstdc++ version bump.
* David O'Brien [EMAIL PROTECTED] [050628 11:27] wrote: On Tue, Jun 28, 2005 at 08:46:27AM -0700, Alfred Perlstein wrote: I just got bitten by an upgrade from 5.2.1 to 5.4 where my apps linked with c++ stopped working. The solution I had to do was to copy an old 5.2.1 libstdc++ over my 5.4 one. My question is, why wasn't the library version bumped for this incompatible change? Because 5.2.1 was 5-CURRENT. Not until 5.3 did we make any ABI stability cares or guarantees. It was a conscientious decision the release management team made. I'm sure one could have built a 5.2.1 kernel module (.ko) that is broken on 5.3-RELEASE and 5-STABLE. The difference between kernel compat and userland binary compat... [godwin's law] How very upsetting. Thanks for your help on chat though. Hopefully linking static against libstdc++ on the 5.2.1 machine will fix things. -- - Alfred Perlstein - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Tue, Jun 28, 2005 at 07:17:39PM +0200, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-28 13:03:04 -0400: On Tue, 2005-06-28 at 18:39 +0200, Roman Neuhauser wrote: My apologies if it wasn't clear, but I was responding to your apparent assertion that location does not matter in disk performance benchmarks. We seem to have a misunderstaning, I didn't mean anything like that. I just wish people here were less defensive, that's all. What you see as being defensive I see as being rigorous. If someone is making a claim based upon a performance benchmark, people will quiz the person conducting the benchmark to ascertain exactly how it has been undertaken. To put any stock in a benchmark result, it is important to be able to convince yourself it is a meaningful result. Well, at least most people I've encountered believe that to be the case. Say I install FreeBSD (using default partitions), install MySQL from a package on the CD, run a stress test, collect numbers, then repeat the process with a Linux installed over the previous FreeBSD installation, and find out that FreeBSD allows the MySQL server process 1/3 queries less, what (if anything) will be wrong in my claim that MySQL/FreeBSD is slower than MySQL/Linux? We care about why MySQL appears to be slower, how to improve the situation, and not numbers from poorly done benchmarks which ignored the effect of debugging options, version, disk mount options, etc., which is IMHO meaningless. Maybe a key feature of the new FreeBSD installer would be to automatically tune the user's system (including kernel and other loader/sysctl tunings) according to installed ports :-) To make benchmarks a help provided to improve FreeBSD, a better start would be to run MySQL with profiling options compiled in, to find out the bottleneck and report them (maybe with patches if you have some idea). Cheers, -- Xin LI delphij frontfree net http://www.delphij.net/ See complete headers for GPG key and other information. pgpYEsqFi8zEQ.pgp Description: PGP signature
Re: FreeBSD -STABLE servers repeatedly crashing
Gary, Do you know what the chances are that this problem I'm experiencing is SMP related? I don't mind turning off SMP, and I guess I could for now to see if that runs stable. Otherwise, I think we're going to switch to OpenBSD, because these crashes are occuring so frequently (twice a day)... and as far as the patch and regression testing, if someone sent me a patch right now I would put it on the server, because the server already crashes daily, so a faulty patch wouldn't change much :-(. I appreciate your response. I'm going to do a little more research today before i make my decision on a platform switch. Only way to find out is to try. You could build and install the non-SMP kernel and reboot when you can, or let it boot the new kernel next time the system(s) crash. A lot of the issues seem to be SMP-related. I really loaded up a GENERIC 5.4 kernel and wasn't able to get it to panic. What do you have to lose at this point? I would suggest that before committing to OpenBSD you verify that all the hardware/software you have/use is supported under OpenBSD: http://www.daemonnews.org/200104/bsd_family.html http://www.monkey.org/openbsd/archive/misc/0311/msg01803.html As an example: I'm fairly sure OpenBSD has recently dropped (or will drop) support for the Adaptec aac driver as Theo is not happy with Adaptec's response to his queries for interface specs. From what I've head (YMMV) OpenSBD SMP support is not very optimal, possibly because it is likely that it was implemented extremely conservatively. OpenBSD MySQL with two CPUs can be slower than with one: http://software.newsforge.com/article.pl?sid=04/12/27/1243207from=rss Gary ps. it is a case of: cost, speed, reliability - choose any two. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD -STABLE servers repeatedly crashing
Only way to find out is to try. You could build and install the non-SMP kernel and reboot when you can, or let it boot the new kernel next time the system(s) crash. A lot of the issues seem to be SMP-related. I really loaded up a GENERIC 5.4 kernel and wasn't able to get it to panic. What do you have to lose at this point? I would suggest that before committing to OpenBSD you verify that all the hardware/software you have/use is supported under OpenBSD: http://www.daemonnews.org/200104/bsd_family.html http://www.monkey.org/openbsd/archive/misc/0311/msg01803.html As an example: I'm fairly sure OpenBSD has recently dropped (or will drop) support for the Adaptec aac driver as Theo is not happy with Adaptec's response to his queries for interface specs. From what I've head (YMMV) OpenSBD SMP support is not very optimal, possibly because it is likely that it was implemented extremely conservatively. OpenBSD MySQL with two CPUs can be slower than with one: http://software.newsforge.com/article.pl?sid=04/12/27/1243207from=rss Gary ps. it is a case of: cost, speed, reliability - choose any two. Agreed, Theo just yelled at me cause I was having this discussion on the OpenBSD misc mailing list, which is my fault :-/ ... a lot of people were responding though and I think it just got out of hand. As much as OpenBSD seems nice, my FreeBSD experience is a lot better. I'm going to switch to Uniprocessor and see if that makes us more stable. Hopefully it will. -Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA vs SCSI ...
On 26 Jun, David Magda wrote: On Jun 26, 2005, at 22:34, Marc G. Fournier wrote: In fact, looking at the SATA 2.x specs, each chanell there is rated at 300MB/s, which, again, if I could 'max out evenly', could seriously blow away the SCSI bus itself ... *If* I'm reading this right ... ? Bus speed does not equal drive speed. And while yes, SATA is now approaching SCSI in bus speed, it doesn't mean that SCSI isn't standing still. A 640 MB/s bus was standardized in 2003 (though SATA is planned to go to 600MB/s in 2007): http://en.wikipedia.org/wiki/SCSI#Ultra-640 There's also Serial Attached SCSI (SAS), which shares uses the same connector and cable as SATA, and has the same data transfer rate. Dunno if we support any SAS HBAs yet. There are a few drives available, but they seem to be pricey. Dunno if FreeBSD supports any SAS HBAs ... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD -STABLE servers repeatedly crashing
Hi, I have something like 20 boxes (Dell Power Edge 370, Fujitsu-Siemens PRIMERGY 200 and couple of dual AMD64 Fujitsu-Siemens) servers running 5.4-STABLE. So far, only machine that I have experienced freezing and was unable to get droped into KDB or to get any sort of vmcore was Dell Power Edge 1600SC (dual Xeon 2.4GHz with 4Gb). I have noticed that since it was running squid-2.5 linked to pthread when I have switched to oops which was compiled on 5.2.1 and linked to libc_r that machine stoped crashing (HTT disabled, IPFILTER also disabled configuration GENERIC). However, I have decided to experiment and upgraded to 6.0-CURRENT and so far I haven't experienced any problems - except one panic caused by linux.ko and running edonkeyclc for linux (it was just experiment to see if it will work on 6.0-CURRENT). I suppose that there might be some problems related to SMP on 5.4 and I don't know what for are you using problematic servers and I don't know if it is smart to use 6.0-CURRENT but so far I have positive experince with it on problematic server and would rather stay with FBSD then switching to NetBSD or OpenBSD. Regards, gg. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD -STABLE servers repeatedly crashing
Hi, I have something like 20 boxes (Dell Power Edge 370, Fujitsu-Siemens PRIMERGY 200 and couple of dual AMD64 Fujitsu-Siemens) servers running 5.4-STABLE. So far, only machine that I have experienced freezing and was unable to get droped into KDB or to get any sort of vmcore was Dell Power Edge 1600SC (dual Xeon 2.4GHz with 4Gb). I have noticed that since it was running squid-2.5 linked to pthread when I have switched to oops which was compiled on 5.2.1 and linked to libc_r that machine stoped crashing (HTT disabled, IPFILTER also disabled configuration GENERIC). However, I have decided to experiment and upgraded to 6.0-CURRENT and so far I haven't experienced any problems - except one panic caused by linux.ko and running edonkeyclc for linux (it was just experiment to see if it will work on 6.0-CURRENT). I suppose that there might be some problems related to SMP on 5.4 and I don't know what for are you using problematic servers and I don't know if it is smart to use 6.0-CURRENT but so far I have positive experince with it on problematic server and would rather stay with FBSD then switching to NetBSD or OpenBSD. With what you're saying, maybe my problem is that I use IPFILTER and maybe it isn't an SMP problem? Should I switch to PF? -Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libstdc++ version bump.
Michael Nottebrock wrote: On Tuesday, 28. June 2005 18:21, Scot Hetzel wrote: Are you sure that the problem is with libstdc++ and not the above libraries? Yes, it's a well known-fact. In fact there might have been a break of ABI backwards-compatibility between gcc 3.3 and 3.4, too, but I'm not sure. There is one. I am currently beaten by it and have to put in manually a long path to libstdc++ in some of mine Makefiles. -- Best regards, Alexander. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libstdc++ version bump.
David O'Brien wrote: On Tue, Jun 28, 2005 at 06:44:02PM +0200, Michael Nottebrock wrote: On Tuesday, 28. June 2005 18:21, Scot Hetzel wrote: Are you sure that the problem is with libstdc++ and not the above libraries? Yes, it's a well known-fact. In fact there might have been a break of ABI backwards-compatibility between gcc 3.3 and 3.4, too, but I'm not sure. There was. 3.3 could support either the C++ ABI of GCC 3.2, in which there was an implementation bug; or the fixed ABI of 3.4. I had hoped we had gone with the fixed ABI rather than being G++ 3.2 compatible, but that is what users wanted at the time. Do I read it correctly that on 5.4 (with 3.4 in it) it is possible to convince lang/gcc33 to be binary compatible with system libraries? Do you have any link for it? -- Best regards, Alexander. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD -STABLE servers repeatedly crashing
Some people suggested so - pf is supposed to be faster then IPFILTER. However if you are experiencing machine freezing like I did on 5.4-STABLE I'm not sure this will help - if nothing else helps try 6.0-CURRENT. I've also noticed that it is running much faster with all debuging enabled then regular 5.4-STABLE on same hardware... Regards, gg. On Tue, 28 Jun 2005, Matt Juszczak wrote: With what you're saying, maybe my problem is that I use IPFILTER and maybe it isn't an SMP problem? Should I switch to PF? -Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD -STABLE servers repeatedly crashing
Some people suggested so - pf is supposed to be faster then IPFILTER. However if you are experiencing machine freezing like I did on 5.4-STABLE I'm not sure this will help - if nothing else helps try 6.0-CURRENT. I've also noticed that it is running much faster with all debuging enabled then regular 5.4-STABLE on same hardware... I dont think its a good idea to run 6.0-CURRENT production. I'm moving the main mail server to PF, keeping SMP on. Its also running 5.4-STABLE as of today. We'll see if any of this fixes anything. Regards, Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD -STABLE servers repeatedly crashing
FreeBSD 5.4-STABLE #11: Fri Apr 8 09:48:24 CDT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KSD-SMP 5:02PM up 80 days, 21:08, 1 user, load averages: 4.04, 3.33, 3.01 Yes, SMP is enabled, as is implied by the kernel config tag. (Very busy compilation, web and database server) -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://homecuda.com Emerald Coast: Buy / sell homes, cars, boats! http://genesis3.blogspot.comMusings Of A Sentient Mind On Tue, Jun 28, 2005 at 05:55:17PM -0400, Matt Juszczak wrote: Some people suggested so - pf is supposed to be faster then IPFILTER. However if you are experiencing machine freezing like I did on 5.4-STABLE I'm not sure this will help - if nothing else helps try 6.0-CURRENT. I've also noticed that it is running much faster with all debuging enabled then regular 5.4-STABLE on same hardware... I dont think its a good idea to run 6.0-CURRENT production. I'm moving the main mail server to PF, keeping SMP on. Its also running 5.4-STABLE as of today. We'll see if any of this fixes anything. Regards, Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] %SPAMBLOCK-SYS: Matched [freebsd], message ok ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libstdc++ version bump.
Alexander S. Usov wrote: David O'Brien wrote: On Tue, Jun 28, 2005 at 06:44:02PM +0200, Michael Nottebrock wrote: On Tuesday, 28. June 2005 18:21, Scot Hetzel wrote: Are you sure that the problem is with libstdc++ and not the above libraries? Yes, it's a well known-fact. In fact there might have been a break of ABI backwards-compatibility between gcc 3.3 and 3.4, too, but I'm not sure. There was. 3.3 could support either the C++ ABI of GCC 3.2, in which there was an implementation bug; or the fixed ABI of 3.4. I had hoped we had gone with the fixed ABI rather than being G++ 3.2 compatible, but that is what users wanted at the time. Do I read it correctly that on 5.4 (with 3.4 in it) it is possible to convince lang/gcc33 to be binary compatible with system libraries? Do you have any link for it? I think I have to clarify my question a bit: I have a program which is a mix of c++ fortran code. Fortran part is compiled with lang/ifc, so to link it I use something like ifort -o prog for_lib.a cpp_lib.a -l -lstdc++ Now I have to use one more library, which is not (yet) compatible with gcc 3.4 and up. If it matters -- this library is luabind (luabind.sf.net) and I don't really know of any alternatives to it (except tolua/tolua++ which are even more problematic). So to link my code now I have to rebuild a bunch of other packages using gcc33 and link it like that: ifort -o prog .. /usr/local/lib/gcc-lib/.../libstdc++.a Doing it this way is quite messy, provided that I have to build/use this code time to time on linux machines where it should be linked in absolutely different way. So the question is if it possible to convince lang/gcc33 to produce code binary compatible with system-wide gcc 3.4? -- Best regards, Alexander. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Fatal trap 12 while debugging a 4.11 kernel with remote gdb
Hello, I'm trying to debug a FreeBSD 4.11 kernel that has been compiled with makeoptions DEBUG=-g options DDB The remote machine is running FreeBSD 5.4 and I'm using devel/gdb6. I have no problems as long as I escape to the debugger after the kernel was loaded, but I like to trace something during the initialisation. I type 'boot -d', 'gdb' and 's' on the 4.11 machine and the following commands on the 5.4 machine: (kgdb) s Reply contains invalid hex digit 84 (kgdb) s Warning: Cannot insert breakpoint -1. Error accessing memory address 0xc02f09a8: Input/output error. At the same time of the second 'step' this happens with the 4.11 kernel: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xf0010502 fault code = supervisor read, page not present intruction pointer = 0x8:0xc02ed6b6 stack pointer = 0x10:0xc045de3c frame pointer = 0x10:0xc045de48 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = net tty bio cam Does anyone has a hint for me to prevent this? Thanks in advance Björn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD -STABLE servers repeatedly crashing
Yes, SMP is enabled, as is implied by the kernel config tag. (Very busy compilation, web and database server) Are you using PF? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Promise PDC40518 SATA150 and atacontrol detach/attach problem
Hi, I would like to hotswap hard disks (for backups) with a Promise PDC40518 SATA150 (a.k.a. S-ATA II 150 TX4). Both SATA hard disks on this controller are found while booting. I can mount and use the drives. And this works very nicely and fast. But if I detach a drive via atacontrol or via the SATA hotplug-able backplane then the drive is gone and cannot be re-attached anymore. # atacontrol list [...] ATA channel 5: Master: ad10 WDC WD2000JD-98HBB0/08.02D08 Serial ATA v1.0 Slave: no device present # atacontrol detach 5 # atacontrol attach 5 Master: no device present Slave: no device present Then I find the following messages in the log: for detaching: kernel: ad10: WARNING - removed from configuration for attaching: kernel: ata5-master: timeout sending command=ef kernel: ata5-master: error issueing SETFEATURES SET TRANSFER MODE command kernel: ata5-master: FAILURE - ATA_IDENTIFY timed out kernel: ata5-master: timeout sending command=ec kernel: ata5-master: error issueing ATA_IDENTIFY command Interestingly, in the booting process detection works fine (FreeBSD-5.4- Release #0 with the generic kernel): kernel: atapci1: Promise PDC40518 SATA150 controller port 0xb000-0xb0ff,0xb400-0xb47f mem 0xec80-0xec81,0xed00-0xed000fff irq 18 at device 10.0 on pci0 kernel: atapci1: failed: rid 0x20 is memory, requested 4 kernel: ata2: channel #0 on atapci1 kernel: ata3: channel #1 on atapci1 kernel: ata4: channel #2 on atapci1 kernel: ata5: channel #3 on atapci1 [...] kernel: ad6: 190782MB WDC WD2000JD-98HBB0/08.02D08 [387621/16/63] at ata3-master SATA150 kernel: ad10: 190782MB WDC WD2000JD-98HBB0/08.02D08 [387621/16/63] at ata5-master SATA150 Exists there a patch or a workaround for this problem? Thanks! Best regards, David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Upgrading i386 to amd64?
Is upgrading a i386 system to amd64 supported? Can I just build an amd64 kernel and keep the userland? -- Every sufficiently advanced magic is indistinguishable from technology - Arthur C Anticlarke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On 28-Jun-05, at 1:01 PM, Xin LI wrote: We care about why MySQL appears to be slower, how to improve the situation, and not numbers from poorly done benchmarks which ignored the effect of debugging options, version, disk mount options, etc., which is IMHO meaningless. Maybe a key feature of the new FreeBSD installer would be to automatically tune the user's system (including kernel and other loader/sysctl tunings) according to installed ports :-) To make benchmarks a help provided to improve FreeBSD, a better start would be to run MySQL with profiling options compiled in, to find out the bottleneck and report them (maybe with patches if you have some idea). Cheers, -- Xin LI delphij frontfree nethttp://www.delphij.net/ See complete headers for GPG key and other information. I'm by far not a developer or a programmer, but I am a sysadmin running MySQL on FreeBSD 4.x and 5.x And I am having performance problems running FreeBSD 5.4 + SMP with MySQL. I don't seem to have these problems on my other 4.x servers. The Hardware: Dell PowerEdge 2850 Dual 2.8 XEON 4Gig of RAM Raid controller PERC 4/DC 2x 36Gig 10K drives running Raid 1 for the system 4x72Gig 15K drives running raid 0+1 for where to put my mysql innodb based database. The database is about 10Gigs in size all InnoDB tables. This box is currently setup to slave from the master. My goal is to get the box to replace the master. Currently it is not used in production, so I am free to do what I want to this box. I'm running MySQL 4.1.12 I noticed a couple things PAE kernel (no SMP) System crashed while simply slaving from the master. The system seemed stable doing nothing for 36 hours prior to this. SMP Kernel System was stable, however slaving from the master seemed to me VERY slow. GENERIC Kernel System was stable, and slaving was quite a bit faster. My Goal, is to provide some information that the real miracle workers, the programmers and developers that can contribute to FreeBSD help me identify the problems and where they lie and how to best go about finding solutions for these problems. So my question is. What kind of information can I provide you all to help identify the problems that I'm seeing, and quite possibly others are seeing. Xin, you are talking about something regarding profiling of mysql. If you can point me in the right direction to setup my box to provide the necessary information, I have the time and the will to provide the right information so we can move forward in making FreeBSD the Operating System we all want it to be. I also promise to post some usable information for other people wanting to setup MySQL on FreeBSD once we have identified where are problems lie. This is probably the best way I, myself can contribute back to the FreeBSD Community. Thank you, Stephane. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA vs SCSI ...
On 27 Jun, Artem Kuchin wrote: For the last 6 month i really think that if you don't need something high-end scsi then you should go for SATA. There are test on sites such as Tom's hardware guide and ixbt.com. They show then on sequrncial read there is no difference between scsi and sata. Acatuallty, modern hdds use the same mechanics for sata and scsi versions of them. The brains (electronics) on the hdds are different of course. However, when it comes to random read/writes scsi wins because of command queueing. This was an issue until recently, Recently SATA with NCQ became widly available. Test show that some of those SATA disks with NCW ***WIN*** over scsi 320. The test envolve artificialy random read/write tests as well as real application benchmarking. I din't rememeber where excatly i saw the tests on those site, but you could search. SCSI command queuing also allows you to turn off write-caching on the drive without taking the tremendous performance hit that you'll see if you turn off write-caching on an ATA drive (without NCQ). Soft updates assumes that the drive does not do write-caching and that the data is on the platter when the drive acknowledges the write. If this assumption is violated, a power failure that causes the loss of the unwritten data in the drive's write cache may cause the on-disk state to be inconsistent in a way that is not fixable by a background fsck. I'm also under the impression that consumer-grade drives generally write entire tracks at once so that they can dispense with the need for sector headers and inter-sector gaps. If only one sector is being written, the drive will need to read the entire track (if it is not in cache), update the in-memory copy, and then rewrite the entire sector. For most users, this is probably a good capacity vs. performance tradeoff. I don't know about modern drives, but back in the olden days when I used SMD drives, the per-sector overhead was 80+ bytes when using 512 byte sectors. I would not expect much of a performance hit if the disk is used to store jpegs and mp3s, but random write performance is likely to suffer, especially if write-caching is disabled. Also, a power failure while a write is in progress is more likely to corrupt data in an unrelated file that happens to occupy the same track and is also likely to cause inconsistencies that can't be fixed by a background fsck. BTW, even with an UPS monitored by sysutils/nut, I've had a non-trival number of ungraceful shutdowns caused by power problems (power cord between UPS and computer falls out, sudden battery death, etc.). For this reason, all of my machines (other than my PVR) use SCSI disks with WCE set to 0. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: smbfs
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maxim Kizik Sent: 28. juni 2005 20:35 To: [EMAIL PROTECTED] Subject: smbfs Good Afternoon. After upgrading my system from FreeBSD 4.10 to FreeBSD 5.3, I found mount_smbfs -N broken. The error message is mount_smbfs: unable to open connection: syserr = Authentication error. However, the keyboard interactive password works normally. The problem still persists in 5.4p2. I need this feature strongly because of running automatic backup procedures. Is there any solution? -- Maxim Kizik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Don't have this problem, using mount_smbfs -N -I /XXX/YYY etc. On .4-RELEASE FreeBSD 5.4-RELEASE #4: Sun May 8 01:57:26 CEST 2005 - Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Having just read this thread, I'd like to say that all messages are making valid points, and all participants agree with each other. However, the argumentative discussion is creating a lot of noise. Meanwhile, there are people doing meaningful work on this. A good standby would be to patch your 5.4 with ATAMKIII. As a CURRENT user, i'd like to state that this code is very stable, although I havn't done benchmarks, valid or otherwise. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
I also quickly put a wiki together to help me document any kind of testing or patching we can try. Feel free to contribute. My hope is we can refer others to this document, and not create too much noise on this list as others have suggested is being created (the noise that is). I hope this can help us out to get MySQL humming on -STABLE, if it isn't already. Thanks, Stephane On 28-Jun-05, at 5:08 PM, Stephane Raimbault wrote: On 28-Jun-05, at 1:01 PM, Xin LI wrote: We care about why MySQL appears to be slower, how to improve the situation, and not numbers from poorly done benchmarks which ignored the effect of debugging options, version, disk mount options, etc., which is IMHO meaningless. Maybe a key feature of the new FreeBSD installer would be to automatically tune the user's system (including kernel and other loader/sysctl tunings) according to installed ports :-) To make benchmarks a help provided to improve FreeBSD, a better start would be to run MySQL with profiling options compiled in, to find out the bottleneck and report them (maybe with patches if you have some idea). Cheers, -- Xin LI delphij frontfree nethttp://www.delphij.net/ See complete headers for GPG key and other information. I'm by far not a developer or a programmer, but I am a sysadmin running MySQL on FreeBSD 4.x and 5.x And I am having performance problems running FreeBSD 5.4 + SMP with MySQL. I don't seem to have these problems on my other 4.x servers. The Hardware: Dell PowerEdge 2850 Dual 2.8 XEON 4Gig of RAM Raid controller PERC 4/DC 2x 36Gig 10K drives running Raid 1 for the system 4x72Gig 15K drives running raid 0+1 for where to put my mysql innodb based database. The database is about 10Gigs in size all InnoDB tables. This box is currently setup to slave from the master. My goal is to get the box to replace the master. Currently it is not used in production, so I am free to do what I want to this box. I'm running MySQL 4.1.12 I noticed a couple things PAE kernel (no SMP) System crashed while simply slaving from the master. The system seemed stable doing nothing for 36 hours prior to this. SMP Kernel System was stable, however slaving from the master seemed to me VERY slow. GENERIC Kernel System was stable, and slaving was quite a bit faster. My Goal, is to provide some information that the real miracle workers, the programmers and developers that can contribute to FreeBSD help me identify the problems and where they lie and how to best go about finding solutions for these problems. So my question is. What kind of information can I provide you all to help identify the problems that I'm seeing, and quite possibly others are seeing. Xin, you are talking about something regarding profiling of mysql. If you can point me in the right direction to setup my box to provide the necessary information, I have the time and the will to provide the right information so we can move forward in making FreeBSD the Operating System we all want it to be. I also promise to post some usable information for other people wanting to setup MySQL on FreeBSD once we have identified where are problems lie. This is probably the best way I, myself can contribute back to the FreeBSD Community. Thank you, Stephane. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
speaking of noise how about I include a URL http://www.segr.ca/index.php/FreeBSD/MySQL sheesh... sorry to all. Stephane On 28-Jun-05, at 8:55 PM, Stephane Raimbault wrote: I also quickly put a wiki together to help me document any kind of testing or patching we can try. Feel free to contribute. My hope is we can refer others to this document, and not create too much noise on this list as others have suggested is being created (the noise that is). I hope this can help us out to get MySQL humming on -STABLE, if it isn't already. Thanks, Stephane On 28-Jun-05, at 5:08 PM, Stephane Raimbault wrote: On 28-Jun-05, at 1:01 PM, Xin LI wrote: We care about why MySQL appears to be slower, how to improve the situation, and not numbers from poorly done benchmarks which ignored the effect of debugging options, version, disk mount options, etc., which is IMHO meaningless. Maybe a key feature of the new FreeBSD installer would be to automatically tune the user's system (including kernel and other loader/sysctl tunings) according to installed ports :-) To make benchmarks a help provided to improve FreeBSD, a better start would be to run MySQL with profiling options compiled in, to find out the bottleneck and report them (maybe with patches if you have some idea). Cheers, -- Xin LI delphij frontfree nethttp://www.delphij.net/ See complete headers for GPG key and other information. I'm by far not a developer or a programmer, but I am a sysadmin running MySQL on FreeBSD 4.x and 5.x And I am having performance problems running FreeBSD 5.4 + SMP with MySQL. I don't seem to have these problems on my other 4.x servers. The Hardware: Dell PowerEdge 2850 Dual 2.8 XEON 4Gig of RAM Raid controller PERC 4/DC 2x 36Gig 10K drives running Raid 1 for the system 4x72Gig 15K drives running raid 0+1 for where to put my mysql innodb based database. The database is about 10Gigs in size all InnoDB tables. This box is currently setup to slave from the master. My goal is to get the box to replace the master. Currently it is not used in production, so I am free to do what I want to this box. I'm running MySQL 4.1.12 I noticed a couple things PAE kernel (no SMP) System crashed while simply slaving from the master. The system seemed stable doing nothing for 36 hours prior to this. SMP Kernel System was stable, however slaving from the master seemed to me VERY slow. GENERIC Kernel System was stable, and slaving was quite a bit faster. My Goal, is to provide some information that the real miracle workers, the programmers and developers that can contribute to FreeBSD help me identify the problems and where they lie and how to best go about finding solutions for these problems. So my question is. What kind of information can I provide you all to help identify the problems that I'm seeing, and quite possibly others are seeing. Xin, you are talking about something regarding profiling of mysql. If you can point me in the right direction to setup my box to provide the necessary information, I have the time and the will to provide the right information so we can move forward in making FreeBSD the Operating System we all want it to be. I also promise to post some usable information for other people wanting to setup MySQL on FreeBSD once we have identified where are problems lie. This is probably the best way I, myself can contribute back to the FreeBSD Community. Thank you, Stephane. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
xf86enableIO error 28Feb 2005 Snapshots for FreeBSD available
How could I fix this error? Thanks -- «†£(r)(r)Ø(r) IMPORTANT NOTICE: This e-mail and any attachment to it is intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libstdc++ version bump.
On Tue, Jun 28, 2005 at 09:47:03AM -0700, Alfred Perlstein wrote: No, it's not that. It's just that when we decided to upgrade gcc/g++ in the 5.2.1 era someone didn't bump the library version for libstdc++. It would have been a two second change, but instead it appears that it was decided that early adopters REALLY needed to be put in their place for being stupid enough... to be early adopters. No, it wasn't that simple..there were many places where the ABI was broken, and it wasn't feasible to fix them all. Kris pgpbrbb9WkfLn.pgp Description: PGP signature
