ACPI resume problems in STABLE
Hi all, I have a Thinkpad z60m, with a custom kernel conf. I was trailing RELENG_6 (aka STABLE) on an almost daily basis (and world updates every week). ACPI enabled, APIC disabled. I can't tell for sure when trouble started, but roughly about 2 weeks ago I couldn't resume from suspend anymore. It would come back and the screen would white out, or stay completelly black (white out == a nice warm white colour... but dead otherwise). Caps lock would not light up LED. There was no kernel dump happening either (no HD activity, i even let it sit for 10 minutes to see if it would help). No info on dmesg or /var/log/messages. I simplified my kernel conf (removed vesa, agp and graphic options for sc) - no changes. I thought there was an improvement when I removed agp, but it was just false hopes. I then decided to revert kernel + world to RELENG_6_1, without otherwise changing my kernel or /etc configuration (other than the obvious mergemaster changes to /etc). and.. voila, everything back to normal. My current uname is: $ uname -a FreeBSD ayiin.xxx.com 6.1-RELEASE-p6 FreeBSD 6.1-RELEASE-p6 #23: Tue Sep 12 14:52:32 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AYIIN i386 The only thing I've noticed that in how my lappy works now is that if_iwi0 is loaded on startup, but iw_bss and firmware.ko are not. I can load them by hand, but haven't been able to test to see if it actually works (i have a feeling it doesnt). I have installed iwi-firmware-kmod-3.0_1 Intel PRO/Wireless 2200 Firmware Kernel Module I have kernel dump from my last RELENG_6 attempt when I removed agp - for once it actually died with a dump. I have a copy of the RELENG_6 /boot/ as well. If I can help debugging this problem, please let me know. I can try to move to STABLE from 2 or 3 weeks ago and see if that makes any difference - any significant date I should look at? cheers! My kernel config is: - # AYIIN - Beto's laptop - Kernel config # IBM/Lenovo Thinkpad z60m # BASED ON # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.429.2.5 2006/01/23 14:19:36 marius Exp $ machine i386 #cpuI586_CPU cpu I686_CPU ident AYIIN options PERFMON # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols options INCLUDE_CONFIG_FILE # Include this file in kernel #optionsSCHED_ULE # ULE scheduler options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking ## As as 2006/01/30, IPSEC is still under GIANT - Disabling until i actually need it. #options IPSEC #IP security #options IPSEC_ESP #IP security (crypto; define w/ IPSEC) device crypto # TCP_SIGNATURE adds support for RFC 2385 (TCP-MD5) digests. These are # carried in TCP option 19. This option is commonly used to protect # TCP sessions (e.g. BGP) where IPSEC is not available nor desirable. # This is enabled on a per-socket basis using the TCP_MD5SIG socket option. # This requires the use of 'device crypto', 'options FAST_IPSEC' or 'options # IPSEC', and 'device cryptodev'. #optionsTCP_SIGNATURE #include support for RFC 2385 device cryptodev options NETGRAPH# netgraph(4) system # altq(9). Enable the base part of the hooks with the ALTQ option. # Individual disciplines must be built into the base system and can not be # loaded as modules at this point. options ALTQ options ALTQ_CBQ# Class Bases Queueing options ALTQ_RED# Random Early Detection options ALTQ_RIO# RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler options ALTQ_CDNR # Traffic conditioner options ALTQ_PRIQ # Priority Queueing #options IPFIREWALL #firewall #options IPFIREWALL_VERBOSE #enable logging to syslogd(8) #options IPFIREWALL_VERBOSE_LIMIT=100#limit verbosity #options IPFIREWALL_FORWARD
Re: Anyone??? (was Reproducible data corruption on 6.1-Stable)
Jonathan Stewart writes: > [...] > 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. I > attempted to use unison to update the files on the server with the > correct local copies but it would fail on almost all the files with the > message "destination updated during synchronization." > > 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. > [...] It might be a memory problem. I had a linux server that was serving a subversion repository, plus some web stuff. I added some additional memory to keep it from wheezing and it seemed to be running fine. We started noticing problems with things that had been checked out of the repository (e.g. binary tarballs). Removing the extra memory made things work again. memtest86 didn't find anything wrong, which I gather isn't that unusual in these situations. Then again, your problem might be something else entirely g. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Anyone??? (was Reproducible data corruption on 6.1-Stable)
(I know double posting is bad form but this includes new information and it's been several days. Suggestions on where else to look for help are welcome, highpoint was no help) 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. I attempted to use unison to update the files on the server with the correct local copies but it would fail on almost all the files with the message "destination updated during synchronization." 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. I cvsuped and rebuilt world and kernel recently hoping that it had been fixed but with no luck. I have not seen any error messages on the console at all either. I have a pair of 320GB SATA hard drives setup as RAID0 on a HighPoint RocketRaid 1520 card the card BIOS is the latest revision as is the motherboard BIOS. This being a data corruption issue I can afford any amount of downtime needed for trouble shooting as it's not very useful to have the server up if everything is going to get corrupted. Thank you, Jonathan uname -a: FreeBSD X 6.1-STABLE FreeBSD 6.1-STABLE #0: Sun Sep 10 22:54:17 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVER i386 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-STABLE #0: Sun Sep 10 22:54:17 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVER mptable_probe: MP Config Table has bad signature: 4\^C\^_ Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 3200+ (2090.16-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383fbff AMD Features=0xc0400800 real memory = 1073676288 (1023 MB) avail memory = 1041698816 (993 MB) kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 Correcting nForce2 C1 CPU disconnect hangs agp0: mem 0xd800-0xdbff at device 0.0 on pci0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xe1085000-0xe1085fff irq 5 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xe1082000-0xe1082fff irq 5 at device 2.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xe1083000-0xe10830ff irq 12 at device 2.2 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 4 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 6 ports with 6 removable, self powered nve0: port 0xe400-0xe407 mem 0xe1084000-0xe1084fff irq 12 at device 4.0 on pci0 nve0: Ethernet address 00:0c:6e:7d:e0:79 miibus0: on nve0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto nve0: Ethernet address: 00:0c:6e:7d:e0:79 pci0: at device 5.0 (no driver attached) pci0: at device 6.0 (no driver attached) pcib1: at device 8.0 on pci0 pci1: on pcib1 atapci0: port 0xa000-0xa007,0xa400-0xa403,0xa800-0xa807,0xac00-0xac03,0xb000-0xb0ff irq 11 at device 6.0 on pci1 ata2: on atapci0 ata3: on atapci0 pci1: at device 9.0 (no driver attached) pci1: at device 9.1 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 9.0 on pci0 ata0: on atapci1 ata1: on atapci1 pcib2: at device 12.0 on pci0 pci2: on pcib2 xl0: <3Com 3c920B-EMB Integrated Fast Etherlink XL> port 0xc000-0xc07f mem 0xdd00-0xdd7f irq 5 at device 1.0 on pci
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
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... (For lack of a better word, really.) -STABLE guarantees that interfaces remain stable. If you want reliability then jump from release to release. 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) yknow when you go to a party, and everyones hooked up except one guy and one girl and so they look at each other like.. do we have to? 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]"
question about rebuiding a gmirror on 6.1
A friend of mine decided to take me up on my offer to help him set up and run a freebsd-stable system (he's a photographer who's only ever used shell accounts onto linux systems before). We setup a gmirror using Approach 2 from http://people.freebsd.org/~rse/mirror. It's been up and running for a while and I just noticed that it was running in DEGRADED mode, having failed ad4. I had him reboot it with either ad4 or ad6 attached, and both seem to work individually. The data on ad4 looks "older", which makes sense because hasn't been being updated. Since we're not sure why it was failed in the first place and it seems to work, we're going to hook it up and try again. I'm nervous about whether the system will sync the newer ad6s1 data onto ad4s1 (what I'd like to happen) or sync the ad4s1 data onto the ad6s1 (which would suck). Our solution is to boot off a CD with only ad4 hooked up, use gmirror clear ad4s1 to blow away the metadata on ad4s1, then reboot with both drives and do gmirror forget gm0s1 and gmirror insert gm0s1 ad4s1. Am I being overly paranoid about the direction in which it'll sync the data? Is there a better way that I should have handled this (other than forcing a practice run back when we got started...)? Thanks, g. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal and Softupdates
On Tue, Sep 12, 2006 at 09:47:50PM +0200, Teufel wrote: > Well, thats why i actually don't find journaling filesystems very sexy. > So the question is, if it is still safe to use fsck on a gjournal > enabled FS ? Well, if you just want to check, you can take a snapshot and run fsck -n on it. That will at least tell you if there's any problems that need to be dealt with. Running fsck on a journal-enabled UFS should be safe modulo the usual requirements (not mounted, which probably means single-user mode). Craig ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6 buildkernel broken ?
On Tue, 2006-09-12 at 23:24 +0200, Pascal G. Hofstee wrote: > A RELENG_6 buildkernel with sources updated about 2 hours ago seems to > break down (after a successfull buildworld) on the following error. > I tried updating from at least 3 different cvsup-servers but i am not > seeing any differences. Can anybody confirm this breakage ? I checked the date of the last commit to ata-chipset.c and found it hard to believe nobody had stepped up and notified of a build breakage. I decided to remove the old ata-chipset.c and reupdate (after first generating md5 sums) .. and noticed that after re-fetching ata-chipset.c the new md5-sum changed from the original. Please ignore the line-noise. -- Pascal Hofstee ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RELENG_6 buildkernel broken ?
A RELENG_6 buildkernel with sources updated about 2 hours ago seems to break down (after a successfull buildworld) on the following error. cc -c -O -pipe -march=athlon -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/dev/ata/ata-chipset.c /usr/src/sys/dev/ata/ata-chipset.c: In function `ata_nvidia_ident': /usr/src/sys/dev/ata/ata-chipset.c:2827: error: `ENX300' undeclared (first use in this function) /usr/src/sys/dev/ata/ata-chipset.c:2827: error: (Each undeclared identifier is reported only once /usr/src/sys/dev/ata/ata-chipset.c:2827: error: for each function it appears in.) /usr/src/sys/dev/ata/ata-chipset.c:2827: error: syntax error before '}' token /usr/src/sys/dev/ata/ata-chipset.c: At top level: /usr/src/sys/dev/ata/ata-chipset.c:2800: warning: unused variable `ctlr' /usr/src/sys/dev/ata/ata-chipset.c:2824: warning: unused variable `buffer' Followed by about another full screen of "defined but not used" and "declared static but never defined" warnings. I tried updating from at least 3 different cvsup-servers but i am not seeing any differences. Can anybody confirm this breakage ? -- Pascal Hofstee ___ 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 Tue, September 12, 2006 12:22 pm, Marc G. Fournier wrote: > What are ppl currently using for CFLAGS/COPTFLAGS in /etc/make.conf > for building kernel/world? I know awhile back it wasn't recommended > to go above -O2, for instance, but suspect that has changed ... ? The defaults are "-O2 -pipe -fno-strict-aliasing". I stopped manually setting CFLAGS/COPTFLAGS around the time of 5.1 and haven't really noticed any changes in performance. Prior to that, I used "-Os -pipe". There are reported problems with not using -fno-strict-aliasing with parts of the base and/or kernel. And, the first thing anyone will tell you if you run into any compile/runtime errors is to put CFLAGS/COPTFLAGS back to the defaults. :) Freddie Cash [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: gjournal and Softupdates
Christian Laursen wrote: Ivan Voras <[EMAIL PROTECTED]> writes: Christian Laursen wrote: However, with journaling you can have filesystem corruption and not know about it. With fsck, bg or not, at least you will know. Also, I'm interested about this - what kind of silent corruption? The same kind that can generally come from on-drive caches? Yes, as well as corruption resulting from bugs in the kernel code. The point is that you will never know because you never check your filesystems. Well, thats why i actually don't find journaling filesystems very sexy. So the question is, if it is still safe to use fsck on a gjournal enabled FS ? Having a bgfsck running on a 1 TB volume is not so terrible when it afterwards confirms a valid and consistent filesystem.. Just trusting the journal is a false sense of security in my opinion. my 2cp Stephan ___ 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?!
Karl Denninger wrote: I don't think its too much to ask that before something is MFC'd back to -STABLE from -CURRENT that it be tested for the most common functionality (that is, does it work at all?) In this case all that someone had to do was boot the system and then detach and reattach a mirror component - the most basic of functionality - to detect that the patch was bad. That obviously wasn't done in this instance. I understand that finding corner cases and expecting exhaustive testing is unreasonable from a free project - even in a -RELEASE we don't get that. But this wasn't a corner case - it was a situation where absolutely zero testing was performed before the MFC was sent back to the source tree. So when can the FreeBSD Foundation expect your donation of computers for the purpose of GEOM testing? -- Darren Pilgrim ___ 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 Tue, Sep 12, 2006 at 04:22:51PM -0300, Marc G. Fournier wrote: > > What are ppl currently using for CFLAGS/COPTFLAGS in /etc/make.conf for > building kernel/world? I know awhile back it wasn't recommended to go > above -O2, for instance, but suspect that has changed ... ? Nothing above -O2 is supported. Period. If you try another value and something breaks, don't report it unless you can verify it happens with -O or -O2. For many applications, -O2 will perform better than -O3 so you need to benchmark individual applications. For most applications, there's simply no point. -- Brooks pgps9W0UOMm0W.pgp Description: PGP signature
Re: optimization levels for 6-STABLE build{kernel,world}
Marc G. Fournier wrote: What are ppl currently using for CFLAGS/COPTFLAGS in /etc/make.conf for building kernel/world? I know awhile back it wasn't recommended to go above -O2, for instance, but suspect that has changed ... ? CFLAGS=-O2 -pipe -fno-strict-aliasing COPTFLAGS=-O2 -pipe -fno-strict-aliasing CPUTYPE?=prescott .. just works(tm) for an Intel T-2300 dual core ;-) Using -O3 will get you into bother with the amount of inlining the compiler wants to do to the kernel, Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
optimization levels for 6-STABLE build{kernel,world}
What are ppl currently using for CFLAGS/COPTFLAGS in /etc/make.conf for building kernel/world? I know awhile back it wasn't recommended to go above -O2, for instance, but suspect that has changed ... ? Thanks ... 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?!
Karl Denninger wrote: > You've never been able to get reliability by jumping from release to release, I think there are a lot of users who disagree with you on that one. > and every time someone comes in the lists to complain about something being > broken in -RELEASE, the advice is to go to and track -STABLE! These are different issues. > I don't think its too much to ask that before something is MFC'd back to > -STABLE from -CURRENT that it be tested for the most common > functionality (that is, does it work at all?) In this case all that someone > had to do was boot the system and then detach and reattach a mirror component > - > the most basic of functionality - to detect that the patch was bad. > > That obviously wasn't done in this instance. No one has disagreed with you about this. Several people have apologized already. It's past time that you got over it. That said, no matter how stable (in the dictionary term of the word) a given branch of FreeBSD is (or is not) at any given time, nothing replaces the need to test changes/updates yourself, on non-production hardware, before deploying them to anything you care about. That is just as true of FreeBSD as it is of any commercial software. Time to move on here folks, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
At 10:15 AM 9/12/2006, Karl Denninger wrote: On Tue, Sep 12, 2006 at 09:06:15AM +0200, 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. -STABLE guarantees that interfaces remain > stable. If you want reliability then jump from release to release. > > Regards > Bj?rn You've never been able to get reliability by jumping from release to release, I think FreeBSD does not work for everyone with every setup, but works really well for some number of people. For me, I am in b). In fact it works really well for me and the some 250 boxes I look after of varying age and configs... There have been some unfortunate bugs, but I take that as part of what FreeBSD is-- a volunteer project. If FreeBSD releases have *never* worked for you (I will take your word you are not being childish and exaggerating here), why on earth are you using FreeBSD ? Also, what are you comparing FreeBSD to, where the RELEASE works for everyone out of the box for ever and ever ? You cant mean Windows, as they release monthly updates-- some of which after having gone through tens of thousands of dollars of regression testing (FreeBSD does not have an army of employees to do planned regression testing let alone tens of thousands of dollars), and manage to introduce BIGGER bugs than they were fixing like they did last month with Win2k. You cant mean LINUX as they seem to be doing a kernel a month (or more) recently. Which OS are you talking about that is so perfect from release to release ? ---Mike ___ 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?!
Greg Barniskis wrote: Karl Denninger wrote: and every time someone comes in the lists to complain about something being broken in -RELEASE, the advice is to go to and track -STABLE! Maybe splitting hairs, but advising a user with a problem to try using the -STABLE code that exists at the time of the problem report is really not the same as advising them to /track/ STABLE. 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. On the other hand if you update a production system to a point in time of STABLE that fixes a particular bug that plagued a release point, and then you don't update again until the next release point or security advisory, you will very likely find joy. See my similar comment that echoes Karl's. Now go back and read what Karl said. He's not tracking -STABLE on a production box, he updated to -STABLE to fix an existing problem. What bit him in the ass is a problem with code that "in theory" had not changed and _was_supposed_ to have been tested. That is, it was working, he upgraded, as everyone tells you to do, to get fixes to -RELEASE bugs, not to track -STABLE. John -- John T. Farmer Owner & CTO GoldSword Systems [EMAIL PROTECTED] 865-691-6498 Knoxville TN Consulting, Design, & Development of Networks & Software ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.1-RELEASE ->FreeBSD 6.1-Stable
Oliver Fromme wrote: > Vince wrote: > > Eric wrote: > > > S. M. Ibrahim (Lavlu) wrote: > > > > Now i am using FreeBSD 6.1-RELEASE. Now want to upgrade to FreeBSD > > > > 6.1-Stable. What is the easy process ? > > > > > > this works well > > > > > > http://mikestammer.com/dokuwiki/doku.php?id=bsd:updateos > > the cvsup part looks ok but for the actual build then read > > /usr/src/Makefile > > for the recommended procedure. > > It's better to read /usr/src/UPDATING. > > Best regards >Oliver > my wiki above mentions reading UPDATING (in step 3) before starting... UPDATING pretty much says exactly the same thing, except its 80% of the way into UPDATING. The wiki above also explains things a bit more for someone who has never done it. ___ 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 Tue, 12 Sep 2006 10:55:48 -0500 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. -- C:>WIN | Directable Mirror Arrays The computer obeys and wins.| A better way to focus the sun You lose and Bill collects. |licences available see |http://www.sohara.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cap_mkdb: illegal option -i. upgrade 5.4->6.1
On Tue, Sep 12, 2006 at 04:52:32PM +0200, [EMAIL PROTECTED] wrote:
> Hi list
>
> I'm upgrading 5.4 p18 to 6.1 p6.
>
> here's my tag: RELENG_6_1
>
> I did:
> make update
> make cleanworld
> make buildworld
>
> which gives following issue:
>
> cap_mkdb: illegal option -i
>
> It seems a known problem on netbsd during buildworld compilation. here's
> the solution I'm tring:
>
> cd /usr/src/usr.bin/cap_mkdb
> make clean
> make
> make install
>
> and I'm building world again.
>
> is that a known problem on freebsd?
>
This shouldn't happen. The buildworld target detects the current
version of your system, and bootstraps cap_mkdb if necessary:
: .if ${BOOTSTRAPPING} < 600015
: _cap_mkdb= usr.bin/cap_mkdb
: .endif
BOOTSTRAPPING is defined as follows:
: .if !defined(OSRELDATE)
: .if exists(/usr/include/osreldate.h)
: OSRELDATE!= awk '/^\#define[[:space:]]*__FreeBSD_version/ { print $$3 }' \
: /usr/include/osreldate.h
: .else
: OSRELDATE= 0
: .endif
That is, it's the value of __FreeBSD_version as defined in
/usr/include/osreldate.h. If your /usr/include/osreldate.h
is lying about the current version, e.g. if you accidentally
installed the new headers, then you can force it to zero,
such as:
make buildworld OSRELDATE=0
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpxaixm4fu4M.pgp
Description: PGP signature
Re: FreeBSD 6.1-RELEASE ->FreeBSD 6.1-Stable
Vince wrote: > Eric wrote: > > S. M. Ibrahim (Lavlu) wrote: > > > Now i am using FreeBSD 6.1-RELEASE. Now want to upgrade to FreeBSD > > > 6.1-Stable. What is the easy process ? > > > > this works well > > > > http://mikestammer.com/dokuwiki/doku.php?id=bsd:updateos > the cvsup part looks ok but for the actual build then read > /usr/src/Makefile > for the recommended procedure. It's better to read /usr/src/UPDATING. 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. "I learned Java 3 years before Python. It was my language of choice. It took me two weekends with Python before I was more productive with it than with Java." -- Anthony Roberts ___ 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?!
Karl Denninger wrote: You've never been able to get reliability by jumping from release to release, eh? Been doing that for 10 years without a single significant problem. Granted, we've been lucky enough here not to encounter (a) flakier hardware components and/or (b) flakier combos of drivers & apps & configs & heavy loads (a.k.a. bugs in FreeBSD) that other folks admittedly have encountered in the most painful ways. Releases aren't guaranteed to be perfect, nothing is, but plenty of users have no complaints at all about release point reliability. They're just not posting their non-problems to the lists. and every time someone comes in the lists to complain about something being broken in -RELEASE, the advice is to go to and track -STABLE! Maybe splitting hairs, but advising a user with a problem to try using the -STABLE code that exists at the time of the problem report is really not the same as advising them to /track/ STABLE. 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. On the other hand if you update a production system to a point in time of STABLE that fixes a particular bug that plagued a release point, and then you don't update again until the next release point or security advisory, you will very likely find joy. -- Greg Barniskis, Computer Systems Integrator South Central Library System (SCLS) Library Interchange Network (LINK) , (608) 266-6348 ___ 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?!
Hi. On Tue, Sep 12, 2006 at 09:15:47AM -0500, Karl Denninger wrote: > I don't think its too much to ask that before something is MFC'd back > to -STABLE from -CURRENT that it be tested for the most > common functionality (that is, does it work at all?) In this case all > that someone had to do was boot the system and then detach and > reattach a mirror component - the most basic of functionality - to > detect that the patch was bad. Thank god, nothing really can happen, if you deploy a new -STABLE on your servers, since of course before deploying a new piece of software it's being tested on a non-prod test setup, where you'll notice such apparent problems - especially when using -STABLE, where you never know, if you are probably just in the middle of a bigger commit. So, since nothing important could break, what's the hassle all about? - Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cap_mkdb: illegal option -i. upgrade 5.4->6.1
You might want to read: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cutting-edge.html Andreas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
cap_mkdb: illegal option -i. upgrade 5.4->6.1
Hi list I'm upgrading 5.4 p18 to 6.1 p6. here's my tag: RELENG_6_1 I did: make update make cleanworld make buildworld which gives following issue: cap_mkdb: illegal option -i It seems a known problem on netbsd during buildworld compilation. here's the solution I'm tring: cd /usr/src/usr.bin/cap_mkdb make clean make make install and I'm building world again. is that a known problem on freebsd? thanks for your anwsers ___ 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 Tue, Sep 12, 2006 at 09:59:02AM -0400, Vivek Khera wrote: > > On Sep 12, 2006, at 3:06 AM, Bj?rn K?nig wrote: > > >-STABLE is still a development branch without guarantee of a stable > >and working operating system. -STABLE guarantees that interfaces > >remain stable. If you want reliability then jump from release to > >release. > > If you want reliability, then you need to do your own testing on your > own hardware on your own application prior to replacing your working > version with the new one. Never rely on anyone else saying "Yeah, it > will work". It will come back and bite you where you don't want to > be bit. > > The other side of this is "don't replace what works" and just leave > things as they are. That'd be nice - but in this case the reason for the replacement was that there's SERIOUS breakage in the serial drivers (at least the Rocketport ones, and perhaps more) in 6.x, which was what prompted the update. Finding a totally-unrelated thing MFCd back with zero testing was QUITE a surpriseand not something I would have tested for ANYWAY, since the commitlog for sys and this module suggested that the change made to that section of code was in fact to remove some "inappropriate" comments - not change functionality in a way that could potentially cause this sort of breakage! -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ 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 Tue, Sep 12, 2006 at 09:06:15AM +0200, 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. -STABLE guarantees that interfaces remain > stable. If you want reliability then jump from release to release. > > Regards > Bj?rn You've never been able to get reliability by jumping from release to release, and every time someone comes in the lists to complain about something being broken in -RELEASE, the advice is to go to and track -STABLE! Guys, what's written in a handbook may be all well and good, but its what that matters - and this is what has "really happened" for the last ten years with FreeBSD! I don't think its too much to ask that before something is MFC'd back to -STABLE from -CURRENT that it be tested for the most common functionality (that is, does it work at all?) In this case all that someone had to do was boot the system and then detach and reattach a mirror component - the most basic of functionality - to detect that the patch was bad. That obviously wasn't done in this instance. I understand that finding corner cases and expecting exhaustive testing is unreasonable from a free project - even in a -RELEASE we don't get that. But this wasn't a corner case - it was a situation where absolutely zero testing was performed before the MFC was sent back to the source tree. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ 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?!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vivek Khera wrote: | If you want reliability, then you need to do your own testing on your | own hardware on your own application prior to replacing your working | version with the new one. Never rely on anyone else saying "Yeah, it | will work". It will come back and bite you where you don't want to be bit. | | The other side of this is "don't replace what works" and just leave | things as they are. I must say that this one critical point is what made me choose FreeBSD over Linux way back in ~1992. It is possible, indeed almost mandatory in a commercial setting, to build a local repository containing the OS and *everything* required to build it. Good change management is not about tracking the latest and greatest, it's about being able to make sensible decisions about which changes to implement, when and, most of all, knowing why. Security isn't just about firewalls, it's about business continuity too, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFBr7xQv9rrgRC1JIRAnboAJ4vHl7UAF149CavttzqVwD/r8aIlgCggmY8 JyW4le67COyphcFoUUbZ7ng= =0rDL -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: gjournal and Softupdates
On Tuesday 12 September 2006 19:34, Christian Laursen wrote: > Ivan Voras <[EMAIL PROTECTED]> writes: > > - todays desktop drives can lie about writing data. SoftUpdates relies > > on some assumptions about when the data is physically written to > > media, and those are not always valid today > > I think journaling relies on the same assumptions. You can disable write caching on your disks (most even honour it :) however a lot of people choke at the performance hit.. One big problem is that high capacity disks use track writing - if you modify a single sector the disk re-writes the whole track. If the power fails during the track write then you lose potentially completely unrelated data. This affects all file systems equally though. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpy9EyxUX5NX.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sep 12, 2006, at 3:06 AM, Björn König wrote: -STABLE is still a development branch without guarantee of a stable and working operating system. -STABLE guarantees that interfaces remain stable. If you want reliability then jump from release to release. If you want reliability, then you need to do your own testing on your own hardware on your own application prior to replacing your working version with the new one. Never rely on anyone else saying "Yeah, it will work". It will come back and bite you where you don't want to be bit. The other side of this is "don't replace what works" and just leave things as they are.
Re: FreeBSD 6.1-RELEASE ->FreeBSD 6.1-Stable
Eric wrote: > S. M. Ibrahim (Lavlu) wrote: >> Now i am using FreeBSD 6.1-RELEASE. Now want to upgrade to FreeBSD >> 6.1-Stable. What is the easy process ? >> >> > > this works well > > http://mikestammer.com/dokuwiki/doku.php?id=bsd:updateos the cvsup part looks ok but for the actual build then read /usr/src/Makefile for the recommended procedure. Vince > ___ > 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: FreeBSD 6.1-RELEASE ->FreeBSD 6.1-Stable
S. M. Ibrahim (Lavlu) wrote: > Now i am using FreeBSD 6.1-RELEASE. Now want to upgrade to FreeBSD > 6.1-Stable. What is the easy process ? > > this works well http://mikestammer.com/dokuwiki/doku.php?id=bsd:updateos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Releng_6 suddenly no longer -j safe
Ruslan Ermilov wrote: > On Tue, Sep 12, 2006 at 01:53:28PM +0200, [LoN]Kamikaze wrote: >> Last time I built a kernel on Releng_6 (only a couple of days ago) >> everything was fine with "-j 4". >> Now buildkernel stops, this is an example: >> >> ... >> >> Where it stops is random (I suppose it sometimes is accidentally >> built in the right order), but the error is always similar. >> > This puzzled me for a while, since kmod.mk has mechanisms that > try to ensure `@' is built before it's accessed. What the > implementation is missing is anti-footshooting measures. I bet > your /usr/src/sys/modules/ has some stray `@' symlinks possibly > left from compiling modules manually without creating object > directories, and forgetting to run "make clean" afterwards. Thank you, since I don't know how and where I messed up the source tree, I deleted it and recvsupped it. It's building at the moment and it seems to work fine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 6.1-RELEASE ->FreeBSD 6.1-Stable
Now i am using FreeBSD 6.1-RELEASE. Now want to upgrade to FreeBSD 6.1-Stable. What is the easy process ? -- S. M. Ibrahim (Lavlu) Home page: http://lavluda.tripod.com Blog: http://lavluda.tk Yahoo!! ID: lavluda MSN ID: lavluda Skype : lavluda ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Releng_6 suddenly no longer -j safe
On Tue, Sep 12, 2006 at 01:53:28PM +0200, [LoN]Kamikaze wrote: > Last time I built a kernel on Releng_6 (only a couple of days ago) > everything was fine with "-j 4". > Now buildkernel stops, this is an example: > > ===> sound/driver/als4000 (depend) > awk -f @/tools/makeobjops.awk @/kern/device_if.m -h > machine -> /usr/src/sys/i386/include > awk: can't open file @/tools/makeobjops.awk > source line number 1 source file @/tools/makeobjops.awk > context is > >>> <<< > *** Error code 2 > @ -> /usr/src/sys > 1 error > ... > > Where it stops is random (I suppose it sometimes is accidentally > built in the right order), but the error is always similar. > This puzzled me for a while, since kmod.mk has mechanisms that try to ensure `@' is built before it's accessed. What the implementation is missing is anti-footshooting measures. I bet your /usr/src/sys/modules/ has some stray `@' symlinks possibly left from compiling modules manually without creating object directories, and forgetting to run "make clean" afterwards. Here's how I can reproduce the behavior you're seeing: : # pwd : /usr/src/sys/modules/sound/driver/als4000 : # make -s cleandir : # make -s cleandir : # make @ : @ -> /usr/src/sys : # make obj : /usr/obj/usr/src/sys/modules/sound/driver/als4000 created for /usr/src/sys/modules/sound/driver/als4000 : # make device_if.h : awk -f @/tools/makeobjops.awk @/kern/device_if.m -h : awk: can't open file @/tools/makeobjops.awk : source line number 1 source file @/tools/makeobjops.awk : context is : >>> <<< : *** Error code 2 : : Stop in /usr/src/sys/modules/sound/driver/als4000. Fix: cd /usr/src/sys/modules && make cleandir && make cleandir Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgplaXWKCvVJL.pgp Description: PGP signature
Re: gjournal and Softupdates
Ivan Voras <[EMAIL PROTECTED]> writes: > Christian Laursen wrote: > >> Journaling also needs writes to be done in the correct order. You don't >> want to write the real update to the filesystem before you have made sure > > Ok, but journal is (or should be) protected by checksumming or some > kind of record markers, so invalid entries are not replayed. That is not the issue. Recognizing valid journal entries should be easy enough. Consider the following sequence of events: 1. Data A is written to the journal 2. The journal is flushed to disk 3. Data A is written to the filesystem Now consider what happens if the disk is reordering writes: 1. Data A is partially written to the journal 2. Data A is partially written to the filesystem 3. The system crashes You now have an invalid journal entry for data A which will not be replayed and some unkown amount of the data is already written to the filesysten possibly leaving it in an inconsistent state. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Releng_6 suddenly no longer -j safe
Last time I built a kernel on Releng_6 (only a couple of days ago) everything was fine with "-j 4". Now buildkernel stops, this is an example: ===> sound/driver/als4000 (depend) awk -f @/tools/makeobjops.awk @/kern/device_if.m -h machine -> /usr/src/sys/i386/include awk: can't open file @/tools/makeobjops.awk source line number 1 source file @/tools/makeobjops.awk context is >>> <<< *** Error code 2 @ -> /usr/src/sys 1 error ... Where it stops is random (I suppose it sometimes is accidentally built in the right order), but the error is always similar. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal and Softupdates
Christian Laursen wrote: Journaling also needs writes to be done in the correct order. You don't want to write the real update to the filesystem before you have made sure Ok, but journal is (or should be) protected by checksumming or some kind of record markers, so invalid entries are not replayed. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal and Softupdates
Ivan Voras <[EMAIL PROTECTED]> writes: > Christian Laursen wrote: > >> However, with journaling you can have filesystem corruption and not know >> about it. With fsck, bg or not, at least you will know. > > Also, I'm interested about this - what kind of silent corruption? The > same kind that can generally come from on-drive caches? Yes, as well as corruption resulting from bugs in the kernel code. The point is that you will never know because you never check your filesystems. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal and Softupdates
Ivan Voras <[EMAIL PROTECTED]> writes: > Christian Laursen wrote: >> Ivan Voras <[EMAIL PROTECTED]> writes: >> >>> - todays desktop drives can lie about writing data. SoftUpdates relies >>> on some assumptions about when the data is physically written to >>> media, and those are not always valid today >> >> I think journaling relies on the same assumptions. > > Doesn't it rely less since a journal is written sequentially, but SU > expects ordering of many writes to different parts of the file system > to be persistent and in sequence? Journaling also needs writes to be done in the correct order. You don't want to write the real update to the filesystem before you have made sure that it has been committed to the journal. If that can happen you are no better off than without the journal. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal and Softupdates
Christian Laursen wrote: However, with journaling you can have filesystem corruption and not know about it. With fsck, bg or not, at least you will know. Also, I'm interested about this - what kind of silent corruption? The same kind that can generally come from on-drive caches? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal and Softupdates
Christian Laursen wrote: Ivan Voras <[EMAIL PROTECTED]> writes: - todays desktop drives can lie about writing data. SoftUpdates relies on some assumptions about when the data is physically written to media, and those are not always valid today I think journaling relies on the same assumptions. Doesn't it rely less since a journal is written sequentially, but SU expects ordering of many writes to different parts of the file system to be persistent and in sequence? ___ 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: > >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: gjournal and Softupdates
Ivan Voras <[EMAIL PROTECTED]> writes: > - todays desktop drives can lie about writing data. SoftUpdates relies > on some assumptions about when the data is physically written to > media, and those are not always valid today I think journaling relies on the same assumptions. However, with journaling you can have filesystem corruption and not know about it. With fsck, bg or not, at least you will know. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal and Softupdates
[EMAIL PROTECTED] wrote: Only bgfsck has todo a snapshot and cleanup "unused" space that got lost cause the SU did not finish as the crash occured. Maybe someone can give me some light into that :). I always tought that *BSD don't need a journaling FS as it has already SU Soft-updates was a good idea that was implemented a bit too late (with regards to development in journaling and file system technologies), and now there are several problems with it: - [bg]fsck is still needed, and it takes way too long on large (terabyte-size) file systems. This was not a problem with small file systems when SU was designed. - bgfsck relies on snapshots, and there still are several problems with those (judging from information on mailing lists, not personal experience): they take too long to create on large file systems, there are problems with taking snapshots when the drive is almost full, and (possibly? don't remember exactly now) some NFS issues with either the snapshot or the underlying file system. - (most?) kernel developers tend to disable bgfsck completely on the file systems actively used during development because of possible panic during testing new code while bgfsck is still running, and normal fsck takes too long - todays desktop drives can lie about writing data. SoftUpdates relies on some assumptions about when the data is physically written to media, and those are not always valid today - every now and then there appear some anecdotal evidence that file systems do get destroyed even with SoftUpdates, which are probably related to the previous point, but it can't be investigated - AFAIK the addition of SoftUpdates to file system code made file system code more than usually complex, with bugs that are discovered even now. The basic idea behind SU is good and valid, but judging from side-effects of its practical implementation, right now journaling appears to be a simpler and more effective solution to the problem. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gjournal and Softupdates
I've just watched over some of the gjournal threads. My main question now is, whats the difference from gjournal and softupdates in case of reability ? Wasn't SU design to make the use of journals needless? As far i remember, SU was designed to write in the cache in such a way, that whenever the system crashed, the FS is always consistent. Only bgfsck has todo a snapshot and cleanup "unused" space that got lost cause the SU did not finish as the crash occured. Maybe someone can give me some light into that :). I always tought that *BSD don't need a journaling FS as it has already SU Greetings Teufel ___ 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?!
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. -STABLE guarantees that interfaces remain stable. If you want reliability then jump from release to release. 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]"
