Re: updating xorg-libraries 7.2 to 7.2.1
Stephen Montgomery-Smith wrote: I think that the easiest way (i.e. least disruption) is to add to each of the X11R6 scripts a test at their beginning to see if X11R6 is a symlink to /usr/local, and have the scripts do nothing if this is the case. Umm, no. The easiest way to fix this is in rc.subr, to prevent it from running scripts with the same name more than once. A fix for that problem is currently under discussion. 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]
release cycle
Hi! Reading some of the latest blog entries today, I've seen there has been some (newbie) user frustration with the latest X.org upgrade (mostly by not reading docs or not understanding the ports system at all). flz@ and des@ had a lot of trouble with some guys. Currently, if a new user is trying out FreeBSD, he will most likely set up a 6.2-RELEASE system and end up in the X.org upgrade war. As a new user is most likely not prepared to manage the system at all, he will most likely probe FreeBSD being unmaintainable (as he will most likely not know how to deal with ports at all). While reading about all that latest trouble, I think it might not be a bad idea to have a (quick) release cycle and release something like 6.2.1-RELEASE (6.3 is still TBA). I'm considering the latest X.org upgrade being a major upgrade which would justify a release cycle (@ flz: you did a great job). That would keep the trouble from new users and also from some mailing lists. I know there's a release cycle for 7-CURRENT planned next June but IMHO it can be delayed for some weeks. What does the core and releng team think? It might do good. Just my 2ct. Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: release cycle
On 5/29/07, Volker [EMAIL PROTECTED] wrote: Hi! snip While reading about all that latest trouble, I think it might not be a bad idea to have a (quick) release cycle and release something like 6.2.1-RELEASE (6.3 is still TBA). I'm considering the latest X.org upgrade being a major upgrade which would justify a release cycle (@ flz: you did a great job). That would keep the trouble from new users and also from some mailing lists. I know there's a release cycle for 7-CURRENT planned next June but IMHO it can be delayed for some weeks. What does the core and releng team think? It might do good. Just my 2ct. Volker Voker, I think with ports freeze still the case, they can't release a new version before sorting all Xorg 7.2 issues IMHO. -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: release cycle
On Tue, May 29, 2007 at 11:45:15AM +0200, Volker wrote: Hi! Reading some of the latest blog entries today, I've seen there has been some (newbie) user frustration with the latest X.org upgrade (mostly by not reading docs or not understanding the ports system at all). flz@ and des@ had a lot of trouble with some guys. Currently, if a new user is trying out FreeBSD, he will most likely set up a 6.2-RELEASE system and end up in the X.org upgrade war. As a new user is most likely not prepared to manage the system at all, he will most likely probe FreeBSD being unmaintainable (as he will most likely not know how to deal with ports at all). A new user setting up a 6.2-RELEASE system will most likely use the packages and/or the ports tree that shipped with 6.2-RELEASE. The X.org upgrade will only be a concern to such a user *if* he upgrades his ports tree. Most new users will likely not know how to do that. While reading about all that latest trouble, I think it might not be a bad idea to have a (quick) release cycle and release something like 6.2.1-RELEASE (6.3 is still TBA). I'm considering the latest X.org upgrade being a major upgrade which would justify a release cycle (@ flz: you did a great job). That would keep the trouble from new users and also from some mailing lists. I know there's a release cycle for 7-CURRENT planned next June but IMHO it can be delayed for some weeks. What does the core and releng team think? It might do good. A quick release cycle for a release from -STABLE sounds like a bad idea. There have been enough new things that have gone into the 6-STABLE branch that a full release cycle seems warranted. I also think that it would be a bad idea to create *any* new release until after the X.org upgrade has settled down - it has not done that quite yet as far as I can tell. -- Insert your favourite quote here. Erik Trulsson [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: bug in BSD tar?
- Original Message - From: Colin Percival [EMAIL PROTECTED] - Original Message - From: Colin Percival [EMAIL PROTECTED] tar -xvzf test.tar.gz tar: Ignoring unknown extended header keyword `SCHILY.dev' tar: Ignoring unknown extended header keyword `SCHILY.ino' tar: Ignoring unknown extended header keyword `SCHILY.nlink' cantiquedeno\353l1_loop.wav tar: Error exit delayed from previous errors This looks like fairly typical symptoms of gnutar being broken. What makes you think that the archive created by BSD tar was invalid? As a filename should have no bearing on what extended headers are set. Why not? In this case, bsdtar is detecting that the file name contains non-7-bit-ascii characters and is emitting a pax header for that reason; and since it can't suppress the pax header entirely, it goes ahead and emits the not vital but potentially useful headers for the device #, inode #, number of links, and high precision timestamps. I still see no evidence that bsdtar is doing anything wrong. I suppose this then comes down to the fact that gnu tar is the prevalent version out there and as such with BSD creating archives which are incompatible with that leads to problems. From our side we'll have to switch to using gnutar until this issue is resolved as we need to ensure compatibility. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.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: Unable to install FreeBSD from external USB cdrom
Alas I still get a BTX halted after replacing loader with one from that URL :( int=000d err= efl=00030002 eip=2aca eax=0900 ebx=55aa ecx= edx=0180 esi= edi= ebp=03f0 esp=03da cs=f000 ds=9e02 es=1400fs= gs= ss=9e02 cs:eip=2e 0f 01 16 1c 2c 0f 20-c0 0c 01 0f 22 c0 b8 28 00 8e d8 0f 20 c0 24 fe-0f 22 c0 eb 00 66 58 c3 ss:esp=02 9e 00 00 20 22 01 41-02 9e 24 72 0f 08 00 00 46 02 80 01 3a 07 10 00-01 00 00 00 00 14 00 00 BTX halted (ds might be 9e82, not sure, shot is blury..) That was a Supermicro P8SCT, this is a Gigabyte GA-965P-PS3.. int=000d err= efl=00030002 eip=42b7 eax=0900 ebx=55aa ecx= edx=0180 esi= edi= ebp=03f0 esp=03d8 cs=f000 ds=9e02 es=1400fs= gs= ss=9e02 cs:eip=2e 0f 01 16 d8 44 0f 20-c0 0c 01 0f 22 c0 b8 20 00 8e d8 0f 20 c0 24 fe-0f 22 c0 eb 00 66 58 c3 ss:esp=02 9e 00 00 77 3a 01 41-00 14 02 9e 06 9e 0f 08 BTX halted The second one is more accurate as I didn't copy it from a blurry photo :) -- 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 pgpGwp4ghBrTt.pgp Description: PGP signature
Re: release cycle
Hi, Erik, Erik Trulsson wrote: On Tue, May 29, 2007 at 11:45:15AM +0200, Volker wrote: [...] I know there's a release cycle for 7-CURRENT planned next June but IMHO it can be delayed for some weeks. What does the core and releng team think? It might do good. A quick release cycle for a release from -STABLE sounds like a bad idea. There have been enough new things that have gone into the 6-STABLE branch that a full release cycle seems warranted. I would say that just tagging -STABLE tree as RELEASE is a very bad idea, however, it would not be too bad if we take RELENG_6_2 as a codebase and add the following bugfixes: - zonelim fixes (very helpful for heavy loaded systems). - some socket locking fixes (settled for a long time). - driver updates, like RAID driver bugfixes. Therefore, from src/'s view, I think it would not be too bad to make a point release that merges some (well tested) bugfixes in, or at least, provide a patchset as an errata for 6.2-R. I also think that it would be a bad idea to create *any* new release until after the X.org upgrade has settled down - it has not done that quite yet as far as I can tell. I agree. What's more, freezing the ports/ tree often does not sound quite appealing :-) Just my $0.02. Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: release cycle
On 2007-May-29 12:29:29 +0200, Erik Trulsson [EMAIL PROTECTED] wrote: A quick release cycle for a release from -STABLE sounds like a bad idea. There have been enough new things that have gone into the 6-STABLE branch that a full release cycle seems warranted. Agreed. 6.3-RELEASE would nominally be due around July but the lack of any schedule on http://www.freebsd.org/releng/ suggests that it will be later than that. The plans to start the 7.0-RELEASE cycle will also impact this. I also think that it would be a bad idea to create *any* new release until after the X.org upgrade has settled down - it has not done that quite yet as far as I can tell. Given the size of the upgrade, I think it has gone very smoothly, though there _are_ a few rough edges. A few weeks to a month should shake things out. -- Peter Jeremy pgpXGVNSIVsI5.pgp Description: PGP signature
Re: network performance 6.1 stable vs 4.9
On Fri, 25 May 2007, Stephen Clark wrote: We have a network appliance that is currently based on 4.9. We are in the process of releasing a new version based on 6.1 stable. In our testing using nttcp thru the appliance we see insignifant difference in thruput between the 2 versions in a controlled environment - aproximately 94mbs on a 100mb lan. We have a person that is testing the both system inhouse surfing out over the internet on our T1 link and he complains that he is consistently seeing the 6.1 version being much slower than the 4.9 version (on the same hardware). He has been comparing the 6.1 system to 4.9 system for a couple of weeks and continues to insist the 6.1 version is much slower. Are there any sysctl tunables that may affect performance going over the internet with a slower link, dropped packets, etc that could cause this? Any ideas would be appreciated. Steve, The first thing I'd do is try a double-blind test for your testers -- don't tell them which version is running, and then compare performance complaints with/without. This would let you know if there's actually a difference. The main piece of advice I give people when working with 6.x is to consider turning on net.isr.direct, which enables direct dispatch in the network stack. With 4.x, I get lower forwarding and processing latency than 6.x unless I enable this. However, my recollection is that you don't want to turn it on on releases before 6.1, and I would really be most comfortable turning it on with 6.2 and later. In FreeBSD 7.0, net.isr.direct is the default. You might give that a try and see if it has an effect, but I'd see about getting some sort of objective testing of performance going to confirm that this isn't a subjectivity issue. Robert N M Watson Computer Laboratory University of Cambridge Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) ___ 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: release cycle
If memory serves me right, LI Xin wrote: Hi, Erik, Erik Trulsson wrote: On Tue, May 29, 2007 at 11:45:15AM +0200, Volker wrote: [...] I know there's a release cycle for 7-CURRENT planned next June but IMHO it can be delayed for some weeks. What does the core and releng team think? It might do good. A quick release cycle for a release from -STABLE sounds like a bad idea. There have been enough new things that have gone into the 6-STABLE branch that a full release cycle seems warranted. I would say that just tagging -STABLE tree as RELEASE is a very bad idea, however, it would not be too bad if we take RELENG_6_2 as a codebase and add the following bugfixes: - zonelim fixes (very helpful for heavy loaded systems). - some socket locking fixes (settled for a long time). - driver updates, like RAID driver bugfixes. Therefore, from src/'s view, I think it would not be too bad to make a point release that merges some (well tested) bugfixes in, or at least, provide a patchset as an errata for 6.2-R. We've done point releases in the past but only in cases where there were severe problems and/or regressions with released versions. Look at the announcements and release notes for 4.6.2-RELEASE and 5.2.1-RELEASE...these were the two most recent instances where we did this. There's a reason for this...it's a lot of effort. Folks should realize that making a new release (even a new point release) is not just a matter of tagging the tree and typing make release. We (re@) need to figure out exactly what bugs are to be fixed, get the changes merged and tested, build at least one release candidate, get that tested, and finally build a set of RELEASE bits and push them out. And that's just the src/ part. The original poster was mostly concerned about the X.org upgrade, which as we all know lives in the ports/ tree. If we were to do a point release we'd basically require a complete port freeze and package build run. I believe that we did do that for both 4.6.2-RELEASE and 5.2.1-RELEASE. As someone's pointed out, the ports committers are still fixing up some of the rough edges around the X.org update, so that part of the tree isn't even ready to go yet. The way I see it (and this is just my personal opinion, not an official statement from re@), doing a point release now would be a distraction from our next scheduled release, which is 7.0. Bruce. PS. This having been said I know there are some kernel fixes that were candidates for errata against 6.2-RELEASE...I'm not sure what their current state is. I'd like to see some of these get applied to RELENG_6_2. signature.asc Description: OpenPGP digital signature
Re: release cycle
Bruce A. Mah wrote: We've done point releases in the past but only in cases where there were severe problems and/or regressions with released versions. Look at the announcements and release notes for 4.6.2-RELEASE and 5.2.1-RELEASE...these were the two most recent instances where we did this. There's a reason for this...it's a lot of effort. Folks should realize that making a new release (even a new point release) is not just a matter of tagging the tree and typing make release. We (re@) need to figure out exactly what bugs are to be fixed, get the changes merged and tested, build at least one release candidate, get that tested, and finally build a set of RELEASE bits and push them out. I point releases have been obsoleted by errata notices. In the past when X.Y.Z-RELEASE has happened, it has been because of critical bugs in the X.Y-RELEASE which there wasn't any other mechanism to fix. Now that we have errata noticed and FreeBSD Update is in the base system, it's vastly easier for users to run freebsd-update fetch install than it is for them to upgrade to a new release. PS. This having been said I know there are some kernel fixes that were candidates for errata against 6.2-RELEASE...I'm not sure what their current state is. Don't ask me, I just approve the errata which you send to me. Which hasn't been anything at all lately. :-) Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: release cycle
If memory serves me right, Colin Percival wrote: Bruce A. Mah wrote: We've done point releases in the past but only in cases where there were severe problems and/or regressions with released versions. Look at the announcements and release notes for 4.6.2-RELEASE and 5.2.1-RELEASE...these were the two most recent instances where we did this. There's a reason for this...it's a lot of effort. Folks should realize that making a new release (even a new point release) is not just a matter of tagging the tree and typing make release. We (re@) need to figure out exactly what bugs are to be fixed, get the changes merged and tested, build at least one release candidate, get that tested, and finally build a set of RELEASE bits and push them out. I point releases have been obsoleted by errata notices. In the past when X.Y.Z-RELEASE has happened, it has been because of critical bugs in the X.Y-RELEASE which there wasn't any other mechanism to fix. Now that we have errata noticed and FreeBSD Update is in the base system, it's vastly easier for users to run freebsd-update fetch install than it is for them to upgrade to a new release. That's a good point. I'd be happy if we never had to do another point release again, since we have to do probably half the work of a normal release cycle but it's completely unexpected and unscheduled. BTW I finally added some mention of freebsd-update(8) to the section of the release notes that talks about upgrading FreeBSD. Only on HEAD for now, I'll put this on RELENG_6 when I get a Round Tuit. PS. This having been said I know there are some kernel fixes that were candidates for errata against 6.2-RELEASE...I'm not sure what their current state is. Don't ask me, I just approve the errata which you send to me. Which hasn't been anything at all lately. :-) Ah no, we haven't sent you anything as of late, and that's the problem. :-) Bruce. signature.asc Description: OpenPGP digital signature
Re: release cycle
On Tue, May 29, 2007 at 01:18:51PM +0300, Abdullah Ibn Hamad Al-Marri wrote: Voker, I think with ports freeze still the case, they can't release a new version before sorting all Xorg 7.2 issues IMHO. The freeze has been lifted. OTOH things are still settling down. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: release cycle
On Tue, May 29, 2007 at 09:17:57PM +1000, Peter Jeremy wrote: Agreed. 6.3-RELEASE would nominally be due around July but the lack of any schedule on http://www.freebsd.org/releng/ suggests that it will be later than that. The plans to start the 7.0-RELEASE cycle will also impact this. At BSDCan, Ken Smith mentioned that 7.0 is due to be branched in July and released in Aug/Sep, with 6.3 quickly following (perhaps even overlapping so as to reuse the same ports freeze). The ports tree is not even close to stable enough to release right now. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: release cycle
On 05/29/07 17:26, Bruce A. Mah wrote: And that's just the src/ part. The original poster was mostly concerned about the X.org upgrade, which as we all know lives in the ports/ tree. If we were to do a point release we'd basically require a complete port freeze and package build run. I believe that we did do that for both 4.6.2-RELEASE and 5.2.1-RELEASE. As someone's pointed out, the ports committers are still fixing up some of the rough edges around the X.org update, so that part of the tree isn't even ready to go yet. The way I see it (and this is just my personal opinion, not an official statement from re@), doing a point release now would be a distraction from our next scheduled release, which is 7.0. Bruce, is there any ETA for 7-STABLE? Thx Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Packet Loss w/bge BCM5703 on Dell PE2650
Hello all, I've isolated a problem which appears to be a bug causing packet loss with FreeBSD 6.0 and later on the Dell PowerEdge 2650 servers and the integrated Broadcom BCM5703 NICs. I thought it was the server at first but I did a clean install of FreeBSD 6.2-RELEASE on another 2650 and see the same issue. This issue did not exist in FreeBSD 5.3 or 4.11. Going from FreeBSD 5.3 to 6.0 is when this problem was introduced. I also installed FreeBSD 6.2-RELEASE on a Dell PowerEdge 2950 and don't see any loss at all. This also uses the bge driver but it has a newer chipset, specifically the BCM5708 vs the problem I'm having with the BCM5703 on the 2650. For my tests I am running extended pings from a Cisco router on the same subnet. I have tuned net.inet.icmp.icmplim to -1 to disable ICMP rate limiting. The packet loss doesn't appear to follow any particular pattern and is generally low, but still there. Below is my dmesg output of one of the 2650's in question followed by an example of the loss I am seeing: Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-STABLE #0: Sat Jan 27 00:37:31 EST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ENGBOX Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2781.54-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x4400CNTX-ID,b14 real memory = 4026400768 (3839 MB) avail memory = 3942182912 (3759 MB) ACPI APIC Table: DELL PE2650 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic2: Changing APIC ID to 10 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 Version 1.1 irqs 0-15 on motherboard ioapic1 Version 1.1 irqs 16-31 on motherboard ioapic2 Version 1.1 irqs 32-47 on motherboard acpi0: DELL PE2650 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 32-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: unknown at device 4.0 (no driver attached) pci0: unknown at device 4.1 (no driver attached) pci0: unknown at device 4.2 (no driver attached) pci0: display, VGA at device 14.0 (no driver attached) atapci0: ServerWorks CSB5 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x17 7,0x376,0x8b0-0x8bf at device 15.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 ohci0: OHCI (generic) USB controller mem 0xfe10-0xfe100fff irq 5 at device 15.2 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered isab0: PCI-ISA bridge at device 15.3 on pci0 isa0: ISA bus on isab0 pcib1: ACPI Host-PCI bridge on acpi0 pci4: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 8.0 on pci4 pci5: ACPI PCI bus on pcib2 aac0: Dell PERC 3/Di mem 0xf000-0xf7ff irq 30 at device 8.1 on pci4 aac0: [FAST] aac0: Adaptec Raid Controller 2.0.0-1 pcib3: ACPI Host-PCI bridge on acpi0 pci3: ACPI PCI bus on pcib3 bge0: Broadcom BCM5703 A2, ASIC rev. 0x1002 mem 0xfcf1-0xfcf1 irq 28 a t device 6.0 on pci3 miibus0: MII bus on bge0 brgphy0: BCM5703 10/100/1000baseTX PHY on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto bge0: Ethernet address: 00:0d:56:ba:73:bf bge1: Broadcom BCM5703 A2, ASIC rev. 0x1002 mem 0xfcf0-0xfcf0 irq 29 a t device 8.0 on pci3 miibus1: MII bus on bge1 brgphy1: BCM5703 10/100/1000baseTX PHY on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto bge1: Ethernet address: 00:0d:56:ba:73:c1 pcib4: ACPI Host-PCI bridge on acpi0 pci2: ACPI PCI bus on pcib4 pcib5: ACPI Host-PCI bridge on acpi0 pci1: ACPI PCI bus on pcib5 fdc0: floppy drive controller port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: 1440-KB 3.5 drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
6.2: maillog grows, newsyslog's misbehaving ?
Hi, discovered that the maillog file on my freebsd Desktop grows and grows (now at 50MB). According to the newsyslog.conf file it should be trimmed every night at midnight. /var/log/maillog640 7 *@T00 JC Is it a prerequisite, that the system then runs 24x7 so that the newsyslog default settings work ? I would have expected, that the trimming then happens on the next reboot, if the system doesn't run over midnight. Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? - http://www.apsfilter.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
vnode_pager_putpages errors on 6.2
Howdy! I had this issue on 4.x, which is basically, I have machines that do cgi stuff for customers, and there is a local md device that is used as a tmp. When it fills the machine logs errors vnode_pager_putpages I/O error 28.. and the machine is unresponsive and needs to be power cycled. There is a previous thread on this issue http://atm.tut.fi/list-archive/freebsd-stable/msg19031.html and a subsequent patch for 4.x http://atm.tut.fi/list-archive/freebsd-stable/msg19288.html that I appled to 4.x and it solved the problem. Now that I have upgraded to 6.2, the problem has recurred, but the previous patch is no longer valid. Is there something wrong with the patch/solution given, and is there a solution for 6.2? thanx - steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vnode_pager_putpages errors on 6.2
On 5/29/07, steve [EMAIL PROTECTED] wrote: Howdy! I had this issue on 4.x, which is basically, I have machines that do cgi stuff for customers, and there is a local md device that is used as a tmp. When it fills the machine logs errors vnode_pager_putpages I/O error 28.. and the machine is unresponsive and needs to be power cycled. There is a previous thread on this issue http://atm.tut.fi/list-archive/freebsd-stable/msg19031.html and a subsequent patch for 4.x http://atm.tut.fi/list-archive/freebsd-stable/msg19288.html that I appled to 4.x and it solved the problem. Now that I have upgraded to 6.2, the problem has recurred, but the previous patch is no longer valid. Is there something wrong with the patch/solution given, and is there a solution for 6.2? thanx - steve All the patch does is rate limit error messages to once per second and return VM_PAGER_BAD when there is an error. Constructing a similar patch for 6.2 should be trivial. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: release cycle
Colin Percival wrote: Bruce A. Mah wrote: We've done point releases in the past but only in cases where there were severe problems and/or regressions with released versions. Look at the announcements and release notes for 4.6.2-RELEASE and 5.2.1-RELEASE...these were the two most recent instances where we did this. There's a reason for this...it's a lot of effort. Folks should realize that making a new release (even a new point release) is not just a matter of tagging the tree and typing make release. We (re@) need to figure out exactly what bugs are to be fixed, get the changes merged and tested, build at least one release candidate, get that tested, and finally build a set of RELEASE bits and push them out. I point releases have been obsoleted by errata notices. In the past when X.Y.Z-RELEASE has happened, it has been because of critical bugs in the X.Y-RELEASE which there wasn't any other mechanism to fix. Now that we have errata noticed and FreeBSD Update is in the base system, it's vastly easier for users to run freebsd-update fetch install than it is for them to upgrade to a new release. Not really. 5.2.1 existed because people were having problems getting 5.2 installed on their ATA disks. If you have big problems with storage or network, freebsd-update isn't going to be of much use to you. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: release cycle
Scott Long wrote: Colin Percival wrote: I point releases have been obsoleted by errata notices. In the past when X.Y.Z-RELEASE has happened, it has been because of critical bugs in the X.Y-RELEASE which there wasn't any other mechanism to fix. Now that we have errata noticed and FreeBSD Update is in the base system, it's vastly easier for users to run freebsd-update fetch install than it is for them to upgrade to a new release. Not really. 5.2.1 existed because people were having problems getting 5.2 installed on their ATA disks. If you have big problems with storage or network, freebsd-update isn't going to be of much use to you. Good point, I was forgetting exactly what the problems were that time. Colin Percival ___ 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: maillog grows, newsyslog's misbehaving ?
At 1:08 PM +0200 5/28/07, Andreas Klemm wrote: Hi, discovered that the maillog file on my freebsd Desktop grows and grows (now at 50MB). According to the newsyslog.conf file it should be trimmed every night at midnight. /var/log/maillog640 7 *@T00 JC Is it a prerequisite, that the system then runs 24x7 so that the newsyslog default settings work ? As mentioned in the man page for newsyslog.conf : If a time is specified, the log file will only be trimmed if newsyslog(8) is run within one hour of the specified time. You could force a rotate by running newsyslog yourself: /usr/sbin/newsyslog -F /var/log/maillog but that would be a one-time fix. There is a startup file for newsyslog in /etc/rc.d which runs the program one-time at startup. You could set an alternate value for the variable 'newsyslog_flags' in your /etc/rc.conf file, and use that to do the checks you want at startup. This would probably mean creating a duplicate newsyslog.conf file. So, to answer your question: Yes, the default settings for newsyslog.conf do assume that your system is running 24x7. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [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: bug in BSD tar?
Steven Hartland schrieb: From our side we'll have to switch to using gnutar until this issue is resolved as we need to ensure compatibility. gnutar is available as a package. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug in BSD tar?
Steven Hartland wrote this message on Tue, May 29, 2007 at 11:46 +0100: - Original Message - From: Colin Percival [EMAIL PROTECTED] - Original Message - From: Colin Percival [EMAIL PROTECTED] tar -xvzf test.tar.gz tar: Ignoring unknown extended header keyword `SCHILY.dev' tar: Ignoring unknown extended header keyword `SCHILY.ino' tar: Ignoring unknown extended header keyword `SCHILY.nlink' cantiquedeno\353l1_loop.wav tar: Error exit delayed from previous errors This looks like fairly typical symptoms of gnutar being broken. What makes you think that the archive created by BSD tar was invalid? As a filename should have no bearing on what extended headers are set. Why not? In this case, bsdtar is detecting that the file name contains non-7-bit-ascii characters and is emitting a pax header for that reason; and since it can't suppress the pax header entirely, it goes ahead and emits the not vital but potentially useful headers for the device #, inode #, number of links, and high precision timestamps. I still see no evidence that bsdtar is doing anything wrong. I suppose this then comes down to the fact that gnu tar is the prevalent version out there and as such with BSD creating archives which are incompatible with that leads to problems. From our side we'll have to switch to using gnutar until this issue is resolved as we need to ensure compatibility. Is the file incorrect when extracted? or is this a mater of gtar throwing an error because of the tar format, and an option to bsdtar could be provided to change the output tar format? -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug in BSD tar?
- Original Message - From: John-Mark Gurney [EMAIL PROTECTED] Is the file incorrect when extracted? or is this a mater of gtar throwing an error because of the tar format, and an option to bsdtar could be provided to change the output tar format? The file is correct when extracted but gtar is, as you say, throwing an error because of the tar format. The exit error is the issue as in a scripted environment, as we have, the error causes the failure of the whole operation. == bsd tar archived == tar -xvzf test.tar.gz tar: Ignoring unknown extended header keyword `SCHILY.dev' tar: Ignoring unknown extended header keyword `SCHILY.ino' tar: Ignoring unknown extended header keyword `SCHILY.nlink' cantiquedeno\353l1_loop.wav tar: Error exit delayed from previous errors [EMAIL PROTECTED]/tmp: cksum cantiquedeno\353l1_loop.wav 1601232891 1766066 cantiquedenoël1_loop.wav == gnu tar archived == [EMAIL PROTECTED]/tmp: tar -xvzf test1.tar.gz cantiquedeno\353l1_loop.wav [EMAIL PROTECTED]/tmp: cksum cantiquedeno\353l1_loop.wav 1601232891 1766066 cantiquedenoël1_loop.wav Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.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: vnode_pager_putpages errors on 6.2
Hi, Steve,
steve wrote:
[...]
http://atm.tut.fi/list-archive/freebsd-stable/msg19288.html
that I appled to 4.x and it solved the problem.
Now that I have upgraded to 6.2, the problem has
recurred, but the previous patch is no longer valid. Is
there something wrong with the patch/solution given, and
is there a solution for 6.2?
In RELENG_6_2, the rate limit part of the patch was implemented in a
different way. Could you please try this patch to see if it solves your
problem?
Cheers,
--
Xin LI [EMAIL PROTECTED] http://www.delphij.net/
FreeBSD - The Power to Serve!
Index: vnode_pager.c
===
RCS file: /home/ncvs/src/sys/vm/vnode_pager.c,v
retrieving revision 1.221.2.7
diff -u -p -u -r1.221.2.7 vnode_pager.c
--- vnode_pager.c 14 Oct 2006 06:04:32 - 1.221.2.7
+++ vnode_pager.c 30 May 2007 01:43:39 -
@@ -1083,6 +1083,7 @@ vnode_pager_generic_putpages(vp, m, byte
struct iovec aiov;
int error;
int ioflags;
+ int status;
int ppscheck = 0;
static struct timeval lastfail;
static int curfail;
@@ -1177,8 +1178,9 @@ vnode_pager_generic_putpages(vp, m, byte
printf(vnode_pager_putpages: residual I/O %d at %lu\n,
auio.uio_resid, (u_long)m[0]-pindex);
}
+ status = error ? VM_PAGER_BAD : VM_PAGER_OK;
for (i = 0; i ncount; i++) {
- rtvals[i] = VM_PAGER_OK;
+ rtvals[i] = status;
}
return rtvals[0];
}
signature.asc
Description: OpenPGP digital signature
Re: bug in BSD tar?
Steven Hartland wrote this message on Wed, May 30, 2007 at 02:08 +0100: - Original Message - From: John-Mark Gurney [EMAIL PROTECTED] Is the file incorrect when extracted? or is this a mater of gtar throwing an error because of the tar format, and an option to bsdtar could be provided to change the output tar format? The file is correct when extracted but gtar is, as you say, throwing an error because of the tar format. The exit error is the issue as in a scripted environment, as we have, the error causes the failure of the whole operation. Have you tried the --format argument to bsdtar? Maybe ustar or pax will make gtar happier... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug in BSD tar?
Steven Hartland wrote: - Original Message - From: John-Mark Gurney [EMAIL PROTECTED] Is the file incorrect when extracted? or is this a mater of gtar throwing an error because of the tar format, and an option to bsdtar could be provided to change the output tar format? The file is correct when extracted but gtar is, as you say, throwing an error because of the tar format. The exit error is the issue as in a scripted environment, as we have, the error causes the failure of the whole operation. GNU tar is broken. POSIX specifically allows for vendor extensions (such as the SCHILY.* extensions which were introduced by star), and the correct way to handle them is by printing a warning message, ignoring the extension, and not treating it as an error. You can work around gtar's breakage by explicitly telling it to ignore these options via --pax-option=delete=SCHILY.* . Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
