Re: GPU suggestion: gtx 750ti
Op 2015-09-05 om 03:04 schreef Dot Yet: one thing though, there is some minor tearing, not sure if there is away to fix it. any suggestions? Try fiddling with vsync in nvidia-settings (port: x11/nvidia-settings), in particular which monitor it syncs to. What media player do you use? I've had great success with multimedia/mpv with vdpau support. - Pieter ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
On Monday 12 December 2011 14:47:57 O. Hartmann wrote: Not fully right, boinc defaults to run on idprio 31 so this isn't an issue. And yes, there are cases where SCHED_ULE shows much better performance then SCHED_4BSD. [...] Do we have any proof at hand for such cases where SCHED_ULE performs much better than SCHED_4BSD? Whenever the subject comes up, it is mentioned, that SCHED_ULE has better performance on boxes with a ncpu 2. But in the end I see here contradictionary statements. People complain about poor performance (especially in scientific environments), and other give contra not being the case. Within our department, we developed a highly scalable code for planetary science purposes on imagery. It utilizes present GPUs via OpenCL if present. Otherwise it grabs as many cores as it can. By the end of this year I'll get a new desktop box based on Intels new Sandy Bridge-E architecture with plenty of memory. If the colleague who developed the code is willing performing some benchmarks on the same hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most recent Suse. For FreeBSD I intent also to look for performance with both different schedulers available. O. In my spare time I do some stuff which can be considered HPC. If I recall correctly the most loud supporters of the notion that SCHED_BSD is faster than SCHED_ULE are using more threads than there are cores, causing CPU core contention and more importantly unevenly distributed runtimes among threads, resulting in suboptimal execution times for their programs. Since I've never actually seen that code in question it's hard to say whether or not this unfair distribution actually results in lower throughput or that it simply violates an assumption in the code that each thread takes about as long to finish its task. Although I haven't actually benchmarked the two schedulers directly, I have no reason to suspect SCHED_ULE of suboptimal performance because: 1) A program model where there are N threads on N cores which take work items from a shared queue until it is empty has almost perfect scaling on SCHED_ULE (I get 398% CPU usage on a quadcore) 2) The same program on Linux (dual boot) compiled with exactly the same compiler and flags runs slightly slower. I think this has to do with VM differences. What I'm trying to say is that until someone actually shows some code which has demonstrably lower performance on SCHED_ULE and this is not caused by IMHO improper timing dependencies between threads I'd say that there is no cause for concern here. I actually expect performance differences between the two schedulers to show in problems which cause a lot more contention on the CPU cores and use lots of locks internally so threads are frequently waiting on each other, for instance the MySQL benchmarks done a couple of years ago by Kris Kennaway. Aside from algorithmic limitations (SCHED_BSD doesn't really scale all that well), there will always exist some problems in which SCHED_BSD is faster because it by chance has a better execution order for these problems... The good thing is people have a choice :-). I'm looking forward to the results of your benchmark. -- Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.).
On Saturday 09 October 2010 16:55:35 Andriy Bakay wrote: Do you know any more convenient way (except make buildword, etc.) to upgrade/update several boxes to STABLE on regular basis? Something like freebsd-update or maybe some process, tips, tricks, etc? Thanks. Here's how I do it: 1) Build server: make buildworld make buildkernel 2) Other servers: export / via NFS Repeat for each other server on build server: mount boxN:/ /mnt make installkernel DESTDIR=/mnt -DNO_FSCHG make installworld DESTDIR=/mnt -DNO_FSCHG umount /mnt Note that I use a single filesystem for / and /usr. Obviously if those are separate filesystems more NFS exports and mount commands are necessary. Before the first run all immutable flags need to be removed from the target box, otherwise the install will fail (i.e. chflags -R noschg /). On 2010-10-08, at 6:11, Pete French petefre...@ticketswitch.com wrote: Ok. But how stable (production ready) the FreeBSD-8-STABLE is? What is your opinion? I am running 8-STABLE from 27th September on all our ptoduction machines (from webservers to database servers to the company mail server) and it is fine. I am going to update again over the next few days, as there are some ZFS fixes in which I want - and which may benifit you too - so I will be able to report back next week as to how a more recent version behaves. In general though, I have never had problems running STABLE on prodyction systems over the years. Of course what I do is to test it on a singlre machine before rolling it out (a leaf in a webfarm so if it goes down it wont affect the business) but it is usually fine. keep an eye on -STABLE mailing list though, as that is where problems arise. I watch that, and also the dailing commits, either here http://www.freshbsd.org/?branch=RELENG_8project=freebsdcommitter=modul e=q= or here http://www.secnetix.de/olli/FreeBSD/svnews/?p=stable/8 Just to see whats going into the tree relative to whats being discussed. It only takes a few minutes a dat to monitor the mailin lists and the commits, and the result is that we've been running STABLE for a very long time (close to a decade I suspect) with great success. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Inconsistent IO performance
On Saturday 14 August 2010 05:57:51 Kevin Oberman wrote: Date: Sat, 14 Aug 2010 11:33:57 +0800 From: TJ Varghese t...@tjvarghese.com The deviation in your disk I/O isn't a major surprise (to me anyway), given the system specs. What *does* surprise me is your abysmal I/O speeds in general. 18MB/sec min, 24MB/sec max?! ICH6-M can do a lot more than that. Something isn't right. it's possible that the hw is...suboptimal. From a 2005 post, http://forum.thinkpads.com/viewtopic.php?f=2t=13036start=0 Check out the link to the hddbenchmark, http://img57.imageshack.us/img57/6430/hddbenchmark1no.jpg Thanks, TJ! I guess the disk IO on these boxes simply sucks. Looks like the 34.75MB/sec sequential read speed is all I can hope for. I'm guessing the SATA-PATA converter is to blame. Oh, well. But all of this does not address my real question, why is performance so inconsistent? I agree that it sucks, but that does not explain why it suck so much worse on one run than another. I'm still baffled. My backup disk normally odes not leave my office storage cabinet except when it is in the computer being written, so I don't have it handy ATM. I will try a couple of things on Monday, though. Perhaps the measurements are taken while the laptop is on a different (less/more stable) surface each time? Disk vibrations could account for the differences. Check out this cool video from Sun: http://news.cnet.com/8301-13556_3-10138666-61.html No idea how this affects sequential read and write workloads however. -- Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
On Wednesday 14 April 2010 15:19:13 Andriy Gapon wrote: on 14/04/2010 02:21 Maho NAKATA said the following: 2. install ports/math/gotoblas (manual download required) make install Do you know how gotoblas on Linux was obtained? Was it built from source? Has it come pre-packaged? If so, can you find out details of its build configuration? Thanks! I think the best test would be to run a statically compiled linux binary on FreeBSD. That way the compiler settings are exactly the same. - Pieter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: xen vps issue loading disk?
On Tuesday 06 April 2010 23:40:32 Henrik Hudson wrote: Hey Stable, I recently setup a Xen VPS running FreeBSD and the system came with 8.0-REL-p2 on it. I rebuilt world and then kernel using a 100% stock GENERIC i386. after installkernel and reboot the system stops at trying to load disk: /dev/ad0s1a (or similar; i forget the exact device node at the moment). I'm able to reset and boot kernel.old fine. Did I miss something or is there a regression somewhere? Henrik There is a predefined kernel configuration file for Xen: XEN. You might try building that. -- Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: hardware for home use large storage
On Wednesday 10 February 2010 05:28:57 Dan Langille wrote: Boris Kochergin wrote: Peter C. Lai wrote: On 2010-02-09 06:37:47AM -0500, Dan Langille wrote: Charles Sprickman wrote: On Mon, 8 Feb 2010, Dan Langille wrote: Also, it seems like people who use zfs (or gmirror + gstripe) generally end up buying pricey hardware raid cards for compatibility reasons. There seem to be no decent add-on SATA cards that play nice with FreeBSD other than that weird supermicro card that has to be physically hacked about to fit. Mostly only because certain cards have issues w/shoddy JBOD implementation. Some cards (most notably ones like Adaptec 2610A which was rebranded by Dell as the CERC SATA 1.5/6ch back in the day) won't let you run the drives in passthrough mode and seem to all want to stick their grubby little RAID paws into your JBOD setup (i.e. the only way to have minimal participation from the hardware RAID is to set each disk as its own RAID-0/volume in the controller BIOS) which then cascades into issues with SMART, AHCI, triple caching/write reordering, etc on the FreeBSD side (the controller's own craptastic cache, ZFS vdev cache, vmm/app cache, oh my!). So *some* people go with something tried-and-true (basically bordering on server-level cards that let you ditch any BIOS type of RAID config and present the raw disk devices to the kernel) As someone else has mentioned, recent SiL stuff works well. I have multiple http://www.newegg.com/Product/Product.aspx?Item=N82E16816132008 cards servicing RAID-Z2 and GEOM_RAID3 arrays on 8.0-RELEASE and 8.0-STABLE machines using both the old ata(4) driver and ATA_CAM. Don't let the RAID label scare you--that stuff is off by default and the controller just presents the disks to the operating system. Hot swap works. I haven't had the time to try the siis(4) driver for them, which would result in better performance. That's a really good price. :) If needed, I could host all eight SATA drives for $160, much cheaper than any of the other RAID cards I've seen. The issue then is finding a motherboard which has 4x PCI Express slots. ;) You should be able to put PCIe 4x card in a PCIe 16x or 8x slot. For an explanation allow me to quote wikipedia: A PCIe card will fit into a slot of its physical size or bigger, but may not fit into a smaller PCIe slot. Some slots use open-ended sockets to permit physically longer cards and will negotiate the best available electrical connection. The number of lanes actually connected to a slot may also be less than the number supported by the physical slot size. An example is a x8 slot that actually only runs at ×1; these slots will allow any ×1, ×2, ×4 or ×8 card to be used, though only running at the ×1 speed. This type of socket is described as a ×8 (×1 mode) slot, meaning it physically accepts up to ×8 cards but only runs at ×1 speed. The advantage gained is that a larger range of PCIe cards can still be used without requiring the motherboard hardware to support the full transfer rate—in so doing keeping design and implementation costs down. -- Pieter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: A script that modifies /etc/fstab to mount devices via glabel
On Monday 28 December 2009 21:17:41 Christian Laursen wrote: Hi there, I wrote a script that modifies fstab so that UFS filesystems are mounted via their UFS IDs and swap partitions are labeled with glabel in order to access them that way. It works for me on at least FreeBSD 7.2 and 8.0. Use at your own risk. For swap devices it is neccesary to label the device in order to recognize it later and that requires that swap is turned off briefly. The script requires perl to run. The script is here: http://borderworlds.dk/utils/fstab-glabel.pl Feel free to use it if you find it useful. Works as advertised, thank you! It is probably faster to extract the label from glabel status -s node instead of using dumpfs though. - Pieter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_8 buildworld broken?
On Wednesday 09 December 2009 01:50:03 Pieter de Goeje wrote: I've blown away /usr/obj, checked out a fresh source tree, but no luck: cc -O2 -pipe -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -I. -I/data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools -I/data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc/../../../contrib/libobjc/ob jc -I/data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc/../../../contrib/libobjc -I/data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc/../../../contrib/gcc/config -I/data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc/../../../contrib/gcc -I/data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc/../../../contrib/gcclibs/in clude -fexceptions -frandom-seed=RepeatabilityConsideredGood -std=gnu99 -fstack-protector -c /data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc/../../../contrib/libobjc/enco ding.c In file included from ./tm.h:4, from /data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc/../../../contrib/libobjc/enco ding.c:34: ./options.h:457: error: redeclaration of enumerator 'OPT_Werror' ./options.h:398: error: previous definition of 'OPT_Werror' was here *** Error code 1 Stop in /data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc. *** Error code 1 When trying to build on: FreeBSD 8.0-STABLE #9: Tue Dec 1 21:48:13 CET 2009 amd64 The problem only occurs when doing a parallel make world (make -j8 buildworld). In the past I have always successfully built world using -j4. I guess the recent upgrade of this machine from dual core to quad core just made the problem visible. - Pieter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_8 buildworld broken?
On Wednesday 09 December 2009 20:32:39 Kevin Oberman wrote: Date: Wed, 09 Dec 2009 17:36:26 +0100 From: ocean ocean_i...@yahoo.it Sender: owner-freebsd-sta...@freebsd.org Pieter de Goeje wrote: The problem only occurs when doing a parallel make world (make -j8 buildworld). In the past I have always successfully built world using -j4. I guess the recent upgrade of this machine from dual core to quad core just made the problem visible. - Pieter actually that's not the only problem with buildworld in 8.0. -march isn't added to CFLAGS using CPUTYPE in make.conf, you should add it manually to CFLAGS. Actually, the way you specified CFLAGS overrides CPUTYPE. AFAIK you should set CFLAGS/CPUTYPE like this: CPUTYPE?= CFLAGS+=... Though bothering with CPUTYPE or CFLAGS is actually a waste of time if you ask me. I've never observed any measurable improvement in the speed of the system by setting these. Note that most ports which DO benefit from specialized CFLAGS (mplayer comes to mind) have an option called WITH_OPTIMIZED_CFLAGS. on another thread was said that make delete-old is also broken (and i suspect also delete-old-libs), so options in src.conf are pretty useless. all the problems seems to be triggered by Makefile.incl These options are not useless. You can for instance use them to reduce build time and/or install only the binaries required for a jail or an embedded system. In what way is delete-old broken? I agree that src.conf often does not work. Just try to build a system with 'WITHOUT_OPENSSH='. PR with patch to Makefile.inc1 submitted by b.f. three or four months ago. So far, no response. I have seen the really bad suggestion that somehow files not built due to src.conf entries be added to the list of old files to be deleted. PLEASE DON'T DO THAT! The single most important use I have for /etc/src.conf is to avoid system upgrades over-writing the files for ssh and BIND when the ports are installed to overwrite those in the base system. I certainly don't want a delete-old to try to delete the files installed from ports. I agree completely. Obsolete files is there for files that will never be built again and are generally useless/broken (or break other stuff) when left on the filesystem. It's called ObsoleteFiles for a reason :) And, yes, this is a fairly common practice, especially for BIND. There is good reason that the OVERWRITE_BASE option is offered when you install BIND from ports. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_8 buildworld broken?
On Wednesday 09 December 2009 23:14:13 ocean wrote: Pieter de Goeje wrote: Actually, the way you specified CFLAGS overrides CPUTYPE. AFAIK you should set CFLAGS/CPUTYPE like this: CPUTYPE?= CFLAGS+=... Though bothering with CPUTYPE or CFLAGS is actually a waste of time if you ask me. I've never observed any measurable improvement in the speed of the system by setting these. Note that most ports which DO benefit from specialized CFLAGS (mplayer comes to mind) have an option called WITH_OPTIMIZED_CFLAGS. i specified it with CPUTYPE?=... and wasn't working for buildworld, had to add it in CFLAGS. also doing make buildworld CPUTYPE=... didn't work. It works for me. Just tried with CPUTYPE?=nocona and CFLAGS+=-O3 which resulted in these CFLAGS: -O2 -pipe -O3 -march=nocona when building tcsh for example. Not everything build during buildworld honors these settings btw. My point still stands though, I can't see how any of the base tools would benefit from higher optimization levels. The only thing that could possibly benefit is the kernel, but the kernel uses COPTFLAGS (and CPUTYPE). on my (old) notebook i noticed good improvements in the boot process, it was taking lot of time to start maybe one minute, with a recompiled kernel with ipv6. without ipv6 with tweaked CFLAGS boots in less than 30 seconds (~24 seconds). Most likely the difference was cause by leaving out IPv6, not by the CFLAGS. - Pieter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RELENG_8 buildworld broken?
I've blown away /usr/obj, checked out a fresh source tree, but no luck: cc -O2 -pipe -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -I. -I/data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools -I/data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc/../../../contrib/libobjc/objc -I/data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc/../../../contrib/libobjc -I/data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc/../../../contrib/gcc/config -I/data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc/../../../contrib/gcc -I/data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc/../../../contrib/gcclibs/include -fexceptions -frandom-seed=RepeatabilityConsideredGood -std=gnu99 -fstack-protector -c /data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc/../../../contrib/libobjc/encoding.c In file included from ./tm.h:4, from /data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc/../../../contrib/libobjc/encoding.c:34: ./options.h:457: error: redeclaration of enumerator 'OPT_Werror' ./options.h:398: error: previous definition of 'OPT_Werror' was here *** Error code 1 Stop in /data/FreeBSD/FreeBSD-8.x/src/gnu/lib/libobjc. *** Error code 1 When trying to build on: FreeBSD 8.0-STABLE #9: Tue Dec 1 21:48:13 CET 2009 amd64 - Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 7.1 Release and usb keyboard/mouse problems
On Wednesday 21 January 2009 13:55:11 Andrei Kolu wrote: Martin wrote: Am Sat, 17 Jan 2009 21:23:09 +1100 schrieb Tony Maher tonyma...@optusnet.com.au: Hello, I have been running FreeBSD 7 from around 2008-10-20 and experienced the occasional problems with usb mouse and keyboard. The mouse pointer slowly drift to a corner of the screen and not respond, and the keyboard would become unresponsive. Unplugging and plugging back in fixed the problem. This would happen a few times per week. Hi, I've reported problems like this on -STABLE more than once already. Apparently it is a very uncommon problem for the developers. I have to say that all my new PCs and the new laptop has problems with USB keyboards and mice generally. The laptop (IBM Thinkpad T60p) has the most problems, -STABLE switches the USB devices off in intervals of about 2h. I have updated (flashed) my BIOS firmware on this mainboard here (Gigabyte GA-EP35C-DS3R rev 2.1) to the recent firmware F4a (it's a 6 month old beta release). The problem worsened now. I cannot get my USB mouse working until I reattach it physically. This is not a problem on other OSes, it seems. During device detection and initialization of uhci/ehci my USB-mouse is switched off and does not get power anymore. I get the same effect on -CURRENT as of yesterday. Mouse is Logitech G5, btw. I tried various USB settings in BIOS. USB mouse support on/off, USB legacy device support on/off. What else can I do? This is very annoying. (I wonder if it can be the source of many problems that people report here about umass devices.) Hi, I have similar problem with Gigabyte GA-X48-DS4- I can't boot from usb flash drive or usb floppy drive 9times of 10. My APC ups was recognized only after OS is booted up and usb cable reinserted. Looks like this is Gigabyte problem only- all other motherboards work without any usb issues. Bios upgrade does not help. Changing any bios setting does not help either. I have a Gigabyte GA-P35-DS3R w/ a Logitech G5 mouse and usb keyboard. I had to switch to usb2 on freebsd 8-current for the keyboard to attach after boot. I have enabled usb keyboard support in the BIOS (otherwise the keyboard cannot be used during the boot process). Everything is working fine now. -- Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fxp performance with POLLING
On Friday 03 October 2008, Bartosz Stec wrote: Hello again :) With POLLING enabled I experience about 10%-25% performance drop when copying files over network. Tested with both SAMBA and NFS. Is it normal? Yes. You don't want to use polling unless you set kern.hz to 1 or something in that range. If you have a NIC with interrupt moderation, polling should almost never be necessary. Note that polling can still be useful for routers, because it allows you to have a much more responsive system even when handling heavy network traffic. -- Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Thursday 05 June 2008, Paul Schmehl wrote: --On Thursday, June 05, 2008 10:23:55 -0400 John Baldwin [EMAIL PROTECTED] wrote: FWIW, at Y! 6.3 is more stable than 6.2 (I had a list of about 10 patches for known deadlocks and kernel panics that were errata candidates for 6.2 that never made it into RELENG_6_2 but all of them are in 6.3). We also have many machines with bge(4) and from our perspective 6.3 has less issues with bge0 devices than 6.2. I'm glad to hear that. I have a server that uses bce, and it was completely non-functional until I hunted down some beta code that made it usable. I'd like to upgrade, but this is a critical server with no redundancy (and it's a hobby site with no money to pay for expensive support), and I'm not about to upgrade unless I know for certain the problems won't reoccur, because I have to upgrade remotely and pay money if the system goes down. The problems with that driver were bad enough when the server was being configured in my study. (The system would lock up, and only a hard reboot would restore networking.) It would be hell trying to troubleshoot problems if I had to drive the 45 miles to the hosting site and spend a night there trying to get the server back up, then go to work the next day. # uname -a FreeBSD www.stovebolt.com 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 #2: Mon Oct 16 15:38:02 CDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 # grep bce /var/run/dmesg.boot bce0: Broadcom NetXtreme II BCM5708 1000Base-T (B1), v0.9.6 mem 0xf400-0xf5ff irq 16 at device 0.0 on pci9 bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz miibus0: MII bus on bce0 bce0: Ethernet address: 00:13:72:fb:2a:ad bce1: Broadcom NetXtreme II BCM5708 1000Base-T (B1), v0.9.6 mem 0xf800-0xf9ff irq 16 at device 0.0 on pci5 bce1: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz miibus1: MII bus on bce1 bce1: Ethernet address: 00:13:72:fb:2a:ab # grep bce0 /var/log/messages May 2 09:10:31 www kernel: bce0: link state changed to DOWN May 2 09:10:39 www kernel: bce0: link state changed to UP May 25 07:49:49 www kernel: bce0: link state changed to DOWN May 25 07:50:31 www kernel: bce0: link state changed to UP May 26 21:28:36 www kernel: bce0: link state changed to DOWN May 26 21:28:40 www kernel: bce0: link state changed to UP May 27 13:13:21 www kernel: bce0: link state changed to DOWN May 27 13:13:31 www kernel: bce0: link state changed to UP It's been like that since the server was installed. So, if I upgrade to 6.3 or 7.0, am I still going to experience these problems? Is the server going to stop working entirely? How can I know that for sure before starting an upgrade? [...] There's a really easy way to test this. Build install a new kernel, but keep the old kernel around (by default it's in /boot/kernel.old). If the problem is gone, do the upgrade as usual. If it's still there, you know upgrading won't fix it and you don't waste time; simply rename kernel.old to kernel. This even works with 7.0 provided that you leave COMPAT_FREEBSD6 in the kernel configuration file. -- Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: arp: unknown hardware address format (0x0000) ?
On Tuesday 01 April 2008, Abdullah Ibn Hamad Al-Marri wrote: Hello, Did you see these weird msgs before? I didn't see any of them when I was using i386 and 6.x over 2 years. I see these all the time. I'm on a really large network, so I always assumed they originated from some misbehaving hosts. For all I know, these messages can be ignored. -- Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recovering from the 6.3 xorg mess
On Monday 17 March 2008, Robert Chalmers wrote: Well, I suppose this will eventually get to the original poster. I too have just gone through this nightmare. But, I short circuited it all. I went to a clean install of 7.0-RELEASE. Ah ha. Easy. Nope. The gremlins were waiting. So basically here's what I did. When I loaded the new system, I installed EVERYTHING I could enable. If there was an option, I installed it. Beautiful. Rebooted - X blah blah blah of course not. Fiddled with the xogconfig and made lots of xorg.config attempts, then realised - looking at the log - that it couldn't find the S3 driver. Yes, ancient S3 card in this box. All of 8 years old. So - took a clue from the log, and went into I think, like, xorg-drivers, and looked at the Makefile, which had everything in it. I commented out the things I would never need - mouses, and video - which is all that is in there, and left in the obvious ones, including some that might come in handy one day and typed Make install clean Now it all works. Well, as soon as I figure out some of the other mystical incantations - worse than World of War this lot. But bottom lline. Go into that xorg-driveers directory and check the Makefile, then make install clean and lots of things start happening. And I add - this is after a clean install where I said Just do it ... yea right. :-) Sorry I can't check those directories - I'm currently trying to port in VNC I live in hope. Robert This is the reason why it is recommended to install x11/xorg. It will install all necessary drivers, servers, fonts and clients automatically. Installing x11-servers/xorg-server is not enough, because it doesn't install any drivers (it used to do this before Xorg 7 existed). -- Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_7: interrupt eating whole cpu core
On Friday 08 February 2008, Tom Evans wrote: On Fri, 2008-02-08 at 17:14 +0100, Dominic Fandrey wrote: Tom Evans wrote: If I try to turn on DMA, I just get WDMA2, which just doesn't cut it: I think any DMA mode is fast enough to handle a DVD drive. There's just no necessity for more. WDMA is not UDMA. Any UDMA variant would be enough. WDMA2 provides a maximum of 16MiB/s, which will frequently lead to buffer underruns viewing a DVD. UDMA2 provides a maximum of 33MiB/s, which IS plenty. DVD video is encoded at max. ~7Mbit/sec, which is way below 16MB/sec. You should have no problems viewing dvds. # atacontrol mode acd0 udma5 current mode = WDMA2 Same as for me. I'm satisfied with the speed of the drive. I'm rarely satisfied - I'm quite often not bothered enough to pursue :) Tom -- Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP on FreeBSD 6.x and 7.0: Worth doing?
On Saturday 22 December 2007, Brett Glass wrote: I will need to build several Web caches over the next few months, and just took advantage of the Christmas lull (and a snowy day, when I couldn't work outside) to test FreeBSD 7.0 BETA 4 to see how it will perform at this task. I built up a 4 core FreeBSD box, and asked a friend who's a Linux fanatic to do the same with Linux on identical hardware. I didn't watch closely how he installed everything, but asked him not to tune it beyond setting it up properly for SMP. We then ran a test suite in which a client starts several processes. Each uses wget to fetch a series of objects in rapid succession via the cache. The fetches done by each process are the same batch of URLS, but shuffled differently, so each URL will get a miss the first time and then hits each time it comes up thereafter unless the cache overflows. We're doing all GETs, with no tricky stuff like subranges. As has been reported in some other messages on this list, Linux is currently blowing FreeBSD away. It's taking as much as 20% less time to get through the benchmark, depending on exactly how the random shuffle came out. This is with 4 GB RAM, the GENERIC FreeBSD SMP kernel (using SCHED_ULE), and aufs as the storage schema for Squid. It appears, though I'd need to instrument the code more to be sure, that the slowdown is coming from file I/O. Could it be that there less concurrency or more overhead in FreeBSD file operations than there is in Linux? Even with SoftUpdates turned on, the cache volume mounted with -noatime, and aufs (which uses kqueues -- a FreeBSD invention -- to optimize multithreaded disk access), the benchmark shows FreeBSD losing out. Why? Since you're using the fs as a cache, I presume it wouldn't be a big problem if the data was lost by a power outage (or crash). If so, you can try the async mount option to seriously increase fs performance. Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: ffs_blkfree: freeing free block on 7.0-PRE
On Wednesday 12 December 2007, Philipp Ost wrote: Hi all, I just got a panic on my 7.0-PRERELEASE box. Here's the backtrace: # kgdb kernel.debug /var/crash/vmcore.0 [...] Unread portion of the kernel message buffer: handle_workitem_freeblocks: block count dev = ad4s1f, block = 7475968, fs = /usr panic: ffs_blkfree: freeing free block Uptime: 4h21m56s Physical memory: 1015 MB Dumping 199 MB: 184 168 152 136 120 104 88 72 56 40 24 8 Known issue, upgrade to 7.x after 2007/10/18 to fix. Hope this helps, Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Extreme load with local password db lookups
On Friday 07 December 2007, Jeremy Chadwick wrote: On Fri, Dec 07, 2007 at 08:44:37AM +0100, Patrick van Iersel wrote: From: Eugene Grosbein [EMAIL PROTECTED] See http://www.freebsd.org/cgi/query-pr.cgi?pr=75855 It seems the regression from RELENG_4 is still here. There are so many regressions in performance that I still prefer to invest time to patch bsd.ports.mk to support 4.x (and have a success, I use fresh ports with 4.x these days) then upgrade my UP boxes to 6.x and suffer from loss of performaince. For what it's worth, Eugene's suggestion of changing nsswitch.conf actually helps. It was mentioned in the PR above as well. It's still a workaround but it works good enough for me now. I stand corrected. :-) The PR referenced by Eugene is dead on. The priority on that PR should really be changed to medium or high, because the impact is major. I'm sure large hosting/shell providers are being bitten by this. I would like to point out that in FreeBSD 7.x there is a daemon called nscd. I believe it was created exactly for this purpose (speeding up name lookups by caching them). - Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Extreme load with local password db lookups
On Friday 07 December 2007, Eugene Grosbein wrote: I would like to point out that in FreeBSD 7.x there is a daemon called nscd. I believe it was created exactly for this purpose (speeding up name lookups by caching them). Is it true that 4.x has nearly O(n) lookup speed while later versions has O(n^2) method? Why 4.x does not need caching daemon to be quick? I don't really know but judging from the others posts the files lookup method is still O(n) thus no change there. The compat method could be slow because of a number of reasons, one of them is bad complexity. One would have to look at the code to find out... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in less version 406.
On Friday 03 August 2007, Xin LI wrote:
Graham Menhennitt wrote:
Ted Hatfield wrote:
Using less -E or more to display a file that is less than a full page,
while then displaying a nonexistent file causes a segmentation fault.
For example on a newly built system you can
less -E /etc/group bogusfile
This will display the file ending with
/etc/group (file 1 of 2) (END) - Next: bogusfile
when you press space or return it gives
Segmentation fault: 11
I can reproduce it using more but not less -E. This is on -Current
as of a week or so ago. TERM=xterm.
I can reliably reproduce this with less -E on both -CURRENT and
-STABLE... :S I need to do an operation on my eye this weekend so I
have to wait a couple of days until I can recover from this.
Less keeps an internal filestate associated with each opened file. However
before opening the bogus file, it free()s the state. Less then notices that
the bogus file can't be opened, calls error(), which does some calculations
on the filestate ('thisfile' in ch.c) and crashes (Use after free). I have
written a workaround (attached) that moves the error() call below the
reinitialization of the previous state.
FYI it doesn't crash on the first file because any_display is not yet TRUE,
which causes error() to ignore the filestate.
There's also another regression in less: it doesn't automatically repaint the
screen anymore when you resize the terminal.
Regards,
Pieter de Goeje
--- contrib/less/edit.c.orig 2007-07-03 15:02:06.0 +0200
+++ contrib/less/edit.c 2007-08-04 01:03:43.0 +0200
@@ -308,8 +308,6 @@
/*
* It looks like a bad file. Don't try to open it.
*/
- error(%s, parg);
- free(parg.p_string);
err1:
if (alt_filename != NULL)
{
@@ -331,6 +329,13 @@
quit(QUIT_ERROR);
}
reedit_ifile(was_curr_ifile);
+
+ /*
+ * Cannot print the error if filestate isn't initialized.
+ */
+ error(%s, parg);
+ free(parg.p_string);
+
return (1);
} else if ((f = open(qopen_filename, OPEN_READ)) 0)
{
@@ -338,8 +343,6 @@
* Got an error trying to open it.
*/
parg.p_string = errno_message(filename);
- error(%s, parg);
- free(parg.p_string);
goto err1;
} else
{
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in less version 406.
On Saturday 04 August 2007, Sean C. Farley wrote: On Sat, 4 Aug 2007, Pieter de Goeje wrote: *snip* There's also another regression in less: it doesn't automatically repaint the screen anymore when you resize the terminal. I have already reported that regression to Mark Nudelman. He is looking into an appropriate fix since this regression was introduced when fixing another bug. Sean Hmm I wonder what that other bug might have been... If I look at signal.c I see two signal handlers for things related to window changes. One for SIGWINCH and one for SIGWIND. The if(reading) intread(); statement was removed from the SIGWINCH handler. If removing that statement fixed the other bug why wasn't it removed from SIGWIND's handler? Does SIGWIND have different semantics? Anyway, re-adding if(reading) intread(); to signal.c:96 makes it work again, but I wonder what I broke by doing that. Regards, Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in less version 406.
On Saturday 04 August 2007, Alexander Kabaev wrote: On Sat, 4 Aug 2007 01:29:57 +0200 Pieter de Goeje [EMAIL PROTECTED] wrote: There's also another regression in less: it doesn't automatically repaint the screen anymore when you resize the terminal. Regards, Pieter de Goeje It most certainly does here. That's odd, are you sure you are using version 406? To clarify: you need to press a key before less notices the change in window size and redraws the screen. - Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock too slow - big time offset with ntpdate
On Thursday 03 May 2007, Martin Dieringer wrote: # sysctl kern.timecounter kern.timecounter.hardware: i8254 kern.timecounter.choice: TSC(-1000) i8254(0) dummy(-100) To me it seems that you are running with acpi disabled. For example I have this: kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-100) kern.timecounter.hardware: ACPI-fast Re-enabling acpi may solve the problem. HTH, Pieter de GOeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug in mdconfig -l (does not list all devices)
On Saturday 28 April 2007, Miroslav Lachman wrote: Is it a bug or is it a desired feature, that mdconfig -l doesn't list all devices, but only last 95 devices? [EMAIL PROTECTED] ~/# mdconfig -l md545 md546 md547 md548 md549 md550 md551 md552 md553 md554 md555 md556 md557 md558 md559 md560 md561 md562 md563 md564 md565 md566 md567 md568 md569 md570 md571 md572 md573 md574 md575 md576 md577 md578 md579 md580 md581 md582 md583 md584 md585 md586 md587 md588 md589 md590 md591 md592 md593 md594 md595 md596 md597 md598 md599 md600 md601 md602 md603 md604 md605 md606 md607 md608 md609 md610 md611 md612 md613 md614 md615 md616 md617 md618 md619 md620 md621 md622 md623 md624 md625 md626 md627 md628 md629 md630 md631 md632 md633 md634 md635 md636 md637 md638 md639 There are 640 devices, but only 95 shown in the list. [EMAIL PROTECTED] ~/# ls /dev/md*[^a-z] | wc -l 640 So following code doesn't work as I expect for device in `mdconfig -l` do echo destroying $device mdconfig -d -u $device done FreeBSD 6.2-RELEASE-p2 #0: Tue Feb 27 22:41:06 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Can somebody test it on STABLE / CURRENT? It works correctly on current but fails on stable. Miroslav Lachman Cheers, Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Newbie Sempron/ISO question
On Friday 02 February 2007 12:15, Simon Dick wrote: Hmm, I run the amd64 version of FreeBSD on mine, but here's what it says: CPU: AMD Sempron(tm) Processor 2800+ (1603.65-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x20fc2 Stepping = 2 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA ,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x1SSE3 AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow+,3DNow ^^ LM = Long Mode ( = 64bit CPU) AMD Features2=0x1LAHF - Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cached file read performance with 6.2-PRERELEASE
On Wednesday 20 December 2006 22:20, Mark Kirkwood wrote: Pieter de Goeje wrote: On Wednesday 20 December 2006 11:38, Mark Kirkwood wrote: In fact if you note that the PIII HW *can* actually do 700MB/s, it suggests that your HW is capable of considerably more than 900MB/s - given that opteron's have excellent cpu to memory bandwidth, and the speed of your memory! Indeed! Copying /dev/zero to /dev/null yields more than 5GB/sec on a simple 2Ghz Athlon64. It imagine there are quite a few extra things done when copying On second thought, this is wrong because /dev/zero isn't a real block of memory so these results say nothing about memory I/O speed because all data is in (cpu) cache. a file from cache, because I can only manage to get one fifth (~1GB/sec) of the theoretical speed. (this is with a file that fills more than half of all memory) Note that linux seems to play tricks (zero copy?) when doing dd if=/dev/zero of=/dev/null, because you can reach speeds which are way above the theoretical maximum. (30GB/sec on a P4 1,6Ghz ??? no way) In the context of databases, I think the speeds are limited by the processing done on the data, as long as the read speed stays above a certain limit. Yeah - typically it is creating tuples out of the blocks/pages just read, so for a big memory scan CPU appears to be the limiting factor! It would be more interesting to see how random access to a (cached) file performs in Linux vs FreeBSD, which seems a more logical pattern for a database. Agreed, and good point, I'll knock up a simple program to do random and/or sequential access of a file and see what we get! I'll check 'em out :) Cheers, Pieter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Error building xfe from ports
On Tuesday 19 December 2006 19:54, chmod000 wrote: Thanks Pieter You were right, the PROFILING ware set enabled. I followed your instructions desabling it. But still having the same error, even if I try to build fox14 before xfe. Have some other idea? []'s You'll probably have to clean the port before rebuilding. # cd /usr/ports/x11-toolkits/fox14 # make clean # make install clean Cheers, Pieter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cached file read performance with 6.2-PRERELEASE
On Wednesday 20 December 2006 11:38, Mark Kirkwood wrote: In fact if you note that the PIII HW *can* actually do 700MB/s, it suggests that your HW is capable of considerably more than 900MB/s - given that opteron's have excellent cpu to memory bandwidth, and the speed of your memory! Indeed! Copying /dev/zero to /dev/null yields more than 5GB/sec on a simple 2Ghz Athlon64. It imagine there are quite a few extra things done when copying a file from cache, because I can only manage to get one fifth (~1GB/sec) of the theoretical speed. (this is with a file that fills more than half of all memory) Note that linux seems to play tricks (zero copy?) when doing dd if=/dev/zero of=/dev/null, because you can reach speeds which are way above the theoretical maximum. (30GB/sec on a P4 1,6Ghz ??? no way) In the context of databases, I think the speeds are limited by the processing done on the data, as long as the read speed stays above a certain limit. It would be more interesting to see how random access to a (cached) file performs in Linux vs FreeBSD, which seems a more logical pattern for a database. Cheers, Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Error building xfe from ports
On Tuesday 19 December 2006 18:01, chmod000 wrote: Hi there, Sorry buggin with this newbe qustion, but... since Sunday, 17 I'm trying to build /usr/ports/x11-fm/xfe, but build doesn't seems to work properly. I make cd /usr/ports/x11-fm/xfe make install clean /usr/bin/ld: cannot find -lstdc++_p *** Error code 1 Stop in /usr/ports/x11-toolkits/fox14/work/fox-1.4.32/utils. My first guess is that you have enabled the PROFILING option in the fox toolkit. cd /usr/ports/x11-toolkits/fox14; make config then deselect PROFILING and try to build again - Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Surround Sound
On Sunday 03 December 2006 13:30, Anton Blajev - Valqk wrote: I'm interested if the SB Creative Live is fully supported too? Anyone that has this card and working surrond? It's very good card but I've never had the time to test it with my fbsd. I can use fbsd on this machine from a month or so and didn't have the time to test. Any comments for SB Live will be a great thing. The SB Live! is extremely well supported, in fact, there are 3 drivers supporting it: snd_emu10k1(4), audio/emu10kx in ports and the 4front OSS (www.opensound.com) driver. The emu10k1 driver doesn't have 5.1 support, but I believe the other two do. Cheers, Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UFS Bug: FreeBSD 6.1/6.2/7.0: MOKB-08-11-2006, CVE-2006-5824, MOKB-03-11-2006, CVE-2006-5679
On Saturday 25 November 2006 13:20, O. Hartmann wrote: Sorry, if my question may sound heretic, but wouldn't it be more sophisticated solving the problem instead of disabling everything what could trigger the bug? Look, on many desktop systems, USB backup drives become very common, even eSATA backup solutions. I try to use those convenienc things eithe in lab or at home on my private machine. Mounting the file system is done via amd() and automatically as the file system gets accessed via its link point. Accessing external (and possibly hostile) media should not be done in kernel, because 1) the system may panic and 2) the system may be compromised. When the storage driver runs in usermode and has only the user's privileges, we have much better security by design. AFAIK fuse (http://fuse4bsd.creo.hu) is an attempt to implement this. Regards, Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSE support in 6.1?
On Wednesday 15 November 2006 02:42, Joe wrote: is there some way to test to make sure its working properly. the guys from steam say that its not enabled and thats why my steam server wont start. so if i could prove that SSE is enabled and working i could send it to them. Im guessing you're referring to Half-Life, Source etc servers. I've successfully run them on FreeBSD in the past (and still do). Could you be more specific? Error message, type of server... Regards, Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Three FreeBSD 6 questions
On Wednesday 01 November 2006 12:53, SiteRollout.com wrote: Many thanks for all the replies guys. I used the following method pasted below remotely without having to boot up in single user mode and it worked fine to upgrade from 6.0 to 6.1/6.2, so I'm sharing with all in case anyone needs to do the same. However I want to downgrade from 6.2 PRERELEASE to 6.1 as I'm getting this message on one server: This system is running FreeBSD 6.2-PRERELEASE. FreeBSD Update is only designed to track FreeBSD Security and Errata branches and cannot update this system 1.) Do I need to downgrade to get the latest security updates? No, to get the security fixes you should upgrade the system to the latest -STABLE by doing a cvsup and then rebuilding your system. 2.) Can I rm -fr /usr/src/ to delete everything and pull the latest files via cvsup again to perform a clean install of 6.0 STABLE(which is currently 6.1) Basically yes, however there's no such thing as 6.0-STABLE anymore, I guess you mean 6.1-RELEASE (RELENG_6_1 in your cvsup file). You cannot use FreeBSD Update when you have built your system from source. If you want to use FreeBSD Update then you'll have to reinstall the system with a release cd. Good Luck! -- Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question on runing STABLE on old Intel SMP boards
On Thursday 12 October 2006 05:47, you wrote: Do you have any tips? (Like running with ACPI disabled ond so on). You could try setting kern.hz=100 in /boot/loader.conf. It lowers system overhead, especially on SMP systems. - Pieter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: (Wrong) CPU utilization reported by top
On Sunday 24 September 2006 01:50, Ronald Klop wrote: I see the same and it is always with threaded applications (libpthread). If you use libthr (see libmap.conf) it shows a lot better. I also found that vlc performs better with libthr than with libpthread; with libthr I am able to view a multicast HD TV stream. Vlc using libpthread doesn't keep up and gives bad (distorted) image quality and the sound skips. - Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DNS query performance
On Monday 11 September 2006 21:55, Marcelo Gardini do Amaral wrote:
I would like to discuss a little bit more about UDP performance. I've
made some tests and the results may have some value here.
In this test is easy to see that there is something different in the
FreeBSD 6 branch.
I made a benchmark with bind 9.3.2 (without threads support) and nsd
3.0.1 (1 server forked) on a HP Proliant Dual AMD Opteron 2.4GHz among
FreeBSD 4.11, 6.1 and Linux kernel 2.6.15, all of them for i386
systems. I used this simple zone file:
snip
queries per second
OS Bind 9.3.2 NSD 3.0.1
Linux 2.6 SMP 3884559645
FreeBSD 4.11 SMP 3497759417
FreeBSD 4.11 UP3392659547
FreeBSD 6.1 SMP1495315908
FreeBSD 6.1 UP 1551614752
I did some UDP performance testing on my own and these are my results:
Both systems are running FreeBSD 6.1-STABLE i386, connected using gigabit
ethernet.
The server is an AMD Athlon64 2Ghz with an onboard sk(4) gbit nic. The server
program is a simple UDP echo server, collecting various performance data.
UDP requests are handled completely synchronously. It ofcourse differs from
the DNS server in the sense that is doesn't actually do anything with the
received data.
The client is an AMD Sempron 1,6Ghz with a cheap re(4) gbit nic which offers
no interrupt moderation. The client program forks into a part that sends
packets as fast as possible to the server and a part that receives echo'ed
packets from the server. The client is thus capable of doing
asynchronous requests. For these tests the client sent 100 packets.
Packet Size Queries/Second LossTotal Bandwidth
Bytes % 10^6 bits/sec
100 57348 0.5 92
200 44873 0.5 144
300 39117 0.4 198
400 35672 0.4 228
100027124 0.4 434
Also note that the client was using 100% cpu during the tests. The server was
approx. 50% idle, using most (28%) cpu in the interrupt handlers, leaving in
in my opinion enough room for the actual data processing.
My conclusion: there's definately something wrong with your setup. Maybe you
could try a different NIC to see if the performance issues are driver
related.
- Pieter de Goeje
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 16M RAM enough for FreeBSD 6.1?
On Sunday 27 August 2006 09:13, Peter Jeremy wrote: On Sun, 2006-Aug-27 03:46:52 +0200, Torfinn Ingolfsen wrote: I have an old laptop, a Compaq Armada 1580DMT, with 16M RAM, 2GB hd, ... However, when I try the 6.1-release CD (CD1), it boots as far as loading the kernel, botting the kernel, and then reboots again?? The CD-ROMs create a RAMdisk and need a minimum of 24MB last I checked. Once you have FreeBSD installed, it will limp along in 16MB (though not very happily). I strongly suggest you find a SODIMM to expand it. A friend of mine installed 6.1 successfully on a pentium with 48MB ram. It runs quite well actually :) He didn't try to to install X however. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfs-client reveals MFC-if_re-probs (or vice-versa) ?
On Saturday 29 July 2006 21:02, Arno J. Klaassen wrote: /me wrote: I have a curious problem which at first sight seems related to the end-June MFC of if_re : - I 'mount -o nfsv3,intr,noconn,-r=32768,-w=32768 -stable-server:/files/bsd /files/bsd ' - (/usr/ports and /usr/src are symlinks to /files/bsd/*) quickly after a portinstall/portversion etc. I get : nfs server -stable-server: not responding (and the corresponding process stuck in 'bo_wwa' according to top(1) ) for info: #define RE_CSUM_FEATURES 0 in otherwise up to date if_re.c solves the problem. I was having the same problem with my if_re card (RealTek 8169S). As a workaround I changed the nic. I'll give your solution a try. Using tcpdump I found that the NFS server was actually sending the right(?) packets (dump attached) but the client was somehow ignoring them... - Pieter No. TimeSourceDestination Protocol Info 15322 *REF* 130.89.165.91 130.89.170.81 NFS V3 READDIR Call (Reply In 15323)[Packet size limited during capture] 15323 0.000266130.89.170.81 130.89.165.91 NFS V3 READDIR Reply (Call In 15322)[Packet size limited during capture] 15324 0.259382130.89.165.91 130.89.170.81 NFS [RPC retransmission of #15322]V3 READDIR Call (Reply In 15323)[Packet size limited during capture] 15325 0.259788130.89.170.81 130.89.165.91 NFS [RPC duplicate of #15323]V3 READDIR Reply (Call In 15322)[Packet size limited during capture] 15326 0.769416130.89.165.91 130.89.170.81 NFS [RPC retransmission of #15322]V3 READDIR Call (Reply In 15323)[Packet size limited during capture] 15327 0.769749130.89.170.81 130.89.165.91 NFS [RPC duplicate of #15323]V3 READDIR Reply (Call In 15322)[Packet size limited during capture] 15328 1.779401130.89.165.91 130.89.170.81 NFS [RPC retransmission of #15322]V3 READDIR Call (Reply In 15323)[Packet size limited during capture] 15329 1.779780130.89.170.81 130.89.165.91 NFS [RPC duplicate of #15323]V3 READDIR Reply (Call In 15322)[Packet size limited during capture] 15330 3.791429130.89.165.91 130.89.170.81 NFS [RPC retransmission of #15322]V3 READDIR Call (Reply In 15323)[Packet size limited during capture] 15331 3.791857130.89.170.81 130.89.165.91 NFS [RPC duplicate of #15323]V3 READDIR Reply (Call In 15322)[Packet size limited during capture] 15332 7.809472130.89.165.91 130.89.170.81 NFS [RPC retransmission of #15322]V3 READDIR Call (Reply In 15323)[Packet size limited during capture] 15333 7.809816130.89.170.81 130.89.165.91 NFS [RPC duplicate of #15323]V3 READDIR Reply (Call In 15322)[Packet size limited during capture] 15334 15.835566 130.89.165.91 130.89.170.81 NFS [RPC retransmission of #15322]V3 READDIR Call (Reply In 15323)[Packet size limited during capture] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6-STABLE on 6 Gb RAM 2 x Xeon 3.0 HTT GDT RAID5 - how?
On Saturday 01 July 2006 21:24, ASTESIN wrote: Purpose: just Apache + mod_perl + MySQL 5.x application server. Install went fine, system boots, I'm going to try PAE kernel on it. But somathing makes me doubt that things are going on well... I.e. I worry about strange messages in dmesg output with regard to ACPI, I'm not sure if they're harmful. see below; will iir0 work with PAE? See PAE(4). According to /usr/src/sys/i386/conf/PAE device iir should work. Regards, Pieter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Asus A8V IRQ/serial problems
On Thursday 22 June 2006 06:54, Daniel O'Connor wrote: I have 2 Asus A8V motherboards running FreeBSD 6.0 and 6.1 (amd64) and I see the following in dmesg.. sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio0: type 16550A sio1: configured irq 4 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 on acpi0 sio1: type 16550A I have the same board and it's also running FreeBSD 6.1 amd64: sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled Only the first port is enabled in the bios. The ports are enabled in the BIOS and do seem to work.. mostly. I have had odd problems trying to talk to stuff connected to the on occasion though. Never had any problems with it. I use it for a serial console at 115200 baud. I have another [custom] driver that is based on sio.c and it shows the same warning (it is a PCI RS485 card). I have tried playing with various ACPI ATPIC settings in the BIOS but no change. If I disable ACPI in the kernel the IDE driver fails to activate it's IRQ and then panics a bit later... I booted once with ACPI disabled, all seemed to work except that it didn't detect the dual core cpu properly. I have updated to the latest BIOS but it had made no change. Hmm actually I just looked through the code.. It appears that this happens because isa_irq_pending() is a noop unless isa is in the kernel, and it isn't in GENERIC. Perhaps those tests in sio.c should be conditionalised on isa too? AFAIK there's no such thing as a real ISA bus on amd64, including it in the kernel would make little sense. Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.1-RC and the audit group
Hi Mark, On Wednesday 10 May 2006 00:51, Mark Kirkwood wrote: Doug White wrote: On Sat, 6 May 2006, Mark Kirkwood wrote: I found that installworld stops, because the 'audit' group has not been created. Now I just pressed 'return' for the default actions during mergemaster -p, but I didn't notice any mention of the audit group. The default action is to do nothing, so its possible you just missed it as you were blazing through. :-) Just updated another box to 6.1-STABLE, and yes I did 'return' though it. The reason being mergemaster -p wanted to patch my group file to remove all the additions (i.e, useful groups and group - user associations) as *well* as add the audit group. Well unless -p changes mergemaster's behaviour, the general idea is that you press 'm' for merge ( correct me if I'm wrong but I think mergemaster was named after this feature :P ). It will let you add the new audit group _and_ keep the extra groups. Would be possible (or sensible) to 2-stage this sort of thing? i.e: 1/ Add required new groups 2/ Offer to patch 'em back to default. Cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Regards, Pieter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.1RC1: Unable to select Minimal distribution
Hi, I installed FreeBSD 6.1RC1 in qemu. When sysinstall comes to the Choose Distributions screen, I am unable to choose the Minimal distribution. The [ ] stay blank. Also, selecting All doesn't include it either. Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Tuesday 28 March 2006 20:37, you wrote: On Tuesday 28 March 2006 11:38, Pieter de Goeje wrote: I can't really tell if the performance is impaired by mpsafenet=0, because the box is mostly busy doing userland stuff. Typical traffic looks like this: I'm going to test the new driver to see if I can disable mpsafenet. To be specific on the NIC: [EMAIL PROTECTED]:10:0: class=0x02 card=0x811a1043 chip=0x432011ab rev=0x13 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8001/8003/8010 Gigabit Ethernet Controller with Integrated PHY (copper)' class= network subclass = ethernet yes, this is the Asus A8V, same here may be you consider to try Pyun's driver http://people.freebsd.org/~yongari/sk/sk_test/if_sk.c http://people.freebsd.org/~yongari/sk/sk_test/if_skreg.h and run yours without mpsafenet ? I have no clue what a game server requires. I tried anything even generic kernel and no sysctls/loader.conf values set in order to see if something else is wrong. Also I have lots of this machines and any of them same result. João I have the system running for 3 days straight now with the new driver, however the problem described earlier still exists. I still need to use mpsafenet=0. Other than that, the driver seems fine. No timeouts whatsoever. I was thinking, maybe it isn't the network driver but the linux compatibility layer that has problems with SMP. Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Tuesday 28 March 2006 04:08, Pyun YongHyeon wrote: On Tue, Mar 28, 2006 at 02:21:28AM +0200, Pieter de Goeje wrote: On Monday 27 March 2006 23:48, JoaoBR wrote: On Monday 27 March 2006 15:51, Mark Linimon wrote: On Mon, Mar 27, 2006 at 12:15:55PM -0300, JoaoBR wrote: well, the actual driver is trash and unusable and overall crashes SMP systems ... so more testing to see if it crashes more? ;) As with any other software development project, you have to draw a line somewhere and say these things will be in the release and these things will not be in the release; otherwise, you will never have a release at all. I am not familiar with the code in this case but if its inclusion changed enough other things in the system where _everything_ had to be re-tested then it's not worth the regression. These are just the simple facts of (any) software development. well, ok that is completly understandable basicly but this driver is unusable since dec/jan for me, for others probably longer IMO it would make sense to be replaced by Pyuns driver because the original is not functional kind of strange getting a new release with a known not functional driver Jo?o This is not quite true; I am running 2 systems with the sk driver. One of them is a dual core athlon64, and it's network connection is indeed flawed unless I change debug.mpsafenet to 0. The other machine is a regular athlon64 and has no problems at all. Both systems are running 6.1-PRERELEASE amd64. Does it happen on my latest sk(4) driver? I'll give it a try. I don't have amd64 systems but the driver was tested on i386(SMP) and sparc64(SMP) and I never see above errors. The only issue known to me is occasional watchdog timeout error which I really want to fix. But the watchdog timeout error is hard to reproduce and I couldn't reproduce the error on my system. With debug.mpsafenet=1, cvsup failes with protocol errors on the SMP box. Also, I run several Half-Life: Counter-Strike servers on it and clients occasionaly receive corrupted UDP packets which cause them to drop the connection. However as soon as I changed debug.mpsafenet to 0, all problems were gone. How about stock sk(4)? Does it have the same issue too? I am using stock sk(4) now. I'm not seeing any watchdog timeout errors. So, maybe you should try changing debug.mpsafenet. FYI: the SMP box has an Asus A8V (agp) mobo, and the other box an Asus K8V SE. I did try an old realtek (rl(4)) card, it had the same problems and I could fix the problems with that card too by turning off mpsafenet. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Tuesday 28 March 2006 12:40, you wrote: snip probably you do not have the traffic to make the box crash or less then 1/2GB of RAM in use The box has 1GB RAM. Traffic is approx. 2-3Mbit/s. in fact the problem does not happen on UP machines, only some times a device timeout which only ocasionally cause rx/tx to stop The problem is appearing on SMP machines when you have less then 2Gb of RAM the problem ocurres once a day or so and seems to depend on memory use and amount of traffic soon the traffic reaches more than 1Mbit/s the crash is predictable and you can wait to see The box has actually crashed once, but I am not sure it was because of the NIC. ~ uptime 4:19PM up 3 days, 9:59, 1 user, load averages: 1.38, 1.20, 1.03 on 4GB of Ram machines and more traffic the crash is imediatly and worse when the box crashed under load (4-6Mbit/s) and comes back then the high demand strokes it and it crashes in minutes or imediatly soon the network is up so probably mpsafenet may help by not processing concurrent packets but this is a workaround not a solution (for me) Agreed. last time I checked mpsafenet=0 almost cut 1Mbit/s of traffic and the overall performance/response was bad, higher HZ did not resolved anything and disabling polling made it still worse (I have other NICs installed), the machines are working as GW I can't really tell if the performance is impaired by mpsafenet=0, because the box is mostly busy doing userland stuff. Typical traffic looks like this: ~ netstat -w 1 input(Total) output packets errs bytespackets errs bytes colls 1186 0 97134 1302 0 276430 0 1206 0 97484 1382 0 264315 0 1193 0 97048 1366 0 278901 0 1198 0 98251 1403 0 273428 0 1205 0 99283 1393 0 270364 0 1162 0 94746 1376 0 265909 0 1162 0 93011 1420 0 258514 0 1187 0 94366 1467 0 263162 0 1178 0 93441 1441 0 248875 0 1176 0 93116 1484 0 266285 0 1146 0 91615 1424 0 256180 0 1222 0 96597 1560 0 432862 0 1222 0 93796 1591 0 66 0 This is all UDP. The traffic generates around 2000 interrupts/sec on sk. until january the machines didn't crashed, only timeouts and rx/tx stops I used Pyun's driver and the timeouts went away, thank's again! so then I got confused by some if_sk talks on stable and thought the driver was comitted and the boxes started crashing until I got it last week and reused Pyun's driver again and my sk problems are gone again, the machines are stable for 4/5 days now I'm going to test the new driver to see if I can disable mpsafenet. To be specific on the NIC: [EMAIL PROTECTED]:10:0: class=0x02 card=0x811a1043 chip=0x432011ab rev=0x13 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8001/8003/8010 Gigabit Ethernet Controller with Integrated PHY (copper)' class= network subclass = ethernet Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
On Monday 27 March 2006 23:48, JoaoBR wrote: On Monday 27 March 2006 15:51, Mark Linimon wrote: On Mon, Mar 27, 2006 at 12:15:55PM -0300, JoaoBR wrote: well, the actual driver is trash and unusable and overall crashes SMP systems ... so more testing to see if it crashes more? ;) As with any other software development project, you have to draw a line somewhere and say these things will be in the release and these things will not be in the release; otherwise, you will never have a release at all. I am not familiar with the code in this case but if its inclusion changed enough other things in the system where _everything_ had to be re-tested then it's not worth the regression. These are just the simple facts of (any) software development. well, ok that is completly understandable basicly but this driver is unusable since dec/jan for me, for others probably longer IMO it would make sense to be replaced by Pyuns driver because the original is not functional kind of strange getting a new release with a known not functional driver João This is not quite true; I am running 2 systems with the sk driver. One of them is a dual core athlon64, and it's network connection is indeed flawed unless I change debug.mpsafenet to 0. The other machine is a regular athlon64 and has no problems at all. Both systems are running 6.1-PRERELEASE amd64. With debug.mpsafenet=1, cvsup failes with protocol errors on the SMP box. Also, I run several Half-Life: Counter-Strike servers on it and clients occasionaly receive corrupted UDP packets which cause them to drop the connection. However as soon as I changed debug.mpsafenet to 0, all problems were gone. So, maybe you should try changing debug.mpsafenet. FYI: the SMP box has an Asus A8V (agp) mobo, and the other box an Asus K8V SE. Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
