Thanks!
In the midst of bugs and issues, to which I can empathize and relate, I wish to offer thanks for all your hard work. My history: In late 03 my one computer died hot death. I built a new one after a quick parts dash. With new parts, Windows would still eventually die. Drivers were unstable. Not fun. Not my scene. In 04 I started looking at Linux. Even tried fink on the Mac. Gravitated to Debian. Did a partition and an install. Ouch! My NIC wasn't supported in Woody. Got source from Intel, compiled the module and upgraded to Sarge. That was the first two days. Used Debian but it was just ancient. Backports were their own headache. Dealt with early 2.6 kernel woes. Went to Fedora 3. Worked OK until 4. Switched to Mandrake 10 and blew an O-ring. Switched to SUSE. Learned to hate YaST. Learned to hate how they did repos. Switched to Ubuntu. Liked the setup for a while, then broke it by hooking to a noncanonical repo. Dealt with the ongoing civil war between livna and freshrpms again, although Fedora 5 was better. Then I found FreeBSD in March 06. After three months I had learned, broken, cussed and whatever else. And in frustration I tried Fedora 5 again and new Ubuntu. Neither did Samba well. Both could be made to hang by a neat little trick I do with Xsane called using my scanner for more than about ten scans. Udev is evil on both. Networking looks like a GUI and acts like...a mother. So I came back to FreeBSD. And I got STABLE up and it has been running great since I did a repartition in August. (It WAS running great since June but I wanted to retune the FS.) STABLE gave me DRM (i845), newer CUPS (after I figured out a few issues and evoked fond memories of my JCL tantrum mat), and as with RELEASE, no hangs with Xsane, all the software I want to run, not just what a distro says I can, and a community that treats thinking people like more than trogs. I never met a Linux distro where the people involved were so accessible and actually answered questions and had discussions instead of just referring one to a Bugzilla page. There's a helluva lot more slack (Bob-style) here than elsewhere. And after reading manpages and googling, I found out that I learned more than most reference books at Borders can tell, especially the ficticious Unix: The Complete Reference. FreeBSD people are helpful, as is reading the man/docs. FreeBSD requires people to kick it to a higher level. But permissions mean what they say, Samba works and os/port maintainers will work with you when a build fails. Software MIDI without ALSA works faster than any Linux. The same for Mplayer and Xine. I can use sudo and nice to crank the heck out of emulators and the system doesn't just die. I got caught a little before 6.1 came out, but I passed that hurdle and got a lot more cautious about how often I update the OS. I learned NetBSD as well. I relearned a lot of computer skills I had forgotten. I also did some just-plain dumb things and got what I asked for. I am real happy with FreeBSD. I would be interested in seeing more desktop stuff become a reality. Neither of the desktop variants of FreeBSD works so well for me, yet. But I would rather stick with it and try to help what little I can. Because this OS is not just an anti-Windows effulgent with GNUish pride. It's like the Unix I remember from yesterday and it is what will provide an alternative to Windows-template mentalities in the future. Cause Windows just breaks when used long enough. Why should I pay for that? Why should I use operating systems that want to think that way and yet pretend to be different? I don't need to become my worst enemy to survive and neither will my OS. You do a lot and know a lot more than I ever will. And when my box turns on, dang it, it works. Swt! Charles ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD does not use all cpus on top show.
On Thu, Sep 14, 2006 at 12:36:33PM +0800, Huang wen hui wrote: hi, I have HP Server install FreeBSD 6.1R/amd64 with 2CPUs ,2 logical CPUs per core. On top show, It should show 4 cpus, but I never see 1 and 3 cpu on show. Does anything I miss? You must switch off hiper threading in bios and in your system. --hwh # dmesg Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-RELEASE #0: Sun May 7 04:15:57 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP ACPI APIC Table: HP 0083 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz K8-class CPU) Origin = GenuineIntel Id = 0xf4a Stepping = 10 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x641dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,b14 AMD Features=0x2800SYSCALL,LM AMD Features2=0x1LAHF Logical CPUs per core: 2 real memory = 6912208896 (6591 MB) avail memory = 6150582272 (5865 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard ioapic3 Version 2.0 irqs 72-95 on motherboard ioapic4 Version 2.0 irqs 96-119 on motherboard kbd1 at kbdmux0 acpi0: HP P51 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x908-0x90b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pci2: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci2 pci3: ACPI PCI bus on pcib2 bge0: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2100 mem 0xfdef-0xfdef irq 25 at device 1.0 on pci3 miibus0: MII bus on bge0 brgphy0: BCM5704 10/100/1000baseTX PHY on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:18:71:74:2a:bf bge1: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2100 mem 0xfdee-0xfdee irq 26 at device 1.1 on pci3 miibus1: MII bus on bge1 brgphy1: BCM5704 10/100/1000baseTX PHY on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:18:71:74:2a:be pcib3: ACPI PCI-PCI bridge at device 0.2 on pci2 pci4: ACPI PCI bus on pcib3 ciss0: HP Smart Array 6i port 0x4000-0x40ff mem 0xfdff-0xfdff1fff,0xfdf8-0xfdfb irq 51 at device 3.0 on pci4 ciss0: [GIANT-LOCKED] pcib4: ACPI PCI-PCI bridge at device 6.0 on pci0 pci5: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge at device 0.0 on pci5 pci6: ACPI PCI bus on pcib5 pcib6: ACPI PCI-PCI bridge at device 0.2 on pci5 pci10: ACPI PCI bus on pcib6 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x2000-0x201f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x2020-0x203f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x2040-0x205f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0x2060-0x207f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: Intel 82801EB (ICH5) USB controller USB-D on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xfbef-0xfbef03ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib7: ACPI PCI-PCI bridge at device 30.0 on pci0 pci1: ACPI PCI bus on pcib7 pci1: display, VGA at device 3.0 (no driver attached)
Re: gmirror RAID-1: rebuilding freezes machine
I have cvsup'd today to make sure I get the updated g_mirror.c, have
rebuilt world and kernel, installed both. however when i rebuild the
degraded drive the same thing happens.
during the rebuild the good drive is reading, but the dirty drive is not
gettin written to according to gstat.
all i have done is a gmirror remove gm0 ad0 after i realised what had
happened, updated to the reverted version, gmirror insert gm0 ad0. the
rebuild process began automatically.
Am I missing something? Do i have to wipe and start again?
This isnt a production machine, its still preproduction, but its
supposed to be deployed in a week.
Michael Butler wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm backing out the attached change to see if it fixes it ..
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (FreeBSD)
iD8DBQFE/2/mQv9rrgRC1JIRArNYAJsEuTtrmig9bdW4aDQQ8W1May+EfQCfUjDQ
Xc1A9gUrrLS2jgbDP4xyC7I=
=5DtW
-END PGP SIGNATURE-
Index: src/sys/geom/mirror/g_mirror.c
===
RCS file: /usr/home/ncvs/src/sys/geom/mirror/g_mirror.c,v
retrieving revision 1.66.2.7
retrieving revision 1.66.2.8
diff -u -r1.66.2.7 -r1.66.2.8
--- src/sys/geom/mirror/g_mirror.c 16 Jul 2006 15:47:46 - 1.66.2.7
+++ src/sys/geom/mirror/g_mirror.c 4 Sep 2006 12:55:43 - 1.66.2.8
@@ -1813,12 +1813,19 @@
bioq_remove(sc-sc_queue, bp);
mtx_unlock(sc-sc_queue_mtx);
- if ((bp-bio_cflags G_MIRROR_BIO_FLAG_REGULAR) != 0)
- g_mirror_regular_request(bp);
- else if ((bp-bio_cflags G_MIRROR_BIO_FLAG_SYNC) != 0)
- g_mirror_sync_request(bp);
- else
+ if (bp-bio_to != sc-sc_provider) {
+ if ((bp-bio_cflags G_MIRROR_BIO_FLAG_REGULAR) != 0)
+ g_mirror_regular_request(bp);
+ else if ((bp-bio_cflags G_MIRROR_BIO_FLAG_SYNC) != 0)
+ g_mirror_sync_request(bp);
+ else {
+ KASSERT(0,
+ (Invalid request cflags=0x%hhx to=%s.,
+ bp-bio_cflags, bp-bio_to-name));
+ }
+ } else {
g_mirror_register_request(bp);
+ }
G_MIRROR_DEBUG(5, %s: I'm here 9., __func__);
}
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror RAID-1: rebuilding freezes machine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jared Ring wrote: | I have cvsup'd today to make sure I get the updated g_mirror.c, have | rebuilt world and kernel, installed both. however when i rebuild the | degraded drive the same thing happens. | | during the rebuild the good drive is reading, but the dirty drive is not | gettin written to according to gstat. I've been bitten by this - make sure that the first slice on the mirrored partition does not start at offset 0. For example, this disk is mirrored on slice 2 .. [EMAIL PROTECTED]:/home/imb sudo bsdlabel mirror/gm0s2 # /dev/mirror/gm0s2: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] ~ a: 524272 164.2BSD 2048 16384 32768 ~^^^ ~ c: 2846557340unused0 0# raw part .. ~ d: 1048576 5242884.2BSD0 0 0 ~ e: 1048576 15728644.2BSD0 0 0 ~ f: 282034294 26214404.2BSD0 0 0 Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFCUAhQv9rrgRC1JIRAnPHAJ9AMnr1PzCfqJBx99zs6BhWSHI4NwCggUpo aI3LrwU8cHDmyLZpKB98EKw= =QPtF -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Marc G. Fournier wrote: Steve O'Hara-Smith wrote: Greg Barniskis [EMAIL PROTECTED] wrote: If you /track/ STABLE by frequently cvsupping it and rebuilding your system, you will very likely encounter a serious problem sooner or later. That's why tracking it is not recommended for production systems. I did exactly that all the way from 2.0 to 4.11 on various machines without ever having any trouble. Ditto ... in fact, I do that on my desktop and have yet to hit a problem ... -STABLE *is* generally very stable ... Same here. However, if you want (or need) to track stable, there are certain possibilities to avoid trouble. Of course watching the -stable mailing list (and possibly even -cvs-all) and reading /usr/src/UPDATING should be a must. But there are more things that can be done. On important production machines, it might be a good idea to track -stable with some delay. For example, always update to the -stable date of 4 weeks ago (using the -D option of cvs, or the date= keyword of cvsup), after making sure that no critical problems have been reported in the mailing list in the past 4 weeks. Chances are that critical bugs are detected and fixed pretty quickly in the -stable branch. And of course: Always make sure that you have good backups. But that's even true if you don't track -stable. Best regards Oliver PS: Some people think that a RAID1 (mirror) is a substitute for a backup. It's not. -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. A language that doesn't have everything is actually easier to program in than some that do. -- Dennis M. Ritchie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD does not use all cpus on top show.
Huang wen hui wrote: hi, I have HP Server install FreeBSD 6.1R/amd64 with 2CPUs ,2 logical CPUs per core. On top show, It should show 4 cpus, but I never see 1 and 3 cpu on show. Does anything I miss? This is a simplified version of things, but it will help you: CPUs 0 and 2 are real CPUs, while 1 and 3 are additional hyperthreaded counterparts of those. Since hyperthreading is disabled in FreeBSD by default (because it generally doesn't help performance and has a sort-of security hole in the hardware itself), processes are never scheduled to run on CPUs 1 and 3. You can either disable hyperthreading in BIOS, so you'll have only CPUs 0 and 1, or enable hyperthreading in FreeBSD with machdep.hyperthreading_allowed=1 sysctl, which will enable you to use all 4 logical CPUs. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: optimization levels for 6-STABLE build{kernel,world}
Gary Kline wrote: A couple of things. Will having gcc unroll loops have any negative consequences? Yes. It will make the code slower, in most cases. In modern processors, the loop overhead is almost zero. That's because the branch prediction unit of a processor also predicts loop instructions (which are just a special case of conditional branches), and chances are that the whole loop body is in the L1 cache. If it is too large to fit into the L1 cache, then the loop overhead doesn't matter anyhow. There are very, very few special cases where unrolling a small loop might give a little speed improvement. Bit in most cases, it makes things worse. Also, don't expect miracles from -O3. It certainly won't make your kernel run twice as fast, and I even doubt that there would be any measurable difference. Therefore I'm not concerned at all that -O3 isn't officially supported. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. C++ is to C as Lung Cancer is to Lung. -- Thomas Funke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal questions
it's working great now that i've redone the whole thing -- Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com Pawel Jakub Dawidek wrote the following on 09/01/06 13:56: On Fri, Sep 01, 2006 at 10:16:09AM -0500, Kevin Kramer wrote: I've already redone the whole thing. here are the steps i took umount /scr09 umount /scr10 gjournal stop da2.journal gjournal stop da4.journal ** had not done this on the first attempt newfs /dev/da1 newfs /dev/da3 This is not needed. gjournal label -v /dev/da2 /dev/da1 gjournal label -v /dev/da4 /dev/da3 newfs -J -L scr09 /dev/da2.journal newfs -J -L scr10 /dev/da4.journal mount /scr09 mount /scr10 Don't know how your /etc/fstab looks like, but you definiately should use 'async' mount option, which is safe to use with gjournaled file systems. it is looking much better so far. before, i was getting this in the debug (only on /scr10) and my mountd process was always the top process Sep 1 00:00:11 donkey kernel: fsync: giving up on dirty Sep 1 00:00:11 donkey kernel: 0xc9ee1bb0: tag devfs, type VCHR Sep 1 00:00:11 donkey kernel: usecount 1, writecount 0, refcount 198 mountedher e 0xc9ebfb00 Sep 1 00:00:11 donkey kernel: flags () Sep 1 00:00:11 donkey kernel: v_object 0xc9fbb528 ref 0 pages 5933 Sep 1 00:00:11 donkey kernel: lock type devfs: EXCL (count 1) by thread 0xc9bd4 180 (pid 38) Sep 1 00:00:11 donkey kernel: dev ufs/scr10 Sep 1 00:00:11 donkey kernel: GEOM_JOURNAL: Cannot suspend file system /scr10 ( error=35). It happens sometimes under load, haven't investigated yet what exactly is happening, but you can ignore it for now, it's harmless, it just means journal switch will be done a bit later. BTW. 8GB for journals is much. You should not need more than 2GB probably. Of course it will work with 8GB just fine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Dell Precision 390 issues (heads-up)
We have one of these new boxes. The latest ISOs for i386/AMD64 install fails with a RAM Parity error if the onboard Broadcom NIC is enabled in the BIOS. To get past this error just disable in the bios to get past. I'll repost after I do a source update to see if the Broadcom is supported. -- -- Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On 9/9/06, Mark Andrews [EMAIL PROTECTED] wrote: Yeah, -STABLE is what you should run if you want stable code, right? No. STABLE means STABLE API. If you want stable code you run releases. Between releases stable can become unstable. Think of stable as permanent BETA code. Changes have passed the first level of testing in current which is permanent ALPHA code. No, this is what it means now. I've been running FreeBSD since 1.1, and -STABLE used to mean exactly that. The developement branch was -C, and -S was where things went after extensive testing. You were not allowed to break -S or Jordan would rip your fingers off. This change to the current structure wasn't meant to be permanent when it was done (between 4 and 5, IIRC), and was only done out of necessity because the changes across that major release were huge. FreeBSD needs an interim track that mirrors what -STABLE used to be, which is a track between point releases that can be relied upon (and RELEASE_x_y doesn't work, since it only addresses security and bugs deemed worthy, which most aren't). -- Jamie Bowden -- It was half way to Rivendell when the drugs began to take hold Hunter S Tolkien Fear and Loathing in Barad Dur Iain Bowen [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: optimization levels for 6-STABLE build{kernel,world}
On Wed, 13 Sep 2006 21:42:41 -0700, Gary Kline [EMAIL PROTECTED] wrote: Isn't the compiler intelligent enough to have a reasonable limit, N, of the loops it will unroll to ensure a faster runtime? Yes, and also permits the user to choose if internal heuristics should be used, user-specified loop size to unroll, and unroll-all-loops. -- Ricardo Nabinger Sanchez [EMAIL PROTECTED],wait4.org} Powered by FreeBSD Left to themselves, things tend to go from bad to worse. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Thanks!
On Thu, 14 Sep 2006 01:27:34 -0500, Charles P. Schaum [EMAIL PROTECTED] wrote: I am real happy with FreeBSD. I would be interested in seeing more desktop stuff become a reality. Neither of the desktop variants of FreeBSD works so well for me, yet. Have you tried Desktop BSD and/or PCBSD? IIRC, they're based on FreeBSD and very desktop oriented -- perhaps they'll work well for you. -- Ricardo Nabinger Sanchez [EMAIL PROTECTED],wait4.org} Powered by FreeBSD Left to themselves, things tend to go from bad to worse. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: optimization levels for 6-STABLE build{kernel,world}
On Sep 13, 2006, at 9:42 PM, Gary Kline wrote: -funroll-loops is as likely to decrease performance for a particular program as it is to help. Isn't the compiler intelligent enough to have a reasonable limit, N, of the loops it will unroll to ensure a faster runtime? Something much less than 1000, say; possibly less than 100. Of course; in fact, N is probably closer to 4 or 8 than it is to 100. At least, if the initializiation and end-loop code *plus* the loop code itself were too large for the cache, my thought is that gcc would back out. Unless you've indicated that the compiler should target a specific CPU architecture, there is no way for it to know whether the size of the L1 cache on the machine doing the compile is the same as, or even similar to the size of the system where the code will run. I may be giving RMS too much credit; but if memory serves, thed compiler was GNU's first project. And Stallman was into GOFAI, c, for better/worse.[1] Anyway, for now I'll comment out the unroll-loops arg. cd /usr/src/contrib/gcc grep Stallman ChangeLog ...returns no results. A tool I wrote suggests: % histogram.py -F' ' -f 2,3 -p @ -c 10 ChangeLog 61 Kazu Hirata [EMAIL PROTECTED] 51 Eric Botcazou [EMAIL PROTECTED] 48 Jan Hubicka [EMAIL PROTECTED] 39 Richard Sandiford [EMAIL PROTECTED] 37 Alan Modra [EMAIL PROTECTED] 30 Richard Henderson [EMAIL PROTECTED] 29 Joseph S. Myers [EMAIL PROTECTED] 27 Jakub Jelinek [EMAIL PROTECTED] 25 Zack Weinberg [EMAIL PROTECTED] 22 Mark Mitchell [EMAIL PROTECTED] 20 John David Anglin [EMAIL PROTECTED] 20 Ulrich Weigand [EMAIL PROTECTED] 17 Rainer Orth [EMAIL PROTECTED] 16 Kelley Cook [EMAIL PROTECTED] 16 Roger Sayle [EMAIL PROTECTED] 13 David Edelsohn [EMAIL PROTECTED] 12 Aldy Hernandez [EMAIL PROTECTED] 11 Stephane Carrez [EMAIL PROTECTED] 11 Ian Lance Taylor [EMAIL PROTECTED] 10 Andrew Pinski [EMAIL PROTECTED] 10 Kaz Kojima [EMAIL PROTECTED] 10 James E Wilson [EMAIL PROTECTED] A safe optimizer must assume that an arbitrary assignment via a pointer dereference can change any value in memory, which means that you have to spill and reload any data being cached in CPU registers around the use of the pointer, except for const's, variables declared as register, and possibly function arguments being passed via registers and not on the stack (cf register windows on the SPARC hardware, or HP/PA's calling conventions). Well, I'd added the no-strict-aliasing flag to make.conf! Pointers give me indigestion ... even after all these years. Thanks for your insights. And the URL. You're welcome. gary [1]. Seems to me that good old-fashioned AI techniques would work in something like a compiler where you probblyhave a good idea of most heuristics. -gk Of course. The compiler enables those optimizations with -O or -O2 which are almost certain to result in beneficial improvements to performance and code size, most of the time. Potential optimizations which are not helpful on average are not enabled by default, until the situations where they are known to be useful can be identified by the compiler at compile-time. Using non-default optimization options isn't like discovering buried treasure that nobody else was aware of; the options aren't enabled by default for good reason(s), usually because the tradeoffs they make aren't helpful in general (yet), or because their usage has known bugs which result in faulty executables being produced. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.2-PRE/amd64: make installworld fails: btxld:No such file or directory
Hi * today i checked out fresh RELENG_6 on my amd64, build(world|kernel) seems fine, installworld fails: [...] === sys/boot/i386/btx (install) === sys/boot/i386/btx/btx (install) === sys/boot/i386/btx/btxldr (install) === sys/boot/i386/btx/lib (install) === sys/boot/i386/boot2 (install) btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin btxld:No such file or directory *** Error code 1 Stop in /usr/src/sys/boot/i386/boot2. *** Error code 1 [...] I found an unanswered question about this: http://lists.freebsd.org/pipermail/freebsd-amd64/2004-August/001906.html Why i386 here: boot/i386/boot2/? I did the following procedure: 1) install new Dell PE2950 with amd64/6.1-RELEASE from CD (minimal) 2) cvsup /usr/src to RELENG_6 this afternoon 3) make clean buildworld buildkernel (forgot to build it for SMP) 4) make buildkernel KERNCONF=PE2950 (which is just SMP plus ident a.t.m) 5) make installkernel KERNCONF=PE2950 6) reboot 7) make installworld -- fails. Did I miss something here? How to fix? Is this amd64 specific? Regards Raphael Becker PS: if this is an amd64 specific issue it might be forwarded to the amd64 mailing list. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell Precision 390 issues (heads-up)
Well, I've cvs'd this morning and rebuilt world and kernel and the Broadcom nic driver still panics the machine. The device is identified as BCM5787 and immediately after it loads the kernel gives RAM Parity Error some other suff like a trace panic , non-maskable interrupt trap it now shows 6.2-pre-release as the version. what can i do to help fix this and maybe get this into 6.2. thanks Kevin Kramer wrote the following on 09/14/06 09:46: We have one of these new boxes. The latest ISOs for i386/AMD64 install fails with a RAM Parity error if the onboard Broadcom NIC is enabled in the BIOS. To get past this error just disable in the bios to get past. I'll repost after I do a source update to see if the Broadcom is supported. ___ 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
Are you able to boot a 7.x kernel on this box? An as yet un-MFC'd optimization to the UDP send path is present in the 7.x kernel, suggested by ISC, which significantly improves threaded BIND9 performance. I've not benchmarked unthreaded BIND9 with the change. If you want to test specifically the before/after case for that change, you can find the reference to sosend_dgram in src/sys/netinet/udp_usrreq.c and swap it to sosend, which restores the old behavior. I booted 7.x kernel UP and SMP on my blade. When I swaped both of them to sosend I got a panic to any DNS query: # dig @localhost test1.foo.bar panic: sosend: protocol calls sosend KDB: enter: panic [thread pid 671 tid 100053 ] Stopped at kdb_enter+0x2b: nop db db bt Tracing pid 671 tid 100053 td 0xc4a52bd0 kdb_enter(c091d7b6) at kdb_enter+0x2b panic(c0925143,e502dc10,c06e6511,c4f9c14c,c4a66370,...) at panic+0xbb sosend(c4f9c14c,c4a66370,e502dbe4,0,0,0,c4a52bd0) at sosend+0x1f kern_sendit(c4a52bd0,15,e502dc5c,0,0,0) at kern_sendit+0x101 sendit(c4a52bd0,15,e502dc5c,0,c4a66150,...) at sendit+0x87 sendmsg(c4a52bd0,e502dd04) at sendmsg+0x53 syscall(3b,3b,3b,1,0,...) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (28, FreeBSD ELF32, sendmsg), eip = 0x28353d6f, esp = 0xbfbfe8ec, eb p = 0xbfbfea68 --- db c Uptime: 1m44s Physical memory: 2039 MB Dumping 99 MB: 84 68 52 36 20 4 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort The other common optimization advice that you may already have received is to check which time counter FreeBSD has selected. Right now, 6.x/7.x err on the side of accurate over fast. There's been quite a bit of debate about this approach, and it's useful to investigate the issue. You can view and set the current choice by looking at the sysctl kern.timecounter.hardware, and you can see the choices on your hardware by looking at kern.timecounter.choice. Typically, TSC is the fastest, but may suffer from drift as the CPU changes speed (as a result of temperature, power saving, etc). Set it to TSC if it's not already TSC, and see what the effect is. As many event libraries read time stamps frequently to set up sleeping in user space, it can have a substantial performance impact. With the 7.x kernel and no changes in src/sys/netinet/udp_usrreq.c I tried different timecounters and I couldn't see any performance difference. Here we see the results for bind 9.3.2, same zone file and queries: Kernel UP Timecounter queries/s --- - ACPI-safe 16200 TSC 16584 i8254 16319 Kernel SMP Timecounter queries/s --- - ACPI-safe 15323 TSC 15930 i8254 14155 Any other tip? -- Att., Marcelo Gardini ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Vivek Khera schrieb: On Sep 12, 2006, at 6:23 PM, hackmiester (Hunter Fuller) wrote: -STABLE is still a development branch without guarantee of a stable and working operating system. Hahahahaha... That's ironic... No, just misinterpretation of which attribute of the system to which the word stable applies. Do you really think I misinterpreted the meaning of -STABLE? *I* think most people misinterprete -STABLE because the first thing that comes to mind is runtime stability. The same issue exists in the GNU/Debian Linux world: Debian stable doesn't mean that the system run always rock-solid and works perfectly, but rather the state of software is stable, i.e. maintainers ensure 100% compatibility between updates. Regards 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: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
hackmiester (Hunter Fuller) schrieb: On 12 September 2006, at 02:06, Björn König wrote: Karl Denninger schrieb: This is not cool folks. I think you misunderstood what -STABLE means. (Or maybe I do?) -STABLE is still a development branch without guarantee of a stable and working operating system. Hahahahaha... That's ironic... That wasn't meant to be ironic. Years of experience and observations of development lead to this conclusion. Regards 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: gmirror RAID-1: rebuilding freezes machine
I traced the problem back to BIOS booting off ad0 instead of ad1. Because ad0 was still a perfectly functioning drive BIOS didnt complain about booting off it. Once the kernel started and gmirror loaded it proceeded to use ad1, but the kernel was loaded from ad0, which was the old, broken one. I noticed my first partition does start at offset 0 though, is this going to come and bite me in the future? J Michael Butler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jared Ring wrote: | I have cvsup'd today to make sure I get the updated g_mirror.c, have | rebuilt world and kernel, installed both. however when i rebuild the | degraded drive the same thing happens. | | during the rebuild the good drive is reading, but the dirty drive is not | gettin written to according to gstat. I've been bitten by this - make sure that the first slice on the mirrored partition does not start at offset 0. For example, this disk is mirrored on slice 2 .. [EMAIL PROTECTED]:/home/imb sudo bsdlabel mirror/gm0s2 # /dev/mirror/gm0s2: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] ~ a: 524272 164.2BSD 2048 16384 32768 ~^^^ ~ c: 2846557340unused0 0# raw part .. ~ d: 1048576 5242884.2BSD0 0 0 ~ e: 1048576 15728644.2BSD0 0 0 ~ f: 282034294 26214404.2BSD0 0 0 Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFCUAhQv9rrgRC1JIRAnPHAJ9AMnr1PzCfqJBx99zs6BhWSHI4NwCggUpo aI3LrwU8cHDmyLZpKB98EKw= =QPtF -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror RAID-1: rebuilding freezes machine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jared Ring wrote: I traced the problem back to BIOS booting off ad0 instead of ad1. Because ad0 was still a perfectly functioning drive BIOS didnt complain about booting off it. Once the kernel started and gmirror loaded it proceeded to use ad1, but the kernel was loaded from ad0, which was the old, broken one. Ah .. that'll do it .. I noticed my first partition does start at offset 0 though, is this going to come and bite me in the future? My guess is 'yes, it will eventually' .. better to fix it now before it does and you've forgotten about it, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFCbxrQv9rrgRC1JIRAk6MAJ9xPYkp0Vr7T38Qf1SMQ3pYtP3v2QCfdzs5 57tFy03R0Zv8AzKsHR0mpv4= =XK+M -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-PRE/amd64: make installworld fails: btxld:No such file or directory
On Thu, Sep 14, 2006 at 06:55:24PM +0200, Raphael H. Becker wrote: Hi * today i checked out fresh RELENG_6 on my amd64, build(world|kernel) seems fine, installworld fails: [...] === sys/boot/i386/btx (install) === sys/boot/i386/btx/btx (install) === sys/boot/i386/btx/btxldr (install) === sys/boot/i386/btx/lib (install) === sys/boot/i386/boot2 (install) btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin btxld:No such file or directory *** Error code 1 Stop in /usr/src/sys/boot/i386/boot2. *** Error code 1 [...] It's trying to build things at an inappropriate time (install phase), hence the error. Why i386 here: boot/i386/boot2/? amd64 shares the boot code with i386. I did the following procedure: 1) install new Dell PE2950 with amd64/6.1-RELEASE from CD (minimal) 2) cvsup /usr/src to RELENG_6 this afternoon 3) make clean buildworld buildkernel (forgot to build it for SMP) 4) make buildkernel KERNCONF=PE2950 (which is just SMP plus ident a.t.m) 5) make installkernel KERNCONF=PE2950 6) reboot 7) make installworld -- fails. Did I miss something here? How to fix? 1) Check that your date/time is correct during the build. 2) Check that your date/time is correct during the install (perhaps missed adjkerntz -i after rebooting into SU?) 3) Check that /usr/src doesn't have files from the future. Is this amd64 specific? No. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpdOK9h1Y37o.pgp Description: PGP signature
Re: Anyone??? (was Reproducible data corruption on 6.1-Stable)
Hello Jonathan, Wednesday, September 13, 2006, 2:38:14 AM, you wrote: I set up a new server recently and transferred all the information from my old server over. I tried to use unison to synchronize the backup of pictures I have taken and noticed that a large number of pictures where marked as changed on the server. After checking the pictures by hand I confirmed that many of the pictures on the server were corrupted. It appears the corruption happens during the read process because when I recompare the files in a graphical diff tool between cache flushes the differences move around!?!?!? The differences also appear to be very small for the most part, single bytes scattered throughout the file. I really have no idea what is causing the problem and would like to pin it down so I can either replace hardware if it's bad or fix whatever the bug is. CPU: AMD Athlon(tm) XP 3200+ (2090.16-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x6a0 Stepping = 0 I saw very similar simptons on p4 3.2ghz. I was able to build world without any problems and the overall stability of the machine was completely good, but when I tried to install some ports, the md5 sums didn't match the source and I was sure that they were all right. The following simple test demonstrates the problem I was hitting: [EMAIL PROTECTED] ~]# sha256 /usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz SHA256 (/usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz) = b95ddf27bc0ffa379c9aa881ca39e92a7d79e0d08999b4dff6d7d9547ee2a72d [EMAIL PROTECTED] ~]# sha256 /usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz SHA256 (/usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz) = 71432841b3965b7ab2d83f0dc7c3049195ea4e9267a8dc2d825a8a0466982930 [EMAIL PROTECTED] ~]# sha256 /usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz SHA256 (/usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz) = 83e44f5301b3270e821850164c74d275f6721bed5d126480cf518a9fe5ca0d6c [EMAIL PROTECTED] ~]# md5 /usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz bd8c2e593e1fa4b01fd98eaf016329bb [EMAIL PROTECTED] ~]# md5 /usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz bd8c2e593e1fa4b01fd98eaf016329bb [EMAIL PROTECTED] ~]# md5 /usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz b9342bb213393238dd37322d4e2ee3fe [EMAIL PROTECTED] ~]# md5 /usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz 88efa7977fd3febaa8d260e3d5f21917 The memtest didn't show any problems with RAM and we were unable to clarify what is really going on. Then we managed to get the machine replaced with the complete new hardware and the problem was gone. Later, I was told that it is some kind of known bug in older p4's bioses (and advised to update the bios which should have been fixed in the meantime) but we were unable to find out any information about the problem. Fortunately the colo company replaced the hardware with no problems. So long so good and the box is running flawlessly. -- Best regards, Danielmailto:[EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI it failed in Acer Ferrari 4005 wmli
Dear friends. The ACPI is not working on my machine, I am using FreeBSD 6.1 Stable. How can i fix and if there is any instruction regarding the fix, please do not just mention just some files, but rather instruct me where and how to put them. Thank you in Advanced -- Mohamed M. Maher ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Thu, Sep 14, 2006 at 11:44:12AM -0400, Jamie Bowden wrote: On 9/9/06, Mark Andrews [EMAIL PROTECTED] wrote: Yeah, -STABLE is what you should run if you want stable code, right? No. STABLE means STABLE API. If you want stable code you run releases. Between releases stable can become unstable. Think of stable as permanent BETA code. Changes have passed the first level of testing in current which is permanent ALPHA code. No, this is what it means now. I've been running FreeBSD since 1.1, and -STABLE used to mean exactly that. The developement branch was -C, and -S was where things went after extensive testing. You were not allowed to break -S or Jordan would rip your fingers off. This change to the current structure wasn't meant to be permanent when it was done (between 4 and 5, IIRC), and was only done out of necessity because the changes across that major release were huge. FreeBSD needs an interim track that mirrors what -STABLE used to be, which is a track between point releases that can be relied upon (and RELEASE_x_y doesn't work, since it only addresses security and bugs deemed worthy, which most aren't). YES [bar]. Until then I'm wedged into running -RELEASE (and occasionally praying to the computer gods. -- Jamie Bowden -- It was half way to Rivendell when the drugs began to take hold Hunter S Tolkien Fear and Loathing in Barad Dur Iain Bowen [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On 14 September 2006, at 14:05, Björn König wrote: hackmiester (Hunter Fuller) schrieb: On 12 September 2006, at 02:06, Björn König wrote: Karl Denninger schrieb: This is not cool folks. I think you misunderstood what -STABLE means. (Or maybe I do?) -STABLE is still a development branch without guarantee of a stable and working operating system. Hahahahaha... That's ironic... That wasn't meant to be ironic. Years of experience and observations of development lead to this conclusion. RIght. All i can say, though, is that someone that doesn't know any better would probably not think Oh! That means that upgrades are possible between releases, and not that my system will actually run, or anything! It just seems it'd be quite a cause of confusion. Regards Björn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED] -- hackmiester (Hunter Fuller) svinx yknow when you go to a party, and everyones hooked up except one guy and one girl svinx and so they look at each other like.. do we have to? svinx intel nvidia must be lookin at each other like that right now Phone Voice: +1 251 589 6348 Fax: Call the voice number and ask. Email General chat: [EMAIL PROTECTED] Large attachments: [EMAIL PROTECTED] SPS-related stuff: [EMAIL PROTECTED] IM AIM: hackmiester1337 Skype: hackmiester31337 YIM: hackm1ester Gtalk: hackmiester MSN: [EMAIL PROTECTED] Xfire: hackmiester ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Thanks!
On Thu, Sep 14, 2006 at 01:36:30PM -0300, Ricardo Nabinger Sanchez wrote: On Thu, 14 Sep 2006 01:27:34 -0500, Charles P. Schaum [EMAIL PROTECTED] wrote: I am real happy with FreeBSD. I would be interested in seeing more desktop stuff become a reality. Neither of the desktop variants of FreeBSD works so well for me, yet. Have you tried Desktop BSD and/or PCBSD? IIRC, they're based on FreeBSD and very desktop oriented -- perhaps they'll work well for you. I *thought* there was a Desktop distro. URL's? or should I just google around? gary -- Ricardo Nabinger Sanchez [EMAIL PROTECTED],wait4.org} Powered by FreeBSD Left to themselves, things tend to go from bad to worse. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Thu, Sep 14, 2006 at 05:34:08PM -0500, hackmiester (Hunter Fuller) wrote: On 14 September 2006, at 14:05, Bj?rn K?nig wrote: hackmiester (Hunter Fuller) schrieb: On 12 September 2006, at 02:06, Bj?rn K?nig wrote: Karl Denninger schrieb: This is not cool folks. I think you misunderstood what -STABLE means. (Or maybe I do?) -STABLE is still a development branch without guarantee of a stable and working operating system. Hahahahaha... That's ironic... That wasn't meant to be ironic. Years of experience and observations of development lead to this conclusion. RIght. All i can say, though, is that someone that doesn't know any better would probably not think Oh! That means that upgrades are possible between releases, and not that my system will actually run, or anything! It just seems it'd be quite a cause of confusion. Anyone who is confused but doesn't attempt to enlighten themselves by reading the provided documentation deserves to stay confused :) Kris pgpdu8UO4NIuT.pgp Description: PGP signature
Re: em0: watchdog timeout -- resetting (6.1-STABLE)
Jack Vogel wrote: On 9/13/06, Ronald Klop [EMAIL PROTECTED] wrote: ... Them manual page em(4) mentions trying another cable when the watchdog timeout happens, so I tried that. But it didn't help. Is there anything I can test to (help) debug this? It happens a lot when my machine is under load. (100% CPU) Is it possible that it happens since I upgraded the memory from 1GB to 2 GB? watchdogs mean that the transmit ring is not being cleaned, so the question is what is your machine doing at 100% cpu, if its that busy the network watchdogs may just be a side effect and not the real problem? Jack I see these too when installing packages over nfs on my Laptop. If I run with a low level of network traffic, i.e. ssh compile, and peg out the cpu with a benchmark such as flops, I don't see these timeouts. 6.1-STABLE FreeBSD 6.1-STABLE #0: Sat Aug 26 14:45:40 CDT 2006 [EMAIL PROTECTED]:1:0: class=0x02 card=0x05491014 chip=0x101e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82540EP Gigabit Ethernet Controller (Mobile)' class= network Any suggestions? Thanks Dan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Friday 15 September 2006 01:15, Kris Kennaway wrote: Anyone who is confused but doesn't attempt to enlighten themselves by reading the provided documentation deserves to stay confused :) What if they're unaware of their own confusion? Cheers Benjamin pgpvrWdyprhGN.pgp Description: PGP signature
Re: Thanks!
On Thu, 14 Sep 2006 16:11:08 -0700, Gary Kline [EMAIL PROTECTED] wrote: I *thought* there was a Desktop distro. URL's? or should I just google around? There you go: http://www.pcbsd.org/ http://www.desktopbsd.net/ :) -- Ricardo Nabinger Sanchez [EMAIL PROTECTED],wait4.org} Powered by FreeBSD Left to themselves, things tend to go from bad to worse. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em0: watchdog timeout -- resetting (6.1-STABLE)
watchdogs mean that the transmit ring is not being cleaned, so the question is what is your machine doing at 100% cpu, if its that busy the network watchdogs may just be a side effect and not the real problem? I get them with a completely idle machine. My home directory is mounted via NFS (from FreeBSD 6.1 on an amd64 machine), and with the kernel from earlier this week, the machine would just hang for 30 seconds to a couple of minutes. A slew of watchdog timeout messages would appear. Then I'd get a moment's responsiveness out of the machine, then another long wait, then a moment's responsiveness, then a long wait... The machine would never recover from this cycle (at least, so far as I was patient enough to wait). Going back to a kernel dated late July resolved everything. Someone else asked me for the hardware version of my em0 board... [EMAIL PROTECTED]:10:0: class=0x02 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00vendor = 'Intel Corporation' device = '82540EM Gigabit Ethernet Controller' class= network subclass = ethernet -David. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Thu, 14 Sep 2006, Jamie Bowden wrote: No, this is what it means now. I've been running FreeBSD since 1.1, and -STABLE used to mean exactly that. The developement branch was -C, and -S was where things went after extensive testing. You were not allowed to break -S or Jordan would rip your fingers off. Ah, QA through fear of the mighty hand of Jordan coming flying out your monitor and ripping your fingers off :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On 15/09/2006 01:37, Benjamin Lutz wrote: On Friday 15 September 2006 01:15, Kris Kennaway wrote: Anyone who is confused but doesn't attempt to enlighten themselves by reading the provided documentation deserves to stay confused :) What if they're unaware of their own confusion? I guess they get what they deserves ;) Is there a be better source of enlightenment than a handbook? To quote[1]: --% 21.2.2.1 What Is FreeBSD-STABLE? FreeBSD-STABLE is our development branch from which major releases are made. Changes go into this branch at a different pace, and with the general assumption that they have first gone into FreeBSD-CURRENT for testing. This is still a development branch, however, and this means that at any given time, the sources for FreeBSD-STABLE may or may not be suitable for any particular purpose. It is simply another engineering development track, not a resource for end-users. --% Regards, Karol [1]http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html -- Karol Kwiatkowski freebsd at orchid dot homeunix dot org OpenPGP: http://www.orchid.homeunix.org/carlos/gpg/0x06E09309.asc signature.asc Description: OpenPGP digital signature
Regression Tests ...
With all the talk about -STABLE, and how bad things can get, and how in 'the good old days, this would never have happened' ... instead of griping about what is, could and should be ... why not focus on how to improve the process? For instance, we know that *most* of the time, -STABLE is exactly that, -STABLE ... and there are several of us that feel that -STABLE is more stable then -RELEASE ... not everyone agrees, but, hey, everyone has a right to disagree ... For the PostgreSQL Project, we have a 'build farm' ... something that I think is similar to the tinderboxes ... but, their point isn't to just build the source tree, but to run its regression tests, and report when something fails: http://www.pgbuildfarm.org/cgi-bin/show_status.pl I saw the post from the guy that caused the original thread, talking about how he was working on regression tests as he's developing the code ... is there some way that we can extend the tinderboxes to run these regression tests, and put a report up on freebsd.org reporting things like 'last successful build/test', so that one could use CVSup to upgrade to that date? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em0: watchdog timeout -- resetting (6.1-STABLE)
On Fri, 15 Sep 2006 02:06:08 +0200, David C. Myers [EMAIL PROTECTED] wrote: watchdogs mean that the transmit ring is not being cleaned, so the question is what is your machine doing at 100% cpu, if its that busy the network watchdogs may just be a side effect and not the real problem? I get them with a completely idle machine. My home directory is mounted via NFS (from FreeBSD 6.1 on an amd64 machine), and with the kernel from earlier this week, the machine would just hang for 30 seconds to a couple of minutes. A slew of watchdog timeout messages would appear. Then I'd get a moment's responsiveness out of the machine, then another long wait, then a moment's responsiveness, then a long wait... The machine would never recover from this cycle (at least, so far as I was patient enough to wait). Going back to a kernel dated late July resolved everything. Someone else asked me for the hardware version of my em0 board... [EMAIL PROTECTED]:10:0: class=0x02 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00vendor = 'Intel Corporation' device = '82540EM Gigabit Ethernet Controller' class= network subclass = ethernet -David. This sounds familiar to my problem. I solved it today by enabling polling. I know it's a workaround. -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone??? (was Reproducible data corruption on 6.1-Stable)
Daniel Gerzo wrote: Hello Jonathan, Wednesday, September 13, 2006, 2:38:14 AM, you wrote: I set up a new server recently and transferred all the information from my old server over. I tried to use unison to synchronize the backup of pictures I have taken and noticed that a large number of pictures where marked as changed on the server. After checking the pictures by hand I confirmed that many of the pictures on the server were corrupted. It appears the corruption happens during the read process because when I recompare the files in a graphical diff tool between cache flushes the differences move around!?!?!? The differences also appear to be very small for the most part, single bytes scattered throughout the file. I really have no idea what is causing the problem and would like to pin it down so I can either replace hardware if it's bad or fix whatever the bug is. CPU: AMD Athlon(tm) XP 3200+ (2090.16-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x6a0 Stepping = 0 I saw very similar simptons on p4 3.2ghz. I was able to build world without any problems and the overall stability of the machine was completely good, but when I tried to install some ports, the md5 sums didn't match the source and I was sure that they were all right. The following simple test demonstrates the problem I was hitting: [EMAIL PROTECTED] ~]# sha256 /usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz SHA256 (/usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz) = b95ddf27bc0ffa379c9aa881ca39e92a7d79e0d08999b4dff6d7d9547ee2a72d [EMAIL PROTECTED] ~]# sha256 /usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz SHA256 (/usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz) = 71432841b3965b7ab2d83f0dc7c3049195ea4e9267a8dc2d825a8a0466982930 [EMAIL PROTECTED] ~]# sha256 /usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz SHA256 (/usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz) = 83e44f5301b3270e821850164c74d275f6721bed5d126480cf518a9fe5ca0d6c [EMAIL PROTECTED] ~]# md5 /usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz bd8c2e593e1fa4b01fd98eaf016329bb [EMAIL PROTECTED] ~]# md5 /usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz bd8c2e593e1fa4b01fd98eaf016329bb [EMAIL PROTECTED] ~]# md5 /usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz b9342bb213393238dd37322d4e2ee3fe [EMAIL PROTECTED] ~]# md5 /usr/ports/distfiles/ruby/ruby-1.8.4.tar.gz 88efa7977fd3febaa8d260e3d5f21917 The memtest didn't show any problems with RAM and we were unable to clarify what is really going on. Then we managed to get the machine replaced with the complete new hardware and the problem was gone. Later, I was told that it is some kind of known bug in older p4's bioses (and advised to update the bios which should have been fixed in the meantime) but we were unable to find out any information about the problem. Fortunately the colo company replaced the hardware with no problems. So long so good and the box is running flawlessly. I don't think it's quite the same as my problem as I have to use dd on a large file to flush the cache and force freebsd to go back to the disk before the checksum changes. At this point I think I need to further narrow down where the error is occurring but I don't know what to try next. I am 99.999% sure memory and cpu are not the problem but after that point I'm getting into driver and filesystem code testing which is a little overwhelming to just dive into. Jonathan ___ 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
Marcelo Gardini do Amaral wrote: With the 7.x kernel and no changes in src/sys/netinet/udp_usrreq.c I tried different timecounters and I couldn't see any performance difference. You have tested with a GENERIC kernel? You should remove all debugging kernel options before testing performance. -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
PC-BSD and DesktopBSD compared to FreeBSD
A note on PC-BSD and DesktopBSD as compared to my -STABLE experiences: -STABLE works best. First, PC-BSD will panic under more conditions than -RELEASE, -STABLE or DesktopBSD. I did some monkeying around and found that to be true, especially with older boxes. Second, DesktopBSD works better than PC-BSD, and noticeably so. But it's based on 5 and I want 6. So that kinda throws a spanner in the works. Both desktop installers, however, do not easily support an install over multiple disks or a lot of customization. FreeBSD does. That's the same reason why I like the Debian installer and the old Ubuntu installer over many of the others. (Although the Ubuntu installer, old and new, has geometry issues.) Fedora's default is to use an LVM setup that will be a pain in the tush if you install anything else over it unless you use a third-party util to hose all the LVM info. Merely creating a new FS, i.e., installing FBSD in the slice where Fedora was, won't cut it; you will get weirdness in the boot loader. When I want desktop, I don't want dumb. I want defaults for those that want them and then I want to depart from that when needed. The desktop attempts based on FreeBSD do not easily handle this. I see that as basically a show-stopper. The elegant thing about FreeBSD is the way in which one can vary things to meet individual needs. This is no canonical distro template mentality. The real trick is to make a desktop work with such variation. One thing I see, for example, is an opportunity to have a decision like here is some default art, themes, whatever in a port/package for those that want a my machine looks like FreeBSD feel. One might suggest that all ports that would normally be associated with menus and MIME types in XFCE, KDE and Gnome, etc. would arrange to install these in the expected places. Presently, some do; some don't. One need not integrate a lot into the OS. Indeed, scripts for removable media events and the like can safely remain in ports. But it strikes me that Linux and Windows, as well as MacOS, all have a certain look and feel per distro and that a move to say for those that want a default option of look and feel and don't want to continually edit menus (for which KDE is easiest) then we have a plan for you. This would not add too much burden to the port maintainers and it would just make the learning curve a little easier for noobs, until they do a BOFH-recommended action after failing to RTFM. Even running the autoconfig for X, if X is installed, and allowing a GUI login manager selection menu in the installer couldn't hurt. After all, if one bundles things like Gnome and KDE on distribution media, why not go the distance and give the option to do all the preliminary integration in the installer, if so selected? For example, I have no problem installing NetBSD, knowing that I first go to the utility menu and set up the NIC, then install, then say yes, I want those NIC settings to save some work, then do the reboots and set things up. Then I tweak more files and add software with pkgsrc. But that's extra work that FreeBSD already integrates to some extent into one installer session. Why not continue along that path? What about a menu that allows an expert mode for certain stages as well as just a default decision like I want FreeBSD with KDE/Gnome. For example, if pdftk or ImageMagick blow up /var/tmp when batch converting or if OpenOffice takes about 9G to compile, then one could consider a resource needs database correlating to packages desired at install time. Given, that puts stress on the size of the image. It could also be a DVD-only option. One could select the ports that one would eventually like (perhaps like synaptic) and the needs could be anticipated for install-time FS-tuning. A subsequent option might allow installation via pkg_add or simply set up a script and notify root to run it in the background to fetch and install the desired packages at a later time. Such an approach would take the selection of distributions and packages to perhaps another level. Yes, it violates the small is better dictum but it also recognizes that the folks at the middle of the bell curve are great in number and short on technical mastery. The decision comes when the target market is determined. It would also give a certain slick factor. That might not always be good, but remembering old Amiga demos, I can hardly deny that eye candy and ease of use does attract. Part of the desktop thing for me is that I am partially blind and I find that Gnome is very friendly to my vision, or lack thereof. It causes much less eye strain than other desktops. So I like working from that environment for accessibility issues. I like the idea of a challenge and solving a problem. I like FreeBSD. I don't get off on messing with pixmaps, menus, MIME types and other mickey-mouse stuff. Requiring a certain standard of desktop integration by port maintainers, giving the option of a default look and feel and
