From clint.olsen at gmail.com Sun Jun 1 03:57:57 2008 From: clint.olsen at gmail.com (Clint Olsen) Date: Sun Jun 1 03:58:01 2008 Subject: 6.X potentially has messed up sk0 Message-ID: <20080601034513.GI29852@0lsen.net> Hi: Since upgrading from 5.4-STABLE to 6.2-RELEASE and now 6.3-STABLE, I've noticed that occasionally sk0 goes weird. I don't quite get it. I was able to connect to it via my local network, but routes to my WAN were completely hosed. So, the machine becomes unable to ping or contact anything that crosses 192.168.1.X. Taking down the interface and bringing it back up via ifconfig fixed it. However, I've seen other cases where the machine can eventually get wedged to the point that nothing can bring it back to life. So, the question is, how can I provide the FreeBSD team something tangible in the way of logs or debug information to prove this is a bug? Thanks, -Clint From joe at tao.org.uk Sun Jun 1 10:39:49 2008 From: joe at tao.org.uk (Dr Josef Karthauser) Date: Sun Jun 1 10:39:53 2008 Subject: Status of ZFS in -stable? In-Reply-To: <5f67a8c40805201747p79e34870qaa842ab034e133d1@mail.gmail.com> References: <48291889.8030406@pldrouin.net> <5f67a8c40805181740v6f655fdjdfaec3312681b5c9@mail.gmail.com> <20080520190804.GA17271@shire.nagual.nl> <200805201249.39201.fjwcash@gmail.com> <5f67a8c40805201747p79e34870qaa842ab034e133d1@mail.gmail.com> Message-ID: <071101c8c3d3$cfa34a40$6ee9dec0$@org.uk> > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Zaphod Beeblebrox > Sent: 21 May 2008 01:48 > To: Freddie Cash > Cc: freebsd-stable@freebsd.org > Subject: Re: Status of ZFS in -stable? > > Correct. If I don't use "verify" ... the backup proceeds normally, but > it's > corrupt. If I turn on verify, the backup stops when it detects the > corruption (somewhere about halfway through). This is with XP using a > Samba-shared ZFS filesystem. When XP uses a samba shared UFS > filesystem, > all is good. Additionally, I tried telling samba _not_ to use mmap() > (there's an option), but this didn't fix things. My guess is that it is still using mmap() somehow; there are definitely corruption problems with zfs and mmap(). Joe From joao at matik.com.br Sun Jun 1 12:37:50 2008 From: joao at matik.com.br (JoaoBR) Date: Sun Jun 1 12:37:53 2008 Subject: zfs start failure when /usr is on zfs (and rcorder change suggestion) Message-ID: <200806010941.09448.joao@matik.com.br> Hi when you need /usr/compat on your sistem (linuxfs) and you have /usr on zfs boot fails because mountcritlocal does not find /usr/compat so I changed the rcorder as you can see in the attached files also I changed /etc/rc.d/zfs and added /etc/rc.d/zfs_swap in order to make the actual zfs_swap behaviour and configuration a little bit more [user]understandable and easier and working this needs two more rc vars as zfs_swap_enable="YES|NO" zfs_swap_vols="spaced vol_list" using this rc files zfs, swap on zfs and other fs mount fine the changed /etc/rc.d/zfs prevents losing zpools (and later import) as long as zfs started by this script -- Jo?o From joao at matik.com.br Sun Jun 1 12:52:41 2008 From: joao at matik.com.br (JoaoBR) Date: Sun Jun 1 12:52:53 2008 Subject: zfs start failure when /usr is on zfs (and rcorder change suggestion) In-Reply-To: <200806010941.09448.joao@matik.com.br> References: <200806010941.09448.joao@matik.com.br> Message-ID: <200806010956.02162.joao@matik.com.br> On Sunday 01 June 2008 09:41:09 JoaoBR wrote: > Hi > > when you need /usr/compat on your sistem (linuxfs) and you have /usr on zfs > boot fails because mountcritlocal does not find /usr/compat > > so I changed the rcorder as you can see in the attached files > > also I changed /etc/rc.d/zfs and added /etc/rc.d/zfs_swap in order to make > the actual zfs_swap behaviour and configuration a little bit more > [user]understandable and easier and working > > this needs two more rc vars as > > zfs_swap_enable="YES|NO" > zfs_swap_vols="spaced vol_list" > > using this rc files zfs, swap on zfs and other fs mount fine > > the changed /etc/rc.d/zfs prevents losing zpools (and later import) as long > as zfs started by this script seems the attached files were cut, you can get them here: http://suporte.matik.com.br/jm/zfs.rcfiles.tar.gz -- Jo?o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From cperciva at freebsd.org Tue Jun 3 03:31:31 2008 From: cperciva at freebsd.org (FreeBSD Security Officer) Date: Tue Jun 3 03:31:36 2008 Subject: FreeBSD supported branches update Message-ID: <20080603033131.GB90341@freefall.freebsd.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Everyone, The branches supported by the FreeBSD Security Officer have been updated to reflect recent EoL (end-of-life) events. The new list is below and at . FreeBSD 5.5, FreeBSD 6.1, and FreeBSD 6.2 have `expired' and are no longer supported effective June 1, 2008. Users of these releases are advised to upgrade promptly to FreeBSD 6.3 or FreeBSD 7.0, either by downloading an updated source tree and building updates manually, or (for i386 and amd64 systems) using the FreeBSD Update utility as described in the FreeBSD 6.3 and FreeBSD 7.0 release announcements. This marks the end of support by the FreeBSD Security Team for the FreeBSD 5-STABLE branch, and at this time support for running software from the ports tree on FreeBSD 5.x is also ceasing: Packages for binary installations will no longer be built for FreeBSD 5.5, building ports from source on FreeBSD 5.x will no longer be supported, and the ports INDEX will no longer be built and made available via portsnap or the 'make fetchindex' target. Patches for individual ports specific for their functioning on FreeBSD 5.5 may still be accepted at the discretion of the port maintainer. [Excerpt from http://security.freebsd.org/ follows] FreeBSD Security Advisories The FreeBSD Security Officer provides security advisories for several branches of FreeBSD development. These are the -STABLE Branches and the Security Branches. (Advisories are not issued for the -CURRENT Branch.) * There is usually only a single -STABLE branch, although during the transition from one major development line to another (such as from FreeBSD 5.x to 6.x), there is a time span in which there are two -STABLE branches. The -STABLE branch tags have names like RELENG_6. The corresponding builds have names like FreeBSD 6.1-STABLE. * Each FreeBSD Release has an associated Security Branch. The Security Branch tags have names like RELENG_6_1. The corresponding builds have names like FreeBSD 6.1-RELEASE-p1. Isses affecting the FreeBSD Ports Collection are covered in the FreeBSD VuXML document. Each branch is supported by the Security Officer for a limited time only, and is designated as one of `Early adopter', `Normal', or `Extended'. The designation is used as a guideline for determining the lifetime of the branch as follows. Early adopter Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release. Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. Extended Selected releases will be supported by the Security Officer for a minimum of 24 months after the release. The current designation and estimated lifetimes of the currently supported branches are given below. The Estimated EoL (end-of-life) column gives the earliest date on which that branch is likely to be dropped. Please note that these dates may be extended into the future, but only extenuating circumstances would lead to a branch's support being dropped earlier than the date listed. +--------------------------------------------------------------------+ | Branch | Release | Type | Release date | Estimated EoL | |-----------+-----------+--------+-----------------+-----------------| |RELENG_6 |n/a |n/a |n/a |January 31, 2010 | |-----------+-----------+--------+-----------------+-----------------| |RELENG_6_3 |6.3-RELEASE|Extended|January 18, 2008 |January 31, 2010 | |-----------+-----------+--------+-----------------+-----------------| |RELENG_7 |n/a |n/a |n/a |last release + 2y| |-----------+-----------+--------+-----------------+-----------------| |RELENG_7_0 |7.0-RELEASE|Normal |February 27, 2008|February 28, 2009| +--------------------------------------------------------------------+ [End excerpt] Colin Percival FreeBSD Security Officer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkhEe5MACgkQFdaIBMps37IXoQCbB3RkY/s2CA+o/OFkuC/1YvUV rY8An1JawL1x8DdUOlVUL0b2+9N4XZ2v =X+Zm -----END PGP SIGNATURE----- From peterjeremy at optushome.com.au Tue Jun 3 07:08:44 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue Jun 3 07:09:01 2008 Subject: Interrupt storm with shared interrupt on digi(4) Message-ID: <20080603070840.GH1028@server.vk2pj.dyndns.org> I have an on-going problem with DigiBoard Xem boards causing interrupt storms (since 4.x days). The FreeBSD driver polls the board and doesn't have a functional interrupt handler (and Linux behaves in the same way). It seems that under some conditions, the board will assert its interrupt line and, since there's no interrupt handler to clear whatever triggered the interrupt, the IRQ is never unasserted. In the past, I have managed to avoid the problem by putting the Digi card on a dedicated interrupt. For reasons I don't understand, this appears to mask the problem. Unfortunately, I now have a system where, courtesy of Compaq's incompetence, I have no way to avoid having two Digi boards sharing an interrupt. In 7.x, as soon as I load digi.ko, I get "interrupt storm" messages. In 6.x, I could see the interrupt storm but it didn't flood my console with messages. Does anyone have a patch that will generate an appropriate EOI to a DigiBoard? Alternatively, can anyone suggest how I can disable or mask a specified PCI interrupt? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080603/cfd07fd9/attachment.pgp From gergely.czuczy at harmless.hu Tue Jun 3 08:47:15 2008 From: gergely.czuczy at harmless.hu (CZUCZY Gergely) Date: Tue Jun 3 08:47:25 2008 Subject: ALTQ and cpufreq(4) Message-ID: <20080603103236.6f145eef@twoflower.in.publishing.hu> Hello, I've met some quite strange reboots recently on my home gateway. I'm trying to reduce its power consumption, so I've loaded the cpufreq(4) driver, and enabled powerd. After this the box started to reboot randomly all over the place. I started to think what can cause the trouble, removing the cpufreq(4) support would be too trivial, so I've removed the ALTQ references from my pf.conf, and surprisingly these accidental reboots gone away. My guess is ALTQ has some problems with cpufreq(4). Before submitting a PR on this, could someone also check this configuration, to be sure on this? System info: FreeBSD beeblebrox.harmless.lan 6.3-STABLE FreeBSD 6.3-STABLE #0: Sat May 31 18:35:15 CEST 2008 toor@beeblebrox.harmless.lan:/usr/obj/usr/src/sys/BEEBLEBROX i386 I'm using hfsc in my pf configuration. Kernel config: machine i386 cpu I686_CPU ident BEEBLEBROX maxusers 32 # 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 SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking #options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories #options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server #options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic # I/O APIC # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver #device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor #device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse options GEOM_MIRROR options GEOM_LABEL options GEOM_ELI device crypto device cryptodev device hifn device tun device tap device pf device pflog options COMPAT_LINUX 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_PRIQ # Priority Queueing options ALTQ_NOPCC # Required for SMP build device ichwd device sk device netgraph options NETGRAPH_SOCKET options NETGRAPH_ETHER options NETGRAPH_PPPOE options NETGRAPH_DEFLATE device cpufreq altq in pf.conf (these are the lines i've commented out - removed ALTQ -, and the reboots had gone away) : #altq on $if_ppp hfsc bandwidth 512Kb queue { std, ssh, http, ack, vpn, stdack} #queue std bandwidth 16% priority 0 qlimit 1024 hfsc (default realtime 32Kb upperlimit 412Kb) #queue http bandwidth 16% priority 2 qlimit 512 hfsc (realtime 16Kb upperlimit 490Kb ) #queue ssh bandwidth 16% priority 5 qlimit 512 hfsc (realtime 32Kb upperlimit 490Kb ) #queue stdack bandwidth 16% priority 5 qlimit 1024 hfsc ( realtime 8Kb upperlimit 384Kb) #queue vpn bandwidth 16% priority 6 qlimit 2048 hfsc ( realtime 16Kb upperlimit 512Kb) #queue ack bandwidth 16% priority 7 qlimit 1024 hfsc ( realtime 8Kb upperlimit 512Kb) #pass out quick on $if_ppp proto udp from any to any port {14567,14568} keep state queue(ssh, ack) #pass out quick on $if_ppp proto tcp from any to port 22 flags S/SA keep state queue (ssh, ack) #pass out quick on $if_ppp proto tcp from any to port {80,443} flags S/SA keep state queue (http, ack) #pass out quick on $if_ppp proto tcp from any to 195.56.55.204 port 60080 flags S/SA keep state queue (http, ack) #pass out quick on $if_ppp proto tcp from port 60150 to any keep state queue(std, stdack) -- ?dv?lettel, Czuczy Gergely Harmless Digital Bt mailto: gergely.czuczy@harmless.hu Tel: +36-30-9702963 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080603/67ca1260/signature.pgp From tinderbox at freebsd.org Tue Jun 3 08:50:24 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 3 08:50:40 2008 Subject: [releng_6 tinderbox] failure on amd64/amd64 Message-ID: <20080603085033.5A2A8241A2@freebsd-legacy.sentex.ca> TB --- 2008-06-03 08:25:39 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2008-06-03 08:25:39 - starting RELENG_6 tinderbox run for amd64/amd64 TB --- 2008-06-03 08:25:39 - cleaning the object tree TB --- 2008-06-03 08:26:23 - cvsupping the source tree TB --- 2008-06-03 08:26:23 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile TB --- 2008-06-03 08:26:44 - building world (CFLAGS=-O2 -pipe) TB --- 2008-06-03 08:26:44 - cd /src TB --- 2008-06-03 08:26:44 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I/src/lib/bind/bind /../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/gettimeofday.c cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I/src/lib/bind/bind /../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/mktemp.c cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I/src/lib/bind/bind /../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/putenv.c cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I/src/lib/bind/bind /../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/readv.c cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I/src/lib/bind/bind /../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/setenv.c In file included from /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/setenv.c:43: /obj/amd64/src/tmp/usr/include/string.h:68: error: conflicting types for 'bcopy' /obj/amd64/src/tmp/usr/include/string.h:68: error: conflicting types for 'bcopy' *** Error code 1 Stop in /src/lib/bind/bind. *** Error code 1 Stop in /src/lib/bind. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-06-03 08:50:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-06-03 08:50:33 - ERROR: failed to build world TB --- 2008-06-03 08:50:33 - tinderbox aborted TB --- 1119.02 user 149.53 system 1493.36 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full From tinderbox at freebsd.org Tue Jun 3 09:06:17 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 3 09:06:30 2008 Subject: [releng_6 tinderbox] failure on i386/i386 Message-ID: <20080603090624.865C4241A2@freebsd-legacy.sentex.ca> TB --- 2008-06-03 08:42:30 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2008-06-03 08:42:30 - starting RELENG_6 tinderbox run for i386/i386 TB --- 2008-06-03 08:42:30 - cleaning the object tree TB --- 2008-06-03 08:43:09 - cvsupping the source tree TB --- 2008-06-03 08:43:09 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/i386/i386/supfile TB --- 2008-06-03 08:43:22 - building world (CFLAGS=-O2 -pipe) TB --- 2008-06-03 08:43:22 - cd /src TB --- 2008-06-03 08:43:22 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I/src/lib/bind/bind /../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/gettimeofday.c cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I/src/lib/bind/bind /../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/mktemp.c cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I/src/lib/bind/bind /../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/putenv.c cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I/src/lib/bind/bind /../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/readv.c cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I/src/lib/bind/bind /../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/setenv.c In file included from /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/setenv.c:43: /obj/src/tmp/usr/include/string.h:68: error: conflicting types for 'bcopy' /obj/src/tmp/usr/include/string.h:68: error: conflicting types for 'bcopy' *** Error code 1 Stop in /src/lib/bind/bind. *** Error code 1 Stop in /src/lib/bind. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-06-03 09:06:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-06-03 09:06:24 - ERROR: failed to build world TB --- 2008-06-03 09:06:24 - tinderbox aborted TB --- 1074.62 user 142.95 system 1434.19 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-i386-i386.full From tinderbox at freebsd.org Tue Jun 3 09:14:11 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 3 09:14:16 2008 Subject: [releng_6 tinderbox] failure on i386/pc98 Message-ID: <20080603091424.4086D241A2@freebsd-legacy.sentex.ca> TB --- 2008-06-03 08:50:33 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2008-06-03 08:50:33 - starting RELENG_6 tinderbox run for i386/pc98 TB --- 2008-06-03 08:50:33 - cleaning the object tree TB --- 2008-06-03 08:51:22 - cvsupping the source tree TB --- 2008-06-03 08:51:22 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/i386/pc98/supfile TB --- 2008-06-03 08:51:35 - building world (CFLAGS=-O2 -pipe) TB --- 2008-06-03 08:51:35 - cd /src TB --- 2008-06-03 08:51:35 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I/src/lib/bind/bind /../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/gettimeofday.c cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I/src/lib/bind/bind /../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/mktemp.c cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I/src/lib/bind/bind /../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/putenv.c cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I/src/lib/bind/bind /../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/readv.c cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I/src/lib/bind/bind /../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/setenv.c In file included from /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/setenv.c:43: /obj/pc98/src/tmp/usr/include/string.h:68: error: conflicting types for 'bcopy' /obj/pc98/src/tmp/usr/include/string.h:68: error: conflicting types for 'bcopy' *** Error code 1 Stop in /src/lib/bind/bind. *** Error code 1 Stop in /src/lib/bind. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-06-03 09:14:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-06-03 09:14:24 - ERROR: failed to build world TB --- 2008-06-03 09:14:24 - tinderbox aborted TB --- 1077.23 user 148.97 system 1430.64 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-i386-pc98.full From tinderbox at freebsd.org Tue Jun 3 09:28:25 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jun 3 09:28:33 2008 Subject: [releng_6 tinderbox] failure on sparc64/sparc64 Message-ID: <20080603092837.B425F241A2@freebsd-legacy.sentex.ca> TB --- 2008-06-03 09:06:24 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2008-06-03 09:06:24 - starting RELENG_6 tinderbox run for sparc64/sparc64 TB --- 2008-06-03 09:06:24 - cleaning the object tree TB --- 2008-06-03 09:06:55 - cvsupping the source tree TB --- 2008-06-03 09:06:55 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/sparc64/sparc64/supfile TB --- 2008-06-03 09:07:10 - building world (CFLAGS=-O2 -pipe) TB --- 2008-06-03 09:07:10 - cd /src TB --- 2008-06-03 09:07:10 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DWORDS_BIGENDIAN -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I /src/lib/bind/bind/../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/gettimeofday.c cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DWORDS_BIGENDIAN -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I /src/lib/bind/bind/../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/mktemp.c cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DWORDS_BIGENDIAN -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I /src/lib/bind/bind/../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/putenv.c cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DWORDS_BIGENDIAN -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I /src/lib/bind/bind/../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/readv.c cc -O2 -pipe -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/port/freebsd/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind/include -I/src/lib/bind/bind -DVERSION='"9.3.5"' -DHAVE_CONFIG_H -DLIBINTERFACE=4 -DLIBREVISION=9 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DWORDS_BIGENDIAN -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind/.. -I/src/lib/bind/bind/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind/../dns -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/isc/nothreads/include -I /src/lib/bind/bind/../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind/../isc -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/unix/include -I/src/lib/bind/bind/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind/../lwres -c /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/setenv.c In file included from /src/lib/bind/bind/../../../contrib/bind9/lib/bind/bsd/setenv.c:43: /obj/sparc64/src/tmp/usr/include/string.h:68: error: conflicting types for 'bcopy' /obj/sparc64/src/tmp/usr/include/string.h:68: error: conflicting types for 'bcopy' *** Error code 1 Stop in /src/lib/bind/bind. *** Error code 1 Stop in /src/lib/bind. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-06-03 09:28:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-06-03 09:28:37 - ERROR: failed to build world TB --- 2008-06-03 09:28:37 - tinderbox aborted TB --- 1052.54 user 145.24 system 1333.09 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-sparc64-sparc64.full From mvoorhis at cs.wpi.edu Tue Jun 3 12:09:17 2008 From: mvoorhis at cs.wpi.edu (Michael C Voorhis) Date: Tue Jun 3 12:09:24 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? Message-ID: <18501.12329.638264.761303@cs.wpi.edu> Has anyone tried 7.0-Stable on a Thinkpad t61p. I've been using one for a few weeks and have had many problems, after several event-free years on a t42. My issues are mainly ACPI related--consistent lockups trying to suspend; hangs during shutdown. Have updated the BIOS and I'm going through the list of items in the acpi-debugging list, in the handbook. I'm also having issues with the DVD reader on the machine. I'm mainly curious to know if anyone else is having these problems, and if anyone has comments about the hardware in general. Mike. From koitsu at FreeBSD.org Tue Jun 3 12:22:19 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Jun 3 12:22:22 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: <18501.12329.638264.761303@cs.wpi.edu> References: <18501.12329.638264.761303@cs.wpi.edu> Message-ID: <20080603122218.GA69827@eos.sc1.parodius.com> On Tue, Jun 03, 2008 at 07:51:05AM -0400, Michael C Voorhis wrote: > > Has anyone tried 7.0-Stable on a Thinkpad t61p. I've been using one > for a few weeks and have had many problems, after several event-free > years on a t42. > > My issues are mainly ACPI related--consistent lockups trying to > suspend; hangs during shutdown. Have updated the BIOS and I'm going > through the list of items in the acpi-debugging list, in the handbook. > > I'm also having issues with the DVD reader on the machine. I'm mainly > curious to know if anyone else is having these problems, Here's what I'm aware of. Apologies on some of these links; some of the participants do not use decent mail clients that utilise thread referencing headers. http://lists.freebsd.org/pipermail/freebsd-stable/2007-October/037652.html http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039452.html http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041509.html http://lists.freebsd.org/pipermail/freebsd-stable/2008-April/041794.html My co-worker runs Kubuntu Linux on his T60p, and it works great. Very decent ACPI support, with full driver support (including H/W monitoring and adjustments). I was quite impressed. > ... and if anyone has comments about the hardware in general. Based on my experiences with my workplace-provided T60p, it's safe to say I'll never recommend a Lenovo product. The temperatures of these laptops are absolutely insane, supported by an incredibly loud fan. I'm not interested in a product that can have a GPU reaching temperatures of almost 70C **while idling**. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jhb at freebsd.org Tue Jun 3 14:52:33 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Jun 3 14:52:38 2008 Subject: Interrupt storm with shared interrupt on digi(4) In-Reply-To: <20080603070840.GH1028@server.vk2pj.dyndns.org> References: <20080603070840.GH1028@server.vk2pj.dyndns.org> Message-ID: <200806031021.35416.jhb@freebsd.org> On Tuesday 03 June 2008 03:08:40 am Peter Jeremy wrote: > I have an on-going problem with DigiBoard Xem boards causing interrupt > storms (since 4.x days). The FreeBSD driver polls the board and > doesn't have a functional interrupt handler (and Linux behaves in the > same way). It seems that under some conditions, the board will assert > its interrupt line and, since there's no interrupt handler to clear > whatever triggered the interrupt, the IRQ is never unasserted. > > In the past, I have managed to avoid the problem by putting the Digi > card on a dedicated interrupt. For reasons I don't understand, this > appears to mask the problem. That is because we leave interrupts masked until it gets an interrupt handler. Since digi(4) doesn't register a handler, we leave the interrupt masked unless some other device is sharing the same interrupt and registers a handler. > Unfortunately, I now have a system where, courtesy of Compaq's > incompetence, I have no way to avoid having two Digi boards sharing an > interrupt. In 7.x, as soon as I load digi.ko, I get "interrupt storm" > messages. In 6.x, I could see the interrupt storm but it didn't > flood my console with messages. > > Does anyone have a patch that will generate an appropriate EOI to > a DigiBoard? No. Even better would be if there was a way to disable interrupt generation in the digi(4) driver via some register. > Alternatively, can anyone suggest how I can disable or mask a specified > PCI interrupt? The problem is that in this case you have another driver that is using that interrupt, so if you completely mask the interrupt the other driver will stop getting interrupts and likely stop working. -- John Baldwin From jhb at freebsd.org Tue Jun 3 14:52:33 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Jun 3 14:52:39 2008 Subject: Interrupt storm with shared interrupt on digi(4) In-Reply-To: <20080603070840.GH1028@server.vk2pj.dyndns.org> References: <20080603070840.GH1028@server.vk2pj.dyndns.org> Message-ID: <200806031021.35416.jhb@freebsd.org> On Tuesday 03 June 2008 03:08:40 am Peter Jeremy wrote: > I have an on-going problem with DigiBoard Xem boards causing interrupt > storms (since 4.x days). The FreeBSD driver polls the board and > doesn't have a functional interrupt handler (and Linux behaves in the > same way). It seems that under some conditions, the board will assert > its interrupt line and, since there's no interrupt handler to clear > whatever triggered the interrupt, the IRQ is never unasserted. > > In the past, I have managed to avoid the problem by putting the Digi > card on a dedicated interrupt. For reasons I don't understand, this > appears to mask the problem. That is because we leave interrupts masked until it gets an interrupt handler. Since digi(4) doesn't register a handler, we leave the interrupt masked unless some other device is sharing the same interrupt and registers a handler. > Unfortunately, I now have a system where, courtesy of Compaq's > incompetence, I have no way to avoid having two Digi boards sharing an > interrupt. In 7.x, as soon as I load digi.ko, I get "interrupt storm" > messages. In 6.x, I could see the interrupt storm but it didn't > flood my console with messages. > > Does anyone have a patch that will generate an appropriate EOI to > a DigiBoard? No. Even better would be if there was a way to disable interrupt generation in the digi(4) driver via some register. > Alternatively, can anyone suggest how I can disable or mask a specified > PCI interrupt? The problem is that in this case you have another driver that is using that interrupt, so if you completely mask the interrupt the other driver will stop getting interrupts and likely stop working. -- John Baldwin From eugen at kuzbass.ru Tue Jun 3 18:49:57 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Tue Jun 3 18:50:03 2008 Subject: Support for Nokia USB modems Message-ID: <20080603181712.GA76741@svzserv.kemerovo.su> Hi! There is PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/117185 waiting too way long, it provides patch that makes it possible to use USB modems built in modern Nokia smartphones. The patch is for RELENG_7 and http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/91546 provides the same patch for RELENG_6. There are numerous success cases about various smartphones and the patch. Please consider this. Detailed info inside PRs. Eugene Grosbein From peterjeremy at optushome.com.au Tue Jun 3 19:04:23 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue Jun 3 19:04:27 2008 Subject: Interrupt storm with shared interrupt on digi(4) In-Reply-To: <200806031021.35416.jhb@freebsd.org> References: <20080603070840.GH1028@server.vk2pj.dyndns.org> <200806031021.35416.jhb@freebsd.org> Message-ID: <20080603190418.GP1028@server.vk2pj.dyndns.org> On 2008-Jun-03 10:21:35 -0400, John Baldwin wrote: >> In the past, I have managed to avoid the problem by putting the Digi >> card on a dedicated interrupt. For reasons I don't understand, this >> appears to mask the problem. > >That is because we leave interrupts masked until it gets an interrupt handler. >Since digi(4) doesn't register a handler, we leave the interrupt masked >unless some other device is sharing the same interrupt and registers a >handler. This is what I assumed but doesn't explain how having two digi boards that share an interrupt with each other but nothing else winds up with an interrupt storm. I will have to investigate further... >No. Even better would be if there was a way to disable interrupt generation >in the digi(4) driver via some register. Agreed. Unfortunately, the only documentation is the Linux driver and it doesn't appear to initialise the digi board any differently to FreeBSD. >> Alternatively, can anyone suggest how I can disable or mask a specified >> PCI interrupt? > >The problem is that in this case you have another driver that is using that >interrupt, so if you completely mask the interrupt the other driver will stop >getting interrupts and likely stop working. I agree that this approach is a hack - but it will let me work around the problem on the problematic system. BTW, your MUA's list-reply configuration don't recognize that freebsd-stable@ and stable@ are aliases. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080603/fca35a0c/attachment.pgp From stevenschlansker at berkeley.edu Tue Jun 3 19:12:29 2008 From: stevenschlansker at berkeley.edu (Steven Schlansker) Date: Tue Jun 3 19:12:34 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: <20080603122218.GA69827@eos.sc1.parodius.com> References: <18501.12329.638264.761303@cs.wpi.edu> <20080603122218.GA69827@eos.sc1.parodius.com> Message-ID: <1FB60F2E-FB30-4118-B5A7-9A818AFF201F@berkeley.edu> On Jun 3, 2008, at 5:22 AM, Jeremy Chadwick wrote: > On Tue, Jun 03, 2008 at 07:51:05AM -0400, Michael C Voorhis wrote: >> > >> ... and if anyone has comments about the hardware in general. > > Based on my experiences with my workplace-provided T60p, it's safe to > say I'll never recommend a Lenovo product. The temperatures of these > laptops are absolutely insane, supported by an incredibly loud fan. > I'm > not interested in a product that can have a GPU reaching > temperatures of > almost 70C **while idling**. Interesting, I've had almost the opposite experience. I have the T61p with the NVIDIA Quadro card. If I run a game, the video card becomes almost too hot to have on my lap rather quickly (I just put it on a magazine or something and it's fine), but if it's idle the temperature is totally comfortable on my lap. It also takes only about 5 minutes to cool off. The fan is almost silent. Perhaps they fixed the issues you describe with the revision? From subhro.kar at gmail.com Tue Jun 3 19:59:38 2008 From: subhro.kar at gmail.com (Subhro) Date: Tue Jun 3 19:59:42 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: <1FB60F2E-FB30-4118-B5A7-9A818AFF201F@berkeley.edu> References: <18501.12329.638264.761303@cs.wpi.edu> <20080603122218.GA69827@eos.sc1.parodius.com> <1FB60F2E-FB30-4118-B5A7-9A818AFF201F@berkeley.edu> Message-ID: I had a feeling nvidia does not work with amd64?? Subhro On Wed, Jun 4, 2008 at 12:31 AM, Steven Schlansker wrote: > > On Jun 3, 2008, at 5:22 AM, Jeremy Chadwick wrote: > >> On Tue, Jun 03, 2008 at 07:51:05AM -0400, Michael C Voorhis wrote: >>> >> >>> ... and if anyone has comments about the hardware in general. >> >> Based on my experiences with my workplace-provided T60p, it's safe to >> say I'll never recommend a Lenovo product. The temperatures of these >> laptops are absolutely insane, supported by an incredibly loud fan. I'm >> not interested in a product that can have a GPU reaching temperatures of >> almost 70C **while idling**. > > Interesting, I've had almost the opposite experience. I have the T61p with > the NVIDIA Quadro card. If I run a game, the video card becomes almost too > hot to have on my lap rather quickly (I just put it on a magazine or > something and it's fine), but if it's idle the temperature is totally > comfortable on my lap. It also takes only about 5 minutes to cool off. The > fan is almost silent. Perhaps they fixed the issues you describe with the > revision? > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Subhro Kar Software Engineer Dynamic Digital Technologies Pvt. Ltd. EPY-3, Sector: V Salt Lake City 700091 India From pjd at FreeBSD.org Tue Jun 3 20:09:55 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Jun 3 20:09:59 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: <18501.12329.638264.761303@cs.wpi.edu> References: <18501.12329.638264.761303@cs.wpi.edu> Message-ID: <20080603193940.GB2637@garage.freebsd.pl> On Tue, Jun 03, 2008 at 07:51:05AM -0400, Michael C Voorhis wrote: > > Has anyone tried 7.0-Stable on a Thinkpad t61p. I've been using one > for a few weeks and have had many problems, after several event-free > years on a t42. > > My issues are mainly ACPI related--consistent lockups trying to > suspend; hangs during shutdown. Have updated the BIOS and I'm going > through the list of items in the acpi-debugging list, in the handbook. I see some lockups from time to time that I can't even get into DDB, but its very rare. Forget about suspend/resume - it doesn't work on any SMP machine. There were some patches posted on freebsd-acpi@ for suspend/resume SMP support, but they didn't work for me. I see no problems with shutdown (if I don't use mentioned patches). Other than that it works quite ok. Unfortunately because of nvidia driver limitation I can't run amd64 or PAE. > I'm also having issues with the DVD reader on the machine. I'm mainly > curious to know if anyone else is having these problems, and if anyone > has comments about the hardware in general. I haven't tried DVD too much, but it's the same reader I had in T43 I think. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080603/193aed28/attachment.pgp From dougb at FreeBSD.org Tue Jun 3 21:20:47 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Jun 3 21:20:51 2008 Subject: [releng_6 tinderbox] failure on i386/i386 In-Reply-To: <20080603090624.865C4241A2@freebsd-legacy.sentex.ca> References: <20080603090624.865C4241A2@freebsd-legacy.sentex.ca> Message-ID: <4845AF6E.5080709@FreeBSD.org> Sorry about the breakage folks, my test run last night before I committed the update went fine, so I'm not sure what happened here, still investigating. If you need to build -stable now the attached patch should be applied to src/lib/bind/bind/config.h, and it should work. I'm testing again now. I'll commit the fix as soon as I am sure it is the right one. Doug -- This .signature sanitized for your protection -------------- next part -------------- Index: config.h =================================================================== --- config.h (revision 179496) +++ config.h (working copy) @@ -14,6 +14,8 @@ /* #undef POSIX_GETPWNAM_R */ /* #undef POSIX_GETGRGID_R */ /* #undef POSIX_GETGRNAM_R */ +#define HAVE_MEMMOVE +#define HAVE_MEMCHR /* #undef NEED_SETGROUPENT */ /* #undef NEED_GETGROUPLIST */ From nakal at web.de Tue Jun 3 22:09:48 2008 From: nakal at web.de (Martin) Date: Tue Jun 3 22:09:53 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: <20080603122218.GA69827@eos.sc1.parodius.com> References: <18501.12329.638264.761303@cs.wpi.edu> <20080603122218.GA69827@eos.sc1.parodius.com> Message-ID: <20080603234736.65737e6c@zelda.local> On Tue, 3 Jun 2008 05:22:18 -0700 Jeremy Chadwick wrote: > Based on my experiences with my workplace-provided T60p, it's safe to > say I'll never recommend a Lenovo product. The temperatures of these > laptops are absolutely insane, supported by an incredibly loud fan. > I'm not interested in a product that can have a GPU reaching > temperatures of almost 70C **while idling**. Hallo, I can confirm this. I've got a T60p Lenovo Thinkpad here. This laptop is very lazy with speeding up the fan, when using automatic fan settings. I've got CPU temperatures up to 101?C here, while compiling world or ports. At this point the laptop powers off. The fan works. I checked it. The fan is far too slow, when setting it to highest level: dev.acpi_ibm.0.fan_speed: 3745 dev.acpi_ibm.0.fan_level: 7 dev.acpi_ibm.0.fan: 0 I'm not sure, but I think I've seen it at 4300 and almost 5000 rpm earlier at high temperatures around 90?C. Today it always stays below 4000 rpm, even at 100?C. Second problem is that the VGA sits under the same heat sink as the CPU. The GPU or chipset is constantly at 75?C minimum, because FreeBSD-powerd does not adjust the voltage settings of the VGA and always runs it at full power. This heats up the CPU additionally. I have a small script that automatically adapts the CPU speed, so it stays below 75?C while compiling big things. Optionally one can set the CPU speed to 1667MHz manually while compiling. -- Martin From dougb at FreeBSD.org Tue Jun 3 22:33:00 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Jun 3 22:33:04 2008 Subject: [releng_6 tinderbox] failure on i386/i386 In-Reply-To: <4845AF6E.5080709@FreeBSD.org> References: <20080603090624.865C4241A2@freebsd-legacy.sentex.ca> <4845AF6E.5080709@FreeBSD.org> Message-ID: <4845C677.3080702@FreeBSD.org> Doug Barton wrote: > Sorry about the breakage folks, my test run last night before I > committed the update went fine, so I'm not sure what happened here, > still investigating. If you need to build -stable now the attached patch > should be applied to src/lib/bind/bind/config.h, and it should work. I'm > testing again now. > > I'll commit the fix as soon as I am sure it is the right one. Ok, done. Once again, sorry for the hassle. Every time I think I've found and fixed all the possible failure modes for a BIND update, I stumble into new ones. Time to update my notes ... Doug -- This .signature sanitized for your protection From nakal at web.de Tue Jun 3 23:16:21 2008 From: nakal at web.de (Martin) Date: Tue Jun 3 23:16:26 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: <20080603193940.GB2637@garage.freebsd.pl> References: <18501.12329.638264.761303@cs.wpi.edu> <20080603193940.GB2637@garage.freebsd.pl> Message-ID: <20080604004944.1138b33f@zelda.local> Am Tue, 3 Jun 2008 21:39:40 +0200 schrieb Pawel Jakub Dawidek : > I see some lockups from time to time that I can't even get into DDB, > but its very rare. Just in case you have 2 different DIMMs in your Thinkpad (even they have same so called "FRU"), try to remove one of them. My T60p got more stable. I could reproduce a full freeze on every platform including MS-Windows, when putting a Thinkpad under high load. Easy with compiling 4 openssl distributions concurrently, in my case. You should accept only exactly the same DIMMs in a T60p Thinkpad. And you should stress this when talking on the hotline or they send you DIMMs with equal FRU number. -- Martin From unixmania at gmail.com Wed Jun 4 02:25:12 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Wed Jun 4 02:25:16 2008 Subject: Why does sysinstall still limits cylinders to 65535? In-Reply-To: <20080526062417.GA61084@eos.sc1.parodius.com> References: <20080526062417.GA61084@eos.sc1.parodius.com> Message-ID: On Mon, May 26, 2008 at 3:24 AM, Jeremy Chadwick wrote: > On Sun, May 25, 2008 at 11:52:06PM -0300, Carlos A. M. dos Santos wrote: >> I have been struglling with sysinstall, attempting to make it handle >> the geometry of some large SATA drives. After a lot of effort I >> decided to stop suffering and modified the program in order to >> circumvent the outdated limit of 65535 cylinders (see attached patch). >> I'm thinking about submitting a PR with a change request but I'd like >> to get some additional opinions first. I did not test it in "batch" >> mode, so it would be great if any kind soul did this. > > Carlos, bottom line is to simply ignore the geometry warning you see. > > For others... > > This is just added evidence that the humongous warning spit out during > sysinstall's fdisk is confusing users (many taking it very seriously > when there's really no problem at all). > > I think this is the third time someone's brought this up in the past > couple months... Sorry if I sound annoying but nobody else answered. I still believe that something must be done to fix sysinstall, so I'm asking you (where "you" means the "others" in Jeremy's message) to provide some additional feedback. Please fill-in the dots in one or more of the following options: 1. We can not make such change sysinstall because ... 2. Your patch is not correct/sufficient. I would be better if ... 3. Please submit a PR. It will momentarily be reviewed by ... 4. Give up. Nobody here cares about this issue. Thanks in advance. -- Carlos A. M. dos Santos From dougb at FreeBSD.org Wed Jun 4 02:49:54 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Wed Jun 4 02:49:59 2008 Subject: Why does sysinstall still limits cylinders to 65535? In-Reply-To: References: <20080526062417.GA61084@eos.sc1.parodius.com> Message-ID: <484602C5.7000400@FreeBSD.org> Carlos A. M. dos Santos wrote: > On Mon, May 26, 2008 at 3:24 AM, Jeremy Chadwick wrote: >> On Sun, May 25, 2008 at 11:52:06PM -0300, Carlos A. M. dos Santos wrote: >>> I have been struglling with sysinstall, attempting to make it handle >>> the geometry of some large SATA drives. After a lot of effort I >>> decided to stop suffering and modified the program in order to >>> circumvent the outdated limit of 65535 cylinders (see attached patch). >>> I'm thinking about submitting a PR with a change request but I'd like >>> to get some additional opinions first. I did not test it in "batch" >>> mode, so it would be great if any kind soul did this. >> Carlos, bottom line is to simply ignore the geometry warning you see. >> >> For others... >> >> This is just added evidence that the humongous warning spit out during >> sysinstall's fdisk is confusing users (many taking it very seriously >> when there's really no problem at all). >> >> I think this is the third time someone's brought this up in the past >> couple months... > > Sorry if I sound annoying but nobody else answered. I still believe > that something must be done to fix sysinstall, so I'm asking you > (where "you" means the "others" in Jeremy's message) to provide some > additional feedback. Please fill-in the dots in one or more of the > following options: > > 1. We can not make such change sysinstall because ... > > 2. Your patch is not correct/sufficient. I would be better if ... > > 3. Please submit a PR. It will momentarily be reviewed by ... > > 4. Give up. Nobody here cares about this issue. 5. -stable is not the right list to discuss sysinstall issues. freebsd-hackers would be the first choice, if you don't get a response there, -current would be the next. Send the PR first, and in your message give a brief background of your issue and a URL for the PR. That way when it gets reviewed the feedback will be consolidated into one convenient location. If you want "momentary" review for your work, open source is probably not the arena you should be looking to contribute in. hth, Doug -- This .signature sanitized for your protection From nlaroche at vt.edu Wed Jun 4 12:16:19 2008 From: nlaroche at vt.edu (nlaroche@vt.edu) Date: Wed Jun 4 12:16:27 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: <1212505961.48455f69d37b8@webmail.vt.edu> References: <18501.12329.638264.761303@cs.wpi.edu> <20080603122218.GA69827@eos.sc1.parodius.com> <1212505961.48455f69d37b8@webmail.vt.edu> Message-ID: <1212506007.48455f97a3788@webmail.vt.edu> Quoting nlaroche@vt.edu: > Quoting Jeremy Chadwick : > > Based on my experiences with my workplace-provided T60p, it's safe to > > say I'll never recommend a Lenovo product. The temperatures of these > > laptops are absolutely insane, supported by an incredibly loud fan. I'm > > not interested in a product that can have a GPU reaching temperatures of > > almost 70C **while idling**. > > I purchased a T60p about two months ago and I haven't had any of these happen > (yet?) running Ubuntu 7.10. The machine only gets slightly warm to the touch > after a few hours idling. > > Does your fan run all the time that loud? I'm wondering if there were changes > made at the factory to fix this type of problem if it was wide spread. > > Regards, > Nick LaRoche > > That was a T61p not a T60p From koitsu at FreeBSD.org Wed Jun 4 12:25:13 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Jun 4 12:25:20 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: <1212506007.48455f97a3788@webmail.vt.edu> References: <18501.12329.638264.761303@cs.wpi.edu> <20080603122218.GA69827@eos.sc1.parodius.com> <1212505961.48455f69d37b8@webmail.vt.edu> <1212506007.48455f97a3788@webmail.vt.edu> Message-ID: <20080604122513.GA24093@eos.sc1.parodius.com> On Tue, Jun 03, 2008 at 11:13:27AM -0400, nlaroche@vt.edu wrote: > Quoting nlaroche@vt.edu: > > Quoting Jeremy Chadwick : > > > Based on my experiences with my workplace-provided T60p, it's safe to > > > say I'll never recommend a Lenovo product. The temperatures of these > > > laptops are absolutely insane, supported by an incredibly loud fan. I'm > > > not interested in a product that can have a GPU reaching temperatures of > > > almost 70C **while idling**. > > > > I purchased a T60p about two months ago and I haven't had any of these happen > > (yet?) running Ubuntu 7.10. The machine only gets slightly warm to the touch > > after a few hours idling. > > > > Does your fan run all the time that loud? I'm wondering if there were changes > > made at the factory to fix this type of problem if it was wide spread. > > > > Regards, > > Nick LaRoche > > That was a T61p not a T60p It really doesn't matter in this case; T60p, T60p (widescreen), T61p, X60p, etc... They all behave the same way when it comes to temperatures: incredibly high, sometimes to the point of the system shutting off (for some). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From nlaroche at vt.edu Wed Jun 4 12:34:45 2008 From: nlaroche at vt.edu (nlaroche@vt.edu) Date: Wed Jun 4 12:34:50 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: <20080603122218.GA69827@eos.sc1.parodius.com> References: <18501.12329.638264.761303@cs.wpi.edu> <20080603122218.GA69827@eos.sc1.parodius.com> Message-ID: <1212505961.48455f69d37b8@webmail.vt.edu> Quoting Jeremy Chadwick : > Based on my experiences with my workplace-provided T60p, it's safe to > say I'll never recommend a Lenovo product. The temperatures of these > laptops are absolutely insane, supported by an incredibly loud fan. I'm > not interested in a product that can have a GPU reaching temperatures of > almost 70C **while idling**. I purchased a T60p about two months ago and I haven't had any of these happen (yet?) running Ubuntu 7.10. The machine only gets slightly warm to the touch after a few hours idling. Does your fan run all the time that loud? I'm wondering if there were changes made at the factory to fix this type of problem if it was wide spread. Regards, Nick LaRoche From koitsu at FreeBSD.org Wed Jun 4 13:04:35 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Jun 4 13:04:39 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: <1212505961.48455f69d37b8@webmail.vt.edu> References: <18501.12329.638264.761303@cs.wpi.edu> <20080603122218.GA69827@eos.sc1.parodius.com> <1212505961.48455f69d37b8@webmail.vt.edu> Message-ID: <20080604130434.GA24817@eos.sc1.parodius.com> On Tue, Jun 03, 2008 at 11:12:41AM -0400, nlaroche@vt.edu wrote: > Quoting Jeremy Chadwick : > > Based on my experiences with my workplace-provided T60p, it's safe to > > say I'll never recommend a Lenovo product. The temperatures of these > > laptops are absolutely insane, supported by an incredibly loud fan. I'm > > not interested in a product that can have a GPU reaching temperatures of > > almost 70C **while idling**. > > I purchased a T60p about two months ago and I haven't had any of these happen > (yet?) running Ubuntu 7.10. The machine only gets slightly warm to the touch > after a few hours idling. I pointed out earlier in the thread that Linux appears to have full ACPI support for the Thinkpad series, including extras -- which probably manage some of the thermal-related features better. > Does your fan run all the time that loud? Within 10-15 seconds of logging in (to Vista), the fan kicks on medium speed. As we all know, Vista enjoys chewing CPU and disk prior to and after logging in, and takes about 5 minutes to relax (assuming you disable Indexing, ReadyBoost, and SuperFetch). After about 10-15 minutes, the fan usually kicks into high mode, and remains that way until the laptop has a chance to go into sleep/power save mode -- or, if the rear of the laptop is raised up off the desk. The amount of hot air coming out of the fan slot on the left side is fairly substantial, indicating the overall design of the laptop is bad, thermal-wise. A couple of my co-workers (but only a few!) do not have this problem. Their laptops run with the fan off, or in low mode. When we were all using XP, I had them run the Thinkpad monitoring utility (an open-source app) to look at the thermals of all the different parts in the system. Their temps were substantially lower than mine (particularly the GPU), but in others, were higher. This could indicate a problem similar to Apple and their Macbooks, where assembly line folks were applying entire tubes of thermal compound to the CPU heatsink area. I haven't taken the time to open one of the Lenovo laptops up -- company rules don't permit me to do so, and I don't trust the coherency of our IT department anyways. ("Sounds isolated, better just replace the entire laptop" "Umm, no...") There are other problems with these laptops, not just thermal-related. The laptop emits high-pitch noises as a result of some power-saving modes the Centrino Duo chipset has. They've been documented in full on the RMClock forum, and there are workarounds using either RMClock or (my preferred method) turning off two options in the BIOS. If you can't hear the noise, then your hearing isn't as sensitive as some peoples. I can dig up the exact BIOS labels if you'd like them. > I'm wondering if there were changes made at the factory to fix this > type of problem if it was wide spread. Possibly. There's quite a lot of evidence on the Web about this problem with Lenovo laptops. IBM/Lenovo's T43 series did not behave this way, but they were on older (cooler, temperature-wise) hardware. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From josh at tcbug.org Wed Jun 4 13:06:30 2008 From: josh at tcbug.org (Josh Paetzel) Date: Wed Jun 4 13:06:36 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: <20080604122513.GA24093@eos.sc1.parodius.com> References: <18501.12329.638264.761303@cs.wpi.edu> <1212506007.48455f97a3788@webmail.vt.edu> <20080604122513.GA24093@eos.sc1.parodius.com> Message-ID: <200806040745.19637.josh@tcbug.org> On Wednesday 04 June 2008 07:25:13 am Jeremy Chadwick wrote: > On Tue, Jun 03, 2008 at 11:13:27AM -0400, nlaroche@vt.edu wrote: > > Quoting nlaroche@vt.edu: > > > Quoting Jeremy Chadwick : > > > > Based on my experiences with my workplace-provided T60p, it's safe to > > > > say I'll never recommend a Lenovo product. The temperatures of these > > > > laptops are absolutely insane, supported by an incredibly loud fan. > > > > I'm not interested in a product that can have a GPU reaching > > > > temperatures of almost 70C **while idling**. > > > > > > I purchased a T60p about two months ago and I haven't had any of these > > > happen (yet?) running Ubuntu 7.10. The machine only gets slightly warm > > > to the touch after a few hours idling. > > > > > > Does your fan run all the time that loud? I'm wondering if there were > > > changes made at the factory to fix this type of problem if it was wide > > > spread. > > > > > > Regards, > > > Nick LaRoche > > > > That was a T61p not a T60p > > It really doesn't matter in this case; T60p, T60p (widescreen), T61p, > X60p, etc... They all behave the same way when it comes to > temperatures: incredibly high, sometimes to the point of the system > shutting off (for some). My T60p is really unusable for anything cpu intensive under FreeBSD. Even with the ibm acpi addons loaded and the fan set to it's highest setting it only turns at 3700rpm, which isn't enough to keep it from shutting down due to heat. (eg over 100C) I'm interested in whatever cooling solutions people have... -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080604/e0b0323c/attachment.pgp From richard at unixguru.nl Wed Jun 4 13:54:18 2008 From: richard at unixguru.nl (Richard Arends) Date: Wed Jun 4 13:54:25 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: <200806040745.19637.josh@tcbug.org> References: <18501.12329.638264.761303@cs.wpi.edu> <1212506007.48455f97a3788@webmail.vt.edu> <20080604122513.GA24093@eos.sc1.parodius.com> <200806040745.19637.josh@tcbug.org> Message-ID: <20080604132629.GI37038@shell.unixguru.nl> On Wed, Jun 04, 2008 at 07:45:12AM -0500, Josh Paetzel wrote: Hi, > I'm interested in whatever cooling solutions people have... For my T60 i made a perl script for controlling the fans and the cpu speed. A few months ago i changed it to work together with powerd and i must say, i got it pretty workable now. With a normal workload (browsing the internet, reading mail, ssh'ing to control the rest of the world), the temp is under 60 degrees. http://www.unixguru.nl/made/ibm_fancontrol_fbsd.txt -- Regards, Richard. /* Homo Sapiens non urinat in ventum */ From avg at icyb.net.ua Wed Jun 4 15:07:51 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Jun 4 15:07:57 2008 Subject: mystery: lock up after fs dump Message-ID: <4846AFC3.3050101@icyb.net.ua> I wouldn't report this if not for one coincidence (which is described below). I have too little facts, so this is more of a mystery problem tale than a real problem report. There are two systems: 1. old, slow, i386, UP, 7-STABLE 2. new, fast, amd64, MP, 6.3-RELEASE Systems are located at different physical locations. What is common between them: 1. they both have the same backup strategy where dumps of certain levels are performed on certain days; there are monthly dumps of level 2 (on first day of each month), weekly dumps of level 4 (each Sunday) and daily dumps of levels > 5 (each day except for Sunday - but including the firsts). dumps are done on live filesystems using -L. dumps are initially done to the same disk and only later are transfered to archive media. 2. both kernels are compiled with softupdates support but there are no filesystems with it enabled 3. both systems have root partition gmirror-ed, it is dumped 4. both systems have gjournal support (on 6.X it is added via a "non-official" patch), there are gjournaled filesystems on both systems and they are dumped. On June 1 (Sunday) exactly the same thing happened on both systems. At 4AM monthly level 2 dump was started and successfully performed. At 5AM weekly level 4 dump was started. Somewhere in the process of it system locked up. When I physically accessed the systems I found the following: keyboard didn't respond[*], screen froze, no pings. After reset I found that logs stopped being updated at some timer shortly after 5AM. [*] - although on amd64 system I was able to switch exactly once between virtual terminals (actually from X terminal to console terminal). But that's all, no led responses, no special combinations (like break to debugger - it is compiled in / enabled). This coincidence in details (and that one successful VT switch) lead me to believe that this was some lock up in kernel rather than a hardware problem. Also, I use that backup scheme for almost a year and never had such a problem before. I just checked and this was the first time that the 1st of a month fell on Sunday, so this was the first time when level 2 dump was followed by level 4 dump. In previous months it was followed by level > 6 dumps. All in all, quite strange. -- Andriy Gapon From kostikbel at gmail.com Wed Jun 4 15:23:38 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Jun 4 15:23:43 2008 Subject: mystery: lock up after fs dump In-Reply-To: <4846AFC3.3050101@icyb.net.ua> References: <4846AFC3.3050101@icyb.net.ua> Message-ID: <20080604152332.GE63348@deviant.kiev.zoral.com.ua> On Wed, Jun 04, 2008 at 06:07:47PM +0300, Andriy Gapon wrote: > > I wouldn't report this if not for one coincidence (which is described > below). I have too little facts, so this is more of a mystery problem > tale than a real problem report. > > There are two systems: > 1. old, slow, i386, UP, 7-STABLE > 2. new, fast, amd64, MP, 6.3-RELEASE > > Systems are located at different physical locations. > > What is common between them: > 1. they both have the same backup strategy where dumps of certain levels > are performed on certain days; there are monthly dumps of level 2 (on > first day of each month), weekly dumps of level 4 (each Sunday) and > daily dumps of levels > 5 (each day except for Sunday - but including > the firsts). > dumps are done on live filesystems using -L. > dumps are initially done to the same disk and only later are transfered > to archive media. > 2. both kernels are compiled with softupdates support but there are no > filesystems with it enabled > 3. both systems have root partition gmirror-ed, it is dumped > 4. both systems have gjournal support (on 6.X it is added via a > "non-official" patch), there are gjournaled filesystems on both systems > and they are dumped. > > On June 1 (Sunday) exactly the same thing happened on both systems. > At 4AM monthly level 2 dump was started and successfully performed. > At 5AM weekly level 4 dump was started. > Somewhere in the process of it system locked up. > When I physically accessed the systems I found the following: keyboard > didn't respond[*], screen froze, no pings. After reset I found that logs > stopped being updated at some timer shortly after 5AM. > [*] - although on amd64 system I was able to switch exactly once between > virtual terminals (actually from X terminal to console terminal). But > that's all, no led responses, no special combinations (like break to > debugger - it is compiled in / enabled). > > This coincidence in details (and that one successful VT switch) lead me > to believe that this was some lock up in kernel rather than a hardware > problem. Also, I use that backup scheme for almost a year and never had > such a problem before. I just checked and this was the first time that > the 1st of a month fell on Sunday, so this was the first time when level > 2 dump was followed by level 4 dump. In previous months it was followed > by level > 6 dumps. > > All in all, quite strange. Do you use snapshots on the gjournaled fs ? I believe this is problematic. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080604/79b089d9/attachment.pgp From avg at icyb.net.ua Wed Jun 4 15:33:49 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Jun 4 15:33:53 2008 Subject: mystery: lock up after fs dump In-Reply-To: <20080604152332.GE63348@deviant.kiev.zoral.com.ua> References: <4846AFC3.3050101@icyb.net.ua> <20080604152332.GE63348@deviant.kiev.zoral.com.ua> Message-ID: <4846B5D9.1050903@icyb.net.ua> on 04/06/2008 18:23 Kostik Belousov said the following: > On Wed, Jun 04, 2008 at 06:07:47PM +0300, Andriy Gapon wrote: [snip] >> dumps are done on live filesystems using -L. [snip] >> 4. both systems have gjournal support (on 6.X it is added via a >> "non-official" patch), there are gjournaled filesystems on both systems >> and they are dumped. > > Do you use snapshots on the gjournaled fs ? I believe this is problematic. Yes, I do via dump -L. I don't otherwise (no mksnap_ffs). I had some thoughts about that. But... I remember discussing this on geom list and I think pjd said that this should work and also it worked for me flawlessly except for that one moment. BTW, those filesystems are mounted like the following: ufs, asynchronous, local, noatime, gjournal This is to say that I do not mix gjournal and softupdates, which is also possible (at least not prohibited). -- Andriy Gapon From koitsu at FreeBSD.org Wed Jun 4 15:41:51 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Jun 4 15:41:58 2008 Subject: mystery: lock up after fs dump In-Reply-To: <4846B5D9.1050903@icyb.net.ua> References: <4846AFC3.3050101@icyb.net.ua> <20080604152332.GE63348@deviant.kiev.zoral.com.ua> <4846B5D9.1050903@icyb.net.ua> Message-ID: <20080604154151.GA29932@eos.sc1.parodius.com> On Wed, Jun 04, 2008 at 06:33:45PM +0300, Andriy Gapon wrote: > on 04/06/2008 18:23 Kostik Belousov said the following: > > On Wed, Jun 04, 2008 at 06:07:47PM +0300, Andriy Gapon wrote: > [snip] > >> dumps are done on live filesystems using -L. > [snip] > >> 4. both systems have gjournal support (on 6.X it is added via a > >> "non-official" patch), there are gjournaled filesystems on both systems > >> and they are dumped. > > > > Do you use snapshots on the gjournaled fs ? I believe this is problematic. > > Yes, I do via dump -L. I don't otherwise (no mksnap_ffs). > I had some thoughts about that. > But... I remember discussing this on geom list and I think pjd said that > this should work and also it worked for me flawlessly except for that > one moment. > BTW, those filesystems are mounted like the following: > ufs, asynchronous, local, noatime, gjournal > This is to say that I do not mix gjournal and softupdates, which is also > possible (at least not prohibited). I haven't seen hard system lock-ups when using dump (the -L on UFS2 systems is implied, but you're not using softupdates, so maybe it's not implied on such), but I have seen all I/O on the system lock up hard until the actual snapshot finishes being taken. I mentioned this a while ago on -stable (not sure; I can dig up the thread), and was told that essentially this is a known problem with snapshots on UFS2, and that the problem over time gets worse and worse. Ultimately I stopped using dump and switched to rsync. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From kostikbel at gmail.com Wed Jun 4 16:10:07 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Jun 4 16:10:11 2008 Subject: mystery: lock up after fs dump In-Reply-To: <4846B5D9.1050903@icyb.net.ua> References: <4846AFC3.3050101@icyb.net.ua> <20080604152332.GE63348@deviant.kiev.zoral.com.ua> <4846B5D9.1050903@icyb.net.ua> Message-ID: <20080604161001.GF63348@deviant.kiev.zoral.com.ua> On Wed, Jun 04, 2008 at 06:33:45PM +0300, Andriy Gapon wrote: > on 04/06/2008 18:23 Kostik Belousov said the following: > > On Wed, Jun 04, 2008 at 06:07:47PM +0300, Andriy Gapon wrote: > [snip] > >> dumps are done on live filesystems using -L. > [snip] > >> 4. both systems have gjournal support (on 6.X it is added via a > >> "non-official" patch), there are gjournaled filesystems on both systems > >> and they are dumped. > > > > Do you use snapshots on the gjournaled fs ? I believe this is problematic. > > Yes, I do via dump -L. I don't otherwise (no mksnap_ffs). > I had some thoughts about that. > But... I remember discussing this on geom list and I think pjd said that > this should work and also it worked for me flawlessly except for that > one moment. > BTW, those filesystems are mounted like the following: > ufs, asynchronous, local, noatime, gjournal > This is to say that I do not mix gjournal and softupdates, which is also > possible (at least not prohibited). SU are irrelevant to the problem I am thinking of. vfs_write_suspend() returns 0 when the filesystem being suspended is already in suspend state. vfs_write_resume() clears the suspend state. vfs_write_suspend/vfs_write_resume are used both by snapshot code and the gjournal. If two users of these interfaces interleave, then you could get: thread1 thread2 vfs_write_suspend() <- fs is suspended there vfs_write_suspend() <- returns 0 vfs_write_resume() <- fs is no more suspended thread2 is burned in flame Snapshots are protected against this because they are created through the mount(2). The mount(2) locks the covered vnode and thus serializes snapshot creation (I think there are further serialization points that prevent simultaneous snapshotting of the same fs). There is nothing I can see that protects snapshots/gjournal interaction. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080604/1a49c84a/attachment.pgp From dougb at FreeBSD.org Wed Jun 4 17:01:56 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Wed Jun 4 17:02:02 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: <20080604132629.GI37038@shell.unixguru.nl> References: <18501.12329.638264.761303@cs.wpi.edu> <1212506007.48455f97a3788@webmail.vt.edu> <20080604122513.GA24093@eos.sc1.parodius.com> <200806040745.19637.josh@tcbug.org> <20080604132629.GI37038@shell.unixguru.nl> Message-ID: <4846CA7B.5070308@FreeBSD.org> Richard Arends wrote: > On Wed, Jun 04, 2008 at 07:45:12AM -0500, Josh Paetzel wrote: > > Hi, > >> I'm interested in whatever cooling solutions people have... I didn't follow this thread earlier because I don't have this laptop, but I wonder if anyone has offered the suggestion to blow out all the vents and heatsinks with compressed air yet? Even in a fairly "healthy" environment at home my laptop gets a non-trivial amount of dust buildup. I blow it clean about once a month and get visible results each time. hth, Doug -- This .signature sanitized for your protection From jrhett at netconsonance.com Wed Jun 4 17:45:52 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed Jun 4 17:45:58 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 Message-ID: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> Okay, I totally understand that FreeBSD wants people to upgrade from 6.2 to 6.3. But given that 6.3 is still experiencing bugs with things that are working fine and stable in 6.2, this is a pretty hard case to make. This is also a fairly significant investment in terms of time and money for any business to handle this ugprade. It totally understand obsoleting 5.x now that 7.x is out. But 6.2 is barely a year old... -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From dougb at FreeBSD.org Wed Jun 4 18:00:47 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Wed Jun 4 18:00:53 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> Message-ID: <4846D849.2090005@FreeBSD.org> Jo Rhett wrote: > Okay, I totally understand that FreeBSD wants people to upgrade from 6.2 > to 6.3. It isn't that we want people to upgrade, it's that we are trying to be realistic regarding what we have the resources to support. > But given that 6.3 is still experiencing bugs with things that > are working fine and stable in 6.2, this is a pretty hard case to make. I admit to not having been following 6.x too closely, but are these things that have been reported, or problems you're having personally? > This is also a fairly significant investment in terms of time and money > for any business to handle this ugprade. Having an upgrade path is something every operation needs. "Set it and forget it" isn't a viable strategy in the current culture where 0-day vulnerabilities are becoming increasingly common. hth, Doug -- This .signature sanitized for your protection From jhb at freebsd.org Wed Jun 4 18:12:37 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Jun 4 18:12:44 2008 Subject: Why does sysinstall still limits cylinders to 65535? In-Reply-To: <484602C5.7000400@FreeBSD.org> References: <484602C5.7000400@FreeBSD.org> Message-ID: <200806041030.37413.jhb@freebsd.org> On Tuesday 03 June 2008 10:49:41 pm Doug Barton wrote: > Carlos A. M. dos Santos wrote: > > On Mon, May 26, 2008 at 3:24 AM, Jeremy Chadwick wrote: > >> On Sun, May 25, 2008 at 11:52:06PM -0300, Carlos A. M. dos Santos wrote: > >>> I have been struglling with sysinstall, attempting to make it handle > >>> the geometry of some large SATA drives. After a lot of effort I > >>> decided to stop suffering and modified the program in order to > >>> circumvent the outdated limit of 65535 cylinders (see attached patch). > >>> I'm thinking about submitting a PR with a change request but I'd like > >>> to get some additional opinions first. I did not test it in "batch" > >>> mode, so it would be great if any kind soul did this. > >> Carlos, bottom line is to simply ignore the geometry warning you see. > >> > >> For others... > >> > >> This is just added evidence that the humongous warning spit out during > >> sysinstall's fdisk is confusing users (many taking it very seriously > >> when there's really no problem at all). > >> > >> I think this is the third time someone's brought this up in the past > >> couple months... > > > > Sorry if I sound annoying but nobody else answered. I still believe > > that something must be done to fix sysinstall, so I'm asking you > > (where "you" means the "others" in Jeremy's message) to provide some > > additional feedback. Please fill-in the dots in one or more of the > > following options: > > > > 1. We can not make such change sysinstall because ... > > > > 2. Your patch is not correct/sufficient. I would be better if ... > > > > 3. Please submit a PR. It will momentarily be reviewed by ... > > > > 4. Give up. Nobody here cares about this issue. > > 5. -stable is not the right list to discuss sysinstall issues. > freebsd-hackers would be the first choice, if you don't get a response > there, -current would be the next. > > Send the PR first, and in your message give a brief background of your > issue and a URL for the PR. That way when it gets reviewed the feedback > will be consolidated into one convenient location. > > If you want "momentary" review for your work, open source is probably > not the arena you should be looking to contribute in. 6. The Real Fix(tm) would be to change sysinstall to allow use of GPT partitions (GPT doesn't use C/H/S at all, so the warning would only be present for the MBR/BSD label case) and then enable those by default. You would still need to allow for MBR/BSD layouts for some embedded devices that don't support the BIOS EDD packet mode (i.e. doing disk I/O using LBA's rather than C/H/S). -- John Baldwin From jhb at freebsd.org Wed Jun 4 18:12:44 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Jun 4 18:12:48 2008 Subject: Interrupt storm with shared interrupt on digi(4) In-Reply-To: <20080603190418.GP1028@server.vk2pj.dyndns.org> References: <20080603070840.GH1028@server.vk2pj.dyndns.org> <200806031021.35416.jhb@freebsd.org> <20080603190418.GP1028@server.vk2pj.dyndns.org> Message-ID: <200806041044.01712.jhb@freebsd.org> On Tuesday 03 June 2008 03:04:18 pm Peter Jeremy wrote: > BTW, your MUA's list-reply configuration don't recognize that > freebsd-stable@ and stable@ are aliases. Yes, kmail is broken and the authors refuse to fix it. It happens on reply to a foo@ e-mail (it changes the 'To' to 'freebsd-foo@' because of the List-Id header and leaves foo@ in the 'CC' field). Note that there isn't anything in the List headers that says that foo@ is an alias for freebsd-foo@. I just wish I could turn off the List-Id crap and use plain old reply-to-all, but that is where the kmail developers disagree. -- John Baldwin From kris at FreeBSD.org Wed Jun 4 18:39:10 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Jun 4 18:39:12 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4846D849.2090005@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> Message-ID: <4846E14C.709@FreeBSD.org> Doug Barton wrote: > Jo Rhett wrote: >> Okay, I totally understand that FreeBSD wants people to upgrade from >> 6.2 to 6.3. > > It isn't that we want people to upgrade, it's that we are trying to be > realistic regarding what we have the resources to support. > >> But given that 6.3 is still experiencing bugs with things that are >> working fine and stable in 6.2, this is a pretty hard case to make. > > I admit to not having been following 6.x too closely, but are these > things that have been reported, or problems you're having personally? > >> This is also a fairly significant investment in terms of time and >> money for any business to handle this ugprade. > > Having an upgrade path is something every operation needs. "Set it and > forget it" isn't a viable strategy in the current culture where 0-day > vulnerabilities are becoming increasingly common. Also, it's not like anyone should have been caught by surprise by the 6.2 EoL; the expiry date has been advertised since the 6.2 release itself. Kris From scottl at samsco.org Wed Jun 4 19:00:14 2008 From: scottl at samsco.org (Scott Long) Date: Wed Jun 4 19:00:20 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> Message-ID: <4846E637.9080101@samsco.org> Jo Rhett wrote: > Okay, I totally understand that FreeBSD wants people to upgrade from 6.2 > to 6.3. But given that 6.3 is still experiencing bugs with things that > are working fine and stable in 6.2, this is a pretty hard case to make. Can you describe the bugs that are affecting you? > > This is also a fairly significant investment in terms of time and money > for any business to handle this ugprade. It totally understand > obsoleting 5.x now that 7.x is out. But 6.2 is barely a year old... > The expectation is always that newer versions of a stable branch will have few regressions, and thus upgrading is a low risk. Scott From gaijin.k at gmail.com Wed Jun 4 19:10:33 2008 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Wed Jun 4 19:10:38 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: <200806040745.19637.josh@tcbug.org> References: <18501.12329.638264.761303@cs.wpi.edu> <1212506007.48455f97a3788@webmail.vt.edu> <20080604122513.GA24093@eos.sc1.parodius.com> <200806040745.19637.josh@tcbug.org> Message-ID: <1212606563.1226.11.camel@RabbitsDen> On Wed, 2008-06-04 at 07:45 -0500, Josh Paetzel wrote: > On Wednesday 04 June 2008 07:25:13 am Jeremy Chadwick wrote: > > On Tue, Jun 03, 2008 at 11:13:27AM -0400, nlaroche@vt.edu wrote: > > > Quoting nlaroche@vt.edu: > > > > Quoting Jeremy Chadwick : > > > > > Based on my experiences with my workplace-provided T60p, it's safe to > > > > > say I'll never recommend a Lenovo product. The temperatures of these > > > > > laptops are absolutely insane, supported by an incredibly loud fan. > > > > > I'm not interested in a product that can have a GPU reaching > > > > > temperatures of almost 70C **while idling**. > > > > > > > > I purchased a T60p about two months ago and I haven't had any of these > > > > happen (yet?) running Ubuntu 7.10. The machine only gets slightly warm > > > > to the touch after a few hours idling. > > > > > > > > Does your fan run all the time that loud? I'm wondering if there were > > > > changes made at the factory to fix this type of problem if it was wide > > > > spread. > > > > > > > > Regards, > > > > Nick LaRoche > > > > > > That was a T61p not a T60p > > > > It really doesn't matter in this case; T60p, T60p (widescreen), T61p, > > X60p, etc... They all behave the same way when it comes to > > temperatures: incredibly high, sometimes to the point of the system > > shutting off (for some). > > My T60p is really unusable for anything cpu intensive under FreeBSD. Even > with the ibm acpi addons loaded and the fan set to it's highest setting it > only turns at 3700rpm, which isn't enough to keep it from shutting down due > to heat. (eg over 100C) > > I'm interested in whatever cooling solutions people have... > You can read through this thread: http://www.freebsd.org/cgi/getmsg.cgi?fetch=141019+0 +/usr/local/www/db/text/2008/freebsd-acpi/20080217.freebsd-acpi which mentions at least two ways to approach it -- the right one from the referenced message forward. HTH, -- Alexandre "Sunny" Kovalenko (????????? ?????????) From sclark46 at earthlink.net Wed Jun 4 20:07:00 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Wed Jun 4 20:07:06 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4846E637.9080101@samsco.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> Message-ID: <4846F5D9.7000408@earthlink.net> Scott Long wrote: > Jo Rhett wrote: >> Okay, I totally understand that FreeBSD wants people to upgrade from >> 6.2 to 6.3. But given that 6.3 is still experiencing bugs with things >> that are working fine and stable in 6.2, this is a pretty hard case to >> make. > > Can you describe the bugs that are affecting you? > >> >> This is also a fairly significant investment in terms of time and >> money for any business to handle this ugprade. It totally understand >> obsoleting 5.x now that 7.x is out. But 6.2 is barely a year old... >> > > The expectation is always that newer versions of a stable branch will > have few regressions, and thus upgrading is a low risk. > > Scott > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > Can just the kernel be upgraded or does all of user space have to be upgrades to. How would someone recommend upgrading 500 hundred remote sites spread throughout the US? Thanks, 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) From kris at FreeBSD.org Wed Jun 4 20:19:49 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Jun 4 20:19:53 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4846F5D9.7000408@earthlink.net> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <4846F5D9.7000408@earthlink.net> Message-ID: <4846F8E5.8090309@FreeBSD.org> Stephen Clark wrote: > Scott Long wrote: >> Jo Rhett wrote: >>> Okay, I totally understand that FreeBSD wants people to upgrade from >>> 6.2 to 6.3. But given that 6.3 is still experiencing bugs with >>> things that are working fine and stable in 6.2, this is a pretty hard >>> case to make. >> >> Can you describe the bugs that are affecting you? >> >>> >>> This is also a fairly significant investment in terms of time and >>> money for any business to handle this ugprade. It totally understand >>> obsoleting 5.x now that 7.x is out. But 6.2 is barely a year old... >>> >> >> The expectation is always that newer versions of a stable branch will >> have few regressions, and thus upgrading is a low risk. >> >> Scott >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > Can just the kernel be upgraded or does all of user space have to be > upgrades to. Most things will work fine with slightly mismatched kernels, but it's not recommended to do this (some utilities may not work properly). > How would someone recommend upgrading 500 hundred remote sites spread > throughout Thoroughly test on identically configured machines, roll out incrementally and make sure you have a fallback (i.e. console access) in case something goes catastrophically wrong. Kris From cliftonr at lava.net Wed Jun 4 20:43:29 2008 From: cliftonr at lava.net (Clifton Royston) Date: Wed Jun 4 20:43:32 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4846D849.2090005@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> Message-ID: <20080604204325.GD4701@lava.net> On Wed, Jun 04, 2008 at 11:00:41AM -0700, Doug Barton wrote: > Jo Rhett wrote: ... > >But given that 6.3 is still experiencing bugs with things that > >are working fine and stable in 6.2, this is a pretty hard case to make. > > I admit to not having been following 6.x too closely, but are these > things that have been reported, or problems you're having personally? Speaking just for myself, I'd love to get a general response from people who have run servers on both as to whether 6.3 is on average more stable than 6.2. I really haven't gotten any clear impression as to this, either from posts on -hackers or -stable, and I believe I asked a couple times. I've seen comments that 6.3 should be considerably more stable than 6.2, but also complaints about bugs such as Jo is commenting on, and I have not seen much committed in the way of errata fixes for 6.3 since its release. I'd love to pick up some more stability, but I'm feeling a little burned by 6.2 relative to 4.10, and thus twice wary. > >This is also a fairly significant investment in terms of time and money > >for any business to handle this ugprade. > > Having an upgrade path is something every operation needs. "Set it and > forget it" isn't a viable strategy in the current culture where 0-day > vulnerabilities are becoming increasingly common. Fair enough. Now I must confess my ignorance; is there a simplest straightforward way to upgrade multiple servers between releases in the same branch, other than rebuilding each from source, or wiping and reinstalling? In the past I've always done one of those two. For example, if I take a 6.3R CD, or build one for 6-RELENG, is there a way to do an "upgrade in place" on each server? Or would it work better to do a build from recent source on the development server, then export /usr/src and /usr/obj via NFS to the production servers and do the usual "make installkernel; reboot;" etc. sequence on them? (In my case I do have all machines on one GigE switch.) -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From yurtesen at ispro.net Wed Jun 4 21:20:11 2008 From: yurtesen at ispro.net (Evren Yurtesen) Date: Wed Jun 4 21:20:16 2008 Subject: powerd is doing nothing? Message-ID: <4847072E.5000709@ispro.net> Hi, I have boxes with 6.2-x86 to 7.0-amd64 with CPUs from AMD and Intel ranging between Athlon64, Pentium4, Xeon processors. OK I have setup powerd and when I run powerd I see (for example): idle time > 90%, decreasing clock speed from 2978 MHz to 2605 MHz idle time > 90%, decreasing clock speed from 2605 MHz to 2233 MHz idle time > 90%, decreasing clock speed from 2233 MHz to 1861 MHz idle time > 90%, decreasing clock speed from 1861 MHz to 1489 MHz idle time > 90%, decreasing clock speed from 1489 MHz to 1116 MHz idle time > 90%, decreasing clock speed from 1116 MHz to 744 MHz idle time > 90%, decreasing clock speed from 744 MHz to 372 MHz and sysctl's seem to be in order: dev.cpu.0.freq: 372 dev.cpu.0.freq_levels: 2978/-1 2605/-1 2233/-1 1861/-1 1489/-1 1116/-1 744/-1 372/-1 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 However, I downloaded acpi_ppc from http://www.spa.is.uec.ac.jp/~nfukuda/software/ and there comes a program called chkfreq with it which measures the cpu time. It always shows the maximum speed. For example 2992751205 for 3ghz P4 (from the above examples) regardless of what freq is set. OK lets say the chkfreq is faulty, but I tested this on another machine with 6.2 box with: CPU: AMD Athlon(tm) 64 Processor 3500+ (2202.83-MHz 686-class CPU) and acpi_ppc says: cpu0: Px state: P0, 2200MHz, 89000mW, 100us, 7us cpu0: Px state: P1, 2000MHz, 69000mW, 100us, 7us cpu0: Px state: P2, 1800MHz, 50000mW, 100us, 7us cpu0: Px state: P3, 1000MHz, 22000mW, 100us, 7us cpu0: Px method: AMD K8 Cool'n'Quiet and when at 1000mhz chkfreq shows 1001297861 when I unload acpi_ppc it shows 2202845489. Then I load cpufreq and I see: powernow0: on cpu0 and run powerd dev.cpu.0.freq: 1000 dev.cpu.0.freq_levels: 2200/89000 2000/69000 1800/50000 1000/22000 dev.powernow.0.freq_settings: 2200/89000 2000/69000 1800/50000 1000/22000 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 but when I run chkfreq I get 2202846202 (I checked with -v, powerd does not increase speed while testing) I tested powerd on several machines with p4, athlon64, xeon processors and it seems to work in none of the machines properly. Does anybody know how any way to check for sure if powerd is really working or not? Thanks, Evren From kensmith at cse.Buffalo.EDU Wed Jun 4 21:32:49 2008 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Wed Jun 4 21:32:53 2008 Subject: Upcoming release schedule Message-ID: <1212613444.13920.38.camel@bauer.cse.buffalo.edu> As some of you may know the FreeBSD Project has been attempting to shift over from "Feature based releases" to "Time based releases" as far as trying to schedule them goes. Lets just say that's still a work in progress (as in doing that with FreeBSD 7.0 didn't work out so well). This is the schedule we will be shooting for through the next several years/branches: 8/2008 7.1 and 6.4 2/2009 7.2 6/2009 8.0 8/2009 7.3 12/2009 8.1 and 7.4 3/2010 8.2 8/2010 8.3 12/2010 9.0 4/2011 9.1 and 8.4 10/2011 9.2 3/2012 9.3 6/2012 10.0 12/2012 10.1 and 9.4 No guarantees at this point, but those will be what we shoot for. I've updated the releng page on the Web site to include the first couple of those (commit was just done so it will take a little while to appear at http://www.freebsd.org/releng). -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080604/c6a759c2/attachment.pgp From andrew at modulus.org Wed Jun 4 21:53:43 2008 From: andrew at modulus.org (Andrew Snow) Date: Wed Jun 4 21:53:49 2008 Subject: powerd is doing nothing? In-Reply-To: <4847072E.5000709@ispro.net> References: <4847072E.5000709@ispro.net> Message-ID: <48470ED0.600@modulus.org> The problem is not powerd but cpufreq. While cpufreq appears to work well on my Athlon X2, it has never worked on any of my Core2Duo or Core-based Xeon servers. This is a great shame as these newer Intel chips have the capability to clock up and down very quickly and seamlessly. Who can fix the cpufreq driver? I think it simply hasn't been updated with the latest data from Intel. - Andrew From kdk at daleco.biz Wed Jun 4 22:05:09 2008 From: kdk at daleco.biz (Kevin Kinsey) Date: Wed Jun 4 22:05:15 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080604204325.GD4701@lava.net> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net> Message-ID: <48470C19.90709@daleco.biz> Clifton Royston wrote: > On Wed, Jun 04, 2008 at 11:00:41AM -0700, Doug Barton wrote: >> Jo Rhett wrote: > ... >>> But given that 6.3 is still experiencing bugs with things that >>> are working fine and stable in 6.2, this is a pretty hard case to make. >> I admit to not having been following 6.x too closely, but are these >> things that have been reported, or problems you're having personally? > > Speaking just for myself, I'd love to get a general response from > people who have run servers on both as to whether 6.3 is on average > more stable than 6.2. I really haven't gotten any clear impression as > to this, either from posts on -hackers or -stable, and I believe I > asked a couple times. I've seen comments that 6.3 should be > considerably more stable than 6.2, but also complaints about bugs such > as Jo is commenting on, and I have not seen much committed in the way > of errata fixes for 6.3 since its release. > > I'd love to pick up some more stability, but I'm feeling a little > burned by 6.2 relative to 4.10, and thus twice wary. > > >>> This is also a fairly significant investment in terms of time and money >>> for any business to handle this ugprade. >> Having an upgrade path is something every operation needs. "Set it and >> forget it" isn't a viable strategy in the current culture where 0-day >> vulnerabilities are becoming increasingly common. > > Fair enough. > > Now I must confess my ignorance; is there a simplest straightforward > way to upgrade multiple servers between releases in the same branch, > other than rebuilding each from source, or wiping and reinstalling? In > the past I've always done one of those two. Define "between releases"? If you have a machine running N.NR, then freebsd-update(8), maybe? Just a thought, and that not thought through, > For example, if I take a 6.3R CD, or build one for 6-RELENG, is there > a way to do an "upgrade in place" on each server? Or would it work > better to do a build from recent source on the development server, then > export /usr/src and /usr/obj via NFS to the production servers and do > the usual "make installkernel; reboot;" etc. sequence on them? (In my > case I do have all machines on one GigE switch.) > > -- Clifton I've heard of the latter being done with decent results. Kevin Kinsey -- No amount of careful planning will ever replace dumb luck. From yurtesen at ispro.net Wed Jun 4 22:13:37 2008 From: yurtesen at ispro.net (Evren Yurtesen) Date: Wed Jun 4 22:13:42 2008 Subject: powerd is doing nothing? In-Reply-To: <48470ED0.600@modulus.org> References: <4847072E.5000709@ispro.net> <48470ED0.600@modulus.org> Message-ID: <484713B2.5030200@ispro.net> Andrew Snow wrote: > > The problem is not powerd but cpufreq. While cpufreq appears to work > well on my Athlon X2, it has never worked on any of my Core2Duo or > Core-based Xeon servers. > > This is a great shame as these newer Intel chips have the capability to > clock up and down very quickly and seamlessly. > > Who can fix the cpufreq driver? I think it simply hasn't been updated > with the latest data from Intel. Yes I can see that powerd is trying to change the frequency so agreed, cpufreq is broken. When you say that it doesnt work, does it give an error or? In my case it doesnt give any errors just says it set it but I see that nothing is set. Did you try acpi_ppc? http://www.spa.is.uec.ac.jp/~nfukuda/software/ Thanks, Evren From mav at FreeBSD.org Wed Jun 4 22:25:46 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Jun 4 22:25:51 2008 Subject: Crashes in devfs. Possibly on interface creation/destruction. Message-ID: <48470853.6080807@FreeBSD.org> Hi. After recent upgrading from 6.3-RC1/mpd-5.0rc1 to 6.3-STABLE/mpd-5.1 some of my PPPoE servers started to crash with about weekly period. Usually they just just hang without rebooting and core dumping. Consoles are inaccessible. All I have got from them was: kernel: Fatal trap 12: page fau kernel: lt while in k kernel: ernel kernel: mode kernel: kernel: cpuid = 1; apic id = 01 kernel: faut virtual address = 0x58 kernel: kernel: fault code = supervisor read, page not present kernel: kernel: instruction pointer = 0x20:0xc04800be kernel: kernel: stack pointer = 0x28:0xd690883c kernel: frame pointer = 0x28:0 kernel: xd6908854 kernel: code segment = kernel: base 0x0, limit 0xfffff, type 0x1b kernel: kernel: = DPL 0, pres 1, def32 1, gra kernel: n 1 kernel: processor eflags = interrupt kernel: enab kernel: led, r kernel: esume kernel: , IOPL kernel: = 0 kernel: kernel: current process = 1835 (mpd5) kernel: kernel: trap number = 12 "fault virtual address" and "instruction pointer" are always the same. Address 0xc04800be looks like part of devfs code: > addr2line -f -e kernel.debug 0xc04800be devfs_populate_loop /usr/src/sys/fs/devfs/devfs_devs.c:443 devfs_devs.c: de = devfs_newdirent(s, q - s); if (cdp->cdp_c.si_flags & SI_ALIAS) { de->de_uid = 0; de->de_gid = 0; de->de_mode = 0755; de->de_dirent->d_type = DT_LNK; pdev = cdp->cdp_c.si_parent; ->> line 443 ->> j = strlen(pdev->si_name) + 1; de->de_symlink = malloc(j, M_DEVFS, M_WAITOK); bcopy(pdev->si_name, de->de_symlink, j); 0x58 - is precisely the offset of si_name field inside of struct cdev. So looks like pdev = cdp->cdp_c.si_parent is NULL here for some reason. As soon as network interfaces have respective devfs entries and looking higher interface creation/destruction rate that newest mpd5.1 is able to reach due to optimizations, I think it may be some kind or race somewhere interface creation. Can somebody give me any hint where to look to? -- Alexander Motin From rsmith at xs4all.nl Wed Jun 4 22:28:50 2008 From: rsmith at xs4all.nl (Roland Smith) Date: Wed Jun 4 22:28:55 2008 Subject: 7-STABLE and Intel G33 Message-ID: <20080604222847.GA1179@slackbox.xs4all.nl> My PC has built-in intel G33 graphics, which I'm trying to get to work in something better then vesa. Following the instructions in http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039638.html I have compiled and installed the driver and kernel modules from the git trees for drm and the xf86-video-intel driver from today. I also patched agp_i810.c to remove the comments from the chipset identifiers and rebuilt the kernel. After loading the i915.ko kernel module, and starting X with a config file using the intel driver, I still get; (II) intel(0): xf86BindGARTMemory: bind key 1 at 0x006ff000 (pgoffset 1791) (WW) intel(0): xf86BindGARTMemory: binding of gart memory with key 1 at offset 0x6ff000 failed (Invalid argument) Fatal server error: Couldn't bind memory for front buffer In dmesg output I see: agp0: trying to bind into stolen memory Looking at the Xorg.0.log, the xf86-video-intel driver and the drm and dri drivers seem to initialize OK. Grepping through the source, this error seems to originate in /usr/src/sys/pci/agp_i810.c; if ( sc->chiptype != CHIP_I810 ) { if ( (offset >> AGP_PAGE_SHIFT) < sc->stolen ) { device_printf(dev, "trying to bind into stolen memory"); return EINVAL; } [disclaimer: I'm not a software engineer by education or trade, just a mechanical engineer who likes to tinker with computers and software] I've been reading the agp code, the intel driver code and I've skimmed the intel docs. I find the code quite hard to understand, and the intel docs nigh-on unreadable. Would modifying the if-statement to not produce this error on the CHIP_G33 fix this problem? Or would it horribly blow up in my face? Any help to get this to work would be very much appreciated! Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080604/36cbf572/attachment.pgp From andrew at modulus.org Wed Jun 4 22:33:42 2008 From: andrew at modulus.org (Andrew Snow) Date: Wed Jun 4 22:33:46 2008 Subject: cpufreq broken on core2duo (was: powerd is doing nothing?) In-Reply-To: <484713B2.5030200@ispro.net> References: <4847072E.5000709@ispro.net> <48470ED0.600@modulus.org> <484713B2.5030200@ispro.net> Message-ID: <48471834.30905@modulus.org> Evren Yurtesen wrote: > When you say that it doesnt work, does it give an error or? In my case > it doesnt give any errors just says it set it but I see that nothing is > set. Here's one box: CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a49200600091a device_attach: est0 attach returned 6 p4tcc0: on cpu0 Here's another one: CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 720072006000720 device_attach: est0 attach returned 6 p4tcc0: on cpu0 SYSCTLs On the first one: dev.cpu.0.freq: 2786 dev.cpu.0.freq_levels: 2786/-1 2437/-1 2089/-1 1741/-1 1393/-1 1044/-1 696/-1 348/-1 Attempting to change dev.cpu.0.freq has no effect and says: sysctl: dev.cpu.0.freq: Invalid argument From yurtesen at ispro.net Wed Jun 4 22:39:15 2008 From: yurtesen at ispro.net (Evren Yurtesen) Date: Wed Jun 4 22:39:20 2008 Subject: cpufreq broken on core2duo In-Reply-To: <48471834.30905@modulus.org> References: <4847072E.5000709@ispro.net> <48470ED0.600@modulus.org> <484713B2.5030200@ispro.net> <48471834.30905@modulus.org> Message-ID: <484719B1.9030508@ispro.net> Andrew Snow wrote: > Evren Yurtesen wrote: > >> When you say that it doesnt work, does it give an error or? In my case >> it doesnt give any errors just says it set it but I see that nothing >> is set. > > Here's one box: > > CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz > cpu0: on acpi0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 61a49200600091a > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > > > Here's another one: > CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz > cpu0: on acpi0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 720072006000720 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > > > > SYSCTLs On the first one: > dev.cpu.0.freq: 2786 > dev.cpu.0.freq_levels: 2786/-1 2437/-1 2089/-1 1741/-1 1393/-1 1044/-1 > 696/-1 348/-1 > > Attempting to change dev.cpu.0.freq has no effect and says: > sysctl: dev.cpu.0.freq: Invalid argument > In one of the boxes I have there is an option in the bios where I can enable Intel Enhanced SpeedStep Technology. If I enable this to disabled in the bios then I get the same results as you are seeing. If I enable this in the bios then I get no errors but the processor speed doesnt change according to chkfreq from acpi_ppc http://www.spa.is.uec.ac.jp/~nfukuda/software/ Did you check the bios for this option? Another thing is that when I enable it from bios the cpufreq finds the processor to be 1500mhz (3000mhz in reality). You said you have an Athlon X2 box. Did you download http://www.spa.is.uec.ac.jp/~nfukuda/software/ and tried the chkfreq program which comes out with it to see if powerd is actually working? Because all I know is that you might be thinking that it is working but it might not be working at all. (I think acpi_ppc doesnt support dual core processors but chkfreq should give reliable results) Thanks, Evren From rsmith at xs4all.nl Wed Jun 4 22:53:21 2008 From: rsmith at xs4all.nl (Roland Smith) Date: Wed Jun 4 22:53:25 2008 Subject: cpufreq broken on core2duo (was: powerd is doing nothing?) In-Reply-To: <48471834.30905@modulus.org> References: <4847072E.5000709@ispro.net> <48470ED0.600@modulus.org> <484713B2.5030200@ispro.net> <48471834.30905@modulus.org> Message-ID: <20080604225312.GA2625@slackbox.xs4all.nl> On Thu, Jun 05, 2008 at 08:33:24AM +1000, Andrew Snow wrote: > Evren Yurtesen wrote: > > > When you say that it doesnt work, does it give an error or? In my case > > it doesnt give any errors just says it set it but I see that nothing is > > set. > > Here's one box: > > CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz > cpu0: on acpi0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 61a49200600091a > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > > > Here's another one: > CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz > cpu0: on acpi0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 720072006000720 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 I had this on a new core2 quad. Updating to a recent 7-STABLE fixed the issue for me. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080604/23b3d8aa/attachment-0001.pgp From yurtesen at ispro.net Wed Jun 4 23:09:06 2008 From: yurtesen at ispro.net (Evren Yurtesen) Date: Wed Jun 4 23:09:11 2008 Subject: cpufreq broken on core2duo In-Reply-To: <20080604225312.GA2625@slackbox.xs4all.nl> References: <4847072E.5000709@ispro.net> <48470ED0.600@modulus.org> <484713B2.5030200@ispro.net> <48471834.30905@modulus.org> <20080604225312.GA2625@slackbox.xs4all.nl> Message-ID: <484720AF.8000405@ispro.net> Roland Smith wrote: > On Thu, Jun 05, 2008 at 08:33:24AM +1000, Andrew Snow wrote: >> Here's another one: >> CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz >> cpu0: on acpi0 >> est0: on cpu0 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 720072006000720 >> device_attach: est0 attach returned 6 >> p4tcc0: on cpu0 > > I had this on a new core2 quad. Updating to a recent 7-STABLE fixed the > issue for me. Did any of you tried chkfreq which comes with acpi_ppc http://www.spa.is.uec.ac.jp/~nfukuda/software/ to check if the cpu frequency is actually changing? Thanks, Evren From freebsd at byshenk.net Wed Jun 4 23:22:12 2008 From: freebsd at byshenk.net (Greg Byshenk) Date: Wed Jun 4 23:22:15 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <48470C19.90709@daleco.biz> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net> <48470C19.90709@daleco.biz> Message-ID: <20080604232135.GD1381@core.byshenk.net> On Wed, Jun 04, 2008 at 04:41:45PM -0500, Kevin Kinsey wrote: > Clifton Royston wrote: > > For example, if I take a 6.3R CD, or build one for 6-RELENG, is there > >a way to do an "upgrade in place" on each server? Or would it work > >better to do a build from recent source on the development server, then > >export /usr/src and /usr/obj via NFS to the production servers and do > >the usual "make installkernel; reboot;" etc. sequence on them? (In my > >case I do have all machines on one GigE switch.) > I've heard of the latter being done with decent results. I can't say that it is "better", but I do the latter (well, actually I build on a test machine to make sure there are no problems, then sync to an NFS server and mount src and object from there, followed by installkernel-reboot-installworld-merge-reboot) on a number of different machines (currently runnign 6.3-STABLE of 2008-05-22 and 7.0-STABLE of 2008-05-27), and it is certainly faster and easier than doing a build on each individual machine. I do the same thing with ports, doing a 'portupgrade -p' on the build machine followed by a 'portupgrade -P' on the "clients" (building packages on the build machine, and then installing via my own packages on the others). Again, I can't say that it is "better", but it is certainly faster and easier. -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From jrhett at netconsonance.com Wed Jun 4 23:34:12 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed Jun 4 23:34:16 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4846D849.2090005@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> Message-ID: <80D7EE2D-A970-407B-A42C-AD17500BC463@netconsonance.com> On Jun 4, 2008, at 11:00 AM, Doug Barton wrote: >> But given that 6.3 is still experiencing bugs with things that are >> working fine and stable in 6.2, this is a pretty hard case to make. > > I admit to not having been following 6.x too closely, but are these > things that have been reported, or problems you're having personally? I go into the hardware and questions list and search for the hardware devices we use, and see problem reports. I see associated bugs, unclosed. I set aside upgrade for later ;-) >> This is also a fairly significant investment in terms of time and >> money for any business to handle this ugprade. > > Having an upgrade path is something every operation needs. "Set it > and forget it" isn't a viable strategy in the current culture where > 0-day vulnerabilities are becoming increasingly common. Absolutely not saying that. In fact, we had 6.3 upgrade on the books for April but when I looked in April there were still open bugs. I looked in late May and saw the same. So we punted to late June (because the original end of life was June 30th) and then suddenly we're getting messages every night saying that we're unsupported. So we're staying unsupported until 6.3 stabilizes obviously. That sucks. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From cliftonr at lava.net Wed Jun 4 23:39:06 2008 From: cliftonr at lava.net (Clifton Royston) Date: Wed Jun 4 23:39:10 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080604232135.GD1381@core.byshenk.net> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net> <48470C19.90709@daleco.biz> <20080604232135.GD1381@core.byshenk.net> Message-ID: <20080604233903.GA1146@lava.net> On Thu, Jun 05, 2008 at 01:21:35AM +0200, Greg Byshenk wrote: > On Wed, Jun 04, 2008 at 04:41:45PM -0500, Kevin Kinsey wrote: > > Clifton Royston wrote: > > > > For example, if I take a 6.3R CD, or build one for 6-RELENG, is there > > >a way to do an "upgrade in place" on each server? Or would it work > > >better to do a build from recent source on the development server, then > > >export /usr/src and /usr/obj via NFS to the production servers and do > > >the usual "make installkernel; reboot;" etc. sequence on them? (In my > > >case I do have all machines on one GigE switch.) > > > I've heard of the latter being done with decent results. > > I can't say that it is "better", but I do the latter (well, actually I > build on a test machine to make sure there are no problems, then sync > to an NFS server and mount src and object from there, followed by > installkernel-reboot-installworld-merge-reboot) Actually, yes, that's precisely what I was planning. I *do* at least have a separate development and test machine, apart from the main server cluster. > on a number of different > machines (currently runnign 6.3-STABLE of 2008-05-22 and 7.0-STABLE of > 2008-05-27), and it is certainly faster and easier than doing a build > on each individual machine. > > I do the same thing with ports, doing a 'portupgrade -p' on the build > machine followed by a 'portupgrade -P' on the "clients" (building > packages on the build machine, and then installing via my own packages > on the others). Again, I can't say that it is "better", but it is > certainly faster and easier. Thanks a lot for the feedback! I'll have to consider freebsd-update too; I simply haven't got used to its being available as an option. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From jrhett at netconsonance.com Wed Jun 4 23:46:09 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed Jun 4 23:46:16 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4846E14C.709@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> Message-ID: On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote: > Also, it's not like anyone should have been caught by surprise by > the 6.2 EoL; the expiry date has been advertised since the 6.2 > release itself. It has changed multiple times. I keep reviewing and finding 6.3 bugs outstanding, and then observe the EoL get pushed. I'm surprised that it failed to get pushed this time. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Wed Jun 4 23:48:22 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed Jun 4 23:48:28 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4846E637.9080101@samsco.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> Message-ID: On Jun 4, 2008, at 12:00 PM, Scott Long wrote: > Can you describe the bugs that are affecting you? gmirror failures, 3ware raid driver timeouts, bge0 problems. All three in production use on dozens of systems. >> This is also a fairly significant investment in terms of time and >> money for any business to handle this ugprade. It totally >> understand obsoleting 5.x now that 7.x is out. But 6.2 is barely a >> year old... > > The expectation is always that newer versions of a stable branch > will have few regressions, and thus upgrading is a low risk. That's my expectation as well. The 6.3 degression has been somewhat surprising. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Wed Jun 4 23:57:42 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed Jun 4 23:57:48 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080604234532.GA89656@k7.mavetju> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net> <20080604234532.GA89656@k7.mavetju> Message-ID: <458FE12C-AE4D-48F9-8193-4663079CEEF8@netconsonance.com> On Jun 4, 2008, at 4:45 PM, Edwin Groothuis wrote: > We have about 40 servers which were running 6.1 and 6.2 and the > seven busy ones (application servers which do mail and proxying, > and the database servers) hung *dead* every week. One per day. I'm sorry to hear that. Our servers have never hung with 6.2. Reboots only occurred to satisfy kernel security patches. But with 6.3 there are many open bug reports about our exact hardware, and I'd prefer to avoid swapping positions with you ;-0 -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From kris at FreeBSD.org Thu Jun 5 00:01:19 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu Jun 5 00:01:31 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> Message-ID: <48472CCF.8080101@FreeBSD.org> Jo Rhett wrote: > On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote: >> Also, it's not like anyone should have been caught by surprise by the >> 6.2 EoL; the expiry date has been advertised since the 6.2 release >> itself. > > > It has changed multiple times. I keep reviewing and finding 6.3 bugs > outstanding, and then observe the EoL get pushed. > > I'm surprised that it failed to get pushed this time. > I'm sorry that the FreeBSD project failed to conform to your expectations. However, I invite you to actually try 6.3 for yourself instead of assuming that it will fail. Kris From edwin at mavetju.org Thu Jun 5 00:01:37 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Thu Jun 5 00:01:45 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080604204325.GD4701@lava.net> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net> Message-ID: <20080604234532.GA89656@k7.mavetju> On Wed, Jun 04, 2008 at 10:43:27AM -1000, Clifton Royston wrote: > On Wed, Jun 04, 2008 at 11:00:41AM -0700, Doug Barton wrote: > > Jo Rhett wrote: > ... > > >But given that 6.3 is still experiencing bugs with things that > > >are working fine and stable in 6.2, this is a pretty hard case to make. > > > > I admit to not having been following 6.x too closely, but are these > > things that have been reported, or problems you're having personally? > > Speaking just for myself, I'd love to get a general response from > people who have run servers on both as to whether 6.3 is on average > more stable than 6.2. I really haven't gotten any clear impression as > to this, either from posts on -hackers or -stable, and I believe I > asked a couple times. I've seen comments that 6.3 should be > considerably more stable than 6.2, but also complaints about bugs such > as Jo is commenting on, and I have not seen much committed in the way > of errata fixes for 6.3 since its release. We have about 40 servers which were running 6.1 and 6.2 and the seven busy ones (application servers which do mail and proxying, and the database servers) hung *dead* every week. One per day. Luckely they were all redundant etc and remotely rebootable, but it was a nightmare for half a year. A handfull of patches (mutex-based) helped a lot, but still it was too much for my liking. The upgrade to 6.3 fixed *everything*, these seven servers now have uptimes of (since february) again. (The updates were scheduled in November as xmas-break updates, so imagine me getting more and more nervous when things got dragged out). So 6.3 saved my sanity :-) Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From scottl at samsco.org Thu Jun 5 00:05:13 2008 From: scottl at samsco.org (Scott Long) Date: Thu Jun 5 00:05:17 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> Message-ID: <48472DB6.5030909@samsco.org> Jo Rhett wrote: > On Jun 4, 2008, at 12:00 PM, Scott Long wrote: >> Can you describe the bugs that are affecting you? > > gmirror failures, 3ware raid driver timeouts, bge0 problems. All three > in production use on dozens of systems. > Give me specific details on the 3ware and bge problems. Scott From jrhett at netconsonance.com Thu Jun 5 00:22:19 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Jun 5 00:22:25 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <48472CCF.8080101@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> Message-ID: <7B3DA577-61F6-41D2-90B1-954E3A5A5C80@netconsonance.com> > Jo Rhett wrote: >> On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote: >>> Also, it's not like anyone should have been caught by surprise by >>> the 6.2 EoL; the expiry date has been advertised since the 6.2 >>> release itself. >> It has changed multiple times. I keep reviewing and finding 6.3 >> bugs outstanding, and then observe the EoL get pushed. >> I'm surprised that it failed to get pushed this time. > > I'm sorry that the FreeBSD project failed to conform to your > expectations. However, I invite you to actually try 6.3 for > yourself instead of assuming that it will fail. Several of the bug reports have the *exact* same hardware we are using. Rackable systems with 3ware controllers. If you're asking why I don't turn a production environment over to being a freebsd-unstable-testbed, I can't really answer that question in a way you'd understand (if you were asking that question) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Jun 5 00:24:50 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Jun 5 00:24:56 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <84EBEA5D3A1F47E79E8E12C4CF4D0314@multiplay.co.uk> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com><4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net><20080604234532.GA89656@k7.mavetju> <458FE12C-AE4D-48F9-8193-4663079CEEF8@netconsonance.com> <84EBEA5D3A1F47E79E8E12C4CF4D0314@multiplay.co.uk> Message-ID: On Jun 4, 2008, at 5:17 PM, Steven Hartland wrote: > I wouldn't be surprised if these are not new bugs, just something > that others have noticed later than 6.2 and I'd suggest you actually > try 6.3 to see if they are in fact an issue for you. I don't have the resources to load up the systems enough to find these problems sitting on my desk. And I can't risk production resources for problems known and reported on the *EXACT* same hardware. "oh but it won't happen to me" isn't a useful methodology in a production environment. I mean, seriously, I know the majority of you are happy rebooting your systems 5x daily to run the latest. I'll do that with my home system, no problem. But I can't do this in a production environment. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Jun 5 00:26:37 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Jun 5 00:26:42 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <48472DB6.5030909@samsco.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> Message-ID: <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> On Jun 4, 2008, at 5:05 PM, Scott Long wrote: > Jo Rhett wrote: >> On Jun 4, 2008, at 12:00 PM, Scott Long wrote: >>> Can you describe the bugs that are affecting you? >> gmirror failures, 3ware raid driver timeouts, bge0 problems. All >> three in production use on dozens of systems. > > Give me specific details on the 3ware and bge problems. Familiar with searching the open bug reports? That's where I found them. Sorry, I'm knee-deep in a major project that I've been working 16+ hours a day on right now, and I just don't have the time for spurious queries. Query the open bug reports for 6.3 and then explain to me again why 6.2 is no longer supported. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From killing at multiplay.co.uk Thu Jun 5 00:32:46 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Thu Jun 5 00:32:53 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com><4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net><20080604234532.GA89656@k7.mavetju> <458FE12C-AE4D-48F9-8193-4663079CEEF8@netconsonance.com> Message-ID: <84EBEA5D3A1F47E79E8E12C4CF4D0314@multiplay.co.uk> ----- Original Message ----- From: "Jo Rhett" > I'm sorry to hear that. Our servers have never hung with 6.2. > Reboots only occurred to satisfy kernel security patches. > > But with 6.3 there are many open bug reports about our exact hardware, > and I'd prefer to avoid swapping positions with you ;-0 I wouldn't be surprised if these are not new bugs, just something that others have noticed later than 6.2 and I'd suggest you actually try 6.3 to see if they are in fact an issue for you. We have been very happy with 6.2 here and we have quite a few machines using it. Apart from the very occasional crash when odd things like multi disk failures, they have all be solid. We won't however be upgrading to 6.3, instead we are moving to 7.0 which has again has been proved very stable here, but has the add benefit of a large amount of improvements especially in SMP performance. You may wish to consider this as an alternative after validation with your hardware / software of course :) 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 postmaster@multiplay.co.uk. From killing at multiplay.co.uk Thu Jun 5 00:32:46 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Thu Jun 5 00:32:54 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com><4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net><20080604234532.GA89656@k7.mavetju> <458FE12C-AE4D-48F9-8193-4663079CEEF8@netconsonance.com> <84EBEA5D3A1F47E79E8E12C4CF4D0314@multiplay.co.uk> Message-ID: <7B8FD1A1E7DA49DFA68252BF9C74AE6F@multiplay.co.uk> ----- Original Message ----- From: "Jo Rhett" > On Jun 4, 2008, at 5:17 PM, Steven Hartland wrote: >> I wouldn't be surprised if these are not new bugs, just something >> that others have noticed later than 6.2 and I'd suggest you actually >> try 6.3 to see if they are in fact an issue for you. > > I don't have the resources to load up the systems enough to find these > problems sitting on my desk. And I can't risk production resources > for problems known and reported on the *EXACT* same hardware. > > "oh but it won't happen to me" isn't a useful methodology in a > production environment. > > I mean, seriously, I know the majority of you are happy rebooting your > systems 5x daily to run the latest. I'll do that with my home system, > no problem. But I can't do this in a production environment. That's unfortunate. One thing you might want to check is are there any changes in those areas between 6.2 and 6.3 e.g. if its a bug with a specific driver but said driver has had no commits or not commits in the specific area then it may be fairly safe to conclude said bug also exists in 6.2 and if you haven't seen it there your unlikely to experience it in 6.3. Without any specifics people will be unable to comment. 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 postmaster@multiplay.co.uk. From edwin at mavetju.org Thu Jun 5 00:35:51 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Thu Jun 5 00:35:56 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <458FE12C-AE4D-48F9-8193-4663079CEEF8@netconsonance.com> <84EBEA5D3A1F47E79E8E12C4CF4D0314@multiplay.co.uk> Message-ID: <20080605003545.GP89632@k7.mavetju> On Wed, Jun 04, 2008 at 05:24:42PM -0700, Jo Rhett wrote: > On Jun 4, 2008, at 5:17 PM, Steven Hartland wrote: > >I wouldn't be surprised if these are not new bugs, just something > >that others have noticed later than 6.2 and I'd suggest you actually > >try 6.3 to see if they are in fact an issue for you. > > I don't have the resources to load up the systems enough to find these > problems sitting on my desk. And I can't risk production resources > for problems known and reported on the *EXACT* same hardware. > > "oh but it won't happen to me" isn't a useful methodology in a > production environment. > > I mean, seriously, I know the majority of you are happy rebooting your > systems 5x daily to run the latest. I'll do that with my home system, > no problem. But I can't do this in a production environment. Use the eat-your-own-food approach (while not knowing what the 500 systems do): Make sure you use the same hardware and software as what is in production. Upgrade it first, run it for two weeks. If it doesn't, fallback and see where it went wrong. If it all works fine after two weeks, roll it out. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From scottl at samsco.org Thu Jun 5 00:44:20 2008 From: scottl at samsco.org (Scott Long) Date: Thu Jun 5 00:44:25 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> Message-ID: <484736E0.6090004@samsco.org> Jo Rhett wrote: > > On Jun 4, 2008, at 5:05 PM, Scott Long wrote: >> Jo Rhett wrote: >>> On Jun 4, 2008, at 12:00 PM, Scott Long wrote: >>>> Can you describe the bugs that are affecting you? >>> gmirror failures, 3ware raid driver timeouts, bge0 problems. All >>> three in production use on dozens of systems. >> >> Give me specific details on the 3ware and bge problems. > > > Familiar with searching the open bug reports? That's where I found them. > > Sorry, I'm knee-deep in a major project that I've been working 16+ hours > a day on right now, and I just don't have the time for spurious > queries. Query the open bug reports for 6.3 and then explain to me > again why 6.2 is no longer supported. > Really, if it's such a big issue that you have time to bitch an moan on the mailing lists, I don't understand why you don't have time to also help a goddamned developer identify the problem. Are you actually experiencing problems with 6.3, or not? Scott From max at love2party.net Thu Jun 5 00:49:29 2008 From: max at love2party.net (Max Laier) Date: Thu Jun 5 00:49:34 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> Message-ID: <200806050248.59229.max@love2party.net> On Thursday 05 June 2008 02:26:29 Jo Rhett wrote: > On Jun 4, 2008, at 5:05 PM, Scott Long wrote: > > Jo Rhett wrote: > >> On Jun 4, 2008, at 12:00 PM, Scott Long wrote: > >>> Can you describe the bugs that are affecting you? > >> > >> gmirror failures, 3ware raid driver timeouts, bge0 problems. All > >> three in production use on dozens of systems. > > > > Give me specific details on the 3ware and bge problems. > > Familiar with searching the open bug reports? That's where I found > them. > > Sorry, I'm knee-deep in a major project that I've been working 16+ > hours a day on right now, and I just don't have the time for spurious > queries. Query the open bug reports for 6.3 and then explain to me > again why 6.2 is no longer supported. Because the people who support FreeBSD 6.2 are also knee-deep in major projects of their own!? We try try to not introduce regressions as we move forward supporting new features and hardware, but unless people put in some effort of their own helping us to test ... You obviously did not put in any effort of your own so why would you expect us to do the work for you? Unless you can provide "*EXACT*" bug reports and show willingness to help debugging them, there really is not much point in this thread. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From adrian at freebsd.org Thu Jun 5 01:27:38 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Thu Jun 5 01:27:41 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net> <20080604234532.GA89656@k7.mavetju> <458FE12C-AE4D-48F9-8193-4663079CEEF8@netconsonance.com> <84EBEA5D3A1F47E79E8E12C4CF4D0314@multiplay.co.uk> Message-ID: If this is so important to you - contribute to the project and/or hire a FreeBSD developer. (Ah, the Curse of Open Source Projects..) Adrian 2008/6/5 Jo Rhett : > > On Jun 4, 2008, at 5:17 PM, Steven Hartland wrote: >> >> I wouldn't be surprised if these are not new bugs, just something >> that others have noticed later than 6.2 and I'd suggest you actually >> try 6.3 to see if they are in fact an issue for you. > > I don't have the resources to load up the systems enough to find these > problems sitting on my desk. And I can't risk production resources for > problems known and reported on the *EXACT* same hardware. > > "oh but it won't happen to me" isn't a useful methodology in a production > environment. > > I mean, seriously, I know the majority of you are happy rebooting your > systems 5x daily to run the latest. I'll do that with my home system, no > problem. But I can't do this in a production environment. > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source and > other randomness > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Adrian Chadd - adrian@freebsd.org From jrhett at netconsonance.com Thu Jun 5 05:15:41 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Jun 5 05:15:48 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <7B8FD1A1E7DA49DFA68252BF9C74AE6F@multiplay.co.uk> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com><4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net><20080604234532.GA89656@k7.mavetju> <458FE12C-AE4D-48F9-8193-4663079CEEF8@netconsonance.com> <84EBEA5D3A1F47E79E8E12C4CF4D0314@multiplay.co.uk> <7B8FD1A1E7DA49DFA68252BF9C74AE6F@multiplay.co.uk> Message-ID: <1A050712-3D0F-4263-A9F8-EE4AD042486E@netconsonance.com> On Jun 4, 2008, at 5:30 PM, Steven Hartland wrote: > That's unfortunate. One thing you might want to check is are there > any changes in those areas between 6.2 and 6.3 e.g. if its a bug > with a specific driver but said driver has had no commits or > not commits in the specific area then it may be fairly safe to > conclude said bug also exists in 6.2 and if you haven't seen it > there your unlikely to experience it in 6.3. The bugs in question are *not* replicable in 6.2, and each of the bug reports has said so. This is the major point of concern for us. What happened between 6.2 and 6.3 to break so many drivers? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Jun 5 05:19:06 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Jun 5 05:19:11 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080605003545.GP89632@k7.mavetju> References: <458FE12C-AE4D-48F9-8193-4663079CEEF8@netconsonance.com> <84EBEA5D3A1F47E79E8E12C4CF4D0314@multiplay.co.uk> <20080605003545.GP89632@k7.mavetju> Message-ID: <13A3FC54-B459-48C5-85CD-14CC38913838@netconsonance.com> On Jun 4, 2008, at 5:35 PM, Edwin Groothuis wrote: > Use the eat-your-own-food approach (while not knowing what the 500 > systems do): Make sure you use the same hardware and software as > what is in production. Upgrade it first, run it for two weeks. If > it doesn't, fallback and see where it went wrong. If it all works > fine after two weeks, roll it out. Edwin, I've been building testbed environments for over 20 years in my professional career. I know a lot more than this basic concept. The costs in our environment for a proper testbed is $20k in hardware and 3000 man hours. That's for a small test of comparable small changes to the existing environment. Why would we take on this cost only to re-document well known and already acknowledged bugs? I mean, really? Not trying to be sarcastic, but do you purchase cars to test them out and see if you can get better gas mileage than the EPA observes? Neither do I ;-) (yes, their testing methodology is flawed but it's a decent enough benchmark to know if you want the vehicle or not) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Jun 5 05:22:36 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Jun 5 05:22:44 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <200806050248.59229.max@love2party.net> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> Message-ID: On Jun 4, 2008, at 5:48 PM, Max Laier wrote: > Because the people who support FreeBSD 6.2 are also knee-deep in major > projects of their own!? We try try to not introduce regressions as we > move forward supporting new features and hardware, but unless people > put > in some effort of their own helping us to test ... > > You obviously did not put in any effort of your own so why would you > expect us to do the work for you? Unless you can provide "*EXACT*" > bug > reports and show willingness to help debugging them, there really is > not > much point in this thread. The bugs in question were very well documented. None of them were in a state indicating that the developer could not reproduce nor were they waiting for more info. Given that situation, I didn't see a need to add more to a known problem. *IF* any of them had been looking for test cases, I would have been happy to build a test system and turn it over to the developer in question. We do that fairly routinely. And please stop with the loaded language. I'm not asking anyone to work for me. I am suggesting that it is perhaps too early to EoL 6.2 because 6.3 isn't ready yet. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Jun 5 05:24:30 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Jun 5 05:24:35 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <484736E0.6090004@samsco.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <484736E0.6090004@samsco.org> Message-ID: <74EB4162-74CB-4591-B7E5-8156BB56C29E@netconsonance.com> On Jun 4, 2008, at 5:44 PM, Scott Long wrote: > Really, if it's such a big issue that you have time to bitch an moan > on the mailing lists, I don't understand why you don't have time to > also > help a goddamned developer identify the problem. Are you actually > experiencing problems with 6.3, or not? None of the bugs were in a state with the developer trying to identify the system. We have several systems dedicated for FreeBSD developers to use for test cases already, and we'd be happy to provide another if one was necessary. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Jun 5 05:33:32 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Jun 5 05:33:37 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <484736E0.6090004@samsco.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <484736E0.6090004@samsco.org> Message-ID: I'm going to be offline for a week starting now, so please don't read my lack of answers as anything other than "out of town". Sorry. For clarity: I'm not asking for anyone to fix anything. I honestly believe most developers are addressing problems as fast as they can. I'd help them in any way I could. I am suggesting that given that the current bug list for 6.3-RELEASE is both (a) too large and (b) breaks things that work fine in 6.2 ... that I think pushing 6.2 (the real stable release) into EoL is a bit rushed. I sympathize with the development costs of maintaining old versions. Again, I will help in any way I can. On my return next week I would happily build and provide 6.3-RELEASE systems for any developer who needs a test environment for reported bugs that affect hardware I have in my possession. Free boxes, free bandwidth, power, etc. No problem. Free my time in whatever way I can help. But until such time as the current bug list for 6.3 hardware reduces to somewhere less than 100% likelyhood of experiencing failures after an upgrade, there's just no way I can take our production environment forward. Going "bravely forward" to guaranteed failure isn't a great way to enjoy your job :-( Which means I'll be doing our security patches by hand. Because it may be time intensive, but it's less likely to cause a production failure. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From torfinn.ingolfsen at broadpark.no Thu Jun 5 06:03:49 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Thu Jun 5 06:03:54 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <13A3FC54-B459-48C5-85CD-14CC38913838@netconsonance.com> References: <458FE12C-AE4D-48F9-8193-4663079CEEF8@netconsonance.com> <84EBEA5D3A1F47E79E8E12C4CF4D0314@multiplay.co.uk> <20080605003545.GP89632@k7.mavetju> <13A3FC54-B459-48C5-85CD-14CC38913838@netconsonance.com> Message-ID: <20080605080344.f99347ec.torfinn.ingolfsen@broadpark.no> On Wed, 04 Jun 2008 22:19:03 -0700 Jo Rhett wrote: > Edwin, I've been building testbed environments for over 20 years in > my professional career. I know a lot more than this basic concept. > > The costs in our environment for a proper testbed is $20k in > hardware and 3000 man hours. That's for a small test of comparable > small changes to the existing environment. > > Why would we take on this cost only to re-document well known and > already acknowledged bugs? I mean, really? I'm surprised that a test environment (for upgrade testing, load testing, release testing) isn't already in place. Some people (customers and operators alike) might think it is unprofessional and unsafe to run a production system without a test system available. If you have a test system available, why don't you use it? -- Regards, Torfinn Ingolfsen From alfred at freebsd.org Thu Jun 5 06:35:39 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Thu Jun 5 06:35:43 2008 Subject: Interrupt storm with shared interrupt on digi(4) In-Reply-To: <200806041044.01712.jhb@freebsd.org> References: <20080603070840.GH1028@server.vk2pj.dyndns.org> <200806031021.35416.jhb@freebsd.org> <20080603190418.GP1028@server.vk2pj.dyndns.org> <200806041044.01712.jhb@freebsd.org> Message-ID: <20080605061931.GF48790@elvis.mu.org> * John Baldwin [080604 11:12] wrote: > On Tuesday 03 June 2008 03:04:18 pm Peter Jeremy wrote: > > BTW, your MUA's list-reply configuration don't recognize that > > freebsd-stable@ and stable@ are aliases. > > Yes, kmail is broken and the authors refuse to fix it. It happens on reply to > a foo@ e-mail (it changes the 'To' to 'freebsd-foo@' because of the List-Id > header and leaves foo@ in the 'CC' field). Note that there isn't anything in > the List headers that says that foo@ is an alias for freebsd-foo@. I just > wish I could turn off the List-Id crap and use plain old reply-to-all, but > that is where the kmail developers disagree. wtf.....why not just have a checkbox to toggle the behavior? -- - Alfred Perlstein From avg at icyb.net.ua Thu Jun 5 07:45:10 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Jun 5 07:45:20 2008 Subject: mystery: lock up after fs dump In-Reply-To: <20080604161001.GF63348@deviant.kiev.zoral.com.ua> References: <4846AFC3.3050101@icyb.net.ua> <20080604152332.GE63348@deviant.kiev.zoral.com.ua> <4846B5D9.1050903@icyb.net.ua> <20080604161001.GF63348@deviant.kiev.zoral.com.ua> Message-ID: <4847997D.4060404@icyb.net.ua> on 04/06/2008 19:10 Kostik Belousov said the following: > SU are irrelevant to the problem I am thinking of. > > vfs_write_suspend() returns 0 when the filesystem being suspended is already > in suspend state. vfs_write_resume() clears the suspend state. > > vfs_write_suspend/vfs_write_resume are used both by snapshot code and > the gjournal. If two users of these interfaces interleave, then you could > get: > > thread1 thread2 > > vfs_write_suspend() > <- fs is suspended there > vfs_write_suspend() <- returns 0 > vfs_write_resume() > <- fs is no more suspended > thread2 is burned in flame > > Snapshots are protected against this because they are created through > the mount(2). The mount(2) locks the covered vnode and thus serializes > snapshot creation (I think there are further serialization points that > prevent simultaneous snapshotting of the same fs). > > There is nothing I can see that protects snapshots/gjournal interaction. Looks like something to be quite concerned about. Thank you for the analysis. -- Andriy Gapon From peterjeremy at optushome.com.au Thu Jun 5 08:39:12 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Thu Jun 5 08:39:19 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> Message-ID: <20080605083907.GD1028@server.vk2pj.dyndns.org> On 2008-Jun-04 22:22:33 -0700, Jo Rhett wrote: >And please stop with the loaded language. I'm not asking anyone to work >for me. I am suggesting that it is perhaps too early to EoL 6.2 because >6.3 isn't ready yet. So you have stated. When asked to provide evidence to backup that statement, you have refused. Since you are the one claiming that "6.3 isn't ready yet", the onus is on you to put up or shut up. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080605/a9109de8/attachment.pgp From killing at multiplay.co.uk Thu Jun 5 09:47:55 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Thu Jun 5 09:47:59 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com><48472DB6.5030909@samsco.org><6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com><200806050248.59229.max@love2party.net> Message-ID: ----- Original Message ----- From: "Jo Rhett" > The bugs in question were very well documented. None of them were in > a state indicating that the developer could not reproduce nor were > they waiting for more info. Given that situation, I didn't see a > need to add more to a known problem. > > *IF* any of them had been looking for test cases, I would have been > happy to build a test system and turn it over to the developer in > question. We do that fairly routinely. > > And please stop with the loaded language. I'm not asking anyone to > work for me. I am suggesting that it is perhaps too early to EoL 6.2 > because 6.3 isn't ready yet. You are still fail to take to the time to even tell people what these bugs are, no ones a mind reader! People are trying to help you here but all I'm hearing is a child like "It doesn't work fix it", with no willingness to even explain what it is or provide resources to test if someone found the time to investigate your issues. Given this I don't see how you can expect these so called issues to ever get fixed. 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 postmaster@multiplay.co.uk. From doconnor at gsoft.com.au Thu Jun 5 10:25:09 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Jun 5 10:25:16 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <84EBEA5D3A1F47E79E8E12C4CF4D0314@multiplay.co.uk> Message-ID: <200806051926.01116.doconnor@gsoft.com.au> On Thu, 5 Jun 2008, Jo Rhett wrote: > I mean, seriously, I know the majority of you are happy rebooting > your systems 5x daily to run the latest. I'll do that with my home > system, no problem. But I can't do this in a production environment. I have 3ware based RELENG_6 systems running without trouble but I don't load them very much. I think the only way forward would be to do a binary search to find the broken code - that means someone who experiences the problem needs to do the testing... I know doing a binary search IS a PITA timewise but since noone seems to know what the underlying problem is it would seem to be the only way forward. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080605/49292a4f/attachment.pgp From adrian at freebsd.org Thu Jun 5 11:34:19 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Thu Jun 5 11:34:23 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <1A050712-3D0F-4263-A9F8-EE4AD042486E@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net> <20080604234532.GA89656@k7.mavetju> <458FE12C-AE4D-48F9-8193-4663079CEEF8@netconsonance.com> <84EBEA5D3A1F47E79E8E12C4CF4D0314@multiplay.co.uk> <7B8FD1A1E7DA49DFA68252BF9C74AE6F@multiplay.co.uk> <1A050712-3D0F-4263-A9F8-EE4AD042486E@netconsonance.com> Message-ID: 2008/6/5 Jo Rhett : > > The bugs in question are *not* replicable in 6.2, and each of the bug > reports has said so. > > This is the major point of concern for us. What happened between 6.2 and > 6.3 to break so many drivers? > If its of major concern for you, then allocate some man hours, grab the /usr/src/sys diffs between RELENG_6_2_0_RELEASE and RELENG_6_3_0_RELEASE. The others on the list have stated over and over again that they haven't seen any issues and would like to know precisely what they are. The diff between 6.2 and 6.3 /usr/src/sys is ~ 440,000 lines in total. I can put the diff online for you if you'd like. If stability is your main concern then you could throw some resources at fixing 6.3 or throw some resources at backporting security fixes to 6.2. I'm sure noone has an agenda to squish the FreeBSD version you're using for any reason other than there aren't enough people volunteering / being paid to work on back-porting security fixes. 2c, Adrian -- Adrian Chadd - adrian@freebsd.org From bms at FreeBSD.org Thu Jun 5 12:03:07 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Jun 5 12:06:26 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <484736E0.6090004@samsco.org> Message-ID: <4847D5F8.80605@FreeBSD.org> Jo Rhett wrote: > > I am suggesting that given that the current bug list for 6.3-RELEASE > is both (a) too large and (b) breaks things that work fine in 6.2 ... > that I think pushing 6.2 (the real stable release) into EoL is a bit > rushed. I sympathize with the development costs of maintaining old > versions. Again, I will help in any way I can. I'm sorry to hear about the problems you've been having. It is worth remembering that FreeBSD is an open source project, and it's maintained on a best-effort basis -- it is offered for free and without any warranty. Like any other open source project, risk management and change management becomes a two-way street, because that's the trade-off struck with the open source model. The risks, as well as the benefits, have to be factored in carefully to your company's technology strategy, as I'm sure you're aware. I'm very surprised that the 6.3 train has been a big issue for you, although speaking from the development side of the fence, there are a lot of moving targets, and vendor support of the OS does play a part. It is difficult to offer any more specific advice without knowing in more detail exactly what's causing such problems for you, although I see you've offered general pointers, the folk directly involved need to be pointed at direct information. The FreeBSD Project just doesn't have the resources to do compatibility testing on the scale of e.g. Windows Hardware Quality Labs, as I'm sure you are also aware. I take on board what you say about your organisation holding back on an upgrade because there are PRs filed for the hardware you use, and having worked in an investment banking environment, I understand this level of conservatism is warranted. However, I point out again: it's the open source model, and where hardware compatibility is concerned, it really is a case of "suck it and see". Always has been, no different anywhere else. Open source requires user participation. Microsoft run the WHQL because their status as a going concern depends on it. I'm pleased to hear about your offer of hardware resources for developers. However, this is only part of the problem. To my mind, you need to find the right people, with the right skills, to deal with the issues, and quite often, those guys are already in demand, and thus their time can attract a high value. Open source succeeds because money is not the only motivation. The alternative is DIY, and that is "the point". If you need firm guarantees about support, consider contracting with someone to do that. Many companies using FreeBSD already outsource this kind of support requirement to 3rd parties. There are also FreeBSD hardware vendors who support FreeBSD as a platform. If you want someone to take responsibility, make 'em an offer. thanks, BMS From koitsu at FreeBSD.org Thu Jun 5 12:51:05 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Jun 5 12:51:13 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4847D5F8.80605@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <484736E0.6090004@samsco.org> <4847D5F8.80605@FreeBSD.org> Message-ID: <20080605125105.GA79727@eos.sc1.parodius.com> On Thu, Jun 05, 2008 at 01:03:04PM +0100, Bruce M. Simpson wrote: > Jo Rhett wrote: >> >> I am suggesting that given that the current bug list for 6.3-RELEASE is >> both (a) too large and (b) breaks things that work fine in 6.2 ... that I >> think pushing 6.2 (the real stable release) into EoL is a bit rushed. I >> sympathize with the development costs of maintaining old versions. Again, >> I will help in any way I can. > > I'm sorry to hear about the problems you've been having. If the exact regression between 6.2 and 6.3 can be tracked down, great. If it's in a specific driver, CVS commit logs or cvsweb will come in handy. Otherwise, if it's some larger piece of code ("ohai i revamped the intrupt handlar!"), chances of finding it are slimmer. I'm a bit disappointed that Jo hasn't explicitly mentioned what's broken in 6.3 that's affecting him, because that might help everyone. Heck, I'll even add it to my Commonly reported issue wiki page. PRs would be good, but I'll gladly take past mailing list discussions. Jo's opinion is reasonable, but the bottom line is that the FreeBSD Project folks will always win the argument once the "it's best-effort" trump card is played; the convo has to end once it's on the table. I consider myself an advocate of open-source, but simultaneously, was raised as a child to take responsibility for things I bring unto others. I do not publicly release code/binaries for things I do not wish to provide support for. Likewise, bugs in my software are my fault, thus thus my responsibility to fix. The FreeBSD Project does things differently than how I do. I have a hard time understanding the opposing view, but every time it comes up, I try a little harder to be open-minded about it. Jo, as we share somewhat of the same viewpoint, I'll mention that it would be within our best interest to try and understand the other viewpoint, and hope that the results of (positive) karma are seen down the road someday. > If you want someone to take responsibility, make 'em an offer. In my case, with some FreeBSD bugs in the past, I have offered monetary compensation (hourly wages, reasonable by Bay Area standards) to developers to fix issues -- only to receive absolutely no response. Offering monetary compensation is not a solution, and I believe that's because the core problem isn't lack of pay -- it's lack of time. That's one which is really hard to solve, no matter what the conditions of an open-source project. On the other hand, there was the "donation thing" phk@ did when he was out of work, which I felt was great. I still feel good about donating to that. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From des at des.no Thu Jun 5 13:16:51 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Jun 5 13:17:00 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <80D7EE2D-A970-407B-A42C-AD17500BC463@netconsonance.com> (Jo Rhett's message of "Wed\, 4 Jun 2008 16\:34\:04 -0700") References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <80D7EE2D-A970-407B-A42C-AD17500BC463@netconsonance.com> Message-ID: <861w3cf2pj.fsf@ds4.des.no> Jo Rhett writes: > Absolutely not saying that. In fact, we had 6.3 upgrade on the books > for April but when I looked in April there were still open bugs. I > looked in late May and saw the same. So we punted to late June > (because the original end of life was June 30th) and then suddenly > we're getting messages every night saying that we're unsupported. The EoL for 6.2 was never June 30th. It was originally set to January 31st when 6.2 was released, then extended by four months to May 31st. If you have issues with 6.3, your time would be better spent reporting them (by which I mean describe them in detail) than waving your hands in the air and yelling at people. DES -- Dag-Erling Sm?rgrav - des@des.no From hausen at punkt.de Thu Jun 5 13:18:07 2008 From: hausen at punkt.de (Patrick M. Hausen) Date: Thu Jun 5 13:18:09 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080605125105.GA79727@eos.sc1.parodius.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <484736E0.6090004@samsco.org> <4847D5F8.80605@FreeBSD.org> <20080605125105.GA79727@eos.sc1.parodius.com> Message-ID: <20080605130320.GC40682@hugo10.ka.punkt.de> Hi, all, On Thu, Jun 05, 2008 at 05:51:05AM -0700, Jeremy Chadwick wrote: > On Thu, Jun 05, 2008 at 01:03:04PM +0100, Bruce M. Simpson wrote: > > Jo Rhett wrote: > >> > >> I am suggesting that given that the current bug list for 6.3-RELEASE is > >> both (a) too large and (b) breaks things that work fine in 6.2 ... that I > >> think pushing 6.2 (the real stable release) into EoL is a bit rushed. I > >> sympathize with the development costs of maintaining old versions. Again, > >> I will help in any way I can. > > > > I'm sorry to hear about the problems you've been having. > > If the exact regression between 6.2 and 6.3 can be tracked down, great. > If it's in a specific driver, CVS commit logs or cvsweb will come in > handy. Otherwise, if it's some larger piece of code ("ohai i revamped > the intrupt handlar!"), chances of finding it are slimmer. I'm a bit > disappointed that Jo hasn't explicitly mentioned what's broken in 6.3 > that's affecting him, because that might help everyone. Heck, I'll even > add it to my Commonly reported issue wiki page. PRs would be good, but > I'll gladly take past mailing list discussions. Since we, too, use quite a few machines in production, most of them 6.3 BTW, i spent some time searching the PRs with the keyword "3ware" and varying combinations of release, severity, etc. I was not able to find anything with respect to that hardware that wasn't recorded as early as 6.1. em0 lockups were fixed around 6.1 for us with Jack Vogels kind assistance (and hardware provided by us ;-) Kind regards, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J?rgen Egeling AG Mannheim 108285 From des at des.no Thu Jun 5 13:21:51 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Jun 5 13:21:55 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: (Jo Rhett's message of "Wed\, 4 Jun 2008 16\:46\:01 -0700") References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> Message-ID: <8663sof2v1.fsf@ds4.des.no> Jo Rhett writes: > It has changed multiple times. I keep reviewing and finding 6.3 bugs > outstanding, and then observe the EoL get pushed. The EoL date for 6.2 was pushed back *once* and once only, and that was not in response to any specific bug report. See for yourself: http://www.freebsd.org/cgi/cvsweb.cgi/www/en/security/security.sgml DES -- Dag-Erling Sm?rgrav - des@des.no From cmarlatt at rxsec.com Thu Jun 5 14:18:58 2008 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Thu Jun 5 14:19:07 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <48472CCF.8080101@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> Message-ID: <4847EF62.1070709@rxsec.com> Kris Kennaway wrote: > Jo Rhett wrote: >> On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote: >>> Also, it's not like anyone should have been caught by surprise by the >>> 6.2 EoL; the expiry date has been advertised since the 6.2 release >>> itself. >> >> >> It has changed multiple times. I keep reviewing and finding 6.3 bugs >> outstanding, and then observe the EoL get pushed. >> >> I'm surprised that it failed to get pushed this time. >> > > I'm sorry that the FreeBSD project failed to conform to your > expectations. However, I invite you to actually try 6.3 for yourself > instead of assuming that it will fail. > > Kris In an effort to potentially find a compromise between those who believe FreeBSD is EoL'ing previous releases too quickly and those who don't. Have those in a position to set FreeBSD release schedules debated the option of setting a long term support release, a specific release picked by the team to be support for,.. 4 or 5 years? Other projects have done this will relative success and considering the "only" work required for this release would be security patches the work load should be minimized. Hopefully something like this could free up more time for the FreeBSD developers to continue their work on the newer release(s) while still answering the requests of what seems like quite a few of the legacy FreeBSD users. Thoughts? If this has already been discussed on-list I apologize for beating a dead horse but I can't recall it bring brought up before. Regards, Chris From kris at FreeBSD.org Thu Jun 5 14:28:37 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu Jun 5 14:28:44 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4847EF62.1070709@rxsec.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> Message-ID: <4847F814.10409@FreeBSD.org> Chris Marlatt wrote: > Kris Kennaway wrote: >> Jo Rhett wrote: >>> On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote: >>>> Also, it's not like anyone should have been caught by surprise by >>>> the 6.2 EoL; the expiry date has been advertised since the 6.2 >>>> release itself. >>> >>> >>> It has changed multiple times. I keep reviewing and finding 6.3 bugs >>> outstanding, and then observe the EoL get pushed. >>> >>> I'm surprised that it failed to get pushed this time. >>> >> >> I'm sorry that the FreeBSD project failed to conform to your >> expectations. However, I invite you to actually try 6.3 for yourself >> instead of assuming that it will fail. >> >> Kris > > In an effort to potentially find a compromise between those who believe > FreeBSD is EoL'ing previous releases too quickly and those who don't. > Have those in a position to set FreeBSD release schedules debated the > option of setting a long term support release, a specific release picked > by the team to be support for,.. 4 or 5 years? Other projects have done > this will relative success and considering the "only" work required for > this release would be security patches the work load should be > minimized. Hopefully something like this could free up more time for the > FreeBSD developers to continue their work on the newer release(s) while > still answering the requests of what seems like quite a few of the > legacy FreeBSD users. Thoughts? > > If this has already been discussed on-list I apologize for beating a > dead horse but I can't recall it bring brought up before. Uh yeah, this has been in place for *years*. Have you actually read the support announcements? They are public ;) Kris From gonzo at freebsd.org Thu Jun 5 14:44:33 2008 From: gonzo at freebsd.org (Oleksandr Tymoshenko) Date: Thu Jun 5 14:44:39 2008 Subject: Crashes in devfs. Possibly on interface creation/destruction. In-Reply-To: <48470853.6080807@FreeBSD.org> References: <48470853.6080807@FreeBSD.org> Message-ID: <4847E2A4.2020509@freebsd.org> Alexander Motin wrote: > Hi. > > After recent upgrading from 6.3-RC1/mpd-5.0rc1 to 6.3-STABLE/mpd-5.1 > some of my PPPoE servers started to crash with about weekly period. > Usually they just just hang without rebooting and core dumping. Consoles > are inaccessible. All I have got from them was: > > kernel: Fatal trap 12: page fau > kernel: lt while in k > kernel: ernel > kernel: mode > kernel: > kernel: cpuid = 1; apic id = 01 > kernel: faut virtual address = 0x58 > kernel: > kernel: fault code = supervisor read, page not present > kernel: > kernel: instruction pointer = 0x20:0xc04800be > kernel: > kernel: stack pointer = 0x28:0xd690883c > kernel: frame pointer = 0x28:0 > kernel: xd6908854 > kernel: code segment = > kernel: base 0x0, limit 0xfffff, type 0x1b > kernel: > kernel: = DPL 0, pres 1, def32 1, gra > kernel: n 1 > kernel: processor eflags = interrupt > kernel: enab > kernel: led, r > kernel: esume > kernel: , IOPL > kernel: = 0 > kernel: > kernel: current process = 1835 (mpd5) > kernel: > kernel: trap number = 12 > > "fault virtual address" and "instruction pointer" are always the same. > > Address 0xc04800be looks like part of devfs code: > > addr2line -f -e kernel.debug 0xc04800be > devfs_populate_loop > /usr/src/sys/fs/devfs/devfs_devs.c:443 > > devfs_devs.c: > de = devfs_newdirent(s, q - s); > if (cdp->cdp_c.si_flags & SI_ALIAS) { > de->de_uid = 0; > de->de_gid = 0; > de->de_mode = 0755; > de->de_dirent->d_type = DT_LNK; > pdev = cdp->cdp_c.si_parent; > ->> line 443 ->> j = strlen(pdev->si_name) + 1; > de->de_symlink = malloc(j, M_DEVFS, M_WAITOK); > bcopy(pdev->si_name, de->de_symlink, j); > > 0x58 - is precisely the offset of si_name field inside of struct cdev. > So looks like pdev = cdp->cdp_c.si_parent is NULL here for some reason. > > As soon as network interfaces have respective devfs entries and looking > higher interface creation/destruction rate that newest mpd5.1 is able to > reach due to optimizations, I think it may be some kind or race > somewhere interface creation. > > Can somebody give me any hint where to look to? On a quick glance the most likely place is make_dev_alias call in net/if.c line 457. And the most likely suspect is race for if_index variable. There are even a couple of "XXX: should be locked" notes there :) -- gonzo From cmarlatt at rxsec.com Thu Jun 5 14:46:15 2008 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Thu Jun 5 14:46:21 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4847F814.10409@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> Message-ID: <4847FB1D.1050400@rxsec.com> Kris Kennaway wrote: > Chris Marlatt wrote: >> Kris Kennaway wrote: >>> Jo Rhett wrote: >>>> On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote: >>>>> Also, it's not like anyone should have been caught by surprise by >>>>> the 6.2 EoL; the expiry date has been advertised since the 6.2 >>>>> release itself. >>>> >>>> >>>> It has changed multiple times. I keep reviewing and finding 6.3 >>>> bugs outstanding, and then observe the EoL get pushed. >>>> >>>> I'm surprised that it failed to get pushed this time. >>>> >>> >>> I'm sorry that the FreeBSD project failed to conform to your >>> expectations. However, I invite you to actually try 6.3 for yourself >>> instead of assuming that it will fail. >>> >>> Kris >> >> In an effort to potentially find a compromise between those who >> believe FreeBSD is EoL'ing previous releases too quickly and those who >> don't. Have those in a position to set FreeBSD release schedules >> debated the option of setting a long term support release, a specific >> release picked by the team to be support for,.. 4 or 5 years? Other >> projects have done this will relative success and considering the >> "only" work required for this release would be security patches the >> work load should be minimized. Hopefully something like this could >> free up more time for the FreeBSD developers to continue their work on >> the newer release(s) while still answering the requests of what seems >> like quite a few of the legacy FreeBSD users. Thoughts? >> >> If this has already been discussed on-list I apologize for beating a >> dead horse but I can't recall it bring brought up before. > > Uh yeah, this has been in place for *years*. Have you actually read the > support announcements? They are public ;) > > Kris I do actually - and when was the last release that was support for such a duration of time,.. 4.11? As of recent the longest I've seen has been 24 months with others being only 12. Regards, Chris From jhb at freebsd.org Thu Jun 5 14:57:10 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Jun 5 14:57:16 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> Message-ID: <200806051023.56065.jhb@freebsd.org> On Wednesday 04 June 2008 01:20:56 pm Jo Rhett wrote: > Okay, I totally understand that FreeBSD wants people to upgrade from > 6.2 to 6.3. But given that 6.3 is still experiencing bugs with things > that are working fine and stable in 6.2, this is a pretty hard case to > make. > > This is also a fairly significant investment in terms of time and > money for any business to handle this ugprade. It totally understand > obsoleting 5.x now that 7.x is out. But 6.2 is barely a year old... FWIW, at Y! 6.3 is more stable than 6.2 (I had a list of about 10 patches for known deadlocks and kernel panics that were errata candidates for 6.2 that never made it into RELENG_6_2 but all of them are in 6.3). We also have many machines with bge(4) and from our perspective 6.3 has less issues with bge0 devices than 6.2. Given the real world experience I have, your claims of instability w/o even testing 6.3 border on silly. Also, when it comes to bge(4), you need to be _very_ specific about what chipsets you are using and comparing those with the chipsets in the bug reports you read. The bge(4) driver in particular covers a vast range of different hardware variations and is a bit of a hodge-podge itself. If there is a problem with a 5705 card then it may be specific to just 5705 parts and not affect 575x, etc. parts. Again, with 3ware, there are two different drivers (twe(4) vs twa(4)) and again, you need to be more specific with which driver you are using and which model controllers you have. -- John Baldwin From jhb at freebsd.org Thu Jun 5 14:57:18 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Jun 5 14:57:21 2008 Subject: cpufreq broken on core2duo (was: powerd is doing nothing?) In-Reply-To: <48471834.30905@modulus.org> References: <4847072E.5000709@ispro.net> <484713B2.5030200@ispro.net> <48471834.30905@modulus.org> Message-ID: <200806051040.28319.jhb@freebsd.org> On Wednesday 04 June 2008 06:33:24 pm Andrew Snow wrote: > Evren Yurtesen wrote: > > > When you say that it doesnt work, does it give an error or? In my case > > it doesnt give any errors just says it set it but I see that nothing is > > set. > > Here's one box: > > CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz > cpu0: on acpi0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 61a49200600091a > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > > > Here's another one: > CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz > cpu0: on acpi0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 720072006000720 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 You can try http://www.FreeBSD.org/~jhb/patches/est_msr.patch. It won't give you the full range of speeds for you CPU, but it should give you the high and low values that we can guess from the upper 32-bits of the MSR. -- John Baldwin From jhb at freebsd.org Thu Jun 5 14:57:25 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Jun 5 14:57:32 2008 Subject: Interrupt storm with shared interrupt on digi(4) In-Reply-To: <20080605061931.GF48790@elvis.mu.org> References: <20080603070840.GH1028@server.vk2pj.dyndns.org> <200806041044.01712.jhb@freebsd.org> <20080605061931.GF48790@elvis.mu.org> Message-ID: <200806051051.05495.jhb@freebsd.org> On Thursday 05 June 2008 02:19:31 am Alfred Perlstein wrote: > * John Baldwin [080604 11:12] wrote: > > On Tuesday 03 June 2008 03:04:18 pm Peter Jeremy wrote: > > > BTW, your MUA's list-reply configuration don't recognize that > > > freebsd-stable@ and stable@ are aliases. > > > > Yes, kmail is broken and the authors refuse to fix it. It happens on reply to > > a foo@ e-mail (it changes the 'To' to 'freebsd-foo@' because of the List-Id > > header and leaves foo@ in the 'CC' field). Note that there isn't anything in > > the List headers that says that foo@ is an alias for freebsd-foo@. I just > > wish I could turn off the List-Id crap and use plain old reply-to-all, but > > that is where the kmail developers disagree. > > wtf.....why not just have a checkbox to toggle the behavior? That was my request (and I found at least 2 other open bugs for the same issue when I looked again yesterday). The developers reply was "an option is not an option". -- John Baldwin From jhb at freebsd.org Thu Jun 5 14:57:44 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Jun 5 14:57:47 2008 Subject: cpufreq broken on core2duo In-Reply-To: <484720AF.8000405@ispro.net> References: <4847072E.5000709@ispro.net> <20080604225312.GA2625@slackbox.xs4all.nl> <484720AF.8000405@ispro.net> Message-ID: <200806051056.55675.jhb@freebsd.org> On Wednesday 04 June 2008 07:09:35 pm Evren Yurtesen wrote: > Roland Smith wrote: > > On Thu, Jun 05, 2008 at 08:33:24AM +1000, Andrew Snow wrote: > >> Here's another one: > >> CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz > >> cpu0: on acpi0 > >> est0: on cpu0 > >> est: CPU supports Enhanced Speedstep, but is not recognized. > >> est: cpu_vendor GenuineIntel, msr 720072006000720 > >> device_attach: est0 attach returned 6 > >> p4tcc0: on cpu0 > > > > I had this on a new core2 quad. Updating to a recent 7-STABLE fixed the > > issue for me. > > Did any of you tried chkfreq which comes with acpi_ppc > http://www.spa.is.uec.ac.jp/~nfukuda/software/ to check if the cpu frequency is > actually changing? chkfreq checks the frequency by reading the TSC and comparing it across a sleep. However, newer CPUs actually fix the TSC to increment at a constant rate (so at lower CPU speeds 1 CPU tick may actuall be N TSC ticks) to make it easier to use the TSC for timekeeping. Thus, chkfreq will think that newer CPUs are running at the maximum speed when they aren't. This is actually a feature of newer CPUs. Try turning off powerd and using 'openssl speed rsa' at different frequencies to check for real frequency changes. -- John Baldwin From kris at FreeBSD.org Thu Jun 5 15:01:50 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu Jun 5 15:01:58 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4847FB1D.1050400@rxsec.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> Message-ID: <4847FFDE.8000209@FreeBSD.org> Chris Marlatt wrote: > Kris Kennaway wrote: >> Chris Marlatt wrote: >>> Kris Kennaway wrote: >>>> Jo Rhett wrote: >>>>> On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote: >>>>>> Also, it's not like anyone should have been caught by surprise by >>>>>> the 6.2 EoL; the expiry date has been advertised since the 6.2 >>>>>> release itself. >>>>> >>>>> It has changed multiple times. I keep reviewing and finding 6.3 >>>>> bugs outstanding, and then observe the EoL get pushed. >>>>> >>>>> I'm surprised that it failed to get pushed this time. >>>>> >>>> I'm sorry that the FreeBSD project failed to conform to your >>>> expectations. However, I invite you to actually try 6.3 for yourself >>>> instead of assuming that it will fail. >>>> >>>> Kris >>> In an effort to potentially find a compromise between those who >>> believe FreeBSD is EoL'ing previous releases too quickly and those who >>> don't. Have those in a position to set FreeBSD release schedules >>> debated the option of setting a long term support release, a specific >>> release picked by the team to be support for,.. 4 or 5 years? Other >>> projects have done this will relative success and considering the >>> "only" work required for this release would be security patches the >>> work load should be minimized. Hopefully something like this could >>> free up more time for the FreeBSD developers to continue their work on >>> the newer release(s) while still answering the requests of what seems >>> like quite a few of the legacy FreeBSD users. Thoughts? >>> >>> If this has already been discussed on-list I apologize for beating a >>> dead horse but I can't recall it bring brought up before. >> Uh yeah, this has been in place for *years*. Have you actually read the >> support announcements? They are public ;) >> >> Kris > > I do actually - and when was the last release that was support for such > a duration of time,.. 4.11? As of recent the longest I've seen has been > 24 months with others being only 12. Yes, and this is the FreeBSD definition of "long term support". Don't like it? Do something about it. Kris From kostikbel at gmail.com Thu Jun 5 15:02:41 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Jun 5 15:02:51 2008 Subject: Crashes in devfs. Possibly on interface creation/destruction. In-Reply-To: <48470853.6080807@FreeBSD.org> References: <48470853.6080807@FreeBSD.org> Message-ID: <20080605110447.GB94309@deviant.kiev.zoral.com.ua> On Thu, Jun 05, 2008 at 12:25:39AM +0300, Alexander Motin wrote: > Hi. > > After recent upgrading from 6.3-RC1/mpd-5.0rc1 to 6.3-STABLE/mpd-5.1 > some of my PPPoE servers started to crash with about weekly period. > Usually they just just hang without rebooting and core dumping. Consoles > are inaccessible. All I have got from them was: > > kernel: Fatal trap 12: page fau > kernel: lt while in k > kernel: ernel > kernel: mode > kernel: > kernel: cpuid = 1; apic id = 01 > kernel: faut virtual address = 0x58 > kernel: > kernel: fault code = supervisor read, page not present > kernel: > kernel: instruction pointer = 0x20:0xc04800be > kernel: > kernel: stack pointer = 0x28:0xd690883c > kernel: frame pointer = 0x28:0 > kernel: xd6908854 > kernel: code segment = > kernel: base 0x0, limit 0xfffff, type 0x1b > kernel: > kernel: = DPL 0, pres 1, def32 1, gra > kernel: n 1 > kernel: processor eflags = interrupt > kernel: enab > kernel: led, r > kernel: esume > kernel: , IOPL > kernel: = 0 > kernel: > kernel: current process = 1835 (mpd5) > kernel: > kernel: trap number = 12 > > "fault virtual address" and "instruction pointer" are always the same. > > Address 0xc04800be looks like part of devfs code: > > addr2line -f -e kernel.debug 0xc04800be > devfs_populate_loop > /usr/src/sys/fs/devfs/devfs_devs.c:443 > > devfs_devs.c: > de = devfs_newdirent(s, q - s); > if (cdp->cdp_c.si_flags & SI_ALIAS) { > de->de_uid = 0; > de->de_gid = 0; > de->de_mode = 0755; > de->de_dirent->d_type = DT_LNK; > pdev = cdp->cdp_c.si_parent; > ->> line 443 ->> j = strlen(pdev->si_name) + 1; > de->de_symlink = malloc(j, M_DEVFS, M_WAITOK); > bcopy(pdev->si_name, de->de_symlink, j); > > 0x58 - is precisely the offset of si_name field inside of struct cdev. > So looks like pdev = cdp->cdp_c.si_parent is NULL here for some reason. > > As soon as network interfaces have respective devfs entries and looking > higher interface creation/destruction rate that newest mpd5.1 is able to > reach due to optimizations, I think it may be some kind or race > somewhere interface creation. > > Can somebody give me any hint where to look to? Try the following patch. It is against current, there might be further races at the device destruction, but may be not. Also, please note that devfs in RELENG_6 and RELENG_7/CURRENT are diverged enough to make MFC of most bugfixes to RELENG_6 nearly impossible. diff --git a/sys/kern/kern_conf.c b/sys/kern/kern_conf.c index e9d0f7b..af9a47d 100644 --- a/sys/kern/kern_conf.c +++ b/sys/kern/kern_conf.c @@ -825,9 +825,9 @@ make_dev_alias(struct cdev *pdev, const char *fmt, ...) va_end(ap); devfs_create(dev); + dev_dependsl(pdev, dev); clean_unrhdrl(devfs_inos); dev_unlock(); - dev_depends(pdev, dev); notify_create(dev); -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080605/55a1c23d/attachment.pgp From adrian at freebsd.org Thu Jun 5 15:12:28 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Thu Jun 5 15:12:32 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4847FB1D.1050400@rxsec.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> Message-ID: 2008/6/5 Chris Marlatt : >> Uh yeah, this has been in place for *years*. Have you actually read the >> support announcements? They are public ;) >> >> Kris > > I do actually - and when was the last release that was support for such > a duration of time,.. 4.11? As of recent the longest I've seen has been > 24 months with others being only 12. Noone is stopping -anyone- from doing the Debian/ubuntu thing and breaking off snapshots of FreeBSD to roll in a slightly different way. This is happening with PCBSD, for example. The project is doing what it can with what people are contributing. If you'd like a distribution supported for longer then offer to help maintain it. You may be surprised how helpful people get when you offer to help. :0 Adrian -- Adrian Chadd - adrian@freebsd.org (Still inactive...) From petefrench at ticketswitch.com Thu Jun 5 15:18:33 2008 From: petefrench at ticketswitch.com (Pete French) Date: Thu Jun 5 15:18:36 2008 Subject: gmirror patches Message-ID: Has anybody else had a chance to try the gmirror patches I posted here a few weeks ago ? I;ve had no feedback so far - not sre if thats good news or just that nobody tried them. they can be found here if people are interested: http://www.freebsd.org/cgi/query-pr.cgi?pr=123630 I;ve been running ths for a month with no ill effecets whatsoever, and would very much like to get this commited somehow. I am not sure of the best way to do this though, as it's not an actual bug per-se. Whom would I approach about getting this added to the tree ? cheers, -pete. From cmarlatt at rxsec.com Thu Jun 5 15:21:36 2008 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Thu Jun 5 15:21:43 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4847FFDE.8000209@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> Message-ID: <48480473.3010009@rxsec.com> Kris Kennaway wrote: > Chris Marlatt wrote: >> Kris Kennaway wrote: >>> Chris Marlatt wrote: >>>> Kris Kennaway wrote: >>>>> Jo Rhett wrote: >>>>>> On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote: >>>>>>> Also, it's not like anyone should have been caught by surprise by >>>>>>> the 6.2 EoL; the expiry date has been advertised since the 6.2 >>>>>>> release itself. >>>>>> >>>>>> It has changed multiple times. I keep reviewing and finding 6.3 >>>>>> bugs outstanding, and then observe the EoL get pushed. >>>>>> >>>>>> I'm surprised that it failed to get pushed this time. >>>>>> >>>>> I'm sorry that the FreeBSD project failed to conform to your >>>>> expectations. However, I invite you to actually try 6.3 for yourself >>>>> instead of assuming that it will fail. >>>>> >>>>> Kris >>>> In an effort to potentially find a compromise between those who >>>> believe FreeBSD is EoL'ing previous releases too quickly and those who >>>> don't. Have those in a position to set FreeBSD release schedules >>>> debated the option of setting a long term support release, a specific >>>> release picked by the team to be support for,.. 4 or 5 years? Other >>>> projects have done this will relative success and considering the >>>> "only" work required for this release would be security patches the >>>> work load should be minimized. Hopefully something like this could >>>> free up more time for the FreeBSD developers to continue their work on >>>> the newer release(s) while still answering the requests of what seems >>>> like quite a few of the legacy FreeBSD users. Thoughts? >>>> >>>> If this has already been discussed on-list I apologize for beating a >>>> dead horse but I can't recall it bring brought up before. >>> Uh yeah, this has been in place for *years*. Have you actually read the >>> support announcements? They are public ;) >>> >>> Kris >> >> I do actually - and when was the last release that was support for such >> a duration of time,.. 4.11? As of recent the longest I've seen has been >> 24 months with others being only 12. > > Yes, and this is the FreeBSD definition of "long term support". Don't > like it? Do something about it. > > Kris You seem awful hostile - do you really think that's the best way to represent the project you're involved with? Initially belittle someone for offering their opinion and then when they reply telling them to do it themselves or shut up? Try and have an open mind about these things. The option provided seems like a fairly good compromise to both interests. Pick 6.3 (or anything the release team wishes) to support for a longer period of time. Keep all other releases to 12 month support and continue doing what I believe is some fairly incredible work. I really don't see the downside to it. If anything it should reduce the work load for the team and let them focus on making considerable progress. Especially considering Ken Smith's recent post regarding future release schedules. IMHO, the attitude and opinion you have right now accomplishes nothing other than alienating your supporters. Regards, Chris From cmarlatt at rxsec.com Thu Jun 5 15:33:27 2008 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Thu Jun 5 15:33:33 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> Message-ID: <4848073C.2060509@rxsec.com> Adrian Chadd wrote: > The project is doing what it can with what people are contributing. If What if it can accomplish the same or more by simply reorganizing what it's already doing? I completely understand the apparent situation - if you look at it from all angles it appears to be no different than that of the people apposed to the recent scheduling changes FreeBSD has made. There's a limited amount of people and time to do everything. > you'd like a distribution supported for longer then offer to help > maintain it. You may be surprised how helpful people get when you > offer to help. :0 Again IMHO the only message coming across here is either do it yourself or keep your mouth shut. The other side of the coin here is - what's to say the FreeBSD project requires what I can offer? Granted it's been sometime since I've browsed the entire FreeBSD.org site but last I checked there wasn't an area devoted to the needs of the project. Furthermore, just because someone isn't providing assistance doesn't mean that their concerns should go unheard. It's quite possible what was proposed is an awful idea and if it is so be it. But it would appear as though it wasn't even considered. Regards, Chris From adrian at freebsd.org Thu Jun 5 15:33:56 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Thu Jun 5 15:34:03 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <48480473.3010009@rxsec.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com> Message-ID: 2008/6/5 Chris Marlatt : > The option provided seems like a fairly good compromise to both interests. > Pick 6.3 (or anything the release team wishes) to support for a longer > period of time. Keep all other releases to 12 month support and continue > doing what I believe is some fairly incredible work. I really don't see the > downside to it. If anything it should reduce the work load for the team and > let them focus on making considerable progress. Especially considering Ken > Smith's recent post regarding future release schedules. Please remember that: * the people generally pushing changes back down into RELENG_6 are doing so to (hopefully) fix bugs that they see in their production environments; * So the project is (in theory) being driven by people who have real needs and don't mind sharing; so * If you'd like to see this happen then please take charge and offer to trial it. :) Adrian -- Adrian Chadd - adrian@freebsd.org From adrian at freebsd.org Thu Jun 5 15:39:18 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Thu Jun 5 15:39:28 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4848073C.2060509@rxsec.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4848073C.2060509@rxsec.com> Message-ID: (I know I should really be studying, but this thread really irks me, as I have exactly this issue in the project _I_ am involved in..) 2008/6/5 Chris Marlatt : > Again IMHO the only message coming across here is either do it yourself or > keep your mouth shut. The other side of the coin here is - what's to say the Well, its "do it yourself or be helpful to people who are willing to do it". The OP stated "argh argh sky is falling with 6.3!" but hasn't yet listed PRs which indicate this to be happening. He's offered hardware in a week or two - which is great! - but what irks the developers is the large amount of noise and absolutely no useful information. Anyone can say "its broken!".. > FreeBSD project requires what I can offer? Granted it's been sometime since > I've browsed the entire FreeBSD.org site but last I checked there wasn't an > area devoted to the needs of the project. Whatever you want..? > Furthermore, just because someone isn't providing assistance doesn't mean > that their concerns should go unheard. It's quite possible what was proposed > is an awful idea and if it is so be it. But it would appear as though it > wasn't even considered. Thats true in say, your case. And, say another case like yours. But after hundreds of people who aren't providing assistance and are simply providing their 2c, it gets a bit tiresome. Its not that ALL of the comments aren't any good, its that wading through the crap to find the gems is more effort than fun, and people have real work to do! So yes, the way to contribute is to get involved. If you think there's a real desire to take FreeBSD-6.2 (as an example) and continue supporting security patches and critical bugfixes, versus the larger-scale changes which seem to have gone on in /usr/src/sys then just get together a group, generate some patches and submit them. At some point the poor sod who is committing your work will say "screw this, he's getting a commit bit".. Adrian -- Adrian Chadd - adrian@freebsd.org From kris at FreeBSD.org Thu Jun 5 15:39:37 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu Jun 5 15:39:40 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <48480473.3010009@rxsec.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com> Message-ID: <484808B8.8070506@FreeBSD.org> Chris Marlatt wrote: > Kris Kennaway wrote: >> Chris Marlatt wrote: >>> Kris Kennaway wrote: >>>> Chris Marlatt wrote: >>>>> Kris Kennaway wrote: >>>>>> Jo Rhett wrote: >>>>>>> On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote: >>>>>>>> Also, it's not like anyone should have been caught by surprise by >>>>>>>> the 6.2 EoL; the expiry date has been advertised since the 6.2 >>>>>>>> release itself. >>>>>>> >>>>>>> It has changed multiple times. I keep reviewing and finding 6.3 >>>>>>> bugs outstanding, and then observe the EoL get pushed. >>>>>>> >>>>>>> I'm surprised that it failed to get pushed this time. >>>>>>> >>>>>> I'm sorry that the FreeBSD project failed to conform to your >>>>>> expectations. However, I invite you to actually try 6.3 for yourself >>>>>> instead of assuming that it will fail. >>>>>> >>>>>> Kris >>>>> In an effort to potentially find a compromise between those who >>>>> believe FreeBSD is EoL'ing previous releases too quickly and those who >>>>> don't. Have those in a position to set FreeBSD release schedules >>>>> debated the option of setting a long term support release, a specific >>>>> release picked by the team to be support for,.. 4 or 5 years? Other >>>>> projects have done this will relative success and considering the >>>>> "only" work required for this release would be security patches the >>>>> work load should be minimized. Hopefully something like this could >>>>> free up more time for the FreeBSD developers to continue their work on >>>>> the newer release(s) while still answering the requests of what seems >>>>> like quite a few of the legacy FreeBSD users. Thoughts? >>>>> >>>>> If this has already been discussed on-list I apologize for beating a >>>>> dead horse but I can't recall it bring brought up before. >>>> Uh yeah, this has been in place for *years*. Have you actually read >>>> the >>>> support announcements? They are public ;) >>>> >>>> Kris >>> >>> I do actually - and when was the last release that was support for such >>> a duration of time,.. 4.11? As of recent the longest I've seen has been >>> 24 months with others being only 12. >> >> Yes, and this is the FreeBSD definition of "long term support". Don't >> like it? Do something about it. >> >> Kris > > You seem awful hostile - do you really think that's the best way to > represent the project you're involved with? Initially belittle someone > for offering their opinion and then when they reply telling them to do > it themselves or shut up? Try and have an open mind about these things. > > The option provided seems like a fairly good compromise to both > interests. Pick 6.3 (or anything the release team wishes) to support for > a longer period of time. Keep all other releases to 12 month support and > continue doing what I believe is some fairly incredible work. I really > don't see the downside to it. If anything it should reduce the work load > for the team and let them focus on making considerable progress. > Especially considering Ken Smith's recent post regarding future release > schedules. > > IMHO, the attitude and opinion you have right now accomplishes nothing > other than alienating your supporters. There has been nothing of value offered in this thread, and it's only served to piss off a number of developers who already put huge amounts of volunteer time into supporting FreeBSD, and who take pride in the quality of their work. Asking the volunteers to a) fix unspecified problems that the submitter will not name in detail but which are OMG SHOWSTOPPER YOU MUST FIX b) donate even more unpaid time to supporting branches because it seems like a good "compromise" (!) shows a complete failure of understanding and frankly beggars belief. Such people are not acting as supporters of the project, however well-intentioned they may believe themselves to be. Kris From pschmehl_lists at tx.rr.com Thu Jun 5 15:42:45 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Thu Jun 5 15:42:50 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080605083907.GD1028@server.vk2pj.dyndns.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> Message-ID: <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> --On Thursday, June 05, 2008 18:39:07 +1000 Peter Jeremy wrote: > On 2008-Jun-04 22:22:33 -0700, Jo Rhett wrote: >> And please stop with the loaded language. I'm not asking anyone to work >> for me. I am suggesting that it is perhaps too early to EoL 6.2 because >> 6.3 isn't ready yet. > > So you have stated. When asked to provide evidence to backup that > statement, you have refused. Since you are the one claiming that > "6.3 isn't ready yet", the onus is on you to put up or shut up. That is a blatant lie. He has stated repeatedly that there are *known* bugs, complete with bug reports, that are not resolved and that affect the hardware he uses. He has also stated that there is no need for him to provide further evidence of an already documented bug, yet he is willing to provide equipment with 6.3 RELEASE installed if any developer needs a platform to test and troubleshoot the bugs. What is the purpose of the insults and denigration? Do you really hope to accomplish something positive? -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From hausen at punkt.de Thu Jun 5 15:53:43 2008 From: hausen at punkt.de (Patrick M. Hausen) Date: Thu Jun 5 15:53:47 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> Message-ID: <20080605155340.GA51833@hugo10.ka.punkt.de> Hello, On Thu, Jun 05, 2008 at 10:33:18AM -0500, Paul Schmehl wrote: > --On Thursday, June 05, 2008 18:39:07 +1000 Peter Jeremy > wrote: > >> On 2008-Jun-04 22:22:33 -0700, Jo Rhett wrote: >>> And please stop with the loaded language. I'm not asking anyone to work >>> for me. I am suggesting that it is perhaps too early to EoL 6.2 because >>> 6.3 isn't ready yet. >> >> So you have stated. When asked to provide evidence to backup that >> statement, you have refused. Since you are the one claiming that >> "6.3 isn't ready yet", the onus is on you to put up or shut up. > > That is a blatant lie. He has stated repeatedly that there are *known* > bugs, complete with bug reports, that are not resolved and that affect the > hardware he uses. So he should at least be able to name the relevant PRs. Or name at least one. Then nobody would complain. But stating "it's all well documented" without providing evidence doesn't help. I for one was not able to find any open PRs that deal specifically with 3ware hardware and 6.3, but not 6.[0-2]. > He has also stated that there is no need for him to > provide further evidence of an already documented bug Agreed, but he should name the PRs he's referring to. You know, my crystal ball is at the shop for a check, and it seems like everybody else's is, too. Kind regards, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J?rgen Egeling AG Mannheim 108285 From cmarlatt at rxsec.com Thu Jun 5 15:58:53 2008 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Thu Jun 5 15:58:57 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4848073C.2060509@rxsec.com> Message-ID: <48480D2E.2050006@rxsec.com> Adrian Chadd wrote: > > The OP stated "argh argh sky is falling with 6.3!" but hasn't yet > listed PRs which indicate this to be happening. I'm glad we can agree on something. Providing the PRs is not a lot to ask. Especially if it provides some forward movement and gets the support he needs. I can certainly relate to a potentially standoff'ish approach that's been seen recently. It's easy to take people's criticism as completely negative regardless what is said. To be honest though - people are using FreeBSD because it's a good project to say the least. A few negative comments doesn't mean they think the whole project is trash. Excluding the fact that we're all human and have emotions / ego, you have to agree that such a hostile approach isn't really the best thing. Regards, Chris From pschmehl_lists at tx.rr.com Thu Jun 5 15:59:21 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Thu Jun 5 15:59:33 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080605080344.f99347ec.torfinn.ingolfsen@broadpark.no> References: <458FE12C-AE4D-48F9-8193-4663079CEEF8@netconsonance.com> <84EBEA5D3A1F47E79E8E12C4CF4D0314@multiplay.co.uk> <20080605003545.GP89632@k7.mavetju> <13A3FC54-B459-48C5-85CD-14CC38913838@netconsonance.com> <20080605080344.f99347ec.torfinn.ingolfsen@broadpark.no> Message-ID: --On Thursday, June 05, 2008 08:03:44 +0200 Torfinn Ingolfsen wrote: > On Wed, 04 Jun 2008 22:19:03 -0700 > Jo Rhett wrote: > >> Edwin, I've been building testbed environments for over 20 years in >> my professional career. I know a lot more than this basic concept. >> >> The costs in our environment for a proper testbed is $20k in >> hardware and 3000 man hours. That's for a small test of comparable >> small changes to the existing environment. >> >> Why would we take on this cost only to re-document well known and >> already acknowledged bugs? I mean, really? > > I'm surprised that a test environment (for upgrade testing, load > testing, release testing) isn't already in place. > Some people (customers and operators alike) might think it is > unprofessional and unsafe to run a production system without a test > system available. > > If you have a test system available, why don't you use it? I am offended by the tone of many of the responses to Jo Rhett's *legitimate* arguments that *perhaps* the EOL of 6.2 is a bit premature. I think some folks need to take a break, push away from the keyboard and reduce the insulting rhetoric they are casting his way. He has been more than clear that he routinely donates time and equipment to the community. If all you can do is insult him, perhaps you should consider shutting up. Please note: this is *not* directed only at the person to whom I responded but to all those who have chosen to take the low road rather than engage Jo in professional discussion. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From torfinn.ingolfsen at broadpark.no Thu Jun 5 15:59:23 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Thu Jun 5 15:59:33 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080605125105.GA79727@eos.sc1.parodius.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <484736E0.6090004@samsco.org> <4847D5F8.80605@FreeBSD.org> <20080605125105.GA79727@eos.sc1.parodius.com> Message-ID: <20080605175921.5e994658.torfinn.ingolfsen@broadpark.no> On Thu, 05 Jun 2008 05:51:05 -0700 Jeremy Chadwick wrote: > Offering monetary compensation is not a solution, and I believe that's > because the core problem isn't lack of pay -- it's lack of time. > That's one which is really hard to solve, no matter what the > conditions of an open-source project. Hmm, perhaps you and others should train people instead? Offer to pay a student to learn FreeBSD, and to train her / him as developer. I don't know if it is at all possible to fund something like that within the econimcs of a company such as yours, but if it worked, it would bring more developers on board. Just an idea. -- Regards, Torfinn Ingolfsen, Norway From cmarlatt at rxsec.com Thu Jun 5 16:11:17 2008 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Thu Jun 5 16:11:25 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <484808B8.8070506@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com> <484808B8.8070506@FreeBSD.org> Message-ID: <48481015.4030806@rxsec.com> Kris Kennaway wrote: > Chris Marlatt wrote: >> Kris Kennaway wrote: >>> Chris Marlatt wrote: >>>> Kris Kennaway wrote: >>>>> Chris Marlatt wrote: >>>>>> Kris Kennaway wrote: >>>>>>> Jo Rhett wrote: >>>>>>>> On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote: >>>>>>>>> Also, it's not like anyone should have been caught by surprise by >>>>>>>>> the 6.2 EoL; the expiry date has been advertised since the 6.2 >>>>>>>>> release itself. >>>>>>>> >>>>>>>> It has changed multiple times. I keep reviewing and finding 6.3 >>>>>>>> bugs outstanding, and then observe the EoL get pushed. >>>>>>>> >>>>>>>> I'm surprised that it failed to get pushed this time. >>>>>>>> >>>>>>> I'm sorry that the FreeBSD project failed to conform to your >>>>>>> expectations. However, I invite you to actually try 6.3 for >>>>>>> yourself >>>>>>> instead of assuming that it will fail. >>>>>>> >>>>>>> Kris >>>>>> In an effort to potentially find a compromise between those who >>>>>> believe FreeBSD is EoL'ing previous releases too quickly and those >>>>>> who >>>>>> don't. Have those in a position to set FreeBSD release schedules >>>>>> debated the option of setting a long term support release, a specific >>>>>> release picked by the team to be support for,.. 4 or 5 years? Other >>>>>> projects have done this will relative success and considering the >>>>>> "only" work required for this release would be security patches the >>>>>> work load should be minimized. Hopefully something like this could >>>>>> free up more time for the FreeBSD developers to continue their >>>>>> work on >>>>>> the newer release(s) while still answering the requests of what seems >>>>>> like quite a few of the legacy FreeBSD users. Thoughts? >>>>>> >>>>>> If this has already been discussed on-list I apologize for beating a >>>>>> dead horse but I can't recall it bring brought up before. >>>>> Uh yeah, this has been in place for *years*. Have you actually >>>>> read the >>>>> support announcements? They are public ;) >>>>> >>>>> Kris >>>> >>>> I do actually - and when was the last release that was support for such >>>> a duration of time,.. 4.11? As of recent the longest I've seen has been >>>> 24 months with others being only 12. >>> >>> Yes, and this is the FreeBSD definition of "long term support". >>> Don't like it? Do something about it. >>> >>> Kris >> >> You seem awful hostile - do you really think that's the best way to >> represent the project you're involved with? Initially belittle someone >> for offering their opinion and then when they reply telling them to do >> it themselves or shut up? Try and have an open mind about these things. >> >> The option provided seems like a fairly good compromise to both >> interests. Pick 6.3 (or anything the release team wishes) to support >> for a longer period of time. Keep all other releases to 12 month >> support and continue doing what I believe is some fairly incredible >> work. I really don't see the downside to it. If anything it should >> reduce the work load for the team and let them focus on making >> considerable progress. Especially considering Ken Smith's recent post >> regarding future release schedules. >> >> IMHO, the attitude and opinion you have right now accomplishes nothing >> other than alienating your supporters. > > There has been nothing of value offered in this thread, and it's only > served to piss off a number of developers who already put huge amounts > of volunteer time into supporting FreeBSD, and who take pride in the > quality of their work. Asking the volunteers to > I don't think anyone has really said their quality is in question. At least not myself. The OP stated there are unclosed bugs that be believes are preventing him from using 6.3 and called into question the decision of EoL'ing 6.2. Granted he should have tested it anyways vs. waiting until hell freezes over but at this time thats somewhat beside the point. Just because someone questions a decision or notes there are unclosed bugs doesn't mean they appreciate the work the team as a whole is doing any less. > a) fix unspecified problems that the submitter will not name in detail > but which are OMG SHOWSTOPPER YOU MUST FIX > Again I completely agree that the OP should have provided the PRs. If for nothing else to ensure that you're talking about exactly the same issue and not anything similar. How about just saving you from having to look them up? > b) donate even more unpaid time to supporting branches because it seems > like a good "compromise" (!) This may or may not be the case. Like I said if it's a horrible idea sorry for wasting your time. But it seems fairly logical to me as a good solution to the problem and should net the team more time for things that really count. > > shows a complete failure of understanding and frankly beggars belief. > > Such people are not acting as supporters of the project, however > well-intentioned they may believe themselves to be. > I respectfully disagree. > Kris Regards, Chris From pschmehl_lists at tx.rr.com Thu Jun 5 16:14:21 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Thu Jun 5 16:14:26 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <200806051023.56065.jhb@freebsd.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <200806051023.56065.jhb@freebsd.org> Message-ID: --On Thursday, June 05, 2008 10:23:55 -0400 John Baldwin wrote: > > FWIW, at Y! 6.3 is more stable than 6.2 (I had a list of about 10 patches for > known deadlocks and kernel panics that were errata candidates for 6.2 that > never made it into RELENG_6_2 but all of them are in 6.3). We also have many > machines with bge(4) and from our perspective 6.3 has less issues with bge0 > devices than 6.2. > I'm glad to hear that. I have a server that uses bce, and it was completely non-functional until I hunted down some beta code that made it usable. I'd like to upgrade, but this is a critical server with no redundancy (and it's a hobby site with no money to pay for expensive support), and I'm not about to upgrade unless I know for certain the problems won't reoccur, because I have to upgrade remotely and pay money if the system goes down. The problems with that driver were bad enough when the server was being configured in my study. (The system would lock up, and only a hard reboot would restore networking.) It would be hell trying to troubleshoot problems if I had to drive the 45 miles to the hosting site and spend a night there trying to get the server back up, then go to work the next day. # uname -a FreeBSD www.stovebolt.com 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 #2: Mon Oct 16 15:38:02 CDT 2006 root@www.stovebolt.com:/usr/obj/usr/src/sys/GENERIC i386 # grep bce /var/run/dmesg.boot bce0: mem 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci9 bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz miibus0: on bce0 bce0: Ethernet address: 00:13:72:fb:2a:ad bce1: mem 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci5 bce1: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz miibus1: on bce1 bce1: Ethernet address: 00:13:72:fb:2a:ab # grep bce0 /var/log/messages May 2 09:10:31 www kernel: bce0: link state changed to DOWN May 2 09:10:39 www kernel: bce0: link state changed to UP May 25 07:49:49 www kernel: bce0: link state changed to DOWN May 25 07:50:31 www kernel: bce0: link state changed to UP May 26 21:28:36 www kernel: bce0: link state changed to DOWN May 26 21:28:40 www kernel: bce0: link state changed to UP May 27 13:13:21 www kernel: bce0: link state changed to DOWN May 27 13:13:31 www kernel: bce0: link state changed to UP It's been like that since the server was installed. So, if I upgrade to 6.3 or 7.0, am I still going to experience these problems? Is the server going to stop working entirely? How can I know that for sure before starting an upgrade? Because, I have a 7.0 STABLE workstation (I'm sending this email from it) with a serious problem with umass, and no fix seems to be forthcoming. On a workstation, I can work around problems. On a critical server, not so much. Look, I know this is open source, all volunteer (hell, I'm a port maintainer myself) and guys' time is extremely valuable (whose isn't?), but it seems to me there needs to be better communication between the folks who know the code and those who only run boxes. You might be able to read diffs and say, "Aha, they've fixed the problem", but I can't. I don't know, if I upgrade to 6.3, if the server will stop passing packets or not. And I can't take the chance that it will. Saying put up or shut up isn't going to win many friends. I can't use the server for testing. It's a website with 5 to 7 million hits per month. MInd you, I haven't complained about this and I'm not complaining now. I'm simply saying it would be more productive if folks *listened* to what people say about a particular problem and gave it some thought before firing salvos at the "complainers" and demanding that they contribute to solving the problem somehow. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From ivoras at freebsd.org Thu Jun 5 16:28:40 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Jun 5 16:28:48 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <48480473.3010009@rxsec.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com> Message-ID: Chris Marlatt wrote: > The option provided seems like a fairly good compromise to both > interests. Pick 6.3 (or anything the release team wishes) to support for > a longer period of time. Keep all other releases to 12 month support and > continue doing what I believe is some fairly incredible work. I really > don't see the downside to it. If anything it should reduce the work load > for the team and let them focus on making considerable progress. > Especially considering Ken Smith's recent post regarding future release > schedules. This is already being done: 6.1 was a "long term support" release. The topic comes about pretty often. I think it's because people are still impressed / spoiled by 4.x and wish they had a stable operating system that's supported for 6+ years (like 4.x had been). I even heard commercial / embedded companies saying they would use FreeBSD if only they had a 5+ years run off a branch (which is comparable to what Debian has, if you allow 3.0 and 3.1 to be "similar enough"). But all is not so bad: consider for example 7.x: 7.0 was released 2008/02, and from Ken's schedule the last release, 7.4 will be released 2009/12, with probable support for maybe 1-2 more years which makes the whole 7.x generation of the OS officialy supported for 3, maybe 4 years, which is a lot in fast technology-changing world. I know long term support is not doable with the resources the project currently has, but I've been toying with the idea that maybe there's an opportunity for commercial development here - a company that would backport security fixes and important driver fixes for ($$$ * (N-YEAR_OF_LAST_RELEASE)) more years or something. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080605/793f12b3/signature.pgp From kensmith at cse.Buffalo.EDU Thu Jun 5 16:34:10 2008 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Thu Jun 5 16:34:17 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4847FFDE.8000209@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> Message-ID: <1212683649.90048.43.camel@bauer.cse.buffalo.edu> On Thu, 2008-06-05 at 17:01 +0200, Kris Kennaway wrote: > Chris Marlatt wrote: > > Kris Kennaway wrote: > >> Chris Marlatt wrote: > >>> In an effort to potentially find a compromise between those who > >>> believe FreeBSD is EoL'ing previous releases too quickly and those who > >>> don't. Have those in a position to set FreeBSD release schedules > >>> debated the option of setting a long term support release, a specific > >>> release picked by the team to be support for,.. 4 or 5 years? Other > >>> projects have done this will relative success and considering the > >>> "only" work required for this release would be security patches the > >>> work load should be minimized. Hopefully something like this could > >>> free up more time for the FreeBSD developers to continue their work on > >>> the newer release(s) while still answering the requests of what seems > >>> like quite a few of the legacy FreeBSD users. Thoughts? > >>> > >>> If this has already been discussed on-list I apologize for beating a > >>> dead horse but I can't recall it bring brought up before. > >> Uh yeah, this has been in place for *years*. Have you actually read the > >> support announcements? They are public ;) > >> > >> Kris > > > > I do actually - and when was the last release that was support for such > > a duration of time,.. 4.11? As of recent the longest I've seen has been > > 24 months with others being only 12. > > Yes, and this is the FreeBSD definition of "long term support". Don't > like it? Do something about it. > The 4.11 support was an anomoly, to a large degree because you needed to be either "Really Brave" or "Clinically Insane" to use 5.x. :-) It's unfortunate that people seem to be experiencing regressions with 6.3, we do try quite hard to avoid that. And our support model is geared up around that, it's typically the last release for a given development branch that receives the extended support under the assumption there are no issues with upgrading in-branch. As for re-defining extended support to mean 4 or 5 years instead of just two it's not clear us doing that (except for anomolies like 4.11) is really in your best interests. :-) Even if the base system's support were to be extended to that sort of timeframe it's the *applications* you folks rely on the most. The ports folks do their best to keep their stuff usable for the Project-defined life cycle of the releases which gets harder the older a given "target" gets as well as needing to cater to "too many" different branches simultaneously. Keeping the ports builds going for longer than two years after the last release of a given branch just isn't feasible/reasonable. And if the stuff you layer on top of the operating system isn't upgradable giving you the warm fuzzy feeling you're OK because the base OS still receives patches isn't necessarily a good thing. Of course there will be people who feel differently but we need to focus efforts on the average folks. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080605/132a6ef4/attachment.pgp From cmarlatt at rxsec.com Thu Jun 5 16:46:43 2008 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Thu Jun 5 16:46:50 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com> Message-ID: <48481867.3010809@rxsec.com> Ivan Voras wrote: > Chris Marlatt wrote: > >> The option provided seems like a fairly good compromise to both >> interests. Pick 6.3 (or anything the release team wishes) to support for >> a longer period of time. Keep all other releases to 12 month support and >> continue doing what I believe is some fairly incredible work. I really >> don't see the downside to it. If anything it should reduce the work load >> for the team and let them focus on making considerable progress. >> Especially considering Ken Smith's recent post regarding future release >> schedules. > > This is already being done: 6.1 was a "long term support" release. > > The topic comes about pretty often. I think it's because people are > still impressed / spoiled by 4.x and wish they had a stable operating > system that's supported for 6+ years (like 4.x had been). I even heard Spoiled is probably a good word for it. But you have to admit it's extremely useful to the user base to have such support. This was quite evident by the apposition to discontinue the 4.x branch. > commercial / embedded companies saying they would use FreeBSD if only > they had a 5+ years run off a branch (which is comparable to what Debian > has, if you allow 3.0 and 3.1 to be "similar enough"). > > But all is not so bad: consider for example 7.x: 7.0 was released > 2008/02, and from Ken's schedule the last release, 7.4 will be released > 2009/12, with probable support for maybe 1-2 more years which makes the > whole 7.x generation of the OS officialy supported for 3, maybe 4 years, > which is a lot in fast technology-changing world. I think you're missing the point. Whereas it is indeed helpful to have the major release supported for that duration of time. The concern was over the minor release support. For instance if 7.0 is only supported for 12 months it doesn't really matter if 7.x is support for 48. You still need to upgrade and deal with any potential problems 7.1 or 7.2 induces if you wish to continue having "vendor supplied" security fixes. However using the 7.x tree as an example is problem not the best. 7.x, at least from what I've perceived, is a fairly active development branch. The 6.2 to 6.3 change is somewhat a better example but still not perfect. > > I know long term support is not doable with the resources the project > currently has, but I've been toying with the idea that maybe there's an > opportunity for commercial development here - a company that would > backport security fixes and important driver fixes for ($$$ * > (N-YEAR_OF_LAST_RELEASE)) more years or something. > > Regards, Chris From tevans.uk at googlemail.com Thu Jun 5 16:53:08 2008 From: tevans.uk at googlemail.com (Tom Evans) Date: Thu Jun 5 16:53:14 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <200806051023.56065.jhb@freebsd.org> Message-ID: <1212684781.10665.81.camel@localhost> On Thu, 2008-06-05 at 11:14 -0500, Paul Schmehl wrote: > --On Thursday, June 05, 2008 10:23:55 -0400 John Baldwin > wrote: > > > > FWIW, at Y! 6.3 is more stable than 6.2 (I had a list of about 10 patches for > > known deadlocks and kernel panics that were errata candidates for 6.2 that > > never made it into RELENG_6_2 but all of them are in 6.3). We also have many > > machines with bge(4) and from our perspective 6.3 has less issues with bge0 > > devices than 6.2. > > > > I'm glad to hear that. I have a server that uses bce, and it was completely > non-functional until I hunted down some beta code that made it usable. I'd > like to upgrade, but this is a critical server with no redundancy (and it's a > hobby site with no money to pay for expensive support), and I'm not about to > upgrade unless I know for certain the problems won't reoccur, because I have to > upgrade remotely and pay money if the system goes down. > > The problems with that driver were bad enough when the server was being > configured in my study. (The system would lock up, and only a hard reboot > would restore networking.) It would be hell trying to troubleshoot problems if > I had to drive the 45 miles to the hosting site and spend a night there trying > to get the server back up, then go to work the next day. > > # uname -a > FreeBSD www.stovebolt.com 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 #2: Mon Oct > 16 15:38:02 CDT 2006 root@www.stovebolt.com:/usr/obj/usr/src/sys/GENERIC > i386 > > # grep bce /var/run/dmesg.boot > bce0: mem > 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci9 > bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz > miibus0: on bce0 > bce0: Ethernet address: 00:13:72:fb:2a:ad > bce1: mem > 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci5 > bce1: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz > miibus1: on bce1 > bce1: Ethernet address: 00:13:72:fb:2a:ab > > # grep bce0 /var/log/messages > May 2 09:10:31 www kernel: bce0: link state changed to DOWN > May 2 09:10:39 www kernel: bce0: link state changed to UP > May 25 07:49:49 www kernel: bce0: link state changed to DOWN > May 25 07:50:31 www kernel: bce0: link state changed to UP > May 26 21:28:36 www kernel: bce0: link state changed to DOWN > May 26 21:28:40 www kernel: bce0: link state changed to UP > May 27 13:13:21 www kernel: bce0: link state changed to DOWN > May 27 13:13:31 www kernel: bce0: link state changed to UP > > It's been like that since the server was installed. > > So, if I upgrade to 6.3 or 7.0, am I still going to experience these problems? > Is the server going to stop working entirely? How can I know that for sure > before starting an upgrade? > > Because, I have a 7.0 STABLE workstation (I'm sending this email from it) with > a serious problem with umass, and no fix seems to be forthcoming. On a > workstation, I can work around problems. On a critical server, not so much. > > Look, I know this is open source, all volunteer (hell, I'm a port maintainer > myself) and guys' time is extremely valuable (whose isn't?), but it seems to me > there needs to be better communication between the folks who know the code and > those who only run boxes. You might be able to read diffs and say, "Aha, > they've fixed the problem", but I can't. I don't know, if I upgrade to 6.3, if > the server will stop passing packets or not. And I can't take the chance that > it will. > > Saying put up or shut up isn't going to win many friends. I can't use the > server for testing. It's a website with 5 to 7 million hits per month. > > MInd you, I haven't complained about this and I'm not complaining now. I'm > simply saying it would be more productive if folks *listened* to what people > say about a particular problem and gave it some thought before firing salvos at > the "complainers" and demanding that they contribute to solving the problem > somehow. > > -- > Paul Schmehl I think that, especially with open source products, there is a large emphasis on testing in your own environments, and choosing the 'correct' version of a particular software package is important. For example, at $JOB, we had a lot of servers running 6.1 as it was an extended lifetime release, so no point jumping to 6.2, instead we waited for 6.3 to pass our integration testing. We buy usually the same chassis for all our servers, and test extensively before deploying to a new chassis/OS/anything. This is the definition of change management, which is expensive, takes lots of time and planning, and doesn't guarantee zaroo bugs - just a high likelihood of not hitting them. It also isn't smooth, when we tested 6.1, we found a multitude of bugs in bce(4), which we worked with net@ and David Christensen of Broadcom to get fixed (they work lovely now :). If you don't want to do this sort of work, then yes, things may fail unexpectedly (sort of unexpectedly, I would consider not doing any testing and then having things fail as a logical consequence..). It is usually up to $BOSS to decide if you want to invest the resources (time, people and money) locally to do change management planning, or outsource your support to a 3rd party, or ignore the problem (this is a polite way of saying 'put up or shut up', in my mind.) If you just have <5 servers, the expense of getting duplicates for testing, change management and release management may be too much to handle. If you've got >100 servers, you really have no excuses not to do CM; in my mind, not doing it is reckless. This isn't a cost of OSS, we also do this for windows updates and service packs etc. Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080605/7618e556/attachment.pgp From dougb at FreeBSD.org Thu Jun 5 17:01:49 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Thu Jun 5 17:01:54 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080605175921.5e994658.torfinn.ingolfsen@broadpark.no> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <484736E0.6090004@samsco.org> <4847D5F8.80605@FreeBSD.org> <20080605125105.GA79727@eos.sc1.parodius.com> <20080605175921.5e994658.torfinn.ingolfsen@broadpark.no> Message-ID: <48481BF4.4030209@FreeBSD.org> Torfinn Ingolfsen wrote: > On Thu, 05 Jun 2008 05:51:05 -0700 > Jeremy Chadwick wrote: > >> Offering monetary compensation is not a solution, and I believe that's >> because the core problem isn't lack of pay -- it's lack of time. >> That's one which is really hard to solve, no matter what the >> conditions of an open-source project. > > Hmm, perhaps you and others should train people instead? > Offer to pay a student to learn FreeBSD, and to train her / him as > developer. http://www.freebsd.org/projects/summerofcode-2008.html -- This .signature sanitized for your protection From pieter at degoeje.nl Thu Jun 5 17:10:43 2008 From: pieter at degoeje.nl (Pieter de Goeje) Date: Thu Jun 5 17:10:46 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <200806051023.56065.jhb@freebsd.org> Message-ID: <200806051910.20319.pieter@degoeje.nl> On Thursday 05 June 2008, Paul Schmehl wrote: > --On Thursday, June 05, 2008 10:23:55 -0400 John Baldwin > > wrote: > > FWIW, at Y! 6.3 is more stable than 6.2 (I had a list of about 10 patches > > for known deadlocks and kernel panics that were errata candidates for 6.2 > > that never made it into RELENG_6_2 but all of them are in 6.3). We also > > have many machines with bge(4) and from our perspective 6.3 has less > > issues with bge0 devices than 6.2. > > I'm glad to hear that. I have a server that uses bce, and it was > completely non-functional until I hunted down some beta code that made it > usable. I'd like to upgrade, but this is a critical server with no > redundancy (and it's a hobby site with no money to pay for expensive > support), and I'm not about to upgrade unless I know for certain the > problems won't reoccur, because I have to upgrade remotely and pay money if > the system goes down. > > The problems with that driver were bad enough when the server was being > configured in my study. (The system would lock up, and only a hard reboot > would restore networking.) It would be hell trying to troubleshoot > problems if I had to drive the 45 miles to the hosting site and spend a > night there trying to get the server back up, then go to work the next day. > > # uname -a > FreeBSD www.stovebolt.com 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 #2: Mon > Oct 16 15:38:02 CDT 2006 > root@www.stovebolt.com:/usr/obj/usr/src/sys/GENERIC i386 > > # grep bce /var/run/dmesg.boot > bce0: mem > 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci9 > bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz > miibus0: on bce0 > bce0: Ethernet address: 00:13:72:fb:2a:ad > bce1: mem > 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci5 > bce1: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz > miibus1: on bce1 > bce1: Ethernet address: 00:13:72:fb:2a:ab > > # grep bce0 /var/log/messages > May 2 09:10:31 www kernel: bce0: link state changed to DOWN > May 2 09:10:39 www kernel: bce0: link state changed to UP > May 25 07:49:49 www kernel: bce0: link state changed to DOWN > May 25 07:50:31 www kernel: bce0: link state changed to UP > May 26 21:28:36 www kernel: bce0: link state changed to DOWN > May 26 21:28:40 www kernel: bce0: link state changed to UP > May 27 13:13:21 www kernel: bce0: link state changed to DOWN > May 27 13:13:31 www kernel: bce0: link state changed to UP > > It's been like that since the server was installed. > > So, if I upgrade to 6.3 or 7.0, am I still going to experience these > problems? Is the server going to stop working entirely? How can I know > that for sure before starting an upgrade? > [...] There's a really easy way to test this. Build & install a new kernel, but keep the old kernel around (by default it's in /boot/kernel.old). If the problem is gone, do the upgrade as usual. If it's still there, you know upgrading won't fix it and you don't waste time; simply rename kernel.old to kernel. This even works with 7.0 provided that you leave COMPAT_FREEBSD6 in the kernel configuration file. -- Pieter de Goeje From dougb at FreeBSD.org Thu Jun 5 17:27:14 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Thu Jun 5 17:27:18 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4848073C.2060509@rxsec.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4848073C.2060509@rxsec.com> Message-ID: <484821EE.5070303@FreeBSD.org> Chris Marlatt wrote: > Adrian Chadd wrote: >> The project is doing what it can with what people are >> contributing. If > > What if it can accomplish the same or more by simply reorganizing > what it's already doing? I think that the problem here is that you have no idea how absurd you sound to the people who are actually doing the work. Taking what you said at face value for a minute, a polite response would be something along the lines of, "At this point in the project's history we've already given lengthy and careful consideration to the resources we have available, and how best to allocate them. FreeBSD is a volunteer project, and with few exceptions those who put work into it are doing it 'for fun,' and choose where they want to apply their efforts. Suggestions are often made about where effort can be best applied, some private, some public. But in the end it's the individual developer who chooses what to work on, and the project leadership tries to keep things moving smoothly with the resources available." Now let me approach this from another angle, which is how what you said above can easily sound to us. "Hey you volunteers! It's great that you're working on FreeBSD and giving it to me for free and all, but what I really want you to do is this, so get to it will you?" I'm sure you can imagine the response to that. And frankly, it doesn't even matter which way you _meant_ it. And sure, you have the right to voice your opinion, all FreeBSD users do. You also need to be prepared to take "no" for an answer. >> you'd like a distribution supported for longer then offer to help >> maintain it. You may be surprised how helpful people get when >> you offer to help. :0 > > Again IMHO the only message coming across here is either do it > yourself or keep your mouth shut. That's not _exactly_ what we're saying, but it's pretty close. This is open source after all. "If you can't find what you're looking for, build it, or look elsewhere" would be a better way to say it. > The other side of the coin here is - what's to say the FreeBSD > project requires what I can offer? Without trying to sound rude, I'm pretty sure the only person that's going to matter to is you. > Granted it's been sometime since I've browsed the entire > FreeBSD.org site but last I checked there wasn't an area devoted to > the needs of the project. http://www.freebsd.org/cgi/query-pr-summary.cgi?category=&severity=&priority=&class=&state=&sort=none&text=&responsible=&multitext=&originator=&release= > Furthermore, just because someone isn't providing assistance > doesn't mean that their concerns should go unheard. This isn't the '80's, and we aren't in grade school. See above on taking "no" for an answer. > It's quite possible what was proposed is an awful idea and if it is > so be it. But it would appear as though it wasn't even considered. On the contrary. This, and lots of other ideas have been given very careful consideration and have been rejected due to lack of resources. There, feel better? Seriously folks, it's not as if we don't _want_ to be able to provide better, longer, faster, $whatever support. We're just trying to be realistic about what we can reasonably do with what we have available. hth, Doug -- This .signature sanitized for your protection From killing at multiplay.co.uk Thu Jun 5 17:33:31 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Thu Jun 5 17:33:37 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com><48472DB6.5030909@samsco.org><6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com><200806050248.59229.max@love2party.net><20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> Message-ID: ----- Original Message ----- From: "Paul Schmehl" > That is a blatant lie. He has stated repeatedly that there are *known* bugs, > complete with bug reports, that are not resolved and that affect the hardware > he uses. He has also stated that there is no need for him to provide further > evidence of an already documented bug, yet he is willing to provide equipment > with 6.3 RELEASE installed if any developer needs a platform to test and > troubleshoot the bugs. Unforunately to now he has totally avoided telling anyone what said BUG's, PR's etc are, even when asked on several occasions. Instead he continues down the line of "I dont have time or resources to test your fixes so just make it work ffs!" just not in so many words. I'm just a user here, but if something is a show stopper for us I work with anyone who is able to help us resolve the issue. This has proved very successful, in particular one case springs to mind where we worked with HighPoint support to fix a serious corruption issue with 1820a under FreeBSD. I have no sympathy for anyone who's going to moan about a previous release being desupported that isn't willing to put the effort in to make the issues they are seeing get fixed. 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 postmaster@multiplay.co.uk. From dougb at FreeBSD.org Thu Jun 5 17:38:43 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Thu Jun 5 17:39:19 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com><4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net><20080604234532.GA89656@k7.mavetju> <458FE12C-AE4D-48F9-8193-4663079CEEF8@netconsonance.com> <84EBEA5D3A1F47E79E8E12C4CF4D0314@multiplay.co.uk> Message-ID: <4848249E.2050704@FreeBSD.org> Jo Rhett wrote: > > On Jun 4, 2008, at 5:17 PM, Steven Hartland wrote: >> I wouldn't be surprised if these are not new bugs, just something >> that others have noticed later than 6.2 and I'd suggest you actually >> try 6.3 to see if they are in fact an issue for you. > > I don't have the resources to load up the systems enough to find these > problems sitting on my desk. And I can't risk production resources for > problems known and reported on the *EXACT* same hardware. Ok, then don't. Just stop whining about it. The 6.2 EOL has been announced from day 1 (and extended once already). If you haven't made adequate preparations, that's not our fault. Furthermore, if your production environment is as overwhelmingly important as you make it out to be, you ought to have provisions for redundancy and failover already. If you don't have that, and don't have a testbed, that's not our fault either. Bruce put it in much more polite terms than I have patience for atm. Open source software isn't "free," and if you're not interested in holding up your end of the bargain, explore other alternatives. > "oh but it won't happen to me" isn't a useful methodology in a > production environment. > > I mean, seriously, I know the majority of you are happy rebooting your > systems 5x daily to run the latest. I'll do that with my home system, > no problem. But I can't do this in a production environment. Ok, then don't. But you probably ought not to insult the professionalism of the people that you're going to be asking for help again at some point. When you do come back, your first message should contain a list of PRs that you're concerned about, and confirmation (per jhb's message) that you have the _exact_ hardware that is referred to in them. If you can't provide that, don't bother. Doug -- This .signature sanitized for your protection From alfred at freebsd.org Thu Jun 5 17:40:11 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Thu Jun 5 17:40:14 2008 Subject: Interrupt storm with shared interrupt on digi(4) In-Reply-To: <200806051051.05495.jhb@freebsd.org> References: <20080603070840.GH1028@server.vk2pj.dyndns.org> <200806041044.01712.jhb@freebsd.org> <20080605061931.GF48790@elvis.mu.org> <200806051051.05495.jhb@freebsd.org> Message-ID: <20080605174010.GH48790@elvis.mu.org> * John Baldwin [080605 07:58] wrote: > On Thursday 05 June 2008 02:19:31 am Alfred Perlstein wrote: > > * John Baldwin [080604 11:12] wrote: > > > On Tuesday 03 June 2008 03:04:18 pm Peter Jeremy wrote: > > > > BTW, your MUA's list-reply configuration don't recognize that > > > > freebsd-stable@ and stable@ are aliases. > > > > > > Yes, kmail is broken and the authors refuse to fix it. It happens on reply to > > > a foo@ e-mail (it changes the 'To' to 'freebsd-foo@' because of the List-Id > > > header and leaves foo@ in the 'CC' field). Note that there isn't anything in > > > the List headers that says that foo@ is an alias for freebsd-foo@. I just > > > wish I could turn off the List-Id crap and use plain old reply-to-all, but > > > that is where the kmail developers disagree. > > > > wtf.....why not just have a checkbox to toggle the behavior? > > That was my request (and I found at least 2 other open bugs for the same issue > when I looked again yesterday). The developers reply was "an option is not an > option". Did you try sending him email with forged headers a few times with List-Id set to something embarassing? What's his email? I'll do it. -Alfred From bsam at ipt.ru Thu Jun 5 17:49:33 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Thu Jun 5 17:49:38 2008 Subject: [solved] Re: 7-STABLE: bridge and em In-Reply-To: <72197513@bs1.sp34.ru> (Boris Samorodov's message of "Wed\, 28 May 2008 02\:15\:18 +0400") References: <72197513@bs1.sp34.ru> Message-ID: <82792629@bs1.sp34.ru> Hi List! Well, it took me a while to discover the case... Provider attached my ethernet line to a switch and set up port security to restrict to three MAC addresses which were already used by two computers and a network printer. As soon as provider deletted those restrictions all went well. Thanks for all who helped me. On Wed, 28 May 2008 02:15:18 +0400 Boris Samorodov wrote: > When em0 has an inet address while bridge0 doesn't, it seems to be OK: > ----- > bs1% uname -a > FreeBSD bs1.sp34.ru 7.0-STABLE FreeBSD 7.0-STABLE #0: Sun May 25 20:15:26 MSD 2008 root@bs1.sp34.ru:/usr/obj/usr/src/sys/BSM i386 > bs1% ifconfig em0; ifconfig tap0; ifconfig bridge0 > em0: flags=8943 metric 0 mtu 1500 > options=98 > ether 00:0c:f1:6c:37:4c > inet 192.168.16.30 netmask 0xffffff00 broadcast 192.168.16.255 > media: Ethernet autoselect (100baseTX ) > status: active > tap0: flags=8943 metric 0 mtu 1500 > ether 00:bd:3e:24:00:00 > bridge0: flags=8843 metric 0 mtu 1500 > ether ea:8b:1f:65:2a:5c > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: tap0 flags=143 > ifmaxaddr 0 port 7 priority 128 path cost 2000000 > member: em0 flags=143 > ifmaxaddr 0 port 1 priority 128 path cost 2000000 > bs1% netstat -rn > Routing tables > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 192.168.16.254 UGS 0 357 em0 > 127.0.0.1 127.0.0.1 UH 0 3934 lo0 > 192.168.16.0/24 link#1 UC 0 0 em0 > 192.168.16.1 00:07:e9:80:33:bc UHLW 1 16 em0 951 > 192.168.16.254 00:07:e9:80:33:bc UHLW 2 0 em0 1002 > Internet6: > Destination Gateway Flags Netif Expire > ::1 ::1 UHL lo0 > fe80::%lo0/64 fe80::1%lo0 U lo0 > fe80::1%lo0 link#5 UHL lo0 > ff01:5::/32 fe80::1%lo0 UC lo0 > ff02::%lo0/32 fe80::1%lo0 UC lo0 > bs1% ping -c 3 192.168.16.254 > PING 192.168.16.254 (192.168.16.254): 56 data bytes > 64 bytes from 192.168.16.254: icmp_seq=0 ttl=64 time=0.316 ms > 64 bytes from 192.168.16.254: icmp_seq=1 ttl=64 time=0.263 ms > 64 bytes from 192.168.16.254: icmp_seq=2 ttl=64 time=0.266 ms > --- 192.168.16.254 ping statistics --- > 3 packets transmitted, 3 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.263/0.282/0.316/0.024 ms > ----- > But if I move ip address from em0 to bridge0: > ----- > bs1% sudo ifconfig em0 inet 192.168.16.30 netmask 0xffffff00 delete > bs1% sudo ifconfig bridge0 inet 192.168.16.30 netmask 0xffffff00 > bs1% sudo route add default 192.168.16.254 > add net default: gateway 192.168.16.254 > bs1% ifconfig em0; ifconfig tap0; ifconfig bridge0 > em0: flags=8943 metric 0 mtu 1500 > options=98 > ether 00:0c:f1:6c:37:4c > media: Ethernet autoselect (100baseTX ) > status: active > tap0: flags=8943 metric 0 mtu 1500 > ether 00:bd:3e:24:00:00 > bridge0: flags=8843 metric 0 mtu 1500 > ether ea:8b:1f:65:2a:5c > inet 192.168.16.30 netmask 0xffffff00 broadcast 192.168.16.255 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: tap0 flags=143 > ifmaxaddr 0 port 7 priority 128 path cost 2000000 > member: em0 flags=143 > ifmaxaddr 0 port 1 priority 128 path cost 2000000 > bs1% netstat -rn > Routing tables > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 192.168.16.254 UGS 0 0 bridge > 127.0.0.1 127.0.0.1 UH 0 3934 lo0 > 192.168.16.0/24 link#6 UC 0 0 bridge > 192.168.16.254 link#6 UHLW 2 0 bridge > Internet6: > Destination Gateway Flags Netif Expire > ::1 ::1 UHL lo0 > fe80::%lo0/64 fe80::1%lo0 U lo0 > fe80::1%lo0 link#5 UHL lo0 > ff01:5::/32 fe80::1%lo0 UC lo0 > ff02::%lo0/32 fe80::1%lo0 UC lo0 > bs1% ping -c 3 192.168.16.254 > PING 192.168.16.254 (192.168.16.254): 56 data bytes > --- 192.168.16.254 ping statistics --- > 3 packets transmitted, 0 packets received, 100.0% packet loss > ----- > Did I miss something? Thanks! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From utisoft at googlemail.com Thu Jun 5 17:56:25 2008 From: utisoft at googlemail.com (Chris Rees) Date: Thu Jun 5 17:56:28 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 Message-ID: On Thursday, June 05, 2008 10:23:55 -0400 John Baldwin > wrote: > I'm glad to hear that. I have a server that uses bce, and it was completely > non-functional until I hunted down some beta code that made it usable. I'd > like to upgrade, but this is a critical server with no redundancy (and it's a > hobby site with no money to pay for expensive support), and I'm not about to > upgrade unless I know for certain the problems won't reoccur, because I have to > upgrade remotely and pay money if the system goes down. > > The problems with that driver were bad enough when the server was being > configured in my study. (The system would lock up, and only a hard reboot > would restore networking.) It would be hell trying to troubleshoot problems if > I had to drive the 45 miles to the hosting site and spend a night there trying > to get the server back up, then go to work the next day. > > # uname -a > FreeBSD www.stovebolt.com 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 #2: Mon Oct > 16 15:38:02 CDT 2006 root@www.stovebolt.com:/usr/obj/usr/src/sys/GENERIC > i386 > > # grep bce /var/run/dmesg.boot > bce0: mem > 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci9 > bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz > miibus0: on bce0 > bce0: Ethernet address: 00:13:72:fb:2a:ad > bce1: mem > 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci5 > bce1: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz > miibus1: on bce1 > bce1: Ethernet address: 00:13:72:fb:2a:ab > > # grep bce0 /var/log/messages > May 2 09:10:31 www kernel: bce0: link state changed to DOWN > May 2 09:10:39 www kernel: bce0: link state changed to UP > May 25 07:49:49 www kernel: bce0: link state changed to DOWN > May 25 07:50:31 www kernel: bce0: link state changed to UP > May 26 21:28:36 www kernel: bce0: link state changed to DOWN > May 26 21:28:40 www kernel: bce0: link state changed to UP > May 27 13:13:21 www kernel: bce0: link state changed to DOWN > May 27 13:13:31 www kernel: bce0: link state changed to UP > > It's been like that since the server was installed. > > So, if I upgrade to 6.3 or 7.0, am I still going to experience these problems? > Is the server going to stop working entirely? How can I know that for sure > before starting an upgrade? Damn, that's fascinating. I get that with nfe, on my xbox; amnesiac# uname -a FreeBSD amnesiac.bayofrum.net 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #9: Wed May 28 23:14:21 BST 2008 root@amnesiac.bayofrum.net:/usr/obj/usr/src/sys/AMNESIAC i386 amnesiac# uptime 6:27PM up 7 days, 18:53, 1 user, load averages: 0.00, 0.05, 0.06 amnesiac# tail /var/log/messages Jun 3 17:39:31 amnesiac kernel: pid 37682 (python), uid 80 inumber 871485 on /usr/spare: filesystem full Jun 4 17:07:24 amnesiac kernel: nfe0: link state changed to DOWN Jun 4 17:07:34 amnesiac kernel: nfe0: link state changed to UP Jun 4 17:07:40 amnesiac kernel: nfe0: link state changed to DOWN Jun 4 17:07:54 amnesiac kernel: nfe0: link state changed to UP Jun 4 18:39:50 amnesiac kernel: nfe0: link state changed to DOWN Jun 4 18:40:01 amnesiac kernel: nfe0: link state changed to UP Jun 4 18:40:07 amnesiac kernel: nfe0: link state changed to DOWN Jun 4 18:40:21 amnesiac kernel: nfe0: link state changed to UP Jun 5 18:26:58 amnesiac sudo: chris : TTY=ttyp0 ; PWD=/usr/home/chris ; USER=root ; COMMAND=/usr/bin/su Hm, I swear that's getting more regular. Anyway, it hasn't lost permanantly yet, but I was just ignoring them (my Linux background :$). Should I be worried?? I'll provide any other details if anyone's interested. From cmarlatt at rxsec.com Thu Jun 5 18:13:22 2008 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Thu Jun 5 18:13:26 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <484821EE.5070303@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4848073C.2060509@rxsec.com> <484821EE.5070303@FreeBSD.org> Message-ID: <48482CB6.1000908@rxsec.com> Doug Barton wrote: > Chris Marlatt wrote: >> Adrian Chadd wrote: >>> The project is doing what it can with what people are contributing. If >> >> What if it can accomplish the same or more by simply reorganizing what >> it's already doing? > > I think that the problem here is that you have no idea how absurd you > sound to the people who are actually doing the work. Forgive me for not knowing how people I've never met or conversed with before would accept my proposal. I'll do better next time. > > Taking what you said at face value for a minute, a polite response > would be something along the lines of, "At this point in the project's > history we've already given lengthy and careful consideration to the > resources we have available, and how best to allocate them. FreeBSD is > a volunteer project, and with few exceptions those who put work into > it are doing it 'for fun,' and choose where they want to apply their > efforts. Suggestions are often made about where effort can be best > applied, some private, some public. But in the end it's the individual > developer who chooses what to work on, and the project leadership > tries to keep things moving smoothly with the resources available." > > Now let me approach this from another angle, which is how what you > said above can easily sound to us. "Hey you volunteers! It's great > that you're working on FreeBSD and giving it to me for free and all, > but what I really want you to do is this, so get to it will you?" I'm > sure you can imagine the response to that. > > And frankly, it doesn't even matter which way you _meant_ it. And > sure, you have the right to voice your opinion, all FreeBSD users do. > You also need to be prepared to take "no" for an answer. > So take a line from yourself. This isn't grade school. If you or members of your team can't take constructive criticism then you need to grow up. FreeBSD isn't a toy. Thousands of people rely on it for a variety of reasons. Which strangely enough is likely one of the primary reasons the team enjoys volunteering the time that they do. It means so much to so many people. However those same people are the ones who's concerns are being replied with "do it yourself or go away". I'm completely prepared to hear no - assuming it's a no with some sense behind it. As I've said more than once if it's a horrible idea fine. But it's one I haven't seen proposed before. >>> you'd like a distribution supported for longer then offer to help >>> maintain it. You may be surprised how helpful people get when you >>> offer to help. :0 >> >> Again IMHO the only message coming across here is either do it >> yourself or keep your mouth shut. > > That's not _exactly_ what we're saying, but it's pretty close. This is > open source after all. "If you can't find what you're looking for, > build it, or look elsewhere" would be a better way to say it. > >> The other side of the coin here is - what's to say the FreeBSD project >> requires what I can offer? > > Without trying to sound rude, I'm pretty sure the only person that's > going to matter to is you. I respectfully disagree. > >> Granted it's been sometime since I've browsed the entire FreeBSD.org >> site but last I checked there wasn't an area devoted to >> the needs of the project. > > http://www.freebsd.org/cgi/query-pr-summary.cgi?category=&severity=&priority=&class=&state=&sort=none&text=&responsible=&multitext=&originator=&release= > If the only thing the FreeBSD project is in need of is time to work on PR fixes than what I can offer isn't of much help. Which is why the ^original^ comment was made. > >> Furthermore, just because someone isn't providing assistance doesn't >> mean that their concerns should go unheard. > > This isn't the '80's, and we aren't in grade school. See above on > taking "no" for an answer. What does this have to do with the 80's and again no is a perfectly acceptable answer if it doesn't come along with a STFU. > >> It's quite possible what was proposed is an awful idea and if it is >> so be it. But it would appear as though it wasn't even considered. > > On the contrary. This, and lots of other ideas have been given very > careful consideration and have been rejected due to lack of resources. > There, feel better? Yes because "Uh yeah, this has been in place for *years*. Have you actually read the support announcements? They are public ;) " sounds exactly like careful consideration. > > Seriously folks, it's not as if we don't _want_ to be able to provide > better, longer, faster, $whatever support. We're just trying to be > realistic about what we can reasonably do with what we have available. > If you really want to then slow down the release schedule. I've seen a lot less "I _must_ have this feature" than "Whoa! why are we going to safe" threads. The project is creating a circumstance where offering extended support is not an option. > > hth, > > Doug > Regards, Chris From des at des.no Thu Jun 5 18:25:50 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Jun 5 18:25:55 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <48481015.4030806@rxsec.com> (Chris Marlatt's message of "Thu\, 05 Jun 2008 12\:11\:01 -0400") References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com> <484808B8.8070506@FreeBSD.org> <48481015.4030806@rxsec.com> Message-ID: <86lk1jd9hw.fsf@ds4.des.no> Chris Marlatt writes: > This may or may not be the case. Like I said if it's a horrible idea > sorry for wasting your time. But it seems fairly logical to me as a > good solution to the problem and should net the team more time for > things that really count. How does *increasing our workload* free up "more time for things that really count"? DES -- Dag-Erling Sm?rgrav - des@des.no From jhb at freebsd.org Thu Jun 5 18:28:04 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Jun 5 18:28:08 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <200806051023.56065.jhb@freebsd.org> Message-ID: <200806051422.00836.jhb@freebsd.org> On Thursday 05 June 2008 12:14:20 pm Paul Schmehl wrote: > --On Thursday, June 05, 2008 10:23:55 -0400 John Baldwin > wrote: > > > > FWIW, at Y! 6.3 is more stable than 6.2 (I had a list of about 10 patches for > > known deadlocks and kernel panics that were errata candidates for 6.2 that > > never made it into RELENG_6_2 but all of them are in 6.3). We also have many > > machines with bge(4) and from our perspective 6.3 has less issues with bge0 > > devices than 6.2. > > > > I'm glad to hear that. I have a server that uses bce, and it was completely > non-functional until I hunted down some beta code that made it usable. I'd > like to upgrade, but this is a critical server with no redundancy (and it's a > hobby site with no money to pay for expensive support), and I'm not about to > upgrade unless I know for certain the problems won't reoccur, because I have to > upgrade remotely and pay money if the system goes down. I find that bce(4) is far more reliable in 6.3 than 6.1 for us. There have been several fixes (esp. for higher loads, and mostly in 6.2) to this driver. There are known panics in earlier 6.x that are fixed in 6.3 for certain with this driver. In general though, you don't know which bugs are fixed and if any regressions are present w/o testing the code. If you have production systems then hopefully you have QA systems for development, etc. and you can either reuse those when app QA isn't active for OS QA or you can get dedicated boxes for OS QA. Even if you used a commercial OS with a support contract you would need to do the same. -- John Baldwin From linimon at lonesome.com Thu Jun 5 18:29:17 2008 From: linimon at lonesome.com (Mark Linimon) Date: Thu Jun 5 18:29:21 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <484808B8.8070506@FreeBSD.org> References: <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com> <484808B8.8070506@FreeBSD.org> Message-ID: <20080605182917.GB748@soaustin.net> kris points out that I botched my reply by confusing contributions from 2 different posters. My apologies (I have not closely tracked the entire thread). Nevertheless, the URLs and the summary information should still be of interest. mcl From pschmehl_lists at tx.rr.com Thu Jun 5 18:31:45 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Thu Jun 5 18:31:49 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <1212684781.10665.81.camel@localhost> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <200806051023.56065.jhb@freebsd.org> <1212684781.10665.81.camel@localhost> Message-ID: <8A3638B8BF777C9DF4AB354A@utd65257.utdallas.edu> --On Thursday, June 05, 2008 17:53:01 +0100 Tom Evans wrote: > > I think that, especially with open source products, there is a large > emphasis on testing in your own environments, and choosing the 'correct' > version of a particular software package is important. For example, at > $JOB, we had a lot of servers running 6.1 as it was an extended lifetime > release, so no point jumping to 6.2, instead we waited for 6.3 to pass > our integration testing. > Not everyone has those kinds of resources. The domain I'm referring to is a hobby site, run by a husband and wife. They started with shared hosting and moved to a dedicated box when I volunteered to help with the backend work. For several years we ran one server hosting dns, imaps, smtps, mail lists and websites. Yes, it's not ideal, but when you have zero income you do what you can. Testing like you describe is out of the question. We now have the embarrassment of riches of two servers; one for web and the old one for the rest. The old box is still running 5.4 SECURITY. The new box is running 6.1. I'd *like* to upgrade both boxes, and the older box can go offline comfortably for several hours without anyone but me noticing. But if the web box goes down for 30 seconds, queries from the users start pouring in. > We buy usually the same chassis for all our servers, and test > extensively before deploying to a new chassis/OS/anything. This is the > definition of change management, which is expensive, takes lots of time > and planning, and doesn't guarantee zaroo bugs - just a high likelihood > of not hitting them. It also isn't smooth, when we tested 6.1, we found > a multitude of bugs in bce(4), which we worked with net@ and David > Christensen of Broadcom to get fixed (they work lovely now :). > Wouldn't that be nice! Unfortunately, it's not reality for some of us. And I'm not going to run anything but FreeBSD, because it's the best open source solution there is, bar none. When I run into problems I usually don't say much on the lists. I use Google and read diffs and try to do my best to figure it out on my own. But testing? Not a chance? Contributing? I do what I can. I maintain a bunch of ports. I'm not a developer, and I can't "read" code and figure out what's going on except for the simplest of tasks. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From pschmehl_lists at tx.rr.com Thu Jun 5 18:36:03 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Thu Jun 5 18:36:09 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <200806051910.20319.pieter@degoeje.nl> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <200806051023.56065.jhb@freebsd.org> <200806051910.20319.pieter@degoeje.nl> Message-ID: <3E1DBCBBB1C614B1DBD0F166@utd65257.utdallas.edu> --On Thursday, June 05, 2008 19:10:19 +0200 Pieter de Goeje wrote: > > There's a really easy way to test this. Build & install a new kernel, but > keep the old kernel around (by default it's in /boot/kernel.old). If the > problem is gone, do the upgrade as usual. If it's still there, you know > upgrading won't fix it and you don't waste time; simply rename kernel.old to > kernel. This even works with 7.0 provided that you leave COMPAT_FREEBSD6 in > the kernel configuration file. It's not quite that simple. To do that, I have to block out time to drive 45 miles during my supposed "off" hours and do the upgrade there. Because, if it breaks networking and I'm at home, the server will be down for at least an hour until I can drive to the hosting company, get access to the server and restore the old kernel. Again, I'm not complaining. Just sayin' that sometimes stuff ain't quite as easy to do as folks who are surrounded by hardware and test platforms assume it is. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From linimon at lonesome.com Thu Jun 5 18:36:11 2008 From: linimon at lonesome.com (Mark Linimon) Date: Thu Jun 5 18:36:16 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <48480473.3010009@rxsec.com> References: <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com> <484808B8.8070506@FreeBSD.org> Message-ID: <20080605181832.GA31773@soaustin.net> On Thu, Jun 05, 2008 at 05:39:36PM +0200, Kris Kennaway wrote: > You seem awful hostile - do you really think that's the best way to > represent the project you're involved with? When confronted with "what you are doing is wrong, but I am not going to tell you what it is because if you cared you'd already know" (my summary of your past postings in this thread)? Possibly not 'best' but 'understandable'. > The option provided seems like a fairly good compromise to both > interests. Pick 6.3 (or anything the release team wishes) to support > for a longer period of time. If you want FreeBSD to be supported the same as a commercial product, and you be able to dictate the terms, then it's not going to happen completely via volunteer effort. At some point some money is going to have to change hands. Either you pay someone at your company to do support, or you hire someone external. Then you get to dictate what is supported and for how long. Otherwise, all you can do is to suggest. A "consensus statement" signed off on by one person is the former -- not the latter. Now to add my own frustration to the list ... I next note that _after_ you said you had no more time to continue with this thread for now (and thus could not yet give us pointers to specific failures and any corresponding PR numbers), you are still replying to email. Since you still seem to have some time, let me help you do a little research here. Checking the PRs that you have submitted that are still current, none of the src-related ones are from anything newer than 6.0R: http://www.freebsd.org/cgi/query-pr-summary.cgi?originator=Jo+Rhett There are some resources to help you find already-submitted PRs to reference if it will help. (The latter 2 are new, and are attempts by the bugbusting team to flag 'well-known problem' and 'PR indicates regression'): http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues http://people.freebsd.org/~linimon/studies/prs/well_known_prs.html http://people.freebsd.org/~linimon/studies/prs/prs_for_tag_regression.html Now I'll admit the following is a less-obvious query of the database, but it's my attempt to show regressions that we have already flagged in 6.3: http://www.freebsd.org/cgi/query-pr-summary.cgi?release=%5EFreeBSD+6.3&category=kern&text=regression So these 4 links should give you some quick ways to generate some PR numbers for us. Finally, here are some statistics about PR count: rel all kern --- --- ---- 6.0 210 91 6.1 217 81 6.2 396 102 6.3 167 56 7.0 563 140 To me, this doesn't look like an overwhelming case for 6.3 being worse off than 6.2. Yes, I'm sure there are regressions: there are in any release. mcl From kris at FreeBSD.org Thu Jun 5 18:41:46 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu Jun 5 18:41:49 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <8A3638B8BF777C9DF4AB354A@utd65257.utdallas.edu> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <200806051023.56065.jhb@freebsd.org> <1212684781.10665.81.camel@localhost> <8A3638B8BF777C9DF4AB354A@utd65257.utdallas.edu> Message-ID: <4848336B.60907@FreeBSD.org> Paul Schmehl wrote: > --On Thursday, June 05, 2008 17:53:01 +0100 Tom Evans > wrote: >> >> I think that, especially with open source products, there is a large >> emphasis on testing in your own environments, and choosing the 'correct' >> version of a particular software package is important. For example, at >> $JOB, we had a lot of servers running 6.1 as it was an extended lifetime >> release, so no point jumping to 6.2, instead we waited for 6.3 to pass >> our integration testing. >> > > Not everyone has those kinds of resources. The domain I'm referring to > is a hobby site, run by a husband and wife. They started with shared > hosting and moved to a dedicated box when I volunteered to help with the > backend work. For several years we ran one server hosting dns, imaps, > smtps, mail lists and websites. > > Yes, it's not ideal, but when you have zero income you do what you can. > Testing like you describe is out of the question. > > We now have the embarrassment of riches of two servers; one for web and > the old one for the rest. The old box is still running 5.4 SECURITY. > The new box is running 6.1. I'd *like* to upgrade both boxes, and the > older box can go offline comfortably for several hours without anyone > but me noticing. But if the web box goes down for 30 seconds, queries > from the users start pouring in. Come now, even some of the biggest websites on the planet have scheduled downtime :) Kris From pschmehl_lists at tx.rr.com Thu Jun 5 18:44:06 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Thu Jun 5 18:44:10 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <200806051422.00836.jhb@freebsd.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <200806051023.56065.jhb@freebsd.org> <200806051422.00836.jhb@freebsd.org> Message-ID: <7B79C3A3998654916BC4E4EE@utd65257.utdallas.edu> --On Thursday, June 05, 2008 14:22:00 -0400 John Baldwin wrote: > > I find that bce(4) is far more reliable in 6.3 than 6.1 for us. There have > been several fixes (esp. for higher loads, and mostly in 6.2) to this driver. > There are known panics in earlier 6.x that are fixed in 6.3 for certain with > this driver. > Thanks. Knowing that gives me a lot more confidence to go ahead and build a new kernel for that server. > In general though, you don't know which bugs are fixed and if any regressions > are present w/o testing the code. If you have production systems then > hopefully you have QA systems for development, etc. and you can either reuse > those when app QA isn't active for OS QA or you can get dedicated boxes for > OS QA. Even if you used a commercial OS with a support contract you would > need to do the same. Again, that would be nice, but **just like FreeBSD** this is an all volunteer project where both time and money are at a premium. If I had a dollar for every time my wife complained about me using my valuable free time to support this site without any compensation, I could probably afford a test bed. :-) -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From torfinn.ingolfsen at broadpark.no Thu Jun 5 18:56:05 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Thu Jun 5 18:56:10 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <48481BF4.4030209@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <484736E0.6090004@samsco.org> <4847D5F8.80605@FreeBSD.org> <20080605125105.GA79727@eos.sc1.parodius.com> <20080605175921.5e994658.torfinn.ingolfsen@broadpark.no> <48481BF4.4030209@FreeBSD.org> Message-ID: <20080605205541.a2e26693.torfinn.ingolfsen@broadpark.no> On Thu, 05 Jun 2008 10:01:40 -0700 Doug Barton wrote: > Torfinn Ingolfsen wrote: > > On Thu, 05 Jun 2008 05:51:05 -0700 > > Jeremy Chadwick wrote: > > > >> Offering monetary compensation is not a solution, and I believe > >> that's because the core problem isn't lack of pay -- it's lack of > >> time. That's one which is really hard to solve, no matter what the > >> conditions of an open-source project. > > > > Hmm, perhaps you and others should train people instead? > > Offer to pay a student to learn FreeBSD, and to train her / him as > > developer. > > http://www.freebsd.org/projects/summerofcode-2008.html Yes, I know about Google SoC, and it is a good thing (a _very_ good thing). I was thinking more along the lines that if offering money for fixing stuff doesn't work, then maybe getting more interest (in addition to SoC) would work better. Therer must be a reason why nobody has formed a commercial compnay to fix bugs / develop new features fro FreeBSD (either with own employees or with hired people) already. To me, that means that the demand isn't big enough to make it a viable business plan. -- Regards, Torfinn Ingolfsen, Norway From 000.fbsd at quip.cz Thu Jun 5 20:08:29 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Thu Jun 5 20:08:34 2008 Subject: gmirror patches In-Reply-To: References: Message-ID: <4848433C.5020406@quip.cz> Pete French wrote: > Has anybody else had a chance to try the gmirror patches I posted here a > few weeks ago ? I;ve had no feedback so far - not sre if thats good > news or just that nobody tried them. they can be found here if > people are interested: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=123630 > > I;ve been running ths for a month with no ill effecets whatsoever, and would > very much like to get this commited somehow. I am not sure of the best > way to do this though, as it's not an actual bug per-se. Whom would I > approach about getting this added to the tree ? You can get more attention in freebsd-geom@FreeBSD.org mailinglist and gmirror autor - P.J. Dawidek. pjd@FreeBSD.org Miroslav Lachman From peterjeremy at optushome.com.au Thu Jun 5 22:02:52 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Thu Jun 5 22:02:56 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> Message-ID: <20080605220244.GP1028@server.vk2pj.dyndns.org> On 2008-Jun-05 10:33:18 -0500, Paul Schmehl wrote: >--On Thursday, June 05, 2008 18:39:07 +1000 Peter Jeremy > wrote: > >> On 2008-Jun-04 22:22:33 -0700, Jo Rhett wrote: >>> And please stop with the loaded language. I'm not asking anyone to work >>> for me. I am suggesting that it is perhaps too early to EoL 6.2 because >>> 6.3 isn't ready yet. >> >> So you have stated. When asked to provide evidence to backup that >> statement, you have refused. Since you are the one claiming that >> "6.3 isn't ready yet", the onus is on you to put up or shut up. > >That is a blatant lie. I take exception to being called a lier. Please either explain which of my above statements is false or apologise. > He has stated repeatedly that there are *known* >bugs, complete with bug reports, that are not resolved and that affect the >hardware he uses. He has also stated that there is no need for him to >provide further evidence of an already documented bug, I agree that he has made those statements - and those statements may even be true. When asked to provide details of the bugs or references to those problems, he has refused. Random, unsubstantiated claims are hardly evidence of anything. I have checked back through this thread and the provided descriptions of the problems that he believes affect him are (to quote him) "gmirror failures, 3ware raid driver timeouts, bge0 problems". Note that he hasn't done any testing to verify that these problems actually affect his hardware environment. When asked to, he refused. Likewise, he describes his systems as (again, quoting him) "Rackable systems with 3ware controllers". (I note that in another post, you complain about a problem you are having - though you are able to provide details of both the problem and your hardware/software environment). To summarise, so far the OP has made a series of unsubstantianted claims about vaguely defined problems on vaguely defined hardware. When asked for more details, he has refused. Exactly what do you expect the FreeBSD developers to do? > yet he is willing to >provide equipment with 6.3 RELEASE installed if any developer needs a >platform to test and troubleshoot the bugs. In the absence of any details about the problems he believes he has, such an offer is meaningless. Reading his actual posting, it reads more like "who would like to do my QA/validation for me and fix any bugs they find for free". In general, the underlying problem is lack of developer resources, rather than lack of hardware. >What is the purpose of the insults and denigration? I fail to see where I have insulted or denigrated anyone. OTOH, your first words to me were an insult. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080605/fac8cb4c/attachment.pgp From 000.fbsd at quip.cz Thu Jun 5 22:18:51 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Thu Jun 5 22:18:57 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <3E1DBCBBB1C614B1DBD0F166@utd65257.utdallas.edu> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <200806051023.56065.jhb@freebsd.org> <200806051910.20319.pieter@degoeje.nl> <3E1DBCBBB1C614B1DBD0F166@utd65257.utdallas.edu> Message-ID: <48486659.6040007@quip.cz> Paul Schmehl wrote: > --On Thursday, June 05, 2008 19:10:19 +0200 Pieter de Goeje > wrote: > >> >> There's a really easy way to test this. Build & install a new kernel, but >> keep the old kernel around (by default it's in /boot/kernel.old). If the >> problem is gone, do the upgrade as usual. If it's still there, you know >> upgrading won't fix it and you don't waste time; simply rename >> kernel.old to >> kernel. This even works with 7.0 provided that you leave >> COMPAT_FREEBSD6 in >> the kernel configuration file. > > > It's not quite that simple. To do that, I have to block out time to > drive 45 miles during my supposed "off" hours and do the upgrade there. > Because, if it breaks networking and I'm at home, the server will be > down for at least an hour until I can drive to the hosting company, get > access to the server and restore the old kernel. > > Again, I'm not complaining. Just sayin' that sometimes stuff ain't > quite as easy to do as folks who are surrounded by hardware and test > platforms assume it is. I fully understand your situation, but I think there is still way to try... You can use `nextboot` command. If you install new kernel in to /boot/kernel.new/ directory, just use: nextboot -k kernel.new and then reboot the server. New kernel will be used for this (and only this) cycle. So if something goes wrong and you have any possibility to reboot server again (PDU or by phone call to collocation), you will be back with old good kernel without need to travel. I did it a few times and it saved me ;) Miroslav Lachman From scottl at samsco.org Thu Jun 5 22:32:10 2008 From: scottl at samsco.org (Scott Long) Date: Thu Jun 5 22:32:13 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <74EB4162-74CB-4591-B7E5-8156BB56C29E@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <484736E0.6090004@samsco.org> <74EB4162-74CB-4591-B7E5-8156BB56C29E@netconsonance.com> Message-ID: <48486962.7030001@samsco.org> Jo Rhett wrote: > On Jun 4, 2008, at 5:44 PM, Scott Long wrote: >> Really, if it's such a big issue that you have time to bitch an moan >> on the mailing lists, I don't understand why you don't have time to also >> help a goddamned developer identify the problem. Are you actually >> experiencing problems with 6.3, or not? > > > None of the bugs were in a state with the developer trying to identify > the system. We have several systems dedicated for FreeBSD developers to > use for test cases already, and we'd be happy to provide another if one > was necessary. > What is needed prior to talking about loaner systems and test cases is for you to say, "Hardware XYZ isn't working for me anymore. It used to do FOO, and now it does BAR." That's the first step. It's a simple step, but it's an essential step. Seriously. And if you aren't actually experiencing any problems, then all I can say is that your input on the release and support process has been noted, and we all look forward to bug reports from you in the future. And before you circle back on the "but but but the PR database shows unresolved bugs" argument, understand that few of us on this mailing lists are idiots; we know how to read, and we are aware that there are PR entries. What pushes a stalled PR along, though, is having an interested party bring it up and offer insight into the specifics of it. Just pointing from afar adds nothing to the process. You're welcome to disagree on that point, but it seems pretty clear that continuing to argue it in this forum isn't really solving anything. So I'll try one last time.... you seem to be concerned about possible bugs in the the 3ware and broadcom drivers. Can you please provide specifics on what you are concerned about? Any personal insight or experience you have would be highly helpful and appreciated. Scott From pschmehl_lists at tx.rr.com Thu Jun 5 23:10:46 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Thu Jun 5 23:10:51 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080605220244.GP1028@server.vk2pj.dyndns.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> Message-ID: <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> --On Friday, June 06, 2008 08:02:44 +1000 Peter Jeremy wrote: > On 2008-Jun-05 10:33:18 -0500, Paul Schmehl wrote: >> --On Thursday, June 05, 2008 18:39:07 +1000 Peter Jeremy >> wrote: >> >>> On 2008-Jun-04 22:22:33 -0700, Jo Rhett wrote: >>>> And please stop with the loaded language. I'm not asking anyone to work >>>> for me. I am suggesting that it is perhaps too early to EoL 6.2 because >>>> 6.3 isn't ready yet. >>> >>> So you have stated. When asked to provide evidence to backup that >>> statement, you have refused. Since you are the one claiming that >>> "6.3 isn't ready yet", the onus is on you to put up or shut up. >> >> That is a blatant lie. > > I take exception to being called a lier. Please either explain which of > my above statements is false or apologise. I apologize. I reacted in anger because I felt the OP was being savagely attacked rather than being responded to with professionalism. Later in the thread some folks got around to asking which PRs he was referring to, but that was after attacking him for having the temerity to suggest that perhaps 6.2 shouldn't be EOL. > >> He has stated repeatedly that there are *known* >> bugs, complete with bug reports, that are not resolved and that affect the >> hardware he uses. He has also stated that there is no need for him to >> provide further evidence of an already documented bug, > > I agree that he has made those statements - and those statements may > even be true. When asked to provide details of the bugs or references > to those problems, he has refused. Random, unsubstantiated claims are > hardly evidence of anything. > I don't recall him ever refusing. I think after his initial post he's been forced to defend himself from attack from 360 degrees. It's rather hard to focus on the facts when you're being attacked like that. That's what provoked me to respond as I did - to you and to others. > > To summarise, so far the OP has made a series of unsubstantianted > claims about vaguely defined problems on vaguely defined hardware. > When asked for more details, he has refused. I think that's an unfair characterization. He stated that he had noted numerous bugs in 6.3 (submitted PRs) that he perceived affected him personally and so he chose not to update to 6.3. He then asked if 6.2 couldn't be extended farther. That seems like a reasonable question to ask. A simple, professional answer would have settled the matter quickly. But it was all downhill from there. I'm not here to defend him. He can do that himself. What I took offense to was the gang mentality of jumping on him and accusing him of things no one could possibly have knowledge of and the childish, immature reaction of some on the list. > Exactly what do you expect the FreeBSD developers to do? > I expect the FreeBSD developers to continue to produce the highest quality OS on the market. I also expect them to treat their customers with respect and professionalism and patience. I don't think that's too much to ask. Shouldn't the developers' behavior match the high quality of their work? I recently had to deal with two PRs for ports that I maintain. I initially thought both were rather silly. After testing, I found that one was not, and in fact, the user had uncovered a problem I would never have thought to test for (and obviously hadn't.) Had I jumped on them for not giving more details or harangued the committer for not pointing out my errors, I would have missed an opportunity to improve both a port and my knowledge of porting. But I withheld my personal views and approached both submitters with respect and professionalism. In the end, I was wrong. But no one but me knew that (until now) because I withheld my personal, emotional response. I'm not bragging. I don't think that's anything to brag about. I just think we'd all benefit if we could keep the personal opinions personal and deal with requests on the list with respect and professionalism, just as we would like to be treated. >> yet he is willing to >> provide equipment with 6.3 RELEASE installed if any developer needs a >> platform to test and troubleshoot the bugs. > > In the absence of any details about the problems he believes he has, > such an offer is meaningless. You can't possibly mean that. Your choice of words is horrible. How can it ever be meaningless to offer assistance to the community, however small? I've noticed this attitude on more than one occasion. It's as if "we" are the little people, not fit to be in the same room with the mighty developers. Rest assured, each of us has talents that others can't match and each of us has weaknesses that others can expose. We'd all be better off if we focused on the former and de-emphasized the latter. > Reading his actual posting, it reads > more like "who would like to do my QA/validation for me and fix any > bugs they find for free". In general, the underlying problem is lack > of developer resources, rather than lack of hardware. > OK. When he originally posted his question, someone should have simply said, "The EOL issue is well settled and no longer open to debate. However, we'd be happy to try and resolve any issues you think you might have upgrading to 6.3 if you can provide us with the following: 1) Specific issues including references to specific PRs 2) A list of any assistance you can or would be willing to provide to help isolate these issues That alone would have wasted much less of the valuable developers' limited resources. (And I mean that with all sincerity. I have the highest respect for what you folks do and wish I had the skills to contribute.) >> What is the purpose of the insults and denigration? > > I fail to see where I have insulted or denigrated anyone. OTOH, your > first words to me were an insult. I know you fail to see that. I've noticed others have as well. That doesn't mean they aren't preceived that way any more than your perception of his approach to this issue isn't at all what he thought it was. Misunderstanding cuts both ways. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From pschmehl_lists at tx.rr.com Thu Jun 5 23:11:50 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Thu Jun 5 23:11:54 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <48486659.6040007@quip.cz> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <200806051023.56065.jhb@freebsd.org> <200806051910.20319.pieter@degoeje.nl> <3E1DBCBBB1C614B1DBD0F166@utd65257.utdallas.edu> <48486659.6040007@quip.cz> Message-ID: <549F093490ADB6BC7F6AA5D1@utd65257.utdallas.edu> --On Friday, June 06, 2008 00:19:05 +0200 Miroslav Lachman <000.fbsd@quip.cz> wrote: > Paul Schmehl wrote: > >> --On Thursday, June 05, 2008 19:10:19 +0200 Pieter de Goeje >> wrote: >> >>> >>> There's a really easy way to test this. Build & install a new kernel, but >>> keep the old kernel around (by default it's in /boot/kernel.old). If the >>> problem is gone, do the upgrade as usual. If it's still there, you know >>> upgrading won't fix it and you don't waste time; simply rename >>> kernel.old to >>> kernel. This even works with 7.0 provided that you leave >>> COMPAT_FREEBSD6 in >>> the kernel configuration file. >> >> >> It's not quite that simple. To do that, I have to block out time to >> drive 45 miles during my supposed "off" hours and do the upgrade there. >> Because, if it breaks networking and I'm at home, the server will be >> down for at least an hour until I can drive to the hosting company, get >> access to the server and restore the old kernel. >> >> Again, I'm not complaining. Just sayin' that sometimes stuff ain't >> quite as easy to do as folks who are surrounded by hardware and test >> platforms assume it is. > > I fully understand your situation, but I think there is still way to try... > You can use `nextboot` command. If you install new kernel in to > /boot/kernel.new/ directory, just use: nextboot -k kernel.new and then reboot > the server. New kernel will be used for this (and only this) cycle. So if > something goes wrong and you have any possibility to reboot server again (PDU > or by phone call to collocation), you will be back with old good kernel > without need to travel. > > I did it a few times and it saved me ;) Thank you. I was unaware of the nextboot command. That's a valuable tidbit that I will benefit from. Thank you very much. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From 000.fbsd at quip.cz Fri Jun 6 00:11:51 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Fri Jun 6 00:11:56 2008 Subject: gmirror patches In-Reply-To: <48487D60.9040305@sucked-in.com> References: <4848433C.5020406@quip.cz> <48487D60.9040305@sucked-in.com> Message-ID: <484880D6.2060900@quip.cz> Terry Sposato wrote: > Miroslav Lachman wrote: > >> Pete French wrote: >> >>> Has anybody else had a chance to try the gmirror patches I posted here a >>> few weeks ago ? I;ve had no feedback so far - not sre if thats good >>> news or just that nobody tried them. they can be found here if >>> people are interested: >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=123630 >>> >>> I;ve been running ths for a month with no ill effecets whatsoever, >>> and would >>> very much like to get this commited somehow. I am not sure of the best >>> way to do this though, as it's not an actual bug per-se. Whom would I >>> approach about getting this added to the tree ? >> >> >> You can get more attention in freebsd-geom@FreeBSD.org mailinglist and >> gmirror autor - P.J. Dawidek. pjd@FreeBSD.org >> >> Miroslav Lachman > > Am I missing something here? It seems like the patch you attached to the > PR is a binary so it is not viewable by anyone? Patch is gzipped and can be easily gunziped after download. (and uuencoded in webpage view) It is true that patch is better in plaintext diff. Miroslav Lachman From terry at sucked-in.com Fri Jun 6 00:16:50 2008 From: terry at sucked-in.com (Terry Sposato) Date: Fri Jun 6 00:16:55 2008 Subject: gmirror patches In-Reply-To: <4848433C.5020406@quip.cz> References: <4848433C.5020406@quip.cz> Message-ID: <48487D60.9040305@sucked-in.com> Miroslav Lachman wrote: > Pete French wrote: >> Has anybody else had a chance to try the gmirror patches I posted here a >> few weeks ago ? I;ve had no feedback so far - not sre if thats good >> news or just that nobody tried them. they can be found here if >> people are interested: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=123630 >> >> I;ve been running ths for a month with no ill effecets whatsoever, and >> would >> very much like to get this commited somehow. I am not sure of the best >> way to do this though, as it's not an actual bug per-se. Whom would I >> approach about getting this added to the tree ? > > You can get more attention in freebsd-geom@FreeBSD.org mailinglist and > gmirror autor - P.J. Dawidek. pjd@FreeBSD.org > > Miroslav Lachman > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Am I missing something here? It seems like the patch you attached to the PR is a binary so it is not viewable by anyone? -- Regards, Terry Sposato terry@sucked-in.com http://www.sucked-in.com GnuPG Key : 0xB7643BC8 Fingerprint: EE92 D9E1 C98E 759F 5991 DFF6 70CE 8936 B764 3BC8 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080606/b7e6b0e2/signature.pgp From kutulu at kutulu.org Fri Jun 6 01:04:23 2008 From: kutulu at kutulu.org (Mike Edenfield) Date: Fri Jun 6 01:04:28 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> Message-ID: <48488D1A.9070105@kutulu.org> Paul Schmehl wrote: > I think that's an unfair characterization. He stated that he had > noted numerous bugs in 6.3 (submitted PRs) that he perceived affected > him personally and so he chose not to update to 6.3. He then asked if > 6.2 couldn't be extended farther. That seems like a reasonable > question to ask. A simple, professional answer would have settled the > matter quickly. Part of the problem is that a few of us (including myself) *have* looked for the PRs he referenced and can't find them. There are only three critical PR's opened on the hardware devices he mentioned that are filed specifically against version 6.3: one each for bge, gmirror, and 3ware. Of those, one of them appears to be sporadic, one of them appears to be specific to a particular obscure BIOS, and one of them involved a specific dual-card setup on a specific type of motherboard. And none of those *specifically* say that they cannot be reproduced on 6.2 -- one of them is actually filed against version 5 through 7. Since we also know very little about the specific hardware setup of the OP, it's impossible to determine if these are, in fact, the PRs he's looking at, or if he's actually looking at other less-critical PRs that may need to be bumped up to critical, or if they're misfiled, or who knows what. In short, the problem reports that the OP is looking at are not immediately obvious to someone who doesn't already know what they are, and he's not doing himself any favors by insisting that everyone else "already knows" about these problems. If he's seen these bug reports, presumably he knows what their PR #'s are, or at the very least the description of the bugs, and it would be many many times faster for him to just say so than continue to insist that other people read his mind. --Mike From ganbold at micom.mng.net Fri Jun 6 08:08:33 2008 From: ganbold at micom.mng.net (Ganbold) Date: Fri Jun 6 08:08:36 2008 Subject: MFC of em/igb drivers In-Reply-To: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> Message-ID: <4848EC14.8060700@micom.mng.net> Jack Vogel wrote: > I got the new drivers in Friday afternoon for those that don't see CVS > messages. > > The igb driver is for 82575 and 82576 adapters, it has multiqueue support and > MSIX, there will be more server type enhancements in that driver as I get the > time. > > The em driver now will be client oriented, the latest hardware support however > is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, > that actually also has MSIX. This first released support for it will > use 3 interrupt > vectors, one for TX, one for RX, and Link. The hardware actually supports 5 > vectors, so I am planning to add support for another RX and TX queue as my > schedule allows. > > Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver > provides init and an ioctl interface to use that facility, I hope we > see software > support follow on soon. This is an early announcement, I am not sure on > exact dates for availability but they should be soon. > > As ever, issues and bugs should be sent to me. Cheers everyone! > > Jack > Jack, I have Intel Gigabit card and FreeBSD-7.0-STABLE recognizes it as following: ... em0@pci0:0:25:0: class=0x020000 card=0x2800103c chip=0x104a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82566DM Gigabit Network Connection' class = network subclass = ethernet ... # uname -an FreeBSD test.ub.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Jun 5 11:12:34 ULAT 2008 tsgan@test.ub.mng.net:/usr/obj/usr/src/sys/FIREWALL i386 It has some problem, 1000baseTX connection status almost never goes to active in bridged mode, sometimes it goes to active but then immediately it goes to no carrier. (The other end is Cisco4507R, Gigabit Ethernet port) ... em0: flags=8943 metric 0 mtu 1500 options=198 ether 00:0f:fe:82:23:db media: Ethernet 1000baseTX (autoselect) status: no carrier ... Any idea how to solve this issue? thanks, Ganbold > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > -- Q: How many pre-med's does it take to change a lightbulb? A: Five: One to change the bulb and four to pull the ladder out from under him. From koitsu at FreeBSD.org Fri Jun 6 09:04:52 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Jun 6 09:05:00 2008 Subject: MFC of em/igb drivers In-Reply-To: <4848EC14.8060700@micom.mng.net> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <4848EC14.8060700@micom.mng.net> Message-ID: <20080606090452.GA38593@eos.sc1.parodius.com> On Fri, Jun 06, 2008 at 03:49:40PM +0800, Ganbold wrote: > Jack Vogel wrote: >> I got the new drivers in Friday afternoon for those that don't see CVS >> messages. >> >> The igb driver is for 82575 and 82576 adapters, it has multiqueue support and >> MSIX, there will be more server type enhancements in that driver as I get the >> time. >> >> The em driver now will be client oriented, the latest hardware support however >> is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, >> that actually also has MSIX. This first released support for it will >> use 3 interrupt >> vectors, one for TX, one for RX, and Link. The hardware actually supports 5 >> vectors, so I am planning to add support for another RX and TX queue as my >> schedule allows. >> >> Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver >> provides init and an ioctl interface to use that facility, I hope we >> see software >> support follow on soon. This is an early announcement, I am not sure on >> exact dates for availability but they should be soon. >> >> As ever, issues and bugs should be sent to me. Cheers everyone! > > I have Intel Gigabit card and FreeBSD-7.0-STABLE recognizes it as following: > ... > em0@pci0:0:25:0: class=0x020000 card=0x2800103c chip=0x104a8086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82566DM Gigabit Network Connection' > class = network > subclass = ethernet > ... > # uname -an > FreeBSD test.ub.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Jun 5 > 11:12:34 ULAT 2008 tsgan@test.ub.mng.net:/usr/obj/usr/src/sys/FIREWALL > i386 > > > It has some problem, 1000baseTX connection status almost never goes to > active in bridged mode, sometimes > it goes to active but then immediately it goes to no carrier. (The other > end is Cisco4507R, Gigabit Ethernet port) > ... > em0: flags=8943 metric 0 > mtu 1500 > options=198 > ether 00:0f:fe:82:23:db > media: Ethernet 1000baseTX (autoselect) > status: no carrier > ... > > Any idea how to solve this issue? Have you tried disabling speed and duplex negotiation and explicitly stating speed and duplex like so? ifconfig_em0="... media 1000baseTX mediaopt full-duplex" Cisco switches have a notorious history of not being "friendly" with non-Cisco hardware. Forcing duplex on both ends of the link (that means on both the host side, and the Cisco side!) usually fixes it. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From ganbold at micom.mng.net Fri Jun 6 09:29:49 2008 From: ganbold at micom.mng.net (Ganbold) Date: Fri Jun 6 09:29:56 2008 Subject: MFC of em/igb drivers In-Reply-To: <20080606090452.GA38593@eos.sc1.parodius.com> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <4848EC14.8060700@micom.mng.net> <20080606090452.GA38593@eos.sc1.parodius.com> Message-ID: <4849038A.5040007@micom.mng.net> Jeremy Chadwick wrote: > On Fri, Jun 06, 2008 at 03:49:40PM +0800, Ganbold wrote: > >> Jack Vogel wrote: >> >>> I got the new drivers in Friday afternoon for those that don't see CVS >>> messages. >>> >>> The igb driver is for 82575 and 82576 adapters, it has multiqueue support and >>> MSIX, there will be more server type enhancements in that driver as I get the >>> time. >>> >>> The em driver now will be client oriented, the latest hardware support however >>> is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, >>> that actually also has MSIX. This first released support for it will >>> use 3 interrupt >>> vectors, one for TX, one for RX, and Link. The hardware actually supports 5 >>> vectors, so I am planning to add support for another RX and TX queue as my >>> schedule allows. >>> >>> Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver >>> provides init and an ioctl interface to use that facility, I hope we >>> see software >>> support follow on soon. This is an early announcement, I am not sure on >>> exact dates for availability but they should be soon. >>> >>> As ever, issues and bugs should be sent to me. Cheers everyone! >>> >> I have Intel Gigabit card and FreeBSD-7.0-STABLE recognizes it as following: >> ... >> em0@pci0:0:25:0: class=0x020000 card=0x2800103c chip=0x104a8086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82566DM Gigabit Network Connection' >> class = network >> subclass = ethernet >> ... >> # uname -an >> FreeBSD test.ub.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Jun 5 >> 11:12:34 ULAT 2008 tsgan@test.ub.mng.net:/usr/obj/usr/src/sys/FIREWALL >> i386 >> >> >> It has some problem, 1000baseTX connection status almost never goes to >> active in bridged mode, sometimes >> it goes to active but then immediately it goes to no carrier. (The other >> end is Cisco4507R, Gigabit Ethernet port) >> ... >> em0: flags=8943 metric 0 >> mtu 1500 >> options=198 >> ether 00:0f:fe:82:23:db >> media: Ethernet 1000baseTX (autoselect) >> status: no carrier >> ... >> >> Any idea how to solve this issue? >> > > Have you tried disabling speed and duplex negotiation and explicitly > stating speed and duplex like so? > > ifconfig_em0="... media 1000baseTX mediaopt full-duplex" > I tried it and it doesn't work. > Cisco switches have a notorious history of not being "friendly" with > non-Cisco hardware. Forcing duplex on both ends of the link (that means > on both the host side, and the Cisco side!) usually fixes it. > Tried too, doesn't work. Ganbold -- Life is too important to take seriously. -- Corky Siegel From usselmann.m at icg-online.de Fri Jun 6 10:14:02 2008 From: usselmann.m at icg-online.de (Manfred Usselmann) Date: Fri Jun 6 10:14:07 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <8A3638B8BF777C9DF4AB354A@utd65257.utdallas.edu> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <200806051023.56065.jhb@freebsd.org> <1212684781.10665.81.camel@localhost> <8A3638B8BF777C9DF4AB354A@utd65257.utdallas.edu> Message-ID: <20080606115349.452eea4b.usselmann.m@icg-online.de> Hi, On Thu, 05 Jun 2008 13:31:44 -0500 Paul Schmehl wrote: > --On Thursday, June 05, 2008 17:53:01 +0100 Tom Evans > wrote: > > > > I think that, especially with open source products, there is a large > > emphasis on testing in your own environments, and choosing the > > 'correct' version of a particular software package is important. > > For example, at $JOB, we had a lot of servers running 6.1 as it was > > an extended lifetime release, so no point jumping to 6.2, instead > > we waited for 6.3 to pass our integration testing. > > > > Not everyone has those kinds of resources. The domain I'm referring > to is a hobby site, run by a husband and wife. They started with > shared hosting and moved to a dedicated box when I volunteered to > help with the backend work. For several years we ran one server > hosting dns, imaps, smtps, mail lists and websites. > > Yes, it's not ideal, but when you have zero income you do what you > can. Testing like you describe is out of the question. > > We now have the embarrassment of riches of two servers; one for web > and the old one for the rest. The old box is still running 5.4 > SECURITY. The new box is running 6.1. I'd *like* to upgrade both > boxes, and the older box can go offline comfortably for several hours > without anyone but me noticing. But if the web box goes down for 30 > seconds, queries from the users start pouring in. What you are saying sounds like a contradiction to me. On one side it is just a hobby site and generates no income and on the other hand it is a critical server with millions of hits and the box can't even go down for a short time. What happens in case lets say your harddisk crashes? Something which is not an exactly rare case... If the users are not paying for the service they should be able to accept a downtime, may it be scheduled or even completely unexpected. Or pay / donate for a more reliable service (Redundant server as hot standby / testbed etc.). Manfred -- Manfred Usselmann From votdev at gmx.de Fri Jun 6 11:56:19 2008 From: votdev at gmx.de (Volker Theile) Date: Fri Jun 6 11:56:26 2008 Subject: Instant reboot with FreeBSD 6.3 and > 2GB RAM In-Reply-To: <48347329.8020902@vwsoft.com> References: <20080521080156.209010@gmx.net> <48347329.8020902@vwsoft.com> Message-ID: <20080606115617.190950@gmx.net> Hello, i can confirm that the bug fix submitted with PR 108215 solves the reboot problem when using mfsroot images in FreeBSD 6.3. I will test it also on FreeBSD 7.0, but i assume that it will fix it there too. Many users using FreeNAS reporting this reboot problem on their machines with RAM > 2GB. Regards Volker -------- Original-Nachricht -------- > Datum: Wed, 21 May 2008 21:08:25 +0200 > Von: Volker > An: votdev@gmx.de > CC: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org > Betreff: Re: Instant reboot with FreeBSD 6.3 and > 2GB RAM > On 12/23/-58 20:59, votdev@gmx.de wrote: > > Hello, > > > > some users of FreeNAS which is based on FreeBSD 6.3 reported instant > reboots on systems with > 2GB RAM (most of them use 4GB). The reboot occurs > right after displaying the FreeBSD loader menu. Most of them told me that > they can boot if they reduce RAM to <= 2GB. > > > > We are using the following kernel configuration which is based on > GENERIC: > > > http://freenas.svn.sourceforge.net/viewvc/freenas/branches/0.69/build/kernel-config/FREENAS-i386?revision=3291&view=markup > > > > I found out another problem that causes a reboot on my 2GB machine. We > are using a image for the LiveCD which is 64MB great. If i change back > mfs_root size to 63MB all works well, but all above 64MB causes a reboot. > > Is there any limitation? > > > > Could someone help me out of this problem? > > > > Regards > > Volker > > Hi Volker ;) > > I'm not quite sure about your 2nd problem and your report is not quite > detailed but from your description it looks like loader is causing that. > As there's no filesystem available at that time, the loader has to read > itself through the filesystem structures. > > Knowing that, PR misc/108215 comes to mind. I've not been able to check > if the issue and the patch to it is right but you may give it a try. > Probably somebody with loader and filesystem (ufs) knowledge may answer > that question quickly if the patch contained in the PR is right. > > The report is about 6.2-R but at least I've checked loader code and 7.x > code is the same. I came across that report yesterday and was unable to > check the calculation. > > If that is really the case, your problem may be related to that. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=108215 > > Assuming the problem report is right, it's about reading huge files by > loader reads in wrong sectors. > > HTH > > Volker -- Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger From koitsu at FreeBSD.org Fri Jun 6 12:14:57 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Jun 6 12:15:03 2008 Subject: MFC of em/igb drivers In-Reply-To: <4849038A.5040007@micom.mng.net> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <4848EC14.8060700@micom.mng.net> <20080606090452.GA38593@eos.sc1.parodius.com> <4849038A.5040007@micom.mng.net> Message-ID: <20080606121457.GA46283@eos.sc1.parodius.com> On Fri, Jun 06, 2008 at 05:29:46PM +0800, Ganbold wrote: >> Have you tried disabling speed and duplex negotiation and explicitly >> stating speed and duplex like so? >> >> ifconfig_em0="... media 1000baseTX mediaopt full-duplex" >> > > I tried it and it doesn't work. > >> Cisco switches have a notorious history of not being "friendly" with >> non-Cisco hardware. Forcing duplex on both ends of the link (that means >> on both the host side, and the Cisco side!) usually fixes it. >> > > Tried too, doesn't work. Good to know. Sounds like a driver problem; back to Jack for that one. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From des at des.no Fri Jun 6 13:08:28 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri Jun 6 13:08:33 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> (Paul Schmehl's message of "Thu\, 05 Jun 2008 18\:10\:45 -0500") References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> Message-ID: <86tzg6aeye.fsf@ds4.des.no> Paul Schmehl writes: > [...] I reacted in anger because I felt the OP was being savagely > attacked rather than being responded to with professionalism. Later > in the thread some folks got around to asking which PRs he was > referring to, but that was after attacking him for having the temerity > to suggest that perhaps 6.2 shouldn't be EOL. [...] I don't recall > him ever refusing. I think after his initial post he's been forced to > defend himself from attack from 360 degrees. [...] I came in late, and thus had the benefit of reading most of thread in context rather than piece by piece over time, and in my opinion, the above is a gross misrepresentation. I think you need to go back and re-read the thread from the beginning. Here, let me help you. Three people replied to Jo Rhett's initial email. Here's what they said, with Jo's own text elided: Doug Barton: > It isn't that we want people to upgrade, it's that we are trying to be > realistic regarding what we have the resources to support. > [...] > I admit to not having been following 6.x too closely, but are these > things that have been reported, or problems you're having personally? > [...] > Having an upgrade path is something every operation needs. "Set it and > forget it" isn't a viable strategy in the current culture where 0-day > vulnerabilities are becoming increasingly common. Scott Long: > Can you describe the bugs that are affecting you? > [...] > The expectation is always that newer versions of a stable branch will > have few regressions, and thus upgrading is a low risk. John Baldwin: > FWIW, at Y! 6.3 is more stable than 6.2 (I had a list of about 10 patches for > known deadlocks and kernel panics that were errata candidates for 6.2 that > never made it into RELENG_6_2 but all of them are in 6.3). We also have many > machines with bge(4) and from our perspective 6.3 has less issues with bge0 > devices than 6.2. > > Given the real world experience I have, your claims of instability w/o even > testing 6.3 border on silly. Also, when it comes to bge(4), you need to be > _very_ specific about what chipsets you are using and comparing those with > the chipsets in the bug reports you read. The bge(4) driver in particular > covers a vast range of different hardware variations and is a bit of a > hodge-podge itself. If there is a problem with a 5705 card then it may be > specific to just 5705 parts and not affect 575x, etc. parts. > > Again, with 3ware, there are two different drivers (twe(4) vs twa(4)) and > again, you need to be more specific with which driver you are using and which > model controllers you have. It takes a very active imagination to describe this as an "attack from 360 degrees". The fun starts with the following exchange between Jo and Kris Kennaway (who responded to Doug): Kris Kennaway: > Also, it's not like anyone should have been caught by surprise by > the 6.2 EoL; the expiry date has been advertised since the 6.2 > release itself. Jo Rhett: > It has changed multiple times. I keep reviewing and finding 6.3 bugs > outstanding, and then observe the EoL get pushed. > > I'm surprised that it failed to get pushed this time. This is competely untrue - but Kris doesn't swallow the bait, and relies patiently and politely: > I'm sorry that the FreeBSD project failed to conform to your > expectations. However, I invite you to actually try 6.3 for yourself > instead of assuming that it will fail. This is the crux of the matter - Jo is complaining about software he hasn't even tried. There is absolutely no way anybody can help him until he actually tries 6.3 and reports any actual bugs and regressions he finds. This subthread quickly degrades after Chris Marlatt inists that we should support LTS releases for four years instead of two, and takes personal offense at the fact that we don't have the resources to do so. Let's jump back to Scott Long's subthread: Scott Long: > Can you describe the bugs that are affecting you? Jo Rhett: > gmirror failures, 3ware raid driver timeouts, bge0 problems. All > three in production use on dozens of systems. That is also untrue. None of these are "bugs that are affecting [Jo]", since he hasn't tried running 6.3 at all. Scott Long: > Give me specific details on the 3ware and bge problems. Jo Rhett: > Familiar with searching the open bug reports? That's where I found > them. > > Sorry, I'm knee-deep in a major project that I've been working 16+ > hours a day on right now, and I just don't have the time for spurious > queries. Query the open bug reports for 6.3 and then explain to me > again why 6.2 is no longer supported. Scott asks him to describe the problems he's having, and he calls that "spurious queries" which he doesn't have time for. Is that Scott attacking and disrespecting Jo, or Jo attacking and disrespecting Scott? No wonder Scott gets annoyed: > Really, if it's such a big issue that you have time to bitch an moan > on the mailing lists, I don't understand why you don't have time to > also > help a goddamned developer identify the problem. Are you actually > experiencing problems with 6.3, or not? Jo Rhett: > None of the bugs were in a state with the developer trying to identify > the system. We have several systems dedicated for FreeBSD developers > to use for test cases already, and we'd be happy to provide another if > one was necessary. Dodging the issue - Scott asked a very precise question, and the precise answer is "no". (how can Jo tell that noone is working on these PRs, either on their own hardware or in offline correspondance with the originator?) Max Laier steps in, in response to "spurious queries": > Because the people who support FreeBSD 6.2 are also knee-deep in major > projects of their own!? We try try to not introduce regressions as we > move forward supporting new features and hardware, but unless people put > in some effort of their own helping us to test ... > > You obviously did not put in any effort of your own so why would you > expect us to do the work for you? Unless you can provide "*EXACT*" bug > reports and show willingness to help debugging them, there really is not > much point in this thread. But Jo refuses. He won't provide even a single PR number. He prefers to equivocate, allude and hint: > The bugs in question were very well documented. None of them were in > a state indicating that the developer could not reproduce nor were > they waiting for more info. Given that situation, I didn't see a > need to add more to a known problem. > > *IF* any of them had been looking for test cases, I would have been > happy to build a test system and turn it over to the developer in > question. We do that fairly routinely. (again, how can he know for sure that nobody is working on these bugs?) I won't pretend to know what Jo is thinking or what his motivation is, but in my experience, when people respond in this manner, it's because they know they have no solid data or arguments, and are trying to save face. It goes downhill from there. That leaves John's subthread, which I won't go into since it's mainly about your own issues with bce(4) / bge(4) and seems fairly constructive. I hope this helps you to better understand who's attacking who, and who's being rude to who. DES -- Dag-Erling Sm?rgrav - des@des.no From petefrench at ticketswitch.com Fri Jun 6 15:16:27 2008 From: petefrench at ticketswitch.com (Pete French) Date: Fri Jun 6 15:16:35 2008 Subject: gmirror patches In-Reply-To: <484880D6.2060900@quip.cz> Message-ID: > Patch is gzipped and can be easily gunziped after download. (and > uuencoded in webpage view) Ah, yes, sorry about that - thought it would be obvious. I always submit changes that way as I find that whitespace has a habit of breaking otherwise. > It is true that patch is better in plaintext diff. How would I set about doing that without the whitespace being messed up by email transit ? I have always found in the past that tabs end up as spaces and then patch gets upset hwne you try to apply it. -pete. PS: thanks for the emai address BTW! From 000.fbsd at quip.cz Fri Jun 6 15:26:08 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Fri Jun 6 15:26:12 2008 Subject: gmirror patches In-Reply-To: References: Message-ID: <4849571E.606@quip.cz> Pete French wrote: [...] >>It is true that patch is better in plaintext diff. > > > How would I set about doing that without the whitespace being messed up > by email transit ? I have always found in the past that tabs end up as > spaces and then patch gets upset hwne you try to apply it. I sent PR throught webform with plain text patch with txt extension (http://www.freebsd.org/cgi/query-pr.cgi?pr=124248), patch is shown on webpage with spaces instead of tabs, but if you download it, tabs are tabs. Miroslav Lachman From vivek at khera.org Fri Jun 6 16:08:55 2008 From: vivek at khera.org (Vivek Khera) Date: Fri Jun 6 16:08:58 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080604204325.GD4701@lava.net> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net> Message-ID: <702FA4B9-8CEE-4C9D-86A8-157CA1E69BD7@khera.org> On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote: > Speaking just for myself, I'd love to get a general response from > people who have run servers on both as to whether 6.3 is on average > more stable than 6.2. I really haven't gotten any clear impression as I'll throw in my "+1" for running 6.3. I have it on many boxes, some of which run gmirror and some of which have bge devices (some with both). Never any problems. They operate things varying from Postgres servers to DNS servers to mail servers (postfix) under pretty consistent load pushing lots and lots of data both network and to disk. From vivek at khera.org Fri Jun 6 16:11:32 2008 From: vivek at khera.org (Vivek Khera) Date: Fri Jun 6 16:11:36 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <7B3DA577-61F6-41D2-90B1-954E3A5A5C80@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <7B3DA577-61F6-41D2-90B1-954E3A5A5C80@netconsonance.com> Message-ID: <264183D1-4324-405D-B737-1555A6FFFCE7@khera.org> On Jun 4, 2008, at 8:22 PM, Jo Rhett wrote: > If you're asking why I don't turn a production environment over to > being a freebsd-unstable-testbed, I can't really answer that > question in a way you'd understand (if you were asking that question) If you don't have an identical setup to test new software, then you're pretty much not able to ever upgrade anything, IMO, and your "production" environment *is* a testbed for new software. From vivek at khera.org Fri Jun 6 16:13:18 2008 From: vivek at khera.org (Vivek Khera) Date: Fri Jun 6 16:13:22 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net> <20080604234532.GA89656@k7.mavetju> <458FE12C-AE4D-48F9-8193-4663079CEEF8@netconsonance.com> <84EBEA5D3A1F47E79E8E12C4CF4D0314@multiplay.co.uk> Message-ID: <0BEEE81D-74D6-49A4-AABC-380BA690B5BC@khera.org> On Jun 4, 2008, at 9:03 PM, Adrian Chadd wrote: > If this is so important to you - contribute to the project and/or hire > a FreeBSD developer. I've got a strange problem with jails and I've been trying to hire a freebsd developer, but I can't seem to get anyone to a) call me back. I got one response on "try doing xxx" which involved kernel hacking and such, which is beyond what I am in a position to do. From cliftonr at lava.net Fri Jun 6 16:39:43 2008 From: cliftonr at lava.net (Clifton Royston) Date: Fri Jun 6 16:39:49 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <702FA4B9-8CEE-4C9D-86A8-157CA1E69BD7@khera.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net> <702FA4B9-8CEE-4C9D-86A8-157CA1E69BD7@khera.org> Message-ID: <20080606163939.GA3158@lava.net> On Fri, Jun 06, 2008 at 12:08:54PM -0400, Vivek Khera wrote: > > On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote: > > > Speaking just for myself, I'd love to get a general response from > >people who have run servers on both as to whether 6.3 is on average > >more stable than 6.2. I really haven't gotten any clear impression as > > I'll throw in my "+1" for running 6.3. I have it on many boxes, some > of which run gmirror and some of which have bge devices (some with > both). Never any problems. They operate things varying from Postgres > servers to DNS servers to mail servers (postfix) under pretty > consistent load pushing lots and lots of data both network and to disk. Thanks. That sounds like the kind of broad experience I need, particularly as the main group of servers are mail servers (spam filtering machines running Postfix, with some config files on NFS.) -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From michael at quuxo.com Fri Jun 6 16:40:54 2008 From: michael at quuxo.com (Michael Gratton) Date: Fri Jun 6 16:40:58 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <702FA4B9-8CEE-4C9D-86A8-157CA1E69BD7@khera.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net> <702FA4B9-8CEE-4C9D-86A8-157CA1E69BD7@khera.org> Message-ID: <1212768942.6066.20.camel@tremelay> On Fri, 2008-06-06 at 12:08 -0400, Vivek Khera wrote: > On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote: > > > Speaking just for myself, I'd love to get a general response from > > people who have run servers on both as to whether 6.3 is on average > > more stable than 6.2. I really haven't gotten any clear impression as > > I'll throw in my "+1" for running 6.3. I have it on many boxes, some > of which run gmirror and some of which have bge devices (some with > both). Never any problems. They operate things varying from Postgres > servers to DNS servers to mail servers (postfix) under pretty > consistent load pushing lots and lots of data both network and to disk. AOL! 6.3 with gmirror is rock solid here for web, mail, dns and db. No bge here, but still, I haven't seen 6.3 glitch once. /Mike -- Michael Gratton Quuxo Software -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080606/c9c92e6c/attachment.pgp From sthaug at nethelp.no Fri Jun 6 16:47:51 2008 From: sthaug at nethelp.no (sthaug@nethelp.no) Date: Fri Jun 6 16:47:57 2008 Subject: MFC of em/igb drivers In-Reply-To: <20080606090452.GA38593@eos.sc1.parodius.com> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <4848EC14.8060700@micom.mng.net> <20080606090452.GA38593@eos.sc1.parodius.com> Message-ID: <20080606.182108.74659907.sthaug@nethelp.no> > Have you tried disabling speed and duplex negotiation and explicitly > stating speed and duplex like so? > > ifconfig_em0="... media 1000baseTX mediaopt full-duplex" Disagree with this piece of advice. > Cisco switches have a notorious history of not being "friendly" with > non-Cisco hardware. Forcing duplex on both ends of the link (that means > on both the host side, and the Cisco side!) usually fixes it. I might have said the same myself five years ago. But this is 2008, and we have autoneg as default on all ports (even at 100 Mbps). Our Cisco switch ports (and we have a *lot* of them) work just fine with autoneg. Note that GigE is different from FE here - autoneg is a compulsory part of the GigE standard, while it's not compulsory for FE. The only GigE ports that have needed anything else were some pre-standard GigE ports. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From arno at heho.snv.jussieu.fr Fri Jun 6 17:36:56 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Fri Jun 6 17:37:02 2008 Subject: [nvidia | shared irq] umass disconnects [was: panic dd-ing from a USB "disk" ] In-Reply-To: <200805081730.m48HUNjh001532@symbion.zaytman.com> References: <200805081730.m48HUNjh001532@symbion.zaytman.com> Message-ID: Mikhail Teterin writes: > Hello! > > I had some troubles mounting the filesystem from: > > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-2 device > da0: 1.000MB/s transfers > da0: 3886MB (7959552 512 byte sectors: 255H 63S/T 495C) > > and decided to just dd the entire da0 to a file, so that the camera > can be disconnected: > > dd if=/dev/da0 of=/home/mi/da0.dd bs=16384 > > The dd-ing was proceeding slowly (600Kb/s) and I stopped watching it... > > The machine paniced about an hour later (at 0:52). The timestamp on > /home/mi/da0.dd was 23:45, it was only about 500Mb in size. > > The stack is below. Would anybody like to look at the complete > vmcore dump? > > The hardware is a quad Opteron with 8Gb RAM. Only 4Gb of these are > used, because it runs 7.x/i386 from April 5th (without PAE) -- for > the sake of NVidia's card. I can easily produce a similar panic on a dual Opteron 185 with 3G of RAM and running 7-stable-amd64 on a (cheap) nvidia-based MB. It runs gmirror on atapci1 and I attach a geli-encrypted disk via usb. Both share irq 23. Under heavy load ("periodic security" is enough ) it panics after having disconnected umass0 ( kgdb trace below ) : Unread portion of the kernel message buffer: umass0: at uhub1 port 1 (addr 2) disconnected (da1:umass-sim0:0:0:0): lost device (pass1:umass-sim0:0:0:0): lost device (pass1:umass-sim0:0:0:0): removing device entry I'd be happy to provide more info. Best, Arno > Please, advise. Thanks! > > -mi > > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd". > There is no member named pathname. > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > Reading symbols from /opt/modules/fuse.ko...done. > Loaded symbols for /opt/modules/fuse.ko > > Unread portion of the kernel message buffer: > umass0: at uhub0 port 6 (addr 2) disconnected > (da0:umass-sim0:0:0:0): lost device > > > Fatal trap 12: page fault while in kernel mode > cpuid = 3; apic id = 03 > fault virtual address = 0x0 > fault code = supervisor write, page not present > instruction pointer = 0x20:0xc0449702 > stack pointer = 0x28:0xeb74b8bc > frame pointer = 0x28:0xeb74b8dc > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 13989 (dd) > trap number = 12 > panic: page fault > cpuid = 3 > Uptime: 12d10h52m16s > (da0:dead_sim0:0:0:0): Synchronize cache failed, status == 0x34, scsi status == 0xc8 > Physical memory: 3054 MB > Dumping 334 MB: (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 > > #0 doadump () at pcpu.h:195 > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) #0 doadump () at pcpu.h:195 > #1 0xc0599f7b in boot (howto=260) at /ibm/src/sys/kern/kern_shutdown.c:418 > #2 0xc059a449 in panic (fmt=0x104
) > at /ibm/src/sys/kern/kern_shutdown.c:572 > #3 0xc077f60d in trap_fatal (frame=0xeb74b87c, eva=40) > at /ibm/src/sys/i386/i386/trap.c:899 > #4 0xc077f9aa in trap_pfault (frame=0xeb74b87c, usermode=0, eva=0) > at /ibm/src/sys/i386/i386/trap.c:812 > #5 0xc078035c in trap (frame=0xeb74b87c) at /ibm/src/sys/i386/i386/trap.c:490 > #6 0xc076637b in calltrap () at /ibm/src/sys/i386/i386/exception.s:139 > #7 0xc0449702 in xpt_done (done_ccb=0xc690a000) > at /ibm/src/sys/cam/cam_xpt.c:4856 > #8 0xc044b15c in xpt_action (start_ccb=0xc690a000) > at /ibm/src/sys/cam/cam_xpt.c:3057 > #9 0xc04462b6 in cam_periph_runccb (ccb=0xc690a000, error_routine=0, > camflags=CAM_FLAG_NONE, sense_flags=1, ds=0xc6aea690) > at /ibm/src/sys/cam/cam_periph.c:878 > #10 0xc0453aa1 in daclose (dp=0xcc862600) > at /ibm/src/sys/cam/scsi/scsi_da.c:714 > #11 0xc0549b2e in g_disk_access (pp=0xc7e12680, r=0, w=0, e=Variable "e" is not available.) > at /ibm/src/sys/geom/geom_disk.c:152 > #12 0xc054ec4d in g_access (cp=0xc8a90380, dcr=-1, dcw=0, dce=0) > at /ibm/src/sys/geom/geom_subr.c:748 > #13 0xc05490f3 in g_dev_close (dev=0xca1dad00, flags=Variable "flags" is not available.) > at /ibm/src/sys/geom/geom_dev.c:217 > #14 0xc0531f69 in devfs_close (ap=0xeb74ba94) > at /ibm/src/sys/fs/devfs/devfs_vnops.c:372 > #15 0xc0623e86 in vn_close (vp=0xcc8c1dd0, flags=1, file_cred=0xca36e700, > td=0xc8552000) at vnode_if.h:228 > #16 0xc0623f37 in vn_closefile (fp=0xca19bdc8, td=0xc8552000) > at /ibm/src/sys/kern/vfs_vnops.c:868 > #17 0xc0568b14 in fdrop (fp=0xca19bdc8, td=0xc8552000) at file.h:297 > #18 0xc056a3c2 in closef (fp=0xca19bdc8, td=0xc8552000) > at /ibm/src/sys/kern/kern_descrip.c:1958 > #19 0xc056b371 in fdfree (td=0xc8552000) > at /ibm/src/sys/kern/kern_descrip.c:1668 > #20 0xc05775fa in exit1 (td=0xc8552000, rv=256) > at /ibm/src/sys/kern/kern_exit.c:272 > #21 0xc0578e1d in sys_exit (td=Could not find the frame base for "sys_exit". > ) at /ibm/src/sys/kern/kern_exit.c:98 > #22 0xc077fb90 in syscall (frame=0xeb74bd38) > at /ibm/src/sys/i386/i386/trap.c:1035 > #23 0xc07663e0 in Xint0x80_syscall () at /ibm/src/sys/i386/i386/exception.s:196 > #24 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff80162c11 stack pointer = 0x10:0xffffffffabe679c0 frame pointer = 0x10:0xffffff00030f6c00 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2 (g_event) trap number = 12 panic: page fault cpuid = 1 Uptime: 2d12h40m24s (da1:dead_sim0:0:0:0): Synchronize cache failed, status == 0x34, scsi status == 0x0 Physical memory: 2807 MB Dumping 460 MB: 445 429 413 397 381 365 349 333 317 301 285 269 253 237 221 205 189 173 157 141 125 109 93 77 61 45 29 13 Reading symbols from /boot/kernel/umass.ko...Reading symbols from /boot/kernel/umass.ko.symbols...done. done. Loaded symbols for /boot/kernel/umass.ko Reading symbols from /boot/kernel/usb.ko...Reading symbols from /boot/kernel/usb.ko.symbols...done. done. Loaded symbols for /boot/kernel/usb.ko Reading symbols from /boot/kernel/sym.ko...Reading symbols from /boot/kernel/sym.ko.symbols...done. done. Loaded symbols for /boot/kernel/sym.ko Reading symbols from /boot/kernel/iicsmb.ko...Reading symbols from /boot/kernel/iicsmb.ko.symbols...done. done. Loaded symbols for /boot/kernel/iicsmb.ko Reading symbols from /boot/kernel/iicbus.ko...Reading symbols from /boot/kernel/iicbus.ko.symbols...done. done. Loaded symbols for /boot/kernel/iicbus.ko Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /boot/kernel/smbus.ko.symbols...done. done. Loaded symbols for /boot/kernel/smbus.ko Reading symbols from /boot/kernel/smb.ko...Reading symbols from /boot/kernel/smb.ko.symbols...done. done. Loaded symbols for /boot/kernel/smb.ko Reading symbols from /boot/kernel/nfsmb.ko...Reading symbols from /boot/kernel/nfsmb.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfsmb.ko Reading symbols from /boot/kernel/k8temp.ko...Reading symbols from /boot/kernel/k8temp.ko.symbols...done. done. Loaded symbols for /boot/kernel/k8temp.ko Reading symbols from /boot/kernel/if_tap.ko...Reading symbols from /boot/kernel/if_tap.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_tap.ko Reading symbols from /boot/kernel/if_nfe.ko...Reading symbols from /boot/kernel/if_nfe.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_nfe.ko Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/geom_raid5.ko...Reading symbols from /boot/kernel/geom_raid5.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_raid5.ko Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from /boot/kernel/geom_eli.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_eli.ko Reading symbols from /boot/kernel/crypto.ko...Reading symbols from /boot/kernel/crypto.ko.symbols...done. done. Loaded symbols for /boot/kernel/crypto.ko Reading symbols from /boot/kernel/zlib.ko...Reading symbols from /boot/kernel/zlib.ko.symbols...done. done. Loaded symbols for /boot/kernel/zlib.ko #0 doadump () at pcpu.h:194 194 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:194 #1 0x0000000000000004 in ?? () #2 0xffffffff80289290 in boot (howto=260) at /raid1/bsd/src7/sys/kern/kern_shutdown.c:418 #3 0xffffffff802896ad in panic (fmt=0x104
) at /raid1/bsd/src7/sys/kern/kern_shutdown.c:572 #4 0xffffffff80494154 in trap_fatal (frame=0xffffff00010e4000, eva=18446742974215571664) at /raid1/bsd/src7/sys/amd64/amd64/trap.c:724 #5 0xffffffff80494525 in trap_pfault (frame=0xffffffffabe67910, usermode=0) at /raid1/bsd/src7/sys/amd64/amd64/trap.c:641 #6 0xffffffff80494ecb in trap (frame=0xffffffffabe67910) at /raid1/bsd/src7/sys/amd64/amd64/trap.c:410 #7 0xffffffff8047ab1e in calltrap () at /raid1/bsd/src7/sys/amd64/amd64/exception.S:169 #8 0xffffffff80162c11 in xpt_done (done_ccb=0xffffff00030f6c00) at /raid1/bsd/src7/sys/cam/cam_xpt.c:4856 #9 0xffffffff8015f775 in cam_periph_runccb (ccb=0xffffff00030f6c00, error_routine=0, camflags=CAM_FLAG_NONE, sense_flags=1, ds=0xffffff00031765a0) at /raid1/bsd/src7/sys/cam/cam_periph.c:878 #10 0xffffffff80175e7f in daclose (dp=Variable "dp" is not available. ) at /raid1/bsd/src7/sys/cam/scsi/scsi_da.c:714 #11 0xffffffff8023a182 in g_disk_access (pp=0xffffff0003c64600, r=Variable "r" is not available. ) at /raid1/bsd/src7/sys/geom/geom_disk.c:152 #12 0xffffffff8023ed53 in g_access (cp=0xffffff0003fb5a00, dcr=-1, dcw=-1, dce=-2) at /raid1/bsd/src7/sys/geom/geom_subr.c:748 #13 0xffffffff8023ed53 in g_access (cp=0xffffff004c625680, dcr=-1, dcw=-1, dce=-1) at /raid1/bsd/src7/sys/geom/geom_subr.c:748 #14 0xffffffff8023f297 in g_wither_geom_close (gp=0xffffff0003e16000, error=6) at /raid1/bsd/src7/sys/geom/geom_subr.c:351 #15 0xffffffffaf73f1fb in g_eli_destroy () from /boot/kernel/geom_eli.ko #16 0xffffffff8023b47e in g_run_events () at /raid1/bsd/src7/sys/geom/geom_event.c:163 #17 0xffffffff8023c8f5 in g_event_procbody () at /raid1/bsd/src7/sys/geom/geom_kern.c:141 #18 0xffffffff802686f2 in fork_exit ( callout=0xffffffff8023c8a0 , arg=0x0, frame=0xffffffffabe67c80) at /raid1/bsd/src7/sys/kern/kern_fork.c:783 #19 0xffffffff8047aeee in fork_trampoline () at /raid1/bsd/src7/sys/amd64/amd64/exception.S:415 #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000001 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0x0000000000000000 in ?? () #43 0x0000000000000000 in ?? () #44 0x000000000092b000 in ?? () #45 0xffffffff806b6c80 in tdg_maxid () #46 0xffffffff806c3480 in tdq_cpu () #47 0xffffffff806c3480 in tdq_cpu () #48 0xffffff00010e4000 in ?? () #49 0x000000000000000b in ?? () #50 0xffffffffabe671a8 in ?? () #51 0x0000000000000000 in ?? () #52 0xffffffff802a9854 in sched_switch (td=0xffffffff8023c8a0, newtd=0x0, flags=0) at /raid1/bsd/src7/sys/kern/sched_ule.c:1897 From stefan.lambrev at moneybookers.com Fri Jun 6 19:40:07 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Fri Jun 6 19:40:11 2008 Subject: Java binaries for FreeBSD 7 Message-ID: <4849928F.6060502@moneybookers.com> Greetings, From http://www.freebsdfoundation.org/ "We are working on providing Java 1.6 support for FreeBSD 6.3 and 7.0. The binaries for 7.0 will be available by June 1." Any news? :) Where I can read more? P.S. I understand that this is not the mailing list to ask, but I can't find better. -- Best Wishes, Stefan Lambrev ICQ# 24134177 From royce at alaska.net Fri Jun 6 19:46:12 2008 From: royce at alaska.net (Royce Williams) Date: Fri Jun 6 19:46:19 2008 Subject: 6.3 stability and freebsd-update (was: Re: challenge: end of life for 6.2 is premature with buggy 6.3) In-Reply-To: <1212768942.6066.20.camel@tremelay> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net> <702FA4B9-8CEE-4C9D-86A8-157CA1E69BD7@khera.org> <1212768942.6066.20.camel@tremelay> Message-ID: <48499129.4090704@alaska.net> >> On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote: >> >>> Speaking just for myself, I'd love to get a general response from >>> people who have run servers on both as to whether 6.3 is on average >>> more stable than 6.2. I really haven't gotten any clear impression as 6.3 has been stable for me. I've been running since April on DL380 G2, Dell 2450, Supermicro 5015M-MF and 5015T-PR, and some older Intel 815E boards. My bge(4) NICs are detected as Broadcom BCM5703 A2 and BCM5704 A2, with no issues. Running gmirror with no issues. Someone mentioned freebsd-update earlier in the thread. I'd like to take a moment to plug it, since making it easy to move to 6.3 seems topical. I got a little long-winded, so here's an executive summary: freebsd-update is good; business case for more hardware; updating in 'hybrid' mode with custom kernels and stock userland; using kernel config 'includes' to save additional effort. I prefer freebsd-update over the buildworld and then installworld-over-NFS routine, centralized rsyncs, or anything else. I used freebsd-update to uplift the systems above, and also just bumped sixteen more from 6.2. Worked like a charm. Its 'rollback' option is also very handy, for obvious reasons. Based on how much time I save with freebsd-update, I can make a business case for buying another box for a farm, rather than rolling my own kernels and eking out xx% of additional performance. Once ULE gets into 7.x-RELEASE, I probably won't even have to do that. For systems that require a custom kernel, we still patch everything else with freebsd-update. When freebsd-update detects the non-stock kernel, it warns you to install a kernel from the target release. If that scares you, you can swap in a stock kernel from the current release (saved off, or from the release media or FTP) and then upgrade. When finished, save off the new stock kernel for future upgrades, and then rebuild your custom kernel. (Anybody else doing anything like this, or something better?) I also recommend starting your kernel config with 'include SMP' (or GENERIC or PAE or whatever). If you use nocpu, nooptions, nomakeoptions, nodevice etc. to turn off what you don't need, your config is reduced to a 'diff' of sorts against the stock config. Our kernel configs are now ~17 lines, can be grokked at a glance, and should change little from release to release. Here's a stub of an example that uses most of the knobs: include SMP # Inherit SMP (which inherits GENERIC). nocpu I486_CPU # Disable old CPU support; see tuning(7). nocpu I586_CPU ident SMP-GENERIC_CUSTOM_FOO # Inherit ident, custom name. nomakeoption DEBUG # Do not build with gdb(1) debug symbols. nooptions SCHED_4BSD # Do not use the 4BSD scheduler; options SCHED_ULE # use ULE schedule instead. # ALTQ support options ALTQ options ALTQ_CBQ # Class Bases Queuing (CBQ) options ALTQ_RED # Random Early Detection (RED) options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build # Devices for pf device pf # PF device pflog # pflog device pfsync # pfsync Use 'nodevice' to turn off devices worth leaving out, but only as many as are worth the effort. If you haven't already considered freebsd-update, either for the whole system or just userland, I highly recommend it. These days, the gain has to be pretty significant for me to want to go back to making world. For our PXE installs using custom install.cfg, we can go from bare metal to a fully patched vanilla system in four minutes on modern hardware! The novelty of that still hasn't worn off. :-) It's more efficient (and probably safer?) to use freebsd-update against a binary install rather than against local compilation. And if you're bumping major versions (6.x -> 7.x), you still have to rebuild your ports. But try it in your lab or for your next deployment. You can easily convert a freebsd-updated system to a makeworld system, if necessary. And thanks again, Colin! Royce -- Royce D. Williams - http://royce.ws/ Inspiration exists, but it has to find us working. - Pablo Picasso From brooks at freebsd.org Fri Jun 6 19:52:27 2008 From: brooks at freebsd.org (Brooks Davis) Date: Fri Jun 6 19:52:31 2008 Subject: 6.3 stability and freebsd-update (was: Re: challenge: end of life for 6.2 is premature with buggy 6.3) In-Reply-To: <48499129.4090704@alaska.net> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net> <702FA4B9-8CEE-4C9D-86A8-157CA1E69BD7@khera.org> <1212768942.6066.20.camel@tremelay> <48499129.4090704@alaska.net> Message-ID: <20080606195231.GB2438@lor.one-eyed-alien.net> On Fri, Jun 06, 2008 at 11:34:01AM -0800, Royce Williams wrote: > >> On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote: > >> > >>> Speaking just for myself, I'd love to get a general response from > >>> people who have run servers on both as to whether 6.3 is on average > >>> more stable than 6.2. I really haven't gotten any clear impression as > > 6.3 has been stable for me. I've been running since April on DL380 > G2, Dell 2450, Supermicro 5015M-MF and 5015T-PR, and some older Intel > 815E boards. My bge(4) NICs are detected as Broadcom BCM5703 A2 and > BCM5704 A2, with no issues. Running gmirror with no issues. > > Someone mentioned freebsd-update earlier in the thread. I'd like to > take a moment to plug it, since making it easy to move to 6.3 seems > topical. I got a little long-winded, so here's an executive summary: > > freebsd-update is good; business case for more hardware; updating in > 'hybrid' mode with custom kernels and stock userland; using kernel > config 'includes' to save additional effort. > > > I prefer freebsd-update over the buildworld and then > installworld-over-NFS routine, centralized rsyncs, or anything else. > I used freebsd-update to uplift the systems above, and also just > bumped sixteen more from 6.2. Worked like a charm. Its 'rollback' > option is also very handy, for obvious reasons. > > Based on how much time I save with freebsd-update, I can make a > business case for buying another box for a farm, rather than rolling > my own kernels and eking out xx% of additional performance. Once ULE > gets into 7.x-RELEASE, I probably won't even have to do that. > > For systems that require a custom kernel, we still patch everything > else with freebsd-update. When freebsd-update detects the non-stock > kernel, it warns you to install a kernel from the target release. If > that scares you, you can swap in a stock kernel from the current > release (saved off, or from the release media or FTP) and then > upgrade. When finished, save off the new stock kernel for future > upgrades, and then rebuild your custom kernel. (Anybody else doing > anything like this, or something better?) Alternativly, you can edit freebsd-update.conf and tell it to not update your kernel on those machines. You can also exclude particular files. We use this to keep from updating libc directly on some machines where we're using modified RPC timings to improve NIS performance in the face of occataionl packet loss. -- Brooks > GENERIC or PAE or whatever). If you use nocpu, nooptions, > nomakeoptions, nodevice etc. to turn off what you don't need, your > config is reduced to a 'diff' of sorts against the stock config. Our > kernel configs are now ~17 lines, can be grokked at a glance, and > should change little from release to release. Here's a stub of an > example that uses most of the knobs: > > include SMP # Inherit SMP (which inherits GENERIC). > > nocpu I486_CPU # Disable old CPU support; see tuning(7). > nocpu I586_CPU > ident SMP-GENERIC_CUSTOM_FOO # Inherit ident, custom name. > > nomakeoption DEBUG # Do not build with gdb(1) debug symbols. > > nooptions SCHED_4BSD # Do not use the 4BSD scheduler; > options SCHED_ULE # use ULE schedule instead. > > # ALTQ support > options ALTQ > options ALTQ_CBQ # Class Bases Queuing (CBQ) > options ALTQ_RED # Random Early Detection (RED) > options ALTQ_RIO # RED In/Out > options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) > options ALTQ_PRIQ # Priority Queuing (PRIQ) > options ALTQ_NOPCC # Required for SMP build > > # Devices for pf > device pf # PF > device pflog # pflog > device pfsync # pfsync > > > Use 'nodevice' to turn off devices worth leaving out, but only as many > as are worth the effort. > > If you haven't already considered freebsd-update, either for the whole > system or just userland, I highly recommend it. These days, the gain > has to be pretty significant for me to want to go back to making > world. For our PXE installs using custom install.cfg, we can go from > bare metal to a fully patched vanilla system in four minutes on modern > hardware! The novelty of that still hasn't worn off. :-) > > It's more efficient (and probably safer?) to use freebsd-update > against a binary install rather than against local compilation. And > if you're bumping major versions (6.x -> 7.x), you still have to > rebuild your ports. But try it in your lab or for your next > deployment. You can easily convert a freebsd-updated system to a > makeworld system, if necessary. > > And thanks again, Colin! > > Royce > > -- > Royce D. Williams - http://royce.ws/ > Inspiration exists, but it has to find us working. - Pablo Picasso > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080606/2e88578c/attachment.pgp From spomerg at cwu.EDU Fri Jun 6 20:04:01 2008 From: spomerg at cwu.EDU (Gavin Spomer) Date: Fri Jun 6 20:04:05 2008 Subject: 6.2-STABLE => 7.0-STABLE Upgrade root partition more full Message-ID: <4849218F0200009000019B78@hermes.cwu.edu> I successfully did my first FreeBSD upgrade yesterday after looking at the manual, and cross referencing with Googling and getting help from our network engineer here at CWU. Before the upgrade, running df showed: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1a 507630 77662 389358 17% / devfs 1 1 0 100% /dev /dev/da0s1e 507630 588 466432 0% /tmp /dev/da0s1f 268217320 4866120 241893816 2% /usr /dev/da0s1d 4298926 162066 3792946 4% /var Now it shows: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1a 507630 184834 282186 40% / devfs 1 1 0 100% /dev /dev/da0s1e 507630 426 466594 0% /tmp /dev/da0s1f 268217320 5514844 241245092 2% /usr /dev/da0s1d 4298926 187570 3767442 5% /var Notice the the increase in the root partition. Should I have made this partition bigger when I first installed? Is there any cleaning up I can do after version upgrades? I would've thought /usr would be the one that grew more, but then again my /usr partition is fairly sizeable. Does 7.0 just take up a lot more of the root partition than 6.2? - Gavin From lists-fbsdstable at shadypond.com Fri Jun 6 20:50:58 2008 From: lists-fbsdstable at shadypond.com (Pollywog) Date: Fri Jun 6 20:51:03 2008 Subject: Java binaries for FreeBSD 7 In-Reply-To: <4849928F.6060502@moneybookers.com> References: <4849928F.6060502@moneybookers.com> Message-ID: <200806062048.03859.lists-fbsdstable@shadypond.com> On Friday 06 June 2008 19:39:59 Stefan Lambrev wrote: > Greetings, > > From http://www.freebsdfoundation.org/ > "We are working on providing Java 1.6 support for FreeBSD 6.3 and 7.0. > The binaries for 7.0 will be available by June 1." > > Any news? :) Where I can read more? > > P.S. I understand that this is not the mailing list to ask, but I can't > find better. Perhaps here http://www.freebsd.org/java/ From cliftonr at lava.net Fri Jun 6 20:56:36 2008 From: cliftonr at lava.net (Clifton Royston) Date: Fri Jun 6 20:56:39 2008 Subject: 6.2-STABLE => 7.0-STABLE Upgrade root partition more full In-Reply-To: <4849218F0200009000019B78@hermes.cwu.edu> References: <4849218F0200009000019B78@hermes.cwu.edu> Message-ID: <20080606205623.GA17905@lava.net> On Fri, Jun 06, 2008 at 11:37:51AM -0700, Gavin Spomer wrote: > I successfully did my first FreeBSD upgrade yesterday after looking at the manual, and cross referencing with Googling and getting help from our network engineer here at CWU. Before the upgrade, running df showed: > > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/da0s1a 507630 77662 389358 17% / > devfs 1 1 0 100% /dev > /dev/da0s1e 507630 588 466432 0% /tmp > /dev/da0s1f 268217320 4866120 241893816 2% /usr > /dev/da0s1d 4298926 162066 3792946 4% /var > > Now it shows: > > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/da0s1a 507630 184834 282186 40% / > devfs 1 1 0 100% /dev > /dev/da0s1e 507630 426 466594 0% /tmp > /dev/da0s1f 268217320 5514844 241245092 2% /usr > /dev/da0s1d 4298926 187570 3767442 5% /var > > Notice the the increase in the root partition. Should I have made > this partition bigger when I first installed? Is there any cleaning > up I can do after version upgrades? I would've thought /usr would be > the one that grew more, but then again my /usr partition is fairly > sizeable. Does 7.0 just take up a lot more of the root partition than > 6.2? Yes, it just does. It should not keep expanding, though. IMHO, you should still be fine as long as you've got /tmp, /usr/, /var, and the home directories residing on other partitions. If you're using /home under / for home directories, you might want to move it to /usr/home and symlink /home to it. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From skip at menantico.com Fri Jun 6 21:37:08 2008 From: skip at menantico.com (Skip Ford) Date: Fri Jun 6 21:37:12 2008 Subject: 6.2-STABLE => 7.0-STABLE Upgrade root partition more full In-Reply-To: <4849218F0200009000019B78@hermes.cwu.edu> References: <4849218F0200009000019B78@hermes.cwu.edu> Message-ID: <20080606203914.GA858@menantico.com> Gavin Spomer wrote: > I successfully did my first FreeBSD upgrade yesterday after looking at the manual, and cross referencing with Googling and getting help from our network engineer here at CWU. Before the upgrade, running df showed: > > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/da0s1a 507630 77662 389358 17% / > devfs 1 1 0 100% /dev > /dev/da0s1e 507630 588 466432 0% /tmp > /dev/da0s1f 268217320 4866120 241893816 2% /usr > /dev/da0s1d 4298926 162066 3792946 4% /var > > Now it shows: > > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/da0s1a 507630 184834 282186 40% / > devfs 1 1 0 100% /dev > /dev/da0s1e 507630 426 466594 0% /tmp > /dev/da0s1f 268217320 5514844 241245092 2% /usr > /dev/da0s1d 4298926 187570 3767442 5% /var > > Notice the the increase in the root partition. Should I have made this partition bigger when I first installed? Is there any cleaning up I can do after version upgrades? I would've thought /usr would be the one that grew more, but then again my /usr partition is fairly sizeable. Does 7.0 just take up a lot more of the root partition than 6.2? 7.0 installs debugging symbols for the kernel and modules by default. You can avoid that by defining INSTALL_NODEBUG during installkernel. If already installed, you can delete the symbol files without causing problems as long as you don't need to debug the kernel. Also, when you install a new kernel, the old kernel is saved as kernel.old so you now have 2 kernels in /boot instead of one. If you're positive the new kernel works fine, the old kernel can be removed as that's only used to recover from a new kernel with problems. But, your space really isn't that close to the limit, IMO. You appear to have enough space to have an old and new kernel installed both with symbols, so I'd leave it as is in case you need to debug something or boot the old kernel. You can always take care of it later if you're about to run out of space. Why do today what you can put off 'til tomorrow? Also, consider reading UPDATING before every upgrade. The entry for 20060118 covers this issue. -- Skip From ericlin at tamama.org Fri Jun 6 21:43:31 2008 From: ericlin at tamama.org (Lin Jui-Nan Eric) Date: Fri Jun 6 21:43:34 2008 Subject: TMPFS: File System is Full Message-ID: <47713ee10806061443v3e44576am2facb75df031f47e@mail.gmail.com> Hi, I found when we exhaust memory, tmpfs will not be able to write anything into it and cannot mount it. I use ZFS and TMPFS at the same time. Florence# cd /usr/src && make buildworld > /dev/null & Florence# uname -a FreeBSD Florence.tamama.org 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #5: Mon May 5 00:36:32 CST 2008 root@Florence.tamama.org:/usr/obj/usr/src/sys/KERNEL amd64 Florence# mount -t tmpfs -o rw,size=1024000 tmpfs /tmp/tmpfs mount: tmpfs : No space left on device first 5 lines of top: last pid: 26893; load averages: 1.50, 1.58, 1.48 up 12+01:43:49 05:40:51 146 processes: 2 running, 144 sleeping CPU states: % user, % nice, % system, % interrupt, % idle Mem: 406M Active, 574M Inact, 1775M Wired, 83M Cache, 214M Buf, 126M Free Swap: 1024M Total, 1024M Free I think there should be a "lower bound" size limit. Does TMPFS use kernel-space memory? From 000.fbsd at quip.cz Fri Jun 6 23:03:38 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Fri Jun 6 23:03:42 2008 Subject: freebsd-update 6.2-R -> 6.3-B1 rollback failed In-Reply-To: <473F0939.9050800@freebsd.org> References: <473B5D10.1070109@janh.de> <473BD54F.9050808@freebsd.org> <473C1FD1.70001@janh.de> <473DA6B5.10107@freebsd.org> <473EF438.5090004@janh.de> <473F0939.9050800@freebsd.org> Message-ID: <4849C258.6090003@quip.cz> Colin Percival wrote: > Jan Henrik Sylvester wrote: > >>>In short, as long as you don't build a custom kernel but call it >>>"GENERIC" or >>>"SMP", FreeBSD Update should automatically DTRT. >> >>That is exactly my question. On 6.2-RELEASE, I sometimes used a modified >>ld-elf.so.1 or a single patched module without recompiling the kernel. >>What does using freebsd-update (accidentally or deliberately) do in that >>case? By accident, I discovered that it does not always fail. Does it >>skip the modified files, overwrite them with new versions, or overwrite >>them with an unpredictable bdiff merge that is likely garbage? > > > Depending on the UpdateIfUnmodified option in freebsd-update.conf, it will > either update files to "clean" new versions or print a warning message and > not touch them. > > There's also an IgnorePaths directive which you can use to tell FreeBSD > Update not to touch some files (even if they haven't been modified locally). > > FreeBSD Update will never produce mangled files as a result of applying a > bsdiff patch to the wrong file -- it checks file hashes before and after > applying patches and gracefully falls back to downloading complete files > if it can't generate a file via patching. Is it possible to configure freebsd-update to not remove old kernel directory and just rename it to kernel.old or something else? Two times I end up with unbootable machine (upgraded from 6.3 to 7.0 - 7.x version kernel always hangs on this machine, even with CD boot) and then I must use bootable CD / flashdisk with old 6.x kernel to be able to run freebsd-update rollback. It will be useful if one can choose to leave old kernel in boot directory to be able to boot it if something goes wrong. Miroslav Lachman From deb at freebsd.org Sat Jun 7 02:54:04 2008 From: deb at freebsd.org (Deb Goodkin) Date: Sat Jun 7 02:54:08 2008 Subject: Java Status Message-ID: <4849EF89.20909@freebsd.org> Dear Stefan, I'm responding to your inquiry about the Java binaries. I just updated our website with the current status. We have completed the certification testing of Java 1.6 on FreeBSD 7. We are now waiting for approval from Sun. We anticipate it to take another two weeks. Please let me know if you have any other questions. Sincerely, Deb Goodkin Director of Operations The FreeBSD Foundation From pschmehl_lists at tx.rr.com Sat Jun 7 03:18:14 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Sat Jun 7 03:18:19 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080606115349.452eea4b.usselmann.m@icg-online.de> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <200806051023.56065.jhb@freebsd.org> <1212684781.10665.81.camel@localhost> <8A3638B8BF777C9DF4AB354A@utd65257.utdallas.edu> <20080606115349.452eea4b.usselmann.m@icg-online.de> Message-ID: --On June 6, 2008 11:53:49 AM +0200 Manfred Usselmann wrote: > > What you are saying sounds like a contradiction to me. On one side it > is just a hobby site and generates no income and on the other hand it > is a critical server with millions of hits and the box can't even go > down for a short time. > > What happens in case lets say your harddisk crashes? Something which is > not an exactly rare case... > Actually, that happened to us a couple of years ago, on the old server while it still the only server, and I was on vacation 1600 miles away. We ended up having to pay the hosting company to fix the hardware problem and reinstall FreeBSD (which they unfortunately did a lousy job of), and then I rebuilt the server and restored it to service over a dialup account while on vacation. Many of our users are retired old guys who can barely figure out how to use a computer. When the site goes down, some of them claim to go into withdrawal. The total downtime for that incident was about two days, and they "suffered" greatly. > If the users are not paying for the service they should be able to > accept a downtime, may it be scheduled or even completely unexpected. > Or pay / donate for a more reliable service (Redundant server as hot > standby / testbed etc.). > Actually, it was the owners who had to be convinced to accept donations from the users, who were all too willing to help. The new server was purchased with those donations. Maybe some day we *will* be able to afford redundancy. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer. From pschmehl_lists at tx.rr.com Sat Jun 7 04:37:31 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Sat Jun 7 04:37:35 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <86tzg6aeye.fsf@ds4.des.no> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <86tzg6aeye.fsf@ds4.des.no> Message-ID: <5B0709D83455470DA46533C4@Macintosh.local> --On June 6, 2008 3:08:25 PM +0200 Dag-Erling Sm?rgrav wrote: > Paul Schmehl writes: >> [...] I reacted in anger because I felt the OP was being savagely >> attacked rather than being responded to with professionalism. Later >> in the thread some folks got around to asking which PRs he was >> referring to, but that was after attacking him for having the temerity >> to suggest that perhaps 6.2 shouldn't be EOL. [...] I don't recall >> him ever refusing. I think after his initial post he's been forced to >> defend himself from attack from 360 degrees. [...] > > I came in late, and thus had the benefit of reading most of thread in > context rather than piece by piece over time, and in my opinion, the > above is a gross misrepresentation. I think you need to go back and > re-read the thread from the beginning. Here, let me help you. Thanks for the help. My point still stands. I think the behavior of the developers on the lists should be of as high a quality as the work they do on the OS (which, as I have stated, is first rate.) Descending to the levels that some have (some of which you quote here) reflects poorly on the OS and its developers. The fact that FreeBSD is open source does not negate the fact that its users are its customers and should be treated with respect, professionalism and yes, patience. And again, I am trying neither to excuse nor to defend Jo's behavior. That's his gauntlet. I am saying that the fact that developers possess a unique and valuable skill that is much appreciated by those of us who use the product of their labor does not excuse or justify some of the boorish behavior that was exhibited in this thread - regardless of how insulting one may have felt Jo's responses were. Since a lot of people seem to want to pontificate without doing much of anything helpful, allow me to bring this discussion back to Jo's point: That url lists 6 serious problems for bge and 3 non-critical problems, some dating to more than two years ago. Two were patched, one is suspended and 6 are still open; four of those critical. That url lists 1 serious problem and 3 non-critical problems with gmirror, all of which remain open. That url refers to locking problems that cause kernel panics using the twe driver. That url refers to a hang that renders a system unusable when using the twa driver. Jo's concerns about updating to 6.3 rather than sticking with a system that's working for him don't seem unreasonable to me. Do they to you? Furthermore, it seems the reaction of developers, that he wasn't being specific enough are rendered moot by the urls above, which were easily accessed by me, someone with little knowledge at all of two of the three issues. So, rather than berating Jo for not producing PRs, wouldn't it have been more professional to list the relevant PRs (just as I have done, which took me less time than the multiple angry responses to Jo took the involved developers) and ask him which of them gave him the greatest concerns? What's the point of the constant demands to either produce specific relevant information of STFU? Are the developers trying to impress the list with their professionalism? Their patience? Their knowledge? If you're offended that I hold the developers to a higher standard than I do the users, then I plead guilty as charged and believe I am correct to do so. As to your specific points: >> I'm sorry that the FreeBSD project failed to conform to your >> expectations. However, I invite you to actually try 6.3 for yourself >> instead of assuming that it will fail. > > This is the crux of the matter - Jo is complaining about software he > hasn't even tried. There is absolutely no way anybody can help him > until he actually tries 6.3 and reports any actual bugs and regressions > he finds." Not only is this wrong, but it completely misses the point. Why should Jo have to upgrade to find out if his servers will fail under the conditions already articulated in existing, unresolved PRs that affect hardware that he is presently using? That's a bit like saying, "Buy this new car. Sure it has bugs that could easily directly affect you, but what's the chance you'll encounter them? in the off chance that they do, then you can help us resolve them." You reveal extreme naivette when you state this: > That is also untrue. None of these are "bugs that are affecting [Jo]", > since he hasn't tried running 6.3 at all. Trust me. From a server admin's perspective, a bug affects you if it exists in hardware you use. Whether or not you're actually using the OS is completely irrelevant. Upgrading to the OS would be foolhardy. Even testing it on a handful of boxes will not prove that it won't fail under load in production. Anyone who has done testing knows it can only simulate, not duplicate, the conditions under which production servers run. I personally have experienced catastrophic failures after extensive testing that revealed no problems. A civic-minded, community oriented FreeBSD user might volunteer a box to act as a guinea pig (and Jo has), but a server admin would be a bit nuts to experiment with his infrastructure. Nor do the claims of others that he ought to have a test bed or he's negligent impress me. No one but he knows the constraints that prevent him from doing so. Any assumptions otherwise simply reveal the biases and ignorance of those making the claim. All of us are constrained to one degree or another by our circumstances, and the assumption that someone else's circumstances mirror our own reveals either an ignorance of reality or an arrogance that is unseemly. Furthermore, other users who are already running 6.3 with no reported problems would not reassure me that I would not encounter the problems that are clearly articulated in the PRs and which directly affect my hardware and remain unresolved! Or perhaps the developers believe that Jo is simply lying when he says they affect him and refuse to listen to him until he provides the proof by upgrading and experiencing breakage? Yes, I think some perspective is needed here, but it's not only Jo who needs it nor is it he who needs it the most. I've lectured enough. If anyone doesn't get the point by now further explanation isn't going to help. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer. From ericlin at tamama.org Sat Jun 7 05:13:14 2008 From: ericlin at tamama.org (Lin Jui-Nan Eric) Date: Sat Jun 7 05:13:17 2008 Subject: TMPFS: File System is Full In-Reply-To: <47713ee10806061443v3e44576am2facb75df031f47e@mail.gmail.com> References: <47713ee10806061443v3e44576am2facb75df031f47e@mail.gmail.com> Message-ID: <47713ee10806062148l4a4c4550hcd8c70a422343c2a@mail.gmail.com> Hi, I found when we exhaust memory, tmpfs will not be able to write anything into it and cannot mount it. I use ZFS and TMPFS at the same time. Florence# cd /usr/src && make buildworld > /dev/null & Florence# uname -a FreeBSD Florence.tamama.org 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #5: Mon May 5 00:36:32 CST 2008 root@Florence.tamama.org:/usr/obj/usr/src/sys/KERNEL amd64 Florence# mount -t tmpfs -o rw,size=1024000 tmpfs /tmp/tmpfs mount: tmpfs : No space left on device first 5 lines of top: last pid: 26893; load averages: 1.50, 1.58, 1.48 up 12+01:43:49 05:40:51 146 processes: 2 running, 144 sleeping CPU states: % user, % nice, % system, % interrupt, % idle Mem: 406M Active, 574M Inact, 1775M Wired, 83M Cache, 214M Buf, 126M Free Swap: 1024M Total, 1024M Free I think there should be a "lower bound" size limit. Does TMPFS use kernel-space memory? From adrian at freebsd.org Sat Jun 7 06:41:33 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Sat Jun 7 06:41:37 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <5B0709D83455470DA46533C4@Macintosh.local> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <86tzg6aeye.fsf@ds4.des.no> <5B0709D83455470DA46533C4@Macintosh.local> Message-ID: 2008/6/7 Paul Schmehl : > Not only is this wrong, but it completely misses the point. Why should Jo > have to upgrade to find out if his servers will fail under the conditions > already articulated in existing, unresolved PRs that affect hardware that he > is presently using? That's a bit like saying, "Buy this new car. Sure it > has bugs that could easily directly affect you, but what's the chance you'll > encounter them? in the off chance that they do, then you can help us > resolve them." The software is Free. The car was Bought (or suggested to be bought.) Re-visit the analogy with a free car that a friend wants to give you. (Car analogies suck.) > Trust me. From a server admin's perspective, a bug affects you if it exists > in hardware you use. Whether or not you're actually using the OS is > completely irrelevant. Upgrading to the OS would be foolhardy. Even > testing it on a handful of boxes will not prove that it won't fail under > load in production. Anyone who has done testing knows it can only simulate, > not duplicate, the conditions under which production servers run. I > personally have experienced catastrophic failures after extensive testing > that revealed no problems. You're using free software. This translates to "lots of people have put in a lot of effort to provide something to the community which they can use, at no cost, if it suits them." As said before, the reason FreeBSD isn't supporting older 6.x releases anymore is because there's just no manpower to do so. > Yes, I think some perspective is needed here, but it's not only Jo who needs > it nor is it he who needs it the most. > > I've lectured enough. If anyone doesn't get the point by now further > explanation isn't going to help. I still don't think you get it. FreeBSD is a community. A community works when enough people contribute positively towards furthering the goals of the project. Jo is a user. He sounds like he is using it in some reasonably critical and money-earning roles. Jo can participate by testing stuff on test hardware, reporting back issues and working with the community. Bitching about there being no long-term support for releases isn't constructive. Some developer comments may not be constructive either, but this is a -community project-. Join the -community- and help out. It doesn't matter if running a long-term support project would be beneficial for a certain subset of the userbase, its a losing situation to cater to them unless they somehow contribute back to the community. adrian -- Adrian Chadd - adrian@freebsd.org From kostikbel at gmail.com Sat Jun 7 08:56:12 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Jun 7 08:56:17 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <86tzg6aeye.fsf@ds4.des.no> <5B0709D83455470DA46533C4@Macintosh.local> Message-ID: <20080607085607.GM94309@deviant.kiev.zoral.com.ua> On Sat, Jun 07, 2008 at 02:41:32PM +0800, Adrian Chadd wrote: > 2008/6/7 Paul Schmehl : > > > Not only is this wrong, but it completely misses the point. Why should Jo > > have to upgrade to find out if his servers will fail under the conditions > > already articulated in existing, unresolved PRs that affect hardware that he > > is presently using? That's a bit like saying, "Buy this new car. Sure it > > has bugs that could easily directly affect you, but what's the chance you'll > > encounter them? in the off chance that they do, then you can help us > > resolve them." > > The software is Free. The car was Bought (or suggested to be bought.) > > Re-visit the analogy with a free car that a friend wants to give you. > (Car analogies suck.) > > > > Trust me. From a server admin's perspective, a bug affects you if it exists > > in hardware you use. Whether or not you're actually using the OS is > > completely irrelevant. Upgrading to the OS would be foolhardy. Even > > testing it on a handful of boxes will not prove that it won't fail under > > load in production. Anyone who has done testing knows it can only simulate, > > not duplicate, the conditions under which production servers run. I > > personally have experienced catastrophic failures after extensive testing > > that revealed no problems. > > You're using free software. This translates to "lots of people have > put in a lot of effort to provide something to the community which > they can use, at no cost, if it suits them." > > As said before, the reason FreeBSD isn't supporting older 6.x releases > anymore is because there's just no manpower to do so. I want to correct this statement. We do support 6.x releases, but do this exactly in the form of RELENG_6 and further releases from this branch, that are in fact snapshots with more quality engineering applied then usual. A lot of the work put on the RELENG_6 is the support, i.e. bug fixes and quite conservative feature merges. Comparing us with, e.g., Solaris, we would not find a lot of difference in the support model. Althought they formally provide patches for Solaris 10 FCS, after patching you find youself running on the same kernel as the Solaris 10 u5 or later. There could be an argument of more granularity of the patches then the whole release, but inter-patch dependencies again make the difference almost non-existent, IMHO. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080607/5d105223/attachment-0001.pgp From david.buxton at zen.co.uk Sat Jun 7 11:30:38 2008 From: david.buxton at zen.co.uk (David Buxton) Date: Sat Jun 7 11:30:42 2008 Subject: SCSI bus reset with Adaptec 29320ALP and Eonstor RAID In-Reply-To: References: Message-ID: <7C5675E4-982E-4F83-B7CF-13D4DC2C5905@zen.co.uk> On 27 May 2008, at 23:00, David Buxton wrote: > Hello, > > I am trying to use a 1.5TB Eonstor raid array with FreeBSD 7.0, but > I don't understand whether it is the raid or the scsi card or > something else that is causing the computer problems when accessing > the raid. My problem is that soon after recognizing the attached > disk during boot, FreeBSD appears to hang for about 10 seconds and > then says To follow up: Matthew Herzog recommended I ditch the Adaptec 29320 card. I installed an LSI 20320-R yesterday and the errors disappeared. The RAID works perfectly. The Adaptec card went straight in the bin. David. From yurtesen at ispro.net Sat Jun 7 14:51:25 2008 From: yurtesen at ispro.net (Evren Yurtesen) Date: Sat Jun 7 14:51:29 2008 Subject: cpufreq broken on core2duo In-Reply-To: <200806051040.28319.jhb@freebsd.org> References: <4847072E.5000709@ispro.net> <484713B2.5030200@ispro.net> <48471834.30905@modulus.org> <200806051040.28319.jhb@freebsd.org> Message-ID: <484AA07A.2010308@ispro.net> John Baldwin wrote: > On Wednesday 04 June 2008 06:33:24 pm Andrew Snow wrote: >> Evren Yurtesen wrote: >> >>> When you say that it doesnt work, does it give an error or? In my case >>> it doesnt give any errors just says it set it but I see that nothing is >>> set. >> Here's one box: >> >> CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz >> cpu0: on acpi0 >> est0: on cpu0 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 61a49200600091a >> device_attach: est0 attach returned 6 >> p4tcc0: on cpu0 >> >> >> Here's another one: >> CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz >> cpu0: on acpi0 >> est0: on cpu0 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 720072006000720 >> device_attach: est0 attach returned 6 >> p4tcc0: on cpu0 > > You can try http://www.FreeBSD.org/~jhb/patches/est_msr.patch. It won't give > you the full range of speeds for you CPU, but it should give you the high and > low values that we can guess from the upper 32-bits of the MSR. > The patch is causing errors in kernel compilation in FreeBSD 7-Stable. inter-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -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 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/kern/imgact_elf32.c cc -c -O -pipe -march=nocona -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -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 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/i386/cpufreq/powernow.c cc -c -O -pipe -march=nocona -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -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 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/i386/cpufreq/est.c /usr/src/sys/i386/cpufreq/est.c: In function 'bus_speed_ok': /usr/src/sys/i386/cpufreq/est.c:1206: error: invalid storage class for function 'est_msr_info' cc1: warnings being treated as errors /usr/src/sys/i386/cpufreq/est.c:1206: warning: no previous prototype for 'est_msr_info' /usr/src/sys/i386/cpufreq/est.c:1270: error: invalid storage class for function 'est_get_id16' /usr/src/sys/i386/cpufreq/est.c:1270: warning: no previous prototype for 'est_get_id16' /usr/src/sys/i386/cpufreq/est.c:1276: error: invalid storage class for function 'est_set_id16' /usr/src/sys/i386/cpufreq/est.c:1276: warning: no previous prototype for 'est_set_id16' /usr/src/sys/i386/cpufreq/est.c:1303: error: invalid storage class for function 'est_get_current' /usr/src/sys/i386/cpufreq/est.c:1303: warning: no previous prototype for 'est_get_current' /usr/src/sys/i386/cpufreq/est.c:1326: error: invalid storage class for function 'est_settings' /usr/src/sys/i386/cpufreq/est.c:1326: warning: no previous prototype for 'est_settings' /usr/src/sys/i386/cpufreq/est.c:1350: error: invalid storage class for function 'est_set' /usr/src/sys/i386/cpufreq/est.c:1350: warning: no previous prototype for 'est_set' /usr/src/sys/i386/cpufreq/est.c:1371: error: invalid storage class for function 'est_get' /usr/src/sys/i386/cpufreq/est.c:1371: warning: no previous prototype for 'est_get' /usr/src/sys/i386/cpufreq/est.c:1390: error: invalid storage class for function 'est_type' /usr/src/sys/i386/cpufreq/est.c:1390: warning: no previous prototype for 'est_type' /usr/src/sys/i386/cpufreq/est.c:1397: error: expected declaration or statement at end of input *** Error code 1 Stop in /usr/obj/usr/src/sys/MAIL. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. mail:/usr/src# By the way, there is another thing I am wondering about. If I enable HTT and Intel Enhanced SpeedStep in bios on a 3.00GHZ p4 CPU I see: cpu0: on acpi0 acpi_perf0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr f2700000f27 device_attach: est1 attach returned 6 p4tcc1: on cpu1 dev.cpu.0.freq_levels: 1500/27000 1312/23625 1200/13000 1050/11375 900/9750 750/8125 600/6500 450/4875 300/3250 150/1625 dev.acpi_perf.0.freq_settings: 1500/27000 1200/13000 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.cpufreq.1.%driver: cpufreq dev.cpufreq.1.%parent: cpu1 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 and it does not allow me to set the freq. of the cpu. If I disable HTT then I see: cpu0: on acpi0 est0: on cpu0 est0: Setting 1500 MHz p4tcc0: on cpu0 dev.cpu.0.freq: 1500 dev.cpu.0.freq_levels: 1500/27000 1312/23625 1200/13000 1050/11375 900/9750 750/8125 600/6500 450/4875 300/3250 150/1625 dev.est.0.freq_settings: 1500/27000 1200/13000 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 I see the vcore goes to 2.32 when I set the speed to 150 according to mbmon, and when I set the speed to 1500 vcore goes to 2.51 Independent of HTT being active or not, when I enable Intel Enhanced SpeedStep from the bios I start seeing calcru messages: calcru: runtime went backwards from 6 usec to 3 usec for pid 37 (pagezero) calcru: runtime went backwards from 6 usec to 3 usec for pid 36 (vmdaemon) calcru: runtime went backwards from 170 usec to 138 usec for pid 35 (pagedaemon) calcru: runtime went backwards from 553 usec to 291 usec for pid 15 (swi6: task queue) calcru: runtime went backwards from 15521 usec to 10366 usec for pid 2 (g_event) calcru: runtime went backwards from 25 usec to 12 usec for pid 11 (swi1: net) calcru: runtime went backwards from 4417 usec to 3960 usec for pid 1 (init) calcru: runtime went backwards from 2084385 usec to 1793542 usec for pid 1 (init) calcru: runtime went backwards from 408 usec to 204 usec for pid 0 (swapper) Another weird thing is that if I keep HTT enable but disable Intel Enhanced SpeedStep then I see: cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr f2700000f27 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr f2700000f27 device_attach: est1 attach returned 6 p4tcc1: on cpu1 and dev.cpu.0.freq: 2978 dev.cpu.0.freq_levels: 2978/-1 2605/-1 2233/-1 1861/-1 1489/-1 1116/-1 744/-1 372/-1 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.cpufreq.1.%driver: cpufreq dev.cpufreq.1.%parent: cpu1 Notice the correct frequency and changing dev.cpu.0.freq effects the openssl speed rsa test so it is working. However when I change the dev.cpu.0.freq I receive an error (but it changes anyway): mail:/root#sysctl -w dev.cpu.0.freq=2978 dev.cpu.0.freq: 744 sysctl: dev.cpu.0.freq: Invalid argument mail:/root#sysctl -w dev.cpu.0.freq=2978 dev.cpu.0.freq: 2978 sysctl: dev.cpu.0.freq: Invalid argument mail:/root# and the openssl speed rsa test returns results which are consistent with the speed set. But, regardless of the speed set, mbmon shows 2.54volts all the time. When HTT and Intel Enhanced Speedstep is disabled in bios I see: cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr f2700000f27 device_attach: est0 attach returned 6 p4tcc0: on cpu0 and dev.cpu.0.freq: 2977 dev.cpu.0.freq_levels: 2977/-1 2604/-1 2232/-1 1860/-1 1488/-1 1116/-1 744/-1 372/-1 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 Also the sysctl changes do not return an error however the vcore voltage still remains constant according to mbmon. Is there a reason why HTT is not properly detected by cpufreq and behaved accordingly? Thanks, Evren Thanks, Evren From koitsu at FreeBSD.org Sat Jun 7 16:48:13 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Jun 7 16:48:15 2008 Subject: cpufreq broken on core2duo In-Reply-To: <484AA07A.2010308@ispro.net> References: <4847072E.5000709@ispro.net> <484713B2.5030200@ispro.net> <48471834.30905@modulus.org> <200806051040.28319.jhb@freebsd.org> <484AA07A.2010308@ispro.net> Message-ID: <20080607164812.GA11072@eos.sc1.parodius.com> On Sat, Jun 07, 2008 at 05:51:38PM +0300, Evren Yurtesen wrote: > By the way, there is another thing I am wondering about. If I enable HTT > and Intel Enhanced SpeedStep in bios on a 3.00GHZ p4 CPU I see: > > cpu0: on acpi0 > acpi_perf0: on cpu0 > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr f2700000f27 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > > dev.cpu.0.freq_levels: 1500/27000 1312/23625 1200/13000 1050/11375 900/9750 > 750/8125 600/6500 450/4875 300/3250 150/1625 > dev.acpi_perf.0.freq_settings: 1500/27000 1200/13000 > dev.cpufreq.0.%driver: cpufreq > dev.cpufreq.0.%parent: cpu0 > dev.cpufreq.1.%driver: cpufreq > dev.cpufreq.1.%parent: cpu1 > dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 > 2500/-1 1250/-1 > dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 > 2500/-1 1250/-1 > > and it does not allow me to set the freq. of the cpu. How are you setting the frequency? Are you using powerd? You do not have to enable SpeedStep in your BIOS to achieve throttling CPU clock speed. In fact, I would highly recommend leaving EIST/SpeedStep in the BIOS *disabled*, and let powerd adjust the clock frequency via ACPI. > I see the vcore goes to 2.32 when I set the speed to 150 according to > mbmon, and when I set the speed to 1500 vcore goes to 2.51 mbmon is giving you wrong values. There is no way your Vcore on a P4 is 2.32 or 2.51 volts. It's very likely that mbmon doesn't support your hardware monitoring I/C. What motherboard (exact model) do you have? > Independent of HTT being active or not, when I enable Intel Enhanced > SpeedStep from the bios I start seeing calcru messages: > > calcru: runtime went backwards from 6 usec to 3 usec for pid 37 (pagezero) > calcru: runtime went backwards from 6 usec to 3 usec for pid 36 (vmdaemon) > calcru: runtime went backwards from 170 usec to 138 usec for pid 35 (pagedaemon) > calcru: runtime went backwards from 553 usec to 291 usec for pid 15 (swi6: > task queue) > calcru: runtime went backwards from 15521 usec to 10366 usec for pid 2 (g_event) > calcru: runtime went backwards from 25 usec to 12 usec for pid 11 (swi1: net) > calcru: runtime went backwards from 4417 usec to 3960 usec for pid 1 (init) > calcru: runtime went backwards from 2084385 usec to 1793542 usec for pid 1 (init) > calcru: runtime went backwards from 408 usec to 204 usec for pid 0 (swapper) I've documented this problem quite clearly on my Commonly Reported Issues wiki page. See "Kernel - EIST incompatibilities": http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues The solution is to keep EIST (SpeedStep) disabled in the BIOS. You can still use powerd to adjust CPU clock frequency via ACPI. > Another weird thing is that if I keep HTT enable but disable Intel Enhanced > SpeedStep then I see: > > ... > > Also the sysctl changes do not return an error however the vcore voltage > still remains constant according to mbmon. Again: it's highly unlikely mbmon is returning correct values. mbmon and healthd both were written with very old hardware (circa late 90s, very early 2001-2002) in mind. The chips they support are not very common on consumer motherboards, and are no longer used on server motherboards. You might be interested in my bsdhwmon(8) application, but please note I'm trying to avoid supporting any sort of "consumer" motherboards, because many of them do not offer SMBus tie-ins, not to mention many consumer board vendors don't provide any sort of documentation on how to access said H/W IC functionality: http://bsdhwmon.parodius.com/ -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From kensmith at cse.Buffalo.EDU Sat Jun 7 18:01:15 2008 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Sat Jun 7 18:01:21 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <5B0709D83455470DA46533C4@Macintosh.local> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <86tzg6aeye.fsf@ds4.des.no> <5B0709D83455470DA46533C4@Macintosh.local> Message-ID: <1212861667.94878.17.camel@neo.cse.buffalo.edu> On Fri, 2008-06-06 at 23:37 -0500, Paul Schmehl wrote: > My point still stands. I think the behavior of the developers on the > lists should be of as high a quality as the work they do on the OS (which, > as I have stated, is first rate.) Descending to the levels that some have > (some of which you quote here) reflects poorly on the OS and its > developers. I can empathize somewhat with your sentiment. But at the same time I can see where what you are criticizing comes from. As others have said Free Software Projects function as communities. Look around your (real) community. I'm guessing you'll see all sorts of different personalities. And those personalities are often times not shy about speaking their views. Now, factor that in with the following analogy. We've all seen scenes on TV shows or in movies where a customer sends a dish back to the kitchen via the waiter complaining about something. The chef proceeds to pick up a meat cleaver and head towards the door, only to be stopped by the waiter. Sometimes on the mailing lists you'll see the reaction of the chef, there is no waiter to stop him/her. That's just the nature of the community structure surrounding Open Source Projects and it's not unique to FreeBSD. Corporations you can expect to be held to higher standards, or more specifically held to standards that you would hold all corporations to. When on the mailing lists you can't expect "corporate standards", what you'll get is "community standards". -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080607/4c0fae1c/attachment.pgp From andrew-freebsd at areilly.bpc-users.org Sat Jun 7 19:20:35 2008 From: andrew-freebsd at areilly.bpc-users.org (Andrew Reilly) Date: Sat Jun 7 19:20:39 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <702FA4B9-8CEE-4C9D-86A8-157CA1E69BD7@khera.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net> <702FA4B9-8CEE-4C9D-86A8-157CA1E69BD7@khera.org> Message-ID: <20080607125332.GA8784@duncan.reilly.home> On Fri, Jun 06, 2008 at 12:08:54PM -0400, Vivek Khera wrote: > > On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote: > > > Speaking just for myself, I'd love to get a general response from > >people who have run servers on both as to whether 6.3 is on average > >more stable than 6.2. I really haven't gotten any clear impression as > > I'll throw in my "+1" for running 6.3. I have it on many boxes, some > of which run gmirror and some of which have bge devices (some with > both). Never any problems. They operate things varying from Postgres > servers to DNS servers to mail servers (postfix) under pretty > consistent load pushing lots and lots of data both network and to disk. I'll second your "+1" for 6.3 and raise you a 7.0. My main server is a 1U Dell box with bge network interfaces and it's as happy as a clam under 7.0 (infrequently updated _STABLE, actually). All of my more single-use boxes are happy 7_STABLE campers, too. Most of 'em are close to 0 load average, but they're important, continuously used by their smallish user base, and stay up. Cheers, Andrew From arno at heho.snv.jussieu.fr Sat Jun 7 19:22:16 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Sat Jun 7 19:22:21 2008 Subject: cpufreq for Opteron quad-core (2354) Message-ID: Hello, apparently powernow on Opteron quad-core is not recognised; when I kldload cpufreq (leaving it out of kernel) I get : pci0: driver added pci1: driver added pci2: driver added pci3: driver added pci4: driver added pci5: driver added pci6: driver added found-> vendor=0x9005, dev=0x0285, revid=0x00 domain=0, bus=6, slot=14, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x0196, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0xf8 (7440 ns), mingnt=0x01 (250 ns), maxlat=0x01 (250 ns) intpin=a, irq=28 powerspec 2 supports D0 D1 D3 current D0 MSI supports 2 messages, 64 bit pci0:6:14:0: reprobing on driver added pci7: driver added pci8: driver added pci9: driver added pci10: driver added but no dev.cpu.0.freq* showing up. When I dig up the by me so beloved good old acpi_ppc it says : cpu0: Px state: P0, 2200MHz, 28000mW, 19us, 19us cpu0: Px state: P1, 2000MHz, 26250mW, 19us, 19us cpu0: Px state: P2, 1700MHz, 23750mW, 19us, 19us cpu0: Px state: P3, 1400MHz, 21250mW, 19us, 19us cpu0: Px state: P4, 1100MHz, 18750mW, 19us, 19us cpu0: Px method: Unknown, disabled This box will probably stay at my office for a while and I'd be glad to provide more information. Best, Arno From andy.kosela at gmail.com Sat Jun 7 19:23:37 2008 From: andy.kosela at gmail.com (Andy Kosela) Date: Sat Jun 7 19:23:43 2008 Subject: Current status of support for high end SAN hardware Message-ID: <3cc535c80806071158h44ec9be1pbe72ca6711016bde@mail.gmail.com> Hi all, What is the current status of support for high end SAN hardware in FreeBSD? I'm especially interested in support for HP EVA/XP disk arrays, Qlogic HBAs, multipathing. How FreeBSD compares in this environment to RHEL 5? -- Andy Kosela ora et labora From kutulu at kutulu.org Sat Jun 7 19:31:21 2008 From: kutulu at kutulu.org (Mike Edenfield) Date: Sat Jun 7 19:31:26 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <5B0709D83455470DA46533C4@Macintosh.local> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <86tzg6aeye.fsf@ds4.des.no> <5B0709D83455470DA46533C4@Macintosh.local> Message-ID: <484AE20C.3060408@kutulu.org> Paul Schmehl wrote: > Furthermore, it seems the reaction of developers, that he wasn't being > specific enough are rendered moot by the urls above, which were easily > accessed by me, someone with little knowledge at all of two of the > three issues. So, rather than berating Jo for not producing PRs, > wouldn't it have been more professional to list the relevant PRs (just > as I have done, which took me less time than the multiple angry > responses to Jo took the involved developers) and ask him which of > them gave him the greatest concerns? I'm sure I'm not the only person besides yourself who's actually done the searches to see if there are any PRs I may be able to shed light on for Jo. I also briefly read each PR, and even a brief persual would show: > > > That url lists 6 serious problems for bge and 3 non-critical problems, > some dating to more than two years ago. Two were patched, one is > suspended and 6 are still open; four of those critical. Only 3 (2 critical and one patched) of which are specific to 6.3. One is specific to IPv6 and one only occurring on the second of a dual-card configuration; we have no reason to believe that either of these relate to Jo's environment without his providing that kind of detail. > > That url lists 1 serious problem and 3 non-critical problems with > gmirror, all of which remain open. Only one of these is specific to 6.3, and it appears very low priority, almost cosmetic. > > > > That url refers to locking problems that cause kernel panics using the > twe driver. This appears to be a bug in aac, not twe. > > > That url refers to a hang that renders a system unusable when using > the twa driver. And it was present in 6.2. Unfortunately the URLs only serve to make the developer's points for them. None of them gives any indication of what problem Jo may be referring to that is preventing him from upgrading to 6.3. Remember, he claims to have multiple servers running 6.2 with no issues, and is only concerned with upgrades to 6.3. He also stated that the PR's he's worried about explicitly stated that they could not be reproduced in 6.2, so any bug that existed in 6.2 clearly doesn't qualify. That rules out all but two bugs, both of which are so specific to a given hardware setup that it would be impossible to know if they apply in this case or not. --Mike From jrhett at netconsonance.com Sat Jun 7 19:36:02 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 19:36:07 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080605083907.GD1028@server.vk2pj.dyndns.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> Message-ID: <2AB4EE00-3F2C-4DAC-B68F-CA40918BFAC3@netconsonance.com> On Jun 5, 2008, at 1:39 AM, Peter Jeremy wrote: > On 2008-Jun-04 22:22:33 -0700, Jo Rhett > wrote: >> And please stop with the loaded language. I'm not asking anyone to >> work >> for me. I am suggesting that it is perhaps too early to EoL 6.2 >> because >> 6.3 isn't ready yet. > > So you have stated. When asked to provide evidence to backup that > statement, you have refused. Since you are the one claiming that > "6.3 isn't ready yet", the onus is on you to put up or shut up. Sorry, Peter to have annoyed you, but this kind of language is useless for accomplishing anything other than pissing me off. I'm not going to go there. And I never "refused" anything, simply indicated that I didn't have time at that moment. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 19:41:41 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 19:41:47 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com><48472DB6.5030909@samsco.org><6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com><200806050248.59229.max@love2party.net> Message-ID: On Jun 5, 2008, at 2:45 AM, Steven Hartland wrote: > You are still fail to take to the time to even tell people what these > bugs are, no ones a mind reader! > > People are trying to help you here but all I'm hearing is a child like > "It doesn't work fix it", with no willingness to even explain what it > is or provide resources to test if someone found the time to > investigate > your issues. > Given this I don't see how you can expect these so called issues to > ever get fixed. I think you are misunderstanding the point at hand. I'm not trying to address specific issues. (I'd be happy to in another thread next week). This thread was created to address the overall well-documented list of bugs in 6.3, which is the *only* supported stable version of the operating system. (7.0 is even less stable) The most stable (by numbers of bugs and numbers of reported problems) is 6.2. I see no valid reasoning that can be backed up by numbers as to why 6.2 should be EoL. That's the point I'm addressing. The specific bugs that affect us are not necessarily relevant to the overall stability. And anyone can do the same searches on the bug list to confirm these numbers for themselves. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 19:48:22 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 19:48:27 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net> <20080604234532.GA89656@k7.mavetju> <458FE12C-AE4D-48F9-8193-4663079CEEF8@netconsonance.com> <84EBEA5D3A1F47E79E8E12C4CF4D0314@multiplay.co.uk> <7B8FD1A1E7DA49DFA68252BF9C74AE6F@multiplay.co.uk> <1A050712-3D0F-4263-A9F8-EE4AD042486E@netconsonance.com> Message-ID: On Jun 5, 2008, at 4:34 AM, Adrian Chadd wrote: > If its of major concern for you, then allocate some man hours, grab > the /usr/src/sys diffs between RELENG_6_2_0_RELEASE and > RELENG_6_3_0_RELEASE. > > The others on the list have stated over and over again that they > haven't seen any issues and would like to know precisely what they > are. While I appreciate their concern for the specifics, I think those should be addressed in another thread. This thread was meant to question the overall stability issues that pretty much anyone can view for themselves in the freebsd-questions/hardware/scsi mailing lists and queries in the open bug reports. > If stability is your main concern then you could throw some resources > at fixing 6.3 or throw some resources at backporting security fixes to > 6.2. I will apparently be backporting the security fixes myself until 6.4 ships. > I'm sure noone has an agenda to squish the FreeBSD version you're > using for any reason other than there aren't enough people > volunteering / being paid to work on back-porting security fixes. This is perhaps the real topic that needs to be addressed. Can we get some more details on the issues involved here? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From daniel at skytek.it Sat Jun 7 19:51:58 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Sat Jun 7 19:52:04 2008 Subject: Current status of support for high end SAN hardware In-Reply-To: <3cc535c80806071158h44ec9be1pbe72ca6711016bde@mail.gmail.com> References: <3cc535c80806071158h44ec9be1pbe72ca6711016bde@mail.gmail.com> Message-ID: <484AE6E1.2050504@skytek.it> On FreeBSD7, i'm succesfully using Qlogic 4gb fibre channel HBAs (ISP driver) attached to Fibre Brocade Switch and IBM DS4700 (14 disks array) using 4 way multipath with gmultipath. Regards, Daniel Andy Kosela ha scritto: > Hi all, > What is the current status of support for high end SAN hardware in FreeBSD? > I'm especially interested in support for HP EVA/XP disk arrays, Qlogic > HBAs, multipathing. > How FreeBSD compares in this environment to RHEL 5? > > -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From jrhett at netconsonance.com Sat Jun 7 19:53:26 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 19:53:31 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4847D5F8.80605@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <484736E0.6090004@samsco.org> <4847D5F8.80605@FreeBSD.org> Message-ID: <37414AAF-C75A-4292-A174-2198BEF2A7DF@netconsonance.com> (Top posted because I didn't want to snip what you said) Bruce, all of what you said below is well known. I understand and don't have any problem with this. You seem to be trying to address something I wasn't asking about -- certifications, etc and such. Not a concern. The question I raised is simply: given the number of bugs opened and fixed since 6.3-RELEASE shipped, why is 6.3 the only supported version? Why does it make sense for FreeBSD to stop supporting a stable version and force people to choose between two different unstable versions? Is this really the right thing to do? On Jun 5, 2008, at 5:03 AM, Bruce M. Simpson wrote: > It is worth remembering that FreeBSD is an open source project, > and it's maintained on a best-effort basis -- it is offered for free > and without any warranty. Like any other open source project, risk > management and change management becomes a two-way street, because > that's the trade-off struck with the open source model. > > The risks, as well as the benefits, have to be factored in > carefully to your company's technology strategy, as I'm sure you're > aware. > > I'm very surprised that the 6.3 train has been a big issue for > you, although speaking from the development side of the fence, there > are a lot of moving targets, and vendor support of the OS does play > a part. > It is difficult to offer any more specific advice without knowing > in more detail exactly what's causing such problems for you, > although I see you've offered general pointers, the folk directly > involved need to be pointed at direct information. > The FreeBSD Project just doesn't have the resources to do > compatibility testing on the scale of e.g. Windows Hardware Quality > Labs, as I'm sure you are also aware. > > I take on board what you say about your organisation holding back > on an upgrade because there are PRs filed for the hardware you use, > and having worked in an investment banking environment, I understand > this level of conservatism is warranted. > > However, I point out again: it's the open source model, and where > hardware compatibility is concerned, it really is a case of "suck it > and see". > Always has been, no different anywhere else. Open source requires > user participation. Microsoft run the WHQL because their status as a > going concern depends on it. > > I'm pleased to hear about your offer of hardware resources for > developers. However, this is only part of the problem. > To my mind, you need to find the right people, with the right > skills, to deal with the issues, and quite often, those guys are > already in demand, and thus their time can attract a high value. > Open source succeeds because money is not the only motivation. > The alternative is DIY, and that is "the point". > > If you need firm guarantees about support, consider contracting > with someone to do that. Many companies using FreeBSD already > outsource this kind of support requirement to 3rd parties. There are > also FreeBSD hardware vendors who support FreeBSD as a platform. > > If you want someone to take responsibility, make 'em an offer. > > thanks, > BMS -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 19:59:06 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 19:59:11 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080605125105.GA79727@eos.sc1.parodius.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <484736E0.6090004@samsco.org> <4847D5F8.80605@FreeBSD.org> <20080605125105.GA79727@eos.sc1.parodius.com> Message-ID: <0AE1196D-949A-4F2A-B885-2740D95BEF07@netconsonance.com> On Jun 5, 2008, at 5:51 AM, Jeremy Chadwick wrote: > If the exact regression between 6.2 and 6.3 can be tracked down, > great. > If it's in a specific driver, CVS commit logs or cvsweb will come in > handy. Otherwise, if it's some larger piece of code ("ohai i revamped > the intrupt handlar!"), chances of finding it are slimmer. I'm a bit > disappointed that Jo hasn't explicitly mentioned what's broken in 6.3 > that's affecting him, because that might help everyone. Heck, I'll > even > add it to my Commonly reported issue wiki page. PRs would be good, > but > I'll gladly take past mailing list discussions. I will start a new thread with the specific issues that concern my environment upon my return. I'd like to keep the specific issues separate from the overall policy question, because they are very different in my mind. > Jo's opinion is reasonable, but the bottom line is that the FreeBSD > Project folks will always win the argument once the "it's best-effort" > trump card is played; the convo has to end once it's on the table. Yes, but it often gets played too often too fast. It's worth having a discussion of the policy goals. I'm not saying that this isn't the very best that FreeBSD can do -- maybe it is. I just couldn't find any documentation of why dropping 6.2 makes a lot of sense, so I was hoping to get a clear answer for that. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From dick at nagual.nl Sat Jun 7 19:59:46 2008 From: dick at nagual.nl (Dick Hoogendijk) Date: Sat Jun 7 19:59:50 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <37414AAF-C75A-4292-A174-2198BEF2A7DF@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <484736E0.6090004@samsco.org> <4847D5F8.80605@FreeBSD.org> <37414AAF-C75A-4292-A174-2198BEF2A7DF@netconsonance.com> Message-ID: <20080607215930.000034e6@westmark> On Sat, 7 Jun 2008 12:53:10 -0700 Jo Rhett wrote: > Why does it make sense for FreeBSD to stop supporting a stable > version and force people to choose between two different unstable > versions? Is this really the right thing to do? NO, it's not. But you can't change that. The maintainers run the show. It's their time and their baby. And from one pov that's true. Users have to shut up if not contributing big time. I still think your questions are legitimate. You won't win the battle however. -- Dick Hoogendijk -- PGP/GnuPG key: 01D2433D ++ http://nagual.nl/ + SunOS sxde 01/08 ++ From jrhett at netconsonance.com Sat Jun 7 20:04:37 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 20:04:42 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <861w3cf2pj.fsf@ds4.des.no> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <80D7EE2D-A970-407B-A42C-AD17500BC463@netconsonance.com> <861w3cf2pj.fsf@ds4.des.no> Message-ID: <2892DF94-B346-4F36-9D32-165A2EA462D1@netconsonance.com> On Jun 5, 2008, at 6:09 AM, Dag-Erling Sm?rgrav wrote: > If you have issues with 6.3, your time would be better spent reporting > them (by which I mean describe them in detail) than waving your > hands in > the air and yelling at people. Must you resort to nonsense and hyperbole? I'd said nearly a dozen times that the issues I have aren't specifics. I am questioning the overall policy for EoL here. Even if it was known to work properly on my hardware the overwhelming amount of bugs in 6.3 indicates an unstable release. The diffs between 6.3 and 6-STABLE are greater than the diffs between 6.2 and 6.3 last time I checked. I can't understand the logic in having only a single supported version of the OS, especially one which so many known/reported/fixed-post- release bugs. And please don't respond if you can't avoid resorting to hyperbole like what I quoted above. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From yurtesen at ispro.net Sat Jun 7 20:05:30 2008 From: yurtesen at ispro.net (Evren Yurtesen) Date: Sat Jun 7 20:05:35 2008 Subject: cpufreq broken on core2duo In-Reply-To: <20080607164812.GA11072@eos.sc1.parodius.com> References: <4847072E.5000709@ispro.net> <484713B2.5030200@ispro.net> <48471834.30905@modulus.org> <200806051040.28319.jhb@freebsd.org> <484AA07A.2010308@ispro.net> <20080607164812.GA11072@eos.sc1.parodius.com> Message-ID: <484AEA18.4030901@ispro.net> Jeremy Chadwick wrote: > On Sat, Jun 07, 2008 at 05:51:38PM +0300, Evren Yurtesen wrote: >> By the way, there is another thing I am wondering about. If I enable HTT >> and Intel Enhanced SpeedStep in bios on a 3.00GHZ p4 CPU I see: >> >> cpu0: on acpi0 >> acpi_perf0: on cpu0 >> p4tcc0: on cpu0 >> cpu1: on acpi0 >> est1: on cpu1 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr f2700000f27 >> device_attach: est1 attach returned 6 >> p4tcc1: on cpu1 >> >> dev.cpu.0.freq_levels: 1500/27000 1312/23625 1200/13000 1050/11375 900/9750 >> 750/8125 600/6500 450/4875 300/3250 150/1625 >> dev.acpi_perf.0.freq_settings: 1500/27000 1200/13000 >> dev.cpufreq.0.%driver: cpufreq >> dev.cpufreq.0.%parent: cpu0 >> dev.cpufreq.1.%driver: cpufreq >> dev.cpufreq.1.%parent: cpu1 >> dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 >> 2500/-1 1250/-1 >> dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 >> 2500/-1 1250/-1 >> >> and it does not allow me to set the freq. of the cpu. > > How are you setting the frequency? Are you using powerd? You do not > have to enable SpeedStep in your BIOS to achieve throttling CPU clock > speed. In fact, I would highly recommend leaving EIST/SpeedStep in the > BIOS *disabled*, and let powerd adjust the clock frequency via ACPI. I have tested if it is working or not without using powerd. However you are right, SpeedStep in bios seem to be adding some ACPI support which looks like kind of broken. In either case, I get error when I have HTT as powerd (powerd -v) is only able to change 1 CPUs speed (obviously). Perhaps this can be fixed in future hopefully. In the bios, there is also Enhanced C1 support which seems to be reducing the vcore voltage at the same clock speed. (is this normal even?) >> I see the vcore goes to 2.32 when I set the speed to 150 according to >> mbmon, and when I set the speed to 1500 vcore goes to 2.51 > > mbmon is giving you wrong values. There is no way your Vcore on a P4 is > 2.32 or 2.51 volts. It's very likely that mbmon doesn't support your > hardware monitoring I/C. What motherboard (exact model) do you have? I thought about that actually but at this moment the importance is that it is changing only under certain conditions, there is probably some mistake in mbmon which skews the results. This is the motherboard (information from the datacenter): http://www.supermicro.com/products/motherboard/PD/E7230/PDSML-LN2.cfm Although kenv | grep smbios show PDSBM can this be or the datacenter is wrong? I just went to bios and says 1.264v so I guess it is safe to assume that mbmon was showing double. >> Independent of HTT being active or not, when I enable Intel Enhanced >> SpeedStep from the bios I start seeing calcru messages: >> >> calcru: runtime went backwards from 6 usec to 3 usec for pid 37 (pagezero) >> calcru: runtime went backwards from 6 usec to 3 usec for pid 36 (vmdaemon) >> calcru: runtime went backwards from 170 usec to 138 usec for pid 35 (pagedaemon) >> calcru: runtime went backwards from 553 usec to 291 usec for pid 15 (swi6: >> task queue) >> calcru: runtime went backwards from 15521 usec to 10366 usec for pid 2 (g_event) >> calcru: runtime went backwards from 25 usec to 12 usec for pid 11 (swi1: net) >> calcru: runtime went backwards from 4417 usec to 3960 usec for pid 1 (init) >> calcru: runtime went backwards from 2084385 usec to 1793542 usec for pid 1 (init) >> calcru: runtime went backwards from 408 usec to 204 usec for pid 0 (swapper) > > I've documented this problem quite clearly on my Commonly Reported > Issues wiki page. See "Kernel - EIST incompatibilities": > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > The solution is to keep EIST (SpeedStep) disabled in the BIOS. You can > still use powerd to adjust CPU clock frequency via ACPI. Yes, I have nothing against keeping it closed. :) >> Another weird thing is that if I keep HTT enable but disable Intel Enhanced >> SpeedStep then I see: >> >> ... >> >> Also the sysctl changes do not return an error however the vcore voltage >> still remains constant according to mbmon. > > Again: it's highly unlikely mbmon is returning correct values. mbmon > and healthd both were written with very old hardware (circa late 90s, > very early 2001-2002) in mind. The chips they support are not very > common on consumer motherboards, and are no longer used on server > motherboards. > > You might be interested in my bsdhwmon(8) application, but please note > I'm trying to avoid supporting any sort of "consumer" motherboards, > because many of them do not offer SMBus tie-ins, not to mention many > consumer board vendors don't provide any sort of documentation on how to > access said H/W IC functionality: Yes, as a coincidence I found: http://fixunix.com/freebsd/384760-looking-supermicro-hardware-owners.html I have 2 other servers with: http://www.supermicro.com/products/motherboard/Xeon1333/5000V/X7DVL-i.cfm (eh this one gives "X7DVL" correctly in kenv output also :) ) and I have some Intel products. I can test out bsdhwmon... I will send you the bios screenshots later to your e-mail. I have to leave now for a short while. Thanks, Evren From jrhett at netconsonance.com Sat Jun 7 20:09:21 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 20:09:26 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <200806051023.56065.jhb@freebsd.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <200806051023.56065.jhb@freebsd.org> Message-ID: <26AD2497-B8BA-47CD-8802-FA354738A674@netconsonance.com> Hi, John. Thanks for your update and I'll keep your experience in mind. As stated in previous messages, I'll open new threads in the appropriate lists about any specific driver issues (with details) that I am concerned about. This thread was intended to deal with the overall policy issue for dropping 6.2 in just barely more than a year.. On Jun 5, 2008, at 7:23 AM, John Baldwin wrote: > On Wednesday 04 June 2008 01:20:56 pm Jo Rhett wrote: >> Okay, I totally understand that FreeBSD wants people to upgrade from >> 6.2 to 6.3. But given that 6.3 is still experiencing bugs with >> things >> that are working fine and stable in 6.2, this is a pretty hard case >> to >> make. >> >> This is also a fairly significant investment in terms of time and >> money for any business to handle this ugprade. It totally understand >> obsoleting 5.x now that 7.x is out. But 6.2 is barely a year old... > > FWIW, at Y! 6.3 is more stable than 6.2 (I had a list of about 10 > patches for > known deadlocks and kernel panics that were errata candidates for > 6.2 that > never made it into RELENG_6_2 but all of them are in 6.3). We also > have many > machines with bge(4) and from our perspective 6.3 has less issues > with bge0 > devices than 6.2. > > Given the real world experience I have, your claims of instability w/ > o even > testing 6.3 border on silly. Also, when it comes to bge(4), you > need to be > _very_ specific about what chipsets you are using and comparing > those with > the chipsets in the bug reports you read. The bge(4) driver in > particular > covers a vast range of different hardware variations and is a bit of a > hodge-podge itself. If there is a problem with a 5705 card then it > may be > specific to just 5705 parts and not affect 575x, etc. parts. > > Again, with 3ware, there are two different drivers (twe(4) vs > twa(4)) and > again, you need to be more specific with which driver you are using > and which > model controllers you have. > > -- > John Baldwin -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 20:15:30 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 20:15:35 2008 Subject: please stop being nasty to people. In-Reply-To: <4847FFDE.8000209@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> Message-ID: On Jun 5, 2008, at 8:01 AM, Kris Kennaway wrote: >>> Uh yeah, this has been in place for *years*. Have you actually >>> read the >>> support announcements? They are public ;) ... > Yes, and this is the FreeBSD definition of "long term support". > Don't like it? Do something about it. Kris, is this kind of repeated nastiness necessary? Most everyone who has posted on this thread cares deeply about FreeBSD and does what they can to support it. What do you hope to gain by being nasty to them? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From sthaug at nethelp.no Sat Jun 7 20:18:37 2008 From: sthaug at nethelp.no (sthaug@nethelp.no) Date: Sat Jun 7 20:18:41 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <2892DF94-B346-4F36-9D32-165A2EA462D1@netconsonance.com> References: <80D7EE2D-A970-407B-A42C-AD17500BC463@netconsonance.com> <861w3cf2pj.fsf@ds4.des.no> <2892DF94-B346-4F36-9D32-165A2EA462D1@netconsonance.com> Message-ID: <20080607.221835.74664729.sthaug@nethelp.no> > I'd said nearly a dozen times that the issues I have aren't > specifics. I am questioning the overall policy for EoL here. Even if > it was known to work properly on my hardware the overwhelming amount > of bugs in 6.3 indicates an unstable release. No. 6.3 is very stable for us, on multiple machines. So is 7.0. And I have seen lots of other users basically saying the same thing. *You* are the one claiming that "the overwhelming amount of bugs in 6.3 indicates an unstable release" - yet you are unwilling to test 6.3 and you are also unwilling to show the PRs you claim exist. My sympathy for such a view is limited. Personally, I'm very happy with the work that the developers have put in and are *continuing* to put in. However, I'm just a user, not a developer. I have occasionally contributed bug fixes to FreeBSD, which is *my* best waying of returning the favor of all of the persons who have spent countless hours, often unpaid, to make FreeBSD a better system. I hope they continue! Steinar Haug, Nethelp consulting, sthaug@nethelp.no From jrhett at netconsonance.com Sat Jun 7 20:28:38 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 20:28:43 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <484808B8.8070506@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com> <484808B8.8070506@FreeBSD.org> Message-ID: <5CCF0D6E-56C1-4EBD-B8A6-955311F7851E@netconsonance.com> On Jun 5, 2008, at 8:39 AM, Kris Kennaway wrote: > There has been nothing of value offered in this thread, and it's > only served to piss off a number of developers who already put huge > amounts of volunteer time into supporting FreeBSD, and who take > pride in the quality of their work. I'm honestly sorry to hear that. I tried very hard with the very limited time I had available to me to phrase it clearly as a policy/ support issue and not to put the blame on any developer. There are number of issues in projects I support that are waiting on time from me too, so I can hardly point any fingers in that direction. We *all* have less time to work on this stuff than we might want. > Asking the volunteers to > a) fix unspecified problems that the submitter will not name in > detail but which are OMG SHOWSTOPPER YOU MUST FIX In rereading my quotes I may have not been clear on something. The vast majority of these bugs have already been fixed. ("not in a state that needs help identifying" was what I said trying to cover both that and known bugs without a fix yet) However, the fixes are not available in a -RELEASE version of the operating system. This is why EoLing 6.2 and forcing people to upgrade to a release with lots of known issues is a problem. Obviously you have to choose between developer time/effort to create a release candidate and the effort required to backdate security patches to 6.2. I don't know the reasons (which is why I created this thread) but my guess was the latter was easier than the former... > b) donate even more unpaid time to supporting branches because it > seems like a good "compromise" (!) > shows a complete failure of understanding and frankly beggars belief. Although the insults aren't helpful, I agree with you. I created this thread because I have a "failure of understanding". I'd appreciate some enlightenment of the real costs involved (and how we could help if possible). That's why I created this thread. > Such people are not acting as supporters of the project, however > well-intentioned they may believe themselves to be. You seem quite willing to make enemies. I'm not your enemy, and we'd both probably get a lot more work done if you stopped treating me like one. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 20:35:49 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 20:35:56 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4848073C.2060509@rxsec.com> Message-ID: On Jun 5, 2008, at 8:39 AM, Adrian Chadd wrote: > The OP stated "argh argh sky is falling with 6.3!" but hasn't yet > listed PRs which indicate this to be happening. > He's offered hardware in a week or two - which is great! - but what > irks the developers is the large amount of noise and absolutely no > useful information. Anyone can say "its broken!".. Adrian, your other comments are smart and valid. Why is this kind of hyperbole necessary? I never said anything tragic or emergency or anything like that. I questioned the practicality of having a single supported release with significant known bugs in it. It will take pretty much all the time I spend supporting FreeBSD os and applications away to focus entirely on backporting security patches back to 6.2. I know of several other organizations facing the same problem. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 20:39:25 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 20:39:31 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4848073C.2060509@rxsec.com> Message-ID: <346A79CC-B230-412D-892C-7164774C8954@netconsonance.com> On Jun 5, 2008, at 8:39 AM, Adrian Chadd wrote: > So yes, the way to contribute is to get involved. If you think there's > a real desire to take FreeBSD-6.2 (as an example) and continue > supporting security patches and critical bugfixes, versus the > larger-scale changes which seem to have gone on in /usr/src/sys then > just get together a group, generate some patches and submit them. Splinter groups, in my experience, tend to create duplicate work loads and make things harder, not easier. They seem to be useful only when there is a deadlock in the core team, and so far FreeBSD has avoided that. I would rather focus my efforts on something that produces more effective results. This is the reasoning behind my question: why drop 6.2 and 6.1 at the same time? What is the real cost of supporting 6.2 until a new stable version ships? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From emss at free.fr Sat Jun 7 20:44:05 2008 From: emss at free.fr (Eric Masson) Date: Sat Jun 7 20:44:11 2008 Subject: please stop being nasty to people. In-Reply-To: (Jo Rhett's message of "Sat, 7 Jun 2008 13:15:18 -0700") References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> Message-ID: <8663slq8kt.fsf@srvbsdnanssv.interne.kisoft-services.com> Jo Rhett writes: Hi, >> Yes, and this is the FreeBSD definition of "long term support". >> Don't like it? Do something about it. > > Kris, is this kind of repeated nastiness necessary? This is not nastiness, if you don't like the way the project manages release lifecycle, you have workarounds : - Test new release-candidates to verify no regression pop up in your standard setup, fill PRs about problems if needed and help project developpers to make the release better. - Pay someone to maintain the One True Release that suits your particular needs. - Use an os/distro that has the kind of long term support you seem to need. You just can't expect to moan on a mailing list about hypothetical bugs that would impact your setup and be welcomed as the new messiah as you demand extended support for a previous release just because you haven't done your homework. -- > Follow-up fmb.linux, parce que la charte de fca.emacs, redigee par mes > soins, interdit les trolls GNU Emacs/XEmacs, sur lesquels je suis le > premier a me lancer :-) -+- JK in guide du linuxien pervers - bien configurer sa charte -+- From hausen at punkt.de Sat Jun 7 20:44:12 2008 From: hausen at punkt.de (Patrick M. Hausen) Date: Sat Jun 7 20:44:17 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <5CCF0D6E-56C1-4EBD-B8A6-955311F7851E@netconsonance.com> References: <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com> <484808B8.8070506@FreeBSD.org> <5CCF0D6E-56C1-4EBD-B8A6-955311F7851E@netconsonance.com> Message-ID: <20080607204408.GA39103@hugo10.ka.punkt.de> Hello, On Sat, Jun 07, 2008 at 01:28:21PM -0700, Jo Rhett wrote: > In rereading my quotes I may have not been clear on something. The vast > majority of these bugs have already been fixed. ("not in a state that needs > help identifying" was what I said trying to cover both that and known bugs > without a fix yet) > > However, the fixes are not available in a -RELEASE version of the operating > system. Yes. So what? Upgrading your systems to 6.3 takes _precisely_ the same amount of work as upgrading to "6-STABLE as of today 00:00 GMT". You may want to pick a different point of time, but it really doesn't matter, because a release _is_ just a CVS branch created at a certain time. > This is why EoLing 6.2 and forcing people to upgrade to a release > with lots of known issues is a problem. People who have issues with RELENG_6_3 should upgrade to RELENG_6 which is perfectly supported. Kind regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J?rgen Egeling AG Mannheim 108285 From jrhett at netconsonance.com Sat Jun 7 20:45:19 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 20:45:24 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080605155340.GA51833@hugo10.ka.punkt.de> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605155340.GA51833@hugo10.ka.punkt.de> Message-ID: <1C8F6344-4D0B-415C-895C-549A0B4F9C05@netconsonance.com> On Jun 5, 2008, at 8:53 AM, Patrick M. Hausen wrote: > So he should at least be able to name the relevant PRs. > Or name at least one. Then nobody would complain. I'm sure somebody would complain ;-) but yeah, valid. Unfortunately I was on my 3rd day of less than 3 hours sleep and had to leave in less than 9 hours from my post, with 12 hours of work to do before then. I really honestly didn't have the time. I wanted to hold the post until I returned, but last time I did that I got dozens of accusations of sitting on it and speaking sooner, etc etc. I was hoping in my wishes-were-horses brain that someone would provide some insight into the issues that made obsoleting 6.2 a good idea, so that on my return I could determine how best to focus my efforts. > But stating "it's all well documented" without providing evidence > doesn't help. I for one was not able to find any open PRs that > deal specifically with 3ware hardware and 6.3, but not 6.[0-2]. ... > Agreed, but he should name the PRs he's referring to. > You know, my crystal ball is at the shop for a check, and > it seems like everybody else's is, too. Because focusing on the specifics never helps with policy issues. Every time I raise a policy issue and someone asks for specific bugs relevant, I answer them and the overall policy issue degrades into the merits of the specific problem, and usually into insults from people who don't understand why I don't replace X piece of hardware. The overall policy question gets lost. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 20:46:12 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 20:46:17 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <48480D2E.2050006@rxsec.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4848073C.2060509@rxsec.com> <48480D2E.2050006@rxsec.com> Message-ID: On Jun 5, 2008, at 8:58 AM, Chris Marlatt wrote: > I can certainly relate to a potentially standoff'ish approach that's > been seen recently. It's easy to take people's criticism as > completely negative regardless what is said. To be honest though - > people are using FreeBSD because it's a good project to say the > least. A few negative comments doesn't mean they think the whole > project is trash. Excluding the fact that we're all human and have > emotions / ego, you have to agree that such a hostile approach isn't > really the best thing. Thank you. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 20:51:47 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 20:51:50 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <1212683649.90048.43.camel@bauer.cse.buffalo.edu> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <1212683649.90048.43.camel@bauer.cse.buffalo.edu> Message-ID: On Jun 5, 2008, at 9:34 AM, Ken Smith wrote: > As for re-defining extended support to mean 4 or 5 years instead of > just > two it's not clear us doing that (except for anomolies like 4.11) is > really in your best interests. :-) 2 years would be perfectly fine in my mind. I'd love to see 2 years of support for 6.2-RELEASE. 6.2 was (and *is* AFAIK) the most stable release of FreeBSD since 4.11 and it came out the door with less than 12 months of support intended. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From dougb at FreeBSD.org Sat Jun 7 20:53:02 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Jun 7 20:53:05 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <2892DF94-B346-4F36-9D32-165A2EA462D1@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <80D7EE2D-A970-407B-A42C-AD17500BC463@netconsonance.com> <861w3cf2pj.fsf@ds4.des.no> <2892DF94-B346-4F36-9D32-165A2EA462D1@netconsonance.com> Message-ID: <484AF52A.108@FreeBSD.org> Jo Rhett wrote: > I'd said nearly a dozen times that the issues I have aren't specifics. > I am questioning the overall policy for EoL here. Your concerns have been noted. You seem unwilling or unable to accept the explanation that no matter what you think about the situation, we don't have the resources to support 6.2. Furthermore, according to the vast number of people with way more experience and way more hardware running 6.3 than you have (jhb from Yahoo! alone qualifies in this category, but he wasn't alone) your concerns are in fact, misplaced. To drive this thread even further into the realm of uselessness, you seem to be dead set on replying to every single post, saying basically the same thing over and over, and not listening to anything anyone is telling you. So I would like to suggest that you simply stop. Enjoy your trip. When you come back if you have specific concerns about your EXPERIENCE running 6.3 (or later) on your specific hardware, fire away. Doug -- This .signature sanitized for your protection From max at love2party.net Sat Jun 7 20:55:32 2008 From: max at love2party.net (Max Laier) Date: Sat Jun 7 20:55:39 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> Message-ID: <200806072254.43405.max@love2party.net> On Saturday 07 June 2008 21:41:18 Jo Rhett wrote: > On Jun 5, 2008, at 2:45 AM, Steven Hartland wrote: > > You are still fail to take to the time to even tell people what these > > bugs are, no ones a mind reader! > > > > People are trying to help you here but all I'm hearing is a child > > like "It doesn't work fix it", with no willingness to even explain > > what it is or provide resources to test if someone found the time to > > investigate > > your issues. > > Given this I don't see how you can expect these so called issues to > > ever get fixed. > > I think you are misunderstanding the point at hand. I'm not trying to > address specific issues. (I'd be happy to in another thread next > week). This thread was created to address the overall well-documented > list of bugs in 6.3, which is the *only* supported stable version of > the operating system. (7.0 is even less stable) > > The most stable (by numbers of bugs and numbers of reported problems) > is 6.2. > > I see no valid reasoning that can be backed up by numbers as to why > 6.2 should be EoL. That's the point I'm addressing. The specific > bugs that affect us are not necessarily relevant to the overall > stability. And anyone can do the same searches on the bug list to > confirm these numbers for themselves. Here is a cluebat for you: Messages in this flamboyant thread of yours: 113 and counting Messages in support of your claim not sent by yourself: 0 Now please: STFU or invest your time into something more productive. By the way, for somebody who claims to have no time to provide details about the bugs that make 6.3 so bad you seem to have a lot of time to send bogus emails (26 since Wednesday). If you had only spend a bit of that time into actual bughunting ... -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From jrhett at netconsonance.com Sat Jun 7 20:59:35 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 20:59:40 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <484821EE.5070303@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4848073C.2060509@rxsec.com> <484821EE.5070303@FreeBSD.org> Message-ID: <257C4536-3862-42E5-A6CB-E353952AC97F@netconsonance.com> On Jun 5, 2008, at 10:27 AM, Doug Barton wrote: > I'm pretty sure the only person that's going to matter to is you. ... > This isn't the '80's, and we aren't in grade school. See above on > taking "no" for an answer. Doug, is this really necessary? Is this kind of response going to help? Chris, please accept my apology for having created this thread as it seems to have become nothing more than an opportunity for people talk nastily to others. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 21:01:01 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 21:01:07 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <484821EE.5070303@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4848073C.2060509@rxsec.com> <484821EE.5070303@FreeBSD.org> Message-ID: On Jun 5, 2008, at 10:27 AM, Doug Barton wrote: >> It's quite possible what was proposed is an awful idea and if it is >> so be it. But it would appear as though it wasn't even considered. > > On the contrary. This, and lots of other ideas have been given very > careful consideration and have been rejected due to lack of > resources. There, feel better? > > Seriously folks, it's not as if we don't _want_ to be able to > provide better, longer, faster, $whatever support. We're just trying > to be realistic about what we can reasonably do with what we have > available. Doug, would you possibly (without attacking me?) give some insight into the issues here? This is what I was asking: what prevents supporting 6.2 ? Where could I best apply some of my time to improve the situation? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 21:03:16 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 21:03:21 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com><48472DB6.5030909@samsco.org><6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com><200806050248.59229.max@love2party.net><20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> Message-ID: <08056909-E1BB-44D4-8DEC-D1A9EFC3E75D@netconsonance.com> On Jun 5, 2008, at 10:31 AM, Steven Hartland wrote: > I have no sympathy for anyone who's going to moan about a previous > release > being desupported that isn't willing to put the effort in to make the > issues they are seeing get fixed. How do you know I haven't? Point of fact, I have. This thread was not about the specific bug fixes not yet available in a -RELEASE. This thread was to question the reasoning behind obsoleting 6.2 so very quickly. It's a policy issue, not a single bug report. It has more to do with the "X results" column in a PR search than any single one of the entries. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 21:06:34 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 21:06:42 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4848249E.2050704@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com><4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net><20080604234532.GA89656@k7.mavetju> <458FE12C-AE4D-48F9-8193-4663079CEEF8@netconsonance.com> <84EBEA5D3A1F47E79E8E12C4CF4D0314@multiplay.co.uk> <4848249E.2050704@FreeBSD.org> Message-ID: On Jun 5, 2008, at 10:38 AM, Doug Barton wrote: > When you do come back, your first message should contain a list of > PRs that you're concerned about, and confirmation (per jhb's > message) that you have the _exact_ hardware that is referred to in > them. If you can't provide that, don't bother. That's a very separate issue. I was asking about the policy reasoning. Fixing all of the bugs affecting my environment won't help me until they are -RELEASE, which is going to a take a lot of resources. A lot more than supporting 6.2, right? If not, please educate me. And please stop being nasty. I'd said much the same thing over the last 5 days, but I haven't once uttered a word about you not reading what has already been said repeatedly. Nor does that topic interest me. I am curious about the policy issue involved here. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From dougb at FreeBSD.org Sat Jun 7 21:06:35 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Jun 7 21:06:43 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4848073C.2060509@rxsec.com> <484821EE.5070303@FreeBSD.org> Message-ID: <484AF859.9060005@FreeBSD.org> Jo Rhett wrote: > On Jun 5, 2008, at 10:27 AM, Doug Barton wrote: >>> It's quite possible what was proposed is an awful idea and if it is >>> so be it. But it would appear as though it wasn't even considered. >> >> On the contrary. This, and lots of other ideas have been given very >> careful consideration and have been rejected due to lack of resources. >> There, feel better? >> >> Seriously folks, it's not as if we don't _want_ to be able to provide >> better, longer, faster, $whatever support. We're just trying to be >> realistic about what we can reasonably do with what we have available. > > > Doug, would you possibly (without attacking me?) give some insight into > the issues here? This is what I was asking: what prevents supporting > 6.2 ? Lack of time on the part of the people that do the support. (As has been explained lots of times already.) I realize that you'd rather have an answer that gives you something to argue about, but there isn't one. > Where could I best apply some of my time to improve the situation? Backport patches that you find interesting or relevant to 6.2, and post on the -stable list to let others know where to find them. Doug (no, I'm not being flippant) -- This .signature sanitized for your protection From jrhett at netconsonance.com Sat Jun 7 21:11:49 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 21:11:53 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080605181832.GA31773@soaustin.net> References: <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com> <484808B8.8070506@FreeBSD.org> <20080605181832.GA31773@soaustin.net> Message-ID: <1D5A0544-5ACA-4E60-8C6F-D62E4D2CB546@netconsonance.com> Mark, I'm confused by this message. You direct your message to me, but quote Kris and Chris and then using those comments attack me. I think you may have my own comments confused. Finally, I haven't asked for anything you are attacking me for here. You are apparently restating what you think I said into things and attacking me for those ... or something. I'm entirely confused by this message, sorry :-( On Jun 5, 2008, at 11:18 AM, Mark Linimon wrote: > On Thu, Jun 05, 2008 at 05:39:36PM +0200, Kris Kennaway wrote: >> You seem awful hostile - do you really think that's the best way to >> represent the project you're involved with? > > When confronted with "what you are doing is wrong, but I am not going > to tell you what it is because if you cared you'd already know" (my > summary of your past postings in this thread)? Possibly not 'best' > but > 'understandable'. > >> The option provided seems like a fairly good compromise to both >> interests. Pick 6.3 (or anything the release team wishes) to support >> for a longer period of time. > > If you want FreeBSD to be supported the same as a commercial product, > and you be able to dictate the terms, then it's not going to happen > completely via volunteer effort. At some point some money is going to > have to change hands. Either you pay someone at your company to do > support, or you hire someone external. > > Then you get to dictate what is supported and for how long. > Otherwise, > all you can do is to suggest. A "consensus statement" signed off on > by one person is the former -- not the latter. > > Now to add my own frustration to the list ... > > I next note that _after_ you said you had no more time to continue > with this thread for now (and thus could not yet give us pointers to > specific failures and any corresponding PR numbers), you are still > replying to email. Since you still seem to have some time, let me > help you do a little research here. > > Checking the PRs that you have submitted that are still current, none > of the src-related ones are from anything newer than 6.0R: > > http://www.freebsd.org/cgi/query-pr-summary.cgi?originator=Jo+Rhett > > There are some resources to help you find already-submitted PRs to > reference if it will help. (The latter 2 are new, and are attempts > by the bugbusting team to flag 'well-known problem' and 'PR indicates > regression'): > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > http://people.freebsd.org/~linimon/studies/prs/well_known_prs.html > http://people.freebsd.org/~linimon/studies/prs/prs_for_tag_regression.html > > Now I'll admit the following is a less-obvious query of the > database, but > it's my attempt to show regressions that we have already flagged in > 6.3: > > http://www.freebsd.org/cgi/query-pr-summary.cgi?release=%5EFreeBSD+6.3&category=kern&text=regression > > So these 4 links should give you some quick ways to generate some PR > numbers for us. > > Finally, here are some statistics about PR count: > > rel all kern > --- --- ---- > 6.0 210 91 > 6.1 217 81 > 6.2 396 102 > 6.3 167 56 > 7.0 563 140 > > To me, this doesn't look like an overwhelming case for 6.3 being worse > off than 6.2. Yes, I'm sure there are regressions: there are in any > release. > > mcl -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 21:16:44 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 21:16:48 2008 Subject: console access In-Reply-To: <3E1DBCBBB1C614B1DBD0F166@utd65257.utdallas.edu> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <200806051023.56065.jhb@freebsd.org> <200806051910.20319.pieter@degoeje.nl> <3E1DBCBBB1C614B1DBD0F166@utd65257.utdallas.edu> Message-ID: On Jun 5, 2008, at 11:35 AM, Paul Schmehl wrote: > It's not quite that simple. To do that, I have to block out time to > drive 45 miles during my supposed "off" hours and do the upgrade > there. Because, if it breaks networking and I'm at home, the server > will be down for at least an hour until I can drive to the hosting > company, get access to the server and restore the old kernel. Paul, you should arrange with your colocation provider to get an out of band serial connection to the system, and configure the console to go to the serial port. We provide that for free at $EMPLOYER and most other places I know of do it for free or nominal charge. Obviously an operation like ours has lights-out access to everything, but we have a dozen or so freebsd developers as customers, and they routinely rebuild their machines entirely without ever visiting the facility. GNN in particular lives in Japan these days so a colo visit would take him a day or two... -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 21:23:00 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 21:23:05 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080605220244.GP1028@server.vk2pj.dyndns.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> Message-ID: <05D1299E-D2F2-4FB8-BD0B-D30B29764612@netconsonance.com> On Jun 5, 2008, at 3:02 PM, Peter Jeremy wrote: > I agree that he has made those statements - and those statements may > even be true. When asked to provide details of the bugs or references > to those problems, he has refused. Random, unsubstantiated claims are > hardly evidence of anything. I didn't refuse, I said it wasn't relevant. I also offered to provide the list and hardware and time resources for testing if any developer needed it after June 11 (ie when it was physically possible to do so) for anyone who wanted to chase the individual issues. But the individual issues aren't the problem. No single problem would usually warrant that kind of attention. It's the overall amount of issues that concerns me. > To summarise, so far the OP has made a series of unsubstantianted > claims about vaguely defined problems on vaguely defined hardware. > When asked for more details, he has refused. Exactly what do you > expect the FreeBSD developers to do? Perhaps answer the question which was asked, instead of trying to drag the conversation down into specific bug reports? No single specific bug report is relevant to the overall topic. Fixing a single bug won't improve the situation. Anyway, I've said this a dozen times now so I won't be repeating it. You are welcome to continue ignoring it. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 21:30:26 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 21:30:33 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <48486962.7030001@samsco.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <484736E0.6090004@samsco.org> <74EB4162-74CB-4591-B7E5-8156BB56C29E@netconsonance.com> <48486962.7030001@samsco.org> Message-ID: On Jun 5, 2008, at 3:32 PM, Scott Long wrote: > What is needed prior to talking about loaner systems and test cases is > for you to say, "Hardware XYZ isn't working for me anymore. It used > to > do FOO, and now it does BAR." That's the first step. It's a simple > step, but it's an essential step. Seriously. Scott, you are missing the point in your apparent desire to be rude. When there are bugs where something does not work (and nobody else has already reported it) I do open bugs. And more than 90% of my bug reports include patches too. I know how that works. The point is that 6.2-RELEASE works well for many people where 6.3- RELEASE does not. Until 6.4-RELEASE ships there will be a lot of unsupported systems. > And if you aren't > actually experiencing any problems, then all I can say is that your > input on the release and support process has been noted, and we all > look forward to bug reports from you in the future. And before you > circle back on the "but but but the PR database shows unresolved bugs" > argument, understand that few of us on this mailing lists are idiots; > we know how to read, and we are aware that there are PR entries. What > pushes a stalled PR along, though, is having an interested party bring > it up and offer insight into the specifics of it. Just pointing from > afar adds nothing to the process. You're welcome to disagree on that > point, Again, I'm not seeing anything other than you talking down to someone that (I think) you know from personal experience knows better than that. > but it seems pretty clear that continuing to argue it in this > forum isn't really solving anything. You're right. As usual, people would rather insult and attack than address the issue which was raised. This is why I rarely bother with the mailing lists -- flame wars produce no code. > So I'll try one last time.... you seem to be concerned about possible > bugs in the the 3ware and broadcom drivers. Can you please provide > specifics on what you are concerned about? Any personal insight or > experience you have would be highly helpful and appreciated. As stated previously, I'll create another thread about the specific bugs that concern me upon my return. Those are not specifically relevant to the policy issue here. (and those threads will be created in the appropriate hardware-specific list instead of the general - stable mailing list) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From kutulu at kutulu.org Sat Jun 7 21:34:12 2008 From: kutulu at kutulu.org (Mike Edenfield) Date: Sat Jun 7 21:34:17 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <5CCF0D6E-56C1-4EBD-B8A6-955311F7851E@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com> <484808B8.8070506@FreeBSD.org> <5CCF0D6E-56C1-4EBD-B8A6-955311F7851E@netconsonance.com> Message-ID: <484AFED9.1030209@kutulu.org> Jo Rhett wrote: > This is why EoLing 6.2 and forcing people to upgrade to a release with > lots of known issues is a problem. You keep saying this as if it's somehow unusual that 6.3 has a lot of open bugs. Yet even a cursory look at the PR list (admittedly based just on the specific drivers you mentioned early on, but presumably a decent random sampling) shows that most of the remaining open issues in 6.3 are not new, and were present in 6.2 or even as far back as 6.0. Certainly there are plenty of issues that were fixed in 6.3 that were present in the 6.2 version you're already running. In other words, you haven't provided any real support to back up your claim that 6.3 is significantly "less stable", for whatever that means, than 6.2. Meanwhile, the vast majority of the anecdotal, first-person experience in running 6.3 in production indicates quite the opposite -- that it's *more* stable than 6.2. You've already stated that you don't want to side track this thread with specifics about your exact bugs. The problem is, without specifics to back up your claims of instability, they are (in your own words) little more than hyperbole. It shouldn't surprise anyone that you got a negative reaction to that kind of statement. --Mike From daniel at skytek.it Sat Jun 7 21:34:36 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Sat Jun 7 21:34:42 2008 Subject: kernel panic on em0/taskq Message-ID: <484AFEF1.4040500@skytek.it> Hello, i'm experiencing periodic kernel panics on a server with FreeBSD 7.0-STABLE #0: Tue May 20 19:09:43 CEST 2008. My big problem is that the system is not performing memory dumping and/or automatic reoboot, it just stays there. Here' console output: em0: watchdog timeout -- resetting kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic_id = 00 fault virtual address = 0x14 fault code = supervisor read, page not present intruction pointerr = 0x20:0xc056e2ce stack pointer = 0x28:0xe537fc08 frame pointer = 0x28:0xe537fc28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 29 (em0 taskq) trap number = 12 panic: page fault cpuid = 0 It just stays there, unresponsive (no automatic reboot). Any ideas? Thanks, Daniel -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From jrhett at netconsonance.com Sat Jun 7 21:37:26 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 21:37:35 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <48488D1A.9070105@kutulu.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <48488D1A.9070105@kutulu.org> Message-ID: <52E265BB-BBB1-439D-B375-D6C6AA04697C@netconsonance.com> On Jun 5, 2008, at 6:04 PM, Mike Edenfield wrote: > In short, the problem reports that the OP is looking at are not > immediately obvious to someone who doesn't already know what they > are, and he's not doing himself any favors by insisting that > everyone else "already knows" about these problems. If he's seen > these bug reports, presumably he knows what their PR #'s are, or at > the very least the description of the bugs, and it would be many > many times faster for him to just say so than continue to insist > that other people read his mind. Mike, could you do me a favor and provide me with a set of words that will make what I am trying to say on this topic clear? I keep saying the same thing over and over again and nobody is hearing me, so could you perhaps help me translate this? These are the raw issues without any friendly wording. 1. Bugs in 6.3 that are patched aren't available in any other -RELEASE. 2. Bugs in 6.3 outstanding that don't affect 6.2 3. Overall amount of bugs. 4. Difference in code base between 6.3 and 6-STABLE is > than 6.2 and 6.3 These combine to produce a release which will never be "stable" for production needs. Obviously the FreeBSD team(s) involved have to make choices. Perhaps there's nothing we can do to improve it other than work on the specific bugs. But does it hurt to ask why 6.2 was dropped so fast? What the real cost of supporting 6.2 until 6.4 ships is? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 21:46:55 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 21:46:59 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <86tzg6aeye.fsf@ds4.des.no> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <86tzg6aeye.fsf@ds4.des.no> Message-ID: <8E50CCF2-AAEF-4794-9AAA-9300DF36A45B@netconsonance.com> On Jun 6, 2008, at 6:08 AM, Dag-Erling Sm?rgrav wrote: > Three people replied to Jo Rhett's initial email. Here's what they > said, with Jo's own text elided: Among other things, you time-warped some of my comments into replies to things people said to the comments themselves. But the most crucial is that you dropped the entire point I was trying to make and focused on someone else's desire to focus on the specific bugs, rather than the overall policy issue. So your entire thread is misguided at best. Specific bugs are always addressed on the PRs themselves or the hardware-specific mailing list, not on the general -stable list. Even worse is your summary: > I won't pretend to know what Jo is thinking or what his motivation is, > but in my experience, when people respond in this manner, it's because > they know they have no solid data or arguments, and are trying to save > face. What face? Huh? Exactly what face do I have to save? Why on gods green earth would I put saving face over system stability? I think you are confusing me with someone who has time to spend all day writing on mailing lists/forums and considers their reputation important. You're dealing with exactly the opposite -- I rarely read the mailing lists due to lack of time, and generally don't care what people think of me as long as it doesn't get in the way of getting work done. > I hope this helps you to better understand who's attacking who, and > who's being rude to who. You should perhaps start at the beginning and look at the questions I asked, and then recreate the thread showing the responses to the policy questions I have raised. Or just look at your own responses, which have never been less than rude and not once even pretended to focus on the real questions. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 21:49:10 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 21:49:14 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <264183D1-4324-405D-B737-1555A6FFFCE7@khera.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <7B3DA577-61F6-41D2-90B1-954E3A5A5C80@netconsonance.com> <264183D1-4324-405D-B737-1555A6FFFCE7@khera.org> Message-ID: <85E92030-93B9-4460-B522-2C56FD091CBD@netconsonance.com> > On Jun 4, 2008, at 8:22 PM, Jo Rhett wrote: >> If you're asking why I don't turn a production environment over to >> being a freebsd-unstable-testbed, I can't really answer that >> question in a way you'd understand (if you were asking that question) On Jun 6, 2008, at 9:11 AM, Vivek Khera wrote: > If you don't have an identical setup to test new software, then > you're pretty much not able to ever upgrade anything, IMO, and your > "production" environment *is* a testbed for new software. You clipped the part where I said exactly the same thing, and also explained why it wasn't really useful for the problems named. Are you done getting off a random pot-shot? Interested in focusing on the real questions? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 21:59:20 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 21:59:26 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <86tzg6aeye.fsf@ds4.des.no> <5B0709D83455470DA46533C4@Macintosh.local> Message-ID: <2C3F6FAB-1B11-4F96-9F24-7CF6F44C0078@netconsonance.com> On Jun 6, 2008, at 11:41 PM, Adrian Chadd wrote: > As said before, the reason FreeBSD isn't supporting older 6.x releases > anymore is because there's just no manpower to do so. Which is what I was asking about. I've asked the questions more specifically since they apparently weren't phrased well the first time. It would be great to hear answers to those questions. > I still don't think you get it. FreeBSD is a community. A community > works when enough people contribute positively towards furthering the > goals of the project. Jo is a user. He sounds like he is using it in > some reasonably critical and money-earning roles. Jo can participate > by testing stuff on test hardware, reporting back issues and working > with the community. Which I do. If you check out my bug reports they almost always include patches. I've also added freebsd support to many projects, including full package management in the latest versions of cfengine. > Bitching about there being no long-term support > for releases isn't constructive. Some developer comments may not be > constructive either, but this is a -community project-. Join the > -community- and help out. Am I missing an ID card? Where should I go to acquire one? When there is a specific issue I can help with, I do. In this case I was asking about the justification for dropping support so quickly. > It doesn't matter if running a long-term support project would be > beneficial for a certain subset of the userbase, its a losing > situation to cater to them unless they somehow contribute back to the > community. I work on bugs for things I can help with. I add freebsd support to various projects. I test and report bugs on new releases. I spend at least 10% (and sometimes more) of my paid $EMPLOYER's time working on freebsd things, and countless hours of unpaid time. I don't know that I can do any more than this. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From dick at nagual.nl Sat Jun 7 22:00:23 2008 From: dick at nagual.nl (Dick Hoogendijk) Date: Sat Jun 7 22:00:27 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <52E265BB-BBB1-439D-B375-D6C6AA04697C@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <48488D1A.9070105@kutulu.org> <52E265BB-BBB1-439D-B375-D6C6AA04697C@netconsonance.com> Message-ID: <20080608000008.00004a91@westmark> On Sat, 7 Jun 2008 14:37:11 -0700 Jo Rhett wrote: > These are the raw issues without any friendly wording. > > 1. Bugs in 6.3 that are patched aren't available in any other > -RELEASE. 2. Bugs in 6.3 outstanding that don't affect 6.2 > 3. Overall amount of bugs. > 4. Difference in code base between 6.3 and 6-STABLE is > than 6.2 > and 6.3 > > These combine to produce a release which will never be "stable" for > production needs. You are in fact saying 6.3-RELEASE should not have been released at the time it was. It should have been posponed 'till some open bugs were solved. I agree with you that a RELEASE is supposed to be more mature / stable then a development version. And you state it is -not- -- Dick Hoogendijk -- PGP/GnuPG key: 01D2433D ++ http://nagual.nl/ + SunOS sxde 01/08 ++ From gad at FreeBSD.org Sat Jun 7 22:00:55 2008 From: gad at FreeBSD.org (Garance A Drosehn) Date: Sat Jun 7 22:01:00 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <08056909-E1BB-44D4-8DEC-D1A9EFC3E75D@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com><48472DB6.5030909@ samsco.org><6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com><200806 050248.59229.max@love2party.net><20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <08056909-E1BB-44D4-8DEC-D1A9EFC3E75D@netconsonance.com> Message-ID: At 2:02 PM -0700 6/7/08, Jo Rhett wrote: > >This thread was to question the reasoning behind obsoleting 6.2 so >very quickly. It's a policy issue, not a single bug report. It has >more to do with the "X results" column in a PR search than any >single one of the entries. Some CLARITY: There is not a single committer that I know of who is convinced by your argument that we (committers) should sign up for the additional work of supporting 6.2 for an additional 6 months. That is the answer to your "policy concern". Let me say again: *That* is the answer to your policy concern. and: That *is* the answer to your policy concern. and: That is the answer to your *policy* concern. If you have specific issues that you experience with 6.3, then several committers are still willing to investigate those issues, because those would (presumably) help other users who have already upgraded to 6.3. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From jrhett at netconsonance.com Sat Jun 7 22:02:21 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 22:02:26 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080607085607.GM94309@deviant.kiev.zoral.com.ua> References: <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <86tzg6aeye.fsf@ds4.des.no> <5B0709D83455470DA46533C4@Macintosh.local> <20080607085607.GM94309@deviant.kiev.zoral.com.ua> Message-ID: <3FF6BF7B-F3C6-486C-B482-1FA1D900CC47@netconsonance.com> On Jun 7, 2008, at 1:56 AM, Kostik Belousov wrote: > Comparing us with, e.g., Solaris, we would not find a lot of > difference > in the support model. Althought they formally provide patches for Huh? I'm totally not saying that you should be trying to match the support model of a large corporation, this statement is outright wrong. I can still get security patches for Solaris 2.8 which shipped almost 6 years ago now. Again, I'm not saying that 6 years is reasonable for FreeBSD - just pointing out that the statement is invalid. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 22:05:20 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 22:05:24 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080607215930.000034e6@westmark> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <484736E0.6090004@samsco.org> <4847D5F8.80605@FreeBSD.org> <37414AAF-C75A-4292-A174-2198BEF2A7DF@netconsonance.com> <20080607215930.000034e6@westmark> Message-ID: On Jun 7, 2008, at 12:59 PM, Dick Hoogendijk wrote: > I still think your questions are legitimate. > You won't win the battle however. Obviously I got a battle, but that wasn't what I wanted. I wanted to understand the issues involved and from that determine how I might be able to help. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From gad at FreeBSD.org Sat Jun 7 22:05:45 2008 From: gad at FreeBSD.org (Garance A Drosehn) Date: Sat Jun 7 22:05:49 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <52E265BB-BBB1-439D-B375-D6C6AA04697C@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <48488D1A.9070105@kutulu.org> <52E265BB-BBB1-439D-B375-D6C6AA04697C@netconsonance.com> Message-ID: At 2:37 PM -0700 6/7/08, Jo Rhett wrote: > >Mike, could you do me a favor and provide me with a set of words >that will make what I am trying to say on this topic clear? I keep >saying the same thing over and over again and nobody is hearing me, >so could you perhaps help me translate this? The fact that we reject your request that we provide further support for 6.2 does not mean we did not understand the question. It is you who are not understanding the reply. What you are asking for is *SUPPORT* for 6.2. That implies that we need to guarantee we will spend time *WORKING* on 6.2. We see no benefit in doing that. We would much rather spend that time to improve things in 6.3, because 6.3 is one of the branches we are supporting. As soon as you can tell us how we "support" 6.2 without *working* on 6.2, then maybe you'll have a more attentive audience. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From olli at lurza.secnetix.de Sat Jun 7 22:09:23 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Sat Jun 7 22:09:26 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: Message-ID: <200806072209.m57M9JX7023171@lurza.secnetix.de> Jo Rhett wrote: > Ken Smith wrote: > > As for re-defining extended support to mean 4 or 5 years instead of > > just > > two it's not clear us doing that (except for anomolies like 4.11) is > > really in your best interests. :-) > > 2 years would be perfectly fine in my mind. I'd love to see 2 years > of support for 6.2-RELEASE. > > 6.2 was (and *is* AFAIK) the most stable release of FreeBSD since 4.11 > and it came out the door with less than 12 months of support intended. I'm running various FreeBSD versions on lots of machines at customers and our own offices. Among them are about 40 servers with various types of bge(4) chips, and some machines use gmirror. AFAIK we don't have machines with 3ware adapters, so I can't comment on that. But the bge(4) driver runs better with 6.3, 7.0 and 6/7-stable than it did with 6.2. We never had any gmirror problems, so it's neither worse nor better. It just works as expected. Overall I regard *both* 6.3 and 7.0 more stable than 6.2. I'm in the process of bringing most machines to 7.0 or 7-stable, and so far it goes very well. In some cases the performance has noticably improved, especially on multicore servers. I haven't experienced any stability problems so far. I'm with FreeBSD since 2.0.5-Release. I think 7.0 is the most stable dot-zero release that the project ever had. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd From jrhett at netconsonance.com Sat Jun 7 22:12:02 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 22:12:07 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080607204408.GA39103@hugo10.ka.punkt.de> References: <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com> <484808B8.8070506@FreeBSD.org> <5CCF0D6E-56C1-4EBD-B8A6-955311F7851E@netconsonance.com> <20080607204408.GA39103@hugo10.ka.punkt.de> Message-ID: <4004D1C8-58E4-46E7-B735-4F1CDC5BCCB4@netconsonance.com> On Jun 7, 2008, at 1:44 PM, Patrick M. Hausen wrote: > Upgrading your systems to 6.3 takes _precisely_ the same amount > of work as upgrading to "6-STABLE as of today 00:00 GMT". No, it doesn't. You can get to 6.3 with freebsd-update. And you can stay patched with freebsd-update on a -RELEASE. For a corporation to choose to stick with -RELEASE makes perfect sense, and it specifically what the -RELEASE versions were intended for. > You may want to pick a different point of time, but it really > doesn't matter, because a release _is_ just a CVS branch created > at a certain time. >> This is why EoLing 6.2 and forcing people to upgrade to a release >> with lots of known issues is a problem. > > People who have issues with RELENG_6_3 should upgrade to RELENG_6 > which is perfectly supported. I'm sorry, but you clearly don't run RELENG_6 on anything. I run it on two home computers, and grabbing it on any given day and trying to run with it in production is insanity. Lots and lots of things are committed, reverted, recommitted, reverted and then finally redesigned. Each of those steps are often committed to the source tree. The -RELEASE versions prevent this kind of insanity. I'm struggling to find a phrase here that can't be taken to be an insult, so forgive me and try to understand when I say that you really should try watching the cvs tree for a bit before making a nonsense comment like that. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 22:15:58 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 22:16:02 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <484AF52A.108@FreeBSD.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <80D7EE2D-A970-407B-A42C-AD17500BC463@netconsonance.com> <861w3cf2pj.fsf@ds4.des.no> <2892DF94-B346-4F36-9D32-165A2EA462D1@netconsonance.com> <484AF52A.108@FreeBSD.org> Message-ID: On Jun 7, 2008, at 1:52 PM, Doug Barton wrote: >> I'd said nearly a dozen times that the issues I have aren't >> specifics. I am questioning the overall policy for EoL here. > > Your concerns have been noted. You seem unwilling or unable to > accept the explanation that no matter what you think about the > situation, we don't have the resources to support 6.2. I haven't been given an explanation. I was given that bare statement. An explanation might help me understand where I can help improve the situation. > Furthermore, according to the vast number of people with way more > experience and way more hardware running 6.3 than you have (jhb from > Yahoo! alone qualifies in this category, but he wasn't alone) your > concerns are in fact, misplaced. The people that I know of working around problems in 6.3 all work at Yahoo, so ... > To drive this thread even further into the realm of uselessness, you > seem to be dead set on replying to every single post, saying > basically the same thing over and over, and not listening to > anything anyone is telling you. So far I have been (a) insulted (b) told to "take it or leave it" or (c) demanded to provide specific PRs. Nobody has responded to the question. > So I would like to suggest that you simply stop. Enjoy your trip. > When you come back if you have specific concerns about your > EXPERIENCE running 6.3 (or later) on your specific hardware, fire > away. I suspect you are right, it's time to stop dealing with FreeBSD. The product is quality, but the abuse one has to sustain to ask a question on the mailing list isn't worth it. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 22:21:30 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 22:21:34 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <80D7EE2D-A970-407B-A42C-AD17500BC463@netconsonance.com> <861w3cf2pj.fsf@ds4.des.no> <2892DF94-B346-4F36-9D32-165A2EA462D1@netconsonance.com> Message-ID: <9C465B6B-5784-4622-9B89-1FD24A08AF18@netconsonance.com> On Jun 7, 2008, at 2:46 PM, Garance A Drosehn wrote: > Your concern has been noted and rejected. My actual questions were never answered. > you are "challenging" others to support 6.2 for you. For free. No, I never did that. I asked why it was a good idea. And I have always offered to help, and have always helped as much as I could with anything to do with freebsd. For free :-) > Several committers have offered to look at any bugs which prevent you > from going to 6.3, and you don't want to hear about that. No, I said I would provide all those details as soon as I could. > workload is such that you don't really want to even look at any > FreeBSD changes this year, and you assume that our workload is such Are you just making this stuff up? My only comments about workload was that it was on my schedule for May, then June... I could totally do this upgrade NOW if it was feasible. > Your challenge has been read by many committers, and your challenge > has been found lacking, impractical and uninteresting. Now, is it > true that every single freebsd committer must reply to this thread > and tell you "Sorry, but No"? And we must all be nice while we do > it, or we'll also be lectured about our manners? I find it sad that again you find it more interesting to be insulting that to respond in a helpful manner to the questions raised. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 22:24:04 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 22:24:08 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com><48472DB6.5030909@ samsco.org><6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com><200806 050248.59229.max@love2party.net><20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <08056909-E1BB-44D4-8DEC-D1A9EFC3E75D@netconsonance.com> Message-ID: On Jun 7, 2008, at 3:00 PM, Garance A Drosehn wrote: > There is not a single committer that I know of who is convinced > by your argument that we (committers) should sign up for the > additional work of supporting 6.2 for an additional 6 months. I never asked for that. > That is the answer to your "policy concern". > Let me say again: > *That* is the answer to your policy concern. > and: > That *is* the answer to your policy concern. > and: > That is the answer to your *policy* concern. NICE. Go with the insults. Nothing better than pissing off people who work for you for free. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 22:26:23 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 22:26:28 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080608000008.00004a91@westmark> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <48488D1A.9070105@kutulu.org> <52E265BB-BBB1-439D-B375-D6C6AA04697C@netconsonance.com> <20080608000008.00004a91@westmark> Message-ID: <1B48EFB7-C3CB-4568-BB86-7CF54A785B94@netconsonance.com> On Jun 7, 2008, at 3:00 PM, Dick Hoogendijk wrote: > You are in fact saying 6.3-RELEASE should not have been released at > the > time it was. It should have been posponed 'till some open bugs were > solved. I agree with you that a RELEASE is supposed to be more > mature / > stable then a development version. And you state it is -not- That's direct criticism that I am not willing to make of the contributors. I'm sure everyone did the best they could, and with what they knew at the time. I'm saying that now, in retrospect, it doesn't appear to be a stable release. Forcing everyone to upgrade to a unstable release doesn't seem likely to help improve the situation. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Sat Jun 7 22:29:28 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat Jun 7 22:29:32 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <48488D1A.9070105@kutulu.org> <52E265BB-BBB1-439D-B375-D6C6AA04697C@netconsonance.com> Message-ID: On Jun 7, 2008, at 3:05 PM, Garance A Drosehn wrote: > The fact that we reject your request that we provide further support > for 6.2 does not mean we did not understand the question. It is you > who are not understanding the reply. At the very least, I phrased my question badly. Because I asked "why" and I heard "no". And "no" is not an answer to "why". I still haven't heard the why. > What you are asking for is *SUPPORT* for 6.2. That implies that we No, I never asked for that. Depending on the answer to "why" I was going to decide what my choices were for helping out and improving the situation in some form. Without the "why" I haven't the foggiest idea how to help. (for already well known bugs which don't need my time/ effort/attention) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From gad at FreeBSD.org Sat Jun 7 22:56:57 2008 From: gad at FreeBSD.org (Garance A Drosehn) Date: Sat Jun 7 22:57:03 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <2892DF94-B346-4F36-9D32-165A2EA462D1@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <80D7EE2D-A970-407B-A42C-AD17500BC463@netconsonance.com> <861w3cf2pj.fsf@ds4.des.no> <2892DF94-B346-4F36-9D32-165A2EA462D1@netconsonance.com> Message-ID: At 1:04 PM -0700 6/7/08, Jo Rhett wrote: >On Jun 5, 2008, at 6:09 AM, Dag-Erling Sm?rgrav wrote: >>If you have issues with 6.3, your time would be better spent reporting >>them (by which I mean describe them in detail) than waving your hands in >>the air and yelling at people. > >Must you resort to nonsense and hyperbole? > >I'd said nearly a dozen times that the issues I have aren't specifics. >I am questioning the overall policy for EoL here. Your concern has been noted and rejected. Since you obviously are not the FreeBSD project, there will be nothing gained by repeating your concern for the thirtieth time. It is getting mighty annoying that you are "challenging" others to support 6.2 for you. For free. Several committers have offered to look at any bugs which prevent you from going to 6.3, and you don't want to hear about that. Your workload is such that you don't really want to even look at any FreeBSD changes this year, and you assume that our workload is such that we could painlessly continue to guarantee support for the specific release that you want to stick with for another year. Sorry, but we're busy too. We are not changing the rules on you. When you upgraded to 6.2, we announced when the EOL would be. We extended that once already. You have not provided a compelling argument why we should extend it again. In some ways, I can understand your concern. My own manager has very similar opinions to yours. He solved it by choosing linux and buying into the "Enterprise Edition"s of Redhat. 5 years of support. I suggest you look into that option. It seems better suited to your needs. It is a sad truth that the FreeBSD project is not able to be everything to everybody, but there it is. As much as we might like to, but we simply can't. Perhaps you can find a number of other people who love 6.2 and hate 6.3, and together you can pay someone to support 6.2 for you. The way my manager pays Redhat for extended support. As Kris has noted, there has been nothing of value in this thread. Initially it looked like there might be, but the more you talk the less it seems you have a legit complaint. Your challenge has been read by many committers, and your challenge has been found lacking, impractical and uninteresting. Now, is it true that every single freebsd committer must reply to this thread and tell you "Sorry, but No"? And we must all be nice while we do it, or we'll also be lectured about our manners? -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From killing at multiplay.co.uk Sat Jun 7 23:06:02 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Sat Jun 7 23:06:07 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com><48472DB6.5030909@samsco.org><6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com><200806050248.59229.max@love2party.net><20080605083907.GD1028@server.vk2pj.dyndns.org><902E9703E6E50776A17E9F92@utd65257.utdallas.edu><20080605220244.GP1028@server.vk2pj.dyndns.org><34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu><48488D1A.9070105@kutulu.org><52E265BB-BBB1-439D-B375-D6C6AA04697C@netconsonance.com> Message-ID: Seriously man, is it really necessary to reply to every single post? How about you spend some of that time and effort testing 6.3 or 7.0 instead of winging about things which may or may not in fact be any issue at all, as you have not even bothered to test. ----- Original Message ----- From: "Jo Rhett" > No, I never asked for that. Depending on the answer to "why" I was > going to decide what my choices were for helping out and improving the > situation in some form. Without the "why" I haven't the foggiest idea > how to help. (for already well known bugs which don't need my time/ > effort/attention) ================================================ 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 postmaster@multiplay.co.uk. From kensmith at cse.Buffalo.EDU Sat Jun 7 23:47:40 2008 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Sat Jun 7 23:47:48 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <52E265BB-BBB1-439D-B375-D6C6AA04697C@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <48488D1A.9070105@kutulu.org> <52E265BB-BBB1-439D-B375-D6C6AA04697C@netconsonance.com> Message-ID: <1212882453.94878.51.camel@neo.cse.buffalo.edu> On Sat, 2008-06-07 at 14:37 -0700, Jo Rhett wrote: > These are the raw issues without any friendly wording. > > 1. Bugs in 6.3 that are patched aren't available in any other -RELEASE. > 2. Bugs in 6.3 outstanding that don't affect 6.2 > 3. Overall amount of bugs. > 4. Difference in code base between 6.3 and 6-STABLE is > than 6.2 and > 6.3 > > These combine to produce a release which will never be "stable" for > production needs. The issue seems to be that we see no evidence that there is any significant volume to your item #2, and that's why you are receiving so much push-back on this. And that's what you are being asked for evidence of. That is the ONLY thing that should be preventing you from upgrading to 6.3. Item #1 can't be addressed at all and affects you while you're running 6.2 just as much as it would affect you running 6.3. Item #3 is irrelevant in most peoples' eyes because again we see no evidence that those bugs that would be part of #3 are not in 6.2 as well as 6.3. Item #4 is also a non-issue since there is no telling if any of that code that's changed affects something that you would notice. For example if a chunk of the code that's changed between 6.3 and 6-STABLE were an amd(8) import that has absolutely no relevance to any of this discussion, 6.3's overall stability, etc. As for your overall question of "Why can't 6.2 continue to be supported?" I answered that but from your reply it seems you may not have quite understood it. We typically support the LAST release in a branch for 2 years, it's typical to not support the earlier releases that long. That is based on the theory that we don't have regressions, and that if we do have regressions we fix them with Errata Notices. We did indeed have a major regression with 6.3 - there was a problem with the threads libraries which has been fixed with an Errata Notice. As I say the reason for so much push-back seems to be the lack of any concrete evidence that there are major regressions (by definition a regression being something that had worked in 6.2 that is broken in 6.3). From peoples' experiences and their surveys of the PR list we have not seen any evidence of the regressions you say you are concerned about - it seems like anything that would affect you in 6.3 should also be affecting you in 6.2. Since we all seem to be unable to find what you are concerned about could you please (when you have time - I have noticed you said you were time-crunched) let us know what they are? Given that perhaps we can address the issues and do Errata Notices. You have also asked about costs. A large one is the time of the volunteers on the security team. We take Security Advisories and Errata Notices VERY seriously - we try very hard to make sure that what gets posted is absolutely correct. That means applying the patches to all branches concerned and testing them as best we can. As code ages some of the more complicated patches can cause concern that they're not quite right for the older code because of fundamental changes that have been made (for example locking kernel data structures is hard, at times extremely complex, and what you need to "watch out for" can change over time even within a X-STABLE branch). And there is some cost in time/energy/resources to maintain FreeBSD-Update support. Those things don't mean we can't continue support of 6.2, but they do mean it requires effort. And again we can't seem to find any evidence that the effort is needed since we can't seem to find any evidence of *regressions* in 6.3. So when you've got the time let us know what evidence it is we're missing. And again, pointing at the CVS repository and saying "lots changed" isn't evidence. That's completely irrelevant because of many things including what I mentioned above (e.g. an import of vendor code shows up as changed code in our CVS repository but for the purposes of this discussion it's irrelevant). -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080607/77319a2a/attachment-0001.pgp From gad at FreeBSD.org Sat Jun 7 23:56:19 2008 From: gad at FreeBSD.org (Garance A Drosehn) Date: Sat Jun 7 23:56:25 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <48488D1A.9070105@kutulu.org> <52E265BB-BBB1-439D-B375-D6C6AA04697C@netconsonance.com> Message-ID: At 3:29 PM -0700 6/7/08, Jo Rhett wrote: >On Jun 7, 2008, at 3:05 PM, Garance A Drosehn wrote: >>The fact that we reject your request that we provide further support >>for 6.2 does not mean we did not understand the question. It is you >>who are not understanding the reply. > >At the very least, I phrased my question badly. Because I asked >"why" and I heard "no". And "no" is not an answer to "why". I >still haven't heard the why. Apparently the email with this answer from Doug Barton did not reach you: Lack of time on the part of the people that do the support. (As has been explained lots of times already.) I realize that you'd rather have an answer that gives you something to argue about, but there isn't one. Nothing has changed since his email. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From dougb at FreeBSD.org Sun Jun 8 00:12:00 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Jun 8 00:12:06 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <80D7EE2D-A970-407B-A42C-AD17500BC463@netconsonance.com> <861w3cf2pj.fsf@ds4.des.no> <2892DF94-B346-4F36-9D32-165A2EA462D1@netconsonance.com> <484AF52A.108@FreeBSD.org> Message-ID: <484B23C8.3040408@FreeBSD.org> Jo Rhett wrote: > On Jun 7, 2008, at 1:52 PM, Doug Barton wrote: >>> I'd said nearly a dozen times that the issues I have aren't >>> specifics. I am questioning the overall policy for EoL here. >> >> Your concerns have been noted. You seem unwilling or unable to accept >> the explanation that no matter what you think about the situation, we >> don't have the resources to support 6.2. > > I haven't been given an explanation. I was given that bare statement. > An explanation might help me understand where I can help improve the > situation. The only message in this thread that you have NOT responded to was the one where I answered these questions for you (again) in simple terms. The people that do the work of supporting branches do not have the time to support 6.2. You're not going to get another answer because there isn't one. It's clear from you rhetorical style that you are uninterested in anything in the vicinity of a constructive conversation, so this is my last response to you. Doug -- This .signature sanitized for your protection From bri at brianwhalen.net Sun Jun 8 00:57:06 2008 From: bri at brianwhalen.net (Brian) Date: Sun Jun 8 00:57:09 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080607204408.GA39103@hugo10.ka.punkt.de> References: <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com> <484808B8.8070506@FreeBSD.org> <5CCF0D6E-56C1-4EBD-B8A6-955311F7851E@netconsonance.com> <20080607204408.GA39103@hugo10.ka.punkt.de> Message-ID: <484B2653.2050600@brianwhalen.net> > >> >> However, the fixes are not available in a -RELEASE version of the operating >> system. >> > > Does freebsd-update not address these? Brian From adrian at freebsd.org Sun Jun 8 01:01:46 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Sun Jun 8 01:01:51 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <20080604204325.GD4701@lava.net> <20080604234532.GA89656@k7.mavetju> <458FE12C-AE4D-48F9-8193-4663079CEEF8@netconsonance.com> <84EBEA5D3A1F47E79E8E12C4CF4D0314@multiplay.co.uk> <7B8FD1A1E7DA49DFA68252BF9C74AE6F@multiplay.co.uk> <1A050712-3D0F-4263-A9F8-EE4AD042486E@netconsonance.com> Message-ID: 2008/6/8 Jo Rhett : >> If stability is your main concern then you could throw some resources >> at fixing 6.3 or throw some resources at backporting security fixes to >> 6.2. > > I will apparently be backporting the security fixes myself until 6.4 ships. And if you do, someone (or me, if noone bothers) will be quite happy to commit them to the release branch. >> I'm sure noone has an agenda to squish the FreeBSD version you're >> using for any reason other than there aren't enough people >> volunteering / being paid to work on back-porting security fixes. > > > This is perhaps the real topic that needs to be addressed. Can we get some > more details on the issues involved here? .. There isn't much to say. There aren't enough people putting in their volunteer time to work on this. If you / your company is willing to begin fixing this problem by contributing back to the community, I bet the security team will be quite happy to work with you to get the work done. And you get that fuzzy, warm feeling from contributing to an open source project. :) If everyone who wants 6.2 to be maintained longer wants to put in a couple hours a week of time to help maintain and backport stuff, I think we as a project would be stupid to say no. You just have to be prepared to do the work and be honest enough to say when you're unable to do it anymore. Anyway, this thread is making people upset. :) Adrian -- Adrian Chadd - adrian@freebsd.org From adrian at freebsd.org Sun Jun 8 01:03:33 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Sun Jun 8 01:03:38 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4848073C.2060509@rxsec.com> Message-ID: 2008/6/8 Jo Rhett : > On Jun 5, 2008, at 8:39 AM, Adrian Chadd wrote: >> >> The OP stated "argh argh sky is falling with 6.3!" but hasn't yet >> listed PRs which indicate this to be happening. >> He's offered hardware in a week or two - which is great! - but what >> irks the developers is the large amount of noise and absolutely no >> useful information. Anyone can say "its broken!".. > > > Adrian, your other comments are smart and valid. Why is this kind of > hyperbole necessary? Oh don't mind me, I occasionally get pissed off too. :) I have this exact problem with the other project I work on (Squid), and it just gets mto me sometimes. Adrian -- Adrian Chadd - adrian@freebsd.org From cliftonr at lava.net Sun Jun 8 01:32:51 2008 From: cliftonr at lava.net (Clifton Royston) Date: Sun Jun 8 01:32:53 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <37414AAF-C75A-4292-A174-2198BEF2A7DF@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <484736E0.6090004@samsco.org> <4847D5F8.80605@FreeBSD.org> <37414AAF-C75A-4292-A174-2198BEF2A7DF@netconsonance.com> Message-ID: <20080608013246.GB8955@lava.net> On Sat, Jun 07, 2008 at 12:53:10PM -0700, Jo Rhett wrote: ... > The question I raised is simply: given the number of bugs opened and > fixed since 6.3-RELEASE shipped, why is 6.3 the only supported > version? Why does it make sense for FreeBSD to stop supporting a > stable version and force people to choose between two different > unstable versions? Is this really the right thing to do? In what sense do you consider 6.2 stable? Stable as compared to what? I think a part of the problem here - not the only part - is that you are using idiosyncratic definitions of terms. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From des at des.no Sun Jun 8 01:33:12 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sun Jun 8 01:33:17 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: (Jo Rhett's message of "Sat\, 7 Jun 2008 13\:51\:28 -0700") References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <1212683649.90048.43.camel@bauer.cse.buffalo.edu> Message-ID: <86zlpwk8x6.fsf@ds4.des.no> Jo Rhett writes: > 2 years would be perfectly fine in my mind. I'd love to see 2 years > of support for 6.2-RELEASE. Well, you're getting two years for 6.3. > 6.2 was (and *is* AFAIK) the most stable release of FreeBSD since 4.11 > and it came out the door with less than 12 months of support intended. 6.2 was released on 2007-01-15. The original EoL date was 2008-01-31, and was later pushed back to 2008-05-31. How is that "less than 12 months of support intended"? DES -- Dag-Erling Sm?rgrav - des@des.no From des at des.no Sun Jun 8 02:02:39 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sun Jun 8 02:02:44 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <2892DF94-B346-4F36-9D32-165A2EA462D1@netconsonance.com> (Jo Rhett's message of "Sat\, 7 Jun 2008 13\:04\:16 -0700") References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <80D7EE2D-A970-407B-A42C-AD17500BC463@netconsonance.com> <861w3cf2pj.fsf@ds4.des.no> <2892DF94-B346-4F36-9D32-165A2EA462D1@netconsonance.com> Message-ID: <86ve0kk7k3.fsf@ds4.des.no> Jo Rhett writes: > Dag-Erling Sm?rgrav writes: > > If you have issues with 6.3, your time would be better spent > > reporting them (by which I mean describe them in detail) than waving > > your hands in the air and yelling at people. > Must you resort to nonsense and hyperbole? I'll stop the minute you start backing your claims with data - by which I mean PR numbers at the very least, and preferably information about the outcome of your own tests. > I'd said nearly a dozen times that the issues I have aren't specifics. You mean apart from this: > gmirror failures, 3ware raid driver timeouts, bge0 problems. All > three in production use on dozens of systems. or this: > The bugs in question were very well documented. Sounds to me like you have something pretty specific in mind - yet you consistently refuse to share any of it with us. Every time someone asks you for more information, you dodge the issue with nonsense like the following: > I am questioning the overall policy for EoL here. Even if it was known > to work properly on my hardware the overwhelming amount of bugs in 6.3 > indicates an unstable release. Which overwhelming amount of bugs? Mark Linimon gave you the numbers: > Finally, here are some statistics about PR count: > > rel all kern > --- --- ---- > 6.0 210 91 > 6.1 217 81 > 6.2 396 102 > 6.3 167 56 > 7.0 563 140 > > To me, this doesn't look like an overwhelming case for 6.3 being worse > off than 6.2. Yes, I'm sure there are regressions: there are in any > release. Looks like there are significantly fewer open PRs against 6.3 than against 6.2. > The diffs between 6.3 and 6-STABLE are greater than the diffs between > 6.2 and 6.3 last time I checked. Yet another claim that is simply not supported by evidence: des@ds4 ~/projects/freebsd/releng_6/src% ncvs diff -Nu -rRELENG_6_2_BP -rRELENG_6_3_BP >/tmp/releng62-releng63.diff des@ds4 ~/projects/freebsd/releng_6/src% ncvs diff -Nu -rRELENG_6_3_BP -rRELENG_6 >/tmp/releng63-releng6.diff des@ds4 ~/projects/freebsd/releng_6/src% wc /tmp/releng6* 1177219 4227294 48994670 /tmp/releng62-releng63.diff 481059 2094131 16180209 /tmp/releng63-releng6.diff 1658278 6321425 65174879 total > I can't understand the logic in having only a single supported version > of the OS, especially one which so many known/reported/fixed-post- > release bugs. As you have been repeatedly told: we do what we can with the resources we have. DES -- Dag-Erling Sm?rgrav - des@des.no From adrian at freebsd.org Sun Jun 8 02:17:20 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Sun Jun 8 02:17:23 2008 Subject: 6.2; 6.3; EOL; combustible discussions Message-ID: Ok everyone, I think thats enough about this for now. I think the developers and users have made their points clear, and they're no going to agree any more (but they may agree less) over time. For now, I think we should wait for the following: * Some users standing up, stating "yes, 6.2 lifetime means a lot to us, we'll happily contribute back security fixes and/or bug fixes for our hardware so we can continue using it!", and then doing so. * Some users (Jo, in particular) providing hardware which 6.2 runs on but 6.3 may or may not, and allowing interested developers to jump on and test/debug, so this whole discussion can be ejected out the nearest airlock. * Users figuring out they can contribute back to the community. It isn't hard, honest. How do you think some of us learnt how stuff works? :) Anything else, really, is just going to continue upsetting people. Yes, users want stability in their specific environments. Yes, developers are mere mortals, and users should be happy that there's even a project here they can get access to without some kind of warez-like upload/download ratio. further discussion is just going to upset people even further. :) Adrian -- Adrian Chadd - adrian@freebsd.org From josh.carroll at gmail.com Sun Jun 8 02:38:10 2008 From: josh.carroll at gmail.com (Josh Carroll) Date: Sun Jun 8 02:38:15 2008 Subject: 6.2; 6.3; EOL; combustible discussions In-Reply-To: References: Message-ID: <8cb6106e0806071938x6a524ba4o969fbc4f0c85206@mail.gmail.com> > I think the developers and users have made their points clear, and > they're no going to agree any more (but they may agree less) over > time. You make it sound as if all users are of the same opinion as Jo. The majority of the responses from users running 6.3 in the thread(s) have been positive feedback of its operating properly. I know what you meant, though. Just don't want anyone to think there is somehow a line being drawn in the sand between users and developers. :) > * Some users standing up, stating "yes, 6.2 lifetime means a lot to > us, we'll happily contribute back security fixes and/or bug fixes for > our hardware so we can continue using it!", and then doing so. While it would be interesting to see the response here, it still doesn't necessarily provide a solution. It will still involved developers' time to QA the user-submitted patches, so it won't entirely eliminate the additional workload for maintainers. There is also zero (enforceable) accountability. If X people commit to this, what happens when only a fraction of them actually do end up helping? > * Some users (Jo, in particular) providing hardware which 6.2 runs on > but 6.3 may or may not, and allowing interested developers to jump on > and test/debug, so this whole discussion can be ejected out the > nearest airlock. That would, of course, require that Jo actually try to run 6.3 on his particular hardware, something he said he does not have the time (currently) to do. As others have pointed out, hardware often has numerous revisions and it's quite possible 6.3 will work fine for him. > Anything else, really, is just going to continue upsetting people. > Yes, users want stability in their specific environments. Yes, > developers are mere mortals, and users should be happy that there's > even a project here they can get access to without some kind of > warez-like upload/download ratio. further discussion is just going to > upset people even further. :) I agree, the horse has been beaten to death numerous times. I guess the one thing that I've taken away from this entire discussion is that perhaps it would be useful to the end users to have a managed/tracked list of regressions between releases. I know there are known bugs published, but is there a list of items that are strictly regressions? Even if it doesn't solve the problem of users with particular hardware configurations being able to run the new release, at least it's something people can use in deciding when/if to upgrade or whether they want to go the route of self-supporting security/errata fixes until they find a release they feel comfortable migrating to? Just my two cents, and hopefully I'm not throwing wood on the fire here. Regards, Josh From des at des.no Sun Jun 8 02:56:52 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sun Jun 8 02:56:56 2008 Subject: gmirror patches In-Reply-To: (Pete French's message of "Fri\, 06 Jun 2008 16\:16\:24 +0100") References: Message-ID: <86r6b8k5sk.fsf@ds4.des.no> Pete French writes: > Ah, yes, sorry about that - thought it would be obvious. I always > submit changes that way as I find that whitespace has a habit > of breaking otherwise. > [...] > How would I set about doing that without the whitespace being messed up > by email transit ? I have always found in the past that tabs end up as > spaces and then patch gets upset hwne you try to apply it. "email transit" does not mess up whitespace, though perhaps your web browser does (when you copy-paste the patch from the web interface). If the patches were submitted as PR attachments (using 'send-pr -a'), you can download them separately from the web interface, and avoid the entire copy-paste issue: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/113799 Finally, if you do end up with a patch with messed-up whitespace, you can still apply it using 'patch -l'. DES -- Dag-Erling Sm?rgrav - des@des.no From pschmehl_lists at tx.rr.com Sun Jun 8 03:17:13 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Sun Jun 8 03:17:17 2008 Subject: console access In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <200806051023.56065.jhb@freebsd.org> <200806051910.20319.pieter@degoeje.nl> <3E1DBCBBB1C614B1DBD0F166@utd65257.utdallas.edu> Message-ID: <449CAA5455C15CA79034C5D2@Macintosh.local> --On June 7, 2008 2:16:26 PM -0700 Jo Rhett wrote: > On Jun 5, 2008, at 11:35 AM, Paul Schmehl wrote: >> It's not quite that simple. To do that, I have to block out time to >> drive 45 miles during my supposed "off" hours and do the upgrade >> there. Because, if it breaks networking and I'm at home, the server >> will be down for at least an hour until I can drive to the hosting >> company, get access to the server and restore the old kernel. > > Paul, you should arrange with your colocation provider to get an out of > band serial connection to the system, and configure the console to go to > the serial port. We provide that for free at $EMPLOYER and most other > places I know of do it for free or nominal charge. > I was not aware of that. Thanks for the suggestion. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer. From pschmehl_lists at tx.rr.com Sun Jun 8 03:46:21 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Sun Jun 8 03:46:26 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <86tzg6aeye.fsf@ds4.des.no> <5B0709D83455470DA46533C4@Macintosh.local> Message-ID: <1CB0175143266C386F4593B9@Macintosh.local> --On June 7, 2008 2:41:32 PM +0800 Adrian Chadd wrote: > 2008/6/7 Paul Schmehl : > >> Not only is this wrong, but it completely misses the point. Why should >> Jo have to upgrade to find out if his servers will fail under the >> conditions already articulated in existing, unresolved PRs that affect >> hardware that he is presently using? That's a bit like saying, "Buy >> this new car. Sure it has bugs that could easily directly affect you, >> but what's the chance you'll encounter them? in the off chance that >> they do, then you can help us resolve them." > > The software is Free. The car was Bought (or suggested to be bought.) > > Re-visit the analogy with a free car that a friend wants to give you. > (Car analogies suck.) > Yes, they do. It was the best I could come up with on the spur of the moment. > >> Trust me. From a server admin's perspective, a bug affects you if it >> exists in hardware you use. Whether or not you're actually using the >> OS is completely irrelevant. Upgrading to the OS would be foolhardy. >> Even testing it on a handful of boxes will not prove that it won't fail >> under load in production. Anyone who has done testing knows it can >> only simulate, not duplicate, the conditions under which production >> servers run. I personally have experienced catastrophic failures after >> extensive testing that revealed no problems. > > You're using free software. This translates to "lots of people have > put in a lot of effort to provide something to the community which > they can use, at no cost, if it suits them." > Of course. What it *shouldn't* translate to is STFU and eat our dog food or go somewhere else. >> >> I've lectured enough. If anyone doesn't get the point by now further >> explanation isn't going to help. > > I still don't think you get it. FreeBSD is a community. A community > works when enough people contribute positively towards furthering the > goals of the project. Jo is a user. He sounds like he is using it in > some reasonably critical and money-earning roles. Jo can participate > by testing stuff on test hardware, reporting back issues and working > with the community. Bitching about there being no long-term support > for releases isn't constructive. Some developer comments may not be > constructive either, but this is a -community project-. Join the > -community- and help out. > Here's a hint for you. Jo already contributes. So do I. Furthermore, both of us deeply appreciate the work that the developers do to produce FreeBSD and have stated so repeatedly. > It doesn't matter if running a long-term support project would be > beneficial for a certain subset of the userbase, its a losing > situation to cater to them unless they somehow contribute back to the > community. > This is precisely the attitude that I am objecting to. Translated for the average user it states, "If you're using and not contributing, then shut up. You haven't earned the right to complain." Open source projects are not free. They cost the developers in time and effort. They also cost the users in dealing with untested bugs, dealing with making many disparate pieces of software work together rather than using a fully integrated commercial package. Open source projects also have benefits. Developers get the benefit of a huge plus on their resumes. This translates directly into increased income for some of them and could for all of them. They also benefit from intangibles such as the pride of a job well done, the respect of their peers and the admiration of their users. Users get benefits as well. They get to use a system that works better than many commercial products and has a great deal more flexibility. But don't think for one minute that open source is free for users and only costs developers. Neither "side" deserves to be insulted and talked down to. Maybe some developers need to quit. If the work is so difficult and stressful that they can't behave in a professional manner, perhaps it's an indication that they've overextended themselves and need to take a step back. There are few that have displayed an attitude that clearly states that they think they are doing all the contributing and users are doing nothing. Nothing could be further from the truth. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer. From zkolic at sbb.co.yu Sun Jun 8 05:30:23 2008 From: zkolic at sbb.co.yu (Zoran Kolic) Date: Sun Jun 8 05:30:28 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080607234754.0443A106578D@hub.freebsd.org> References: <20080607234754.0443A106578D@hub.freebsd.org> Message-ID: <20080608053037.GA831@faust.net> This thread solves nothing. Two positions are clear. Also, I recall harder words on openbsd list, with a lot shorter thread. The whole thing is finished and should stay in that state. All next posts could be written, but no need to be sent. Best regards Zoran From jfvogel at gmail.com Sun Jun 8 06:42:39 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sun Jun 8 06:42:43 2008 Subject: kernel panic on em0/taskq In-Reply-To: <484AFEF1.4040500@skytek.it> References: <484AFEF1.4040500@skytek.it> Message-ID: <2a41acea0806072342q518ac2afo663c91e730c16db@mail.gmail.com> On Sat, Jun 7, 2008 at 2:34 PM, Daniel Ponticello wrote: > Hello, > i'm experiencing periodic kernel panics on a server with FreeBSD 7.0-STABLE > #0: Tue May 20 19:09:43 CEST 2008. > My big problem is that the system is not performing memory dumping and/or > automatic reoboot, > it just stays there. > > Here' console output: > > em0: watchdog timeout -- resetting > kernel trap 12 with interrupts disabled > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic_id = 00 > fault virtual address = 0x14 > fault code = supervisor read, page not present > intruction pointerr = 0x20:0xc056e2ce > stack pointer = 0x28:0xe537fc08 > frame pointer = 0x28:0xe537fc28 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 29 (em0 taskq) > trap number = 12 > panic: page fault > cpuid = 0 > > > It just stays there, unresponsive (no automatic reboot). > > > > Any ideas? There was a problem in the watchdog path, I don't recall if it was checked in to STABLE, I will check after the weekend. But, there is also the question of why you are in the watchdog path in the first place. Jack From fjwcash at gmail.com Sun Jun 8 06:56:17 2008 From: fjwcash at gmail.com (Freddie Cash) Date: Sun Jun 8 06:56:20 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <37414AAF-C75A-4292-A174-2198BEF2A7DF@netconsonance.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846E637.9080101@samsco.org> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <484736E0.6090004@samsco.org> <4847D5F8.80605@FreeBSD.org> <37414AAF-C75A-4292-A174-2198BEF2A7DF@netconsonance.com> Message-ID: On 6/7/08, Jo Rhett wrote: > The question I raised is simply: given the number of bugs opened and > fixed since 6.3-RELEASE shipped, why is 6.3 the only supported > version? Why does it make sense for FreeBSD to stop supporting a > stable version and force people to choose between two different > unstable versions? Is this really the right thing to do? Define the terms "stable" and "unstable", how you measure said "stability" and "instability", and what you are comparing them against. Only then can people understand what you are talking about, and can any kind of meaningful dialog occur. Right now, you are saying one thing, people are hearing another, and responding with something else. Oh, and be sure to back things up with actual data, otherwise there's no point in going any further with this. -- Freddie Cash fjwcash@gmail.com From robert at ml.erje.net Sun Jun 8 07:31:08 2008 From: robert at ml.erje.net (Robert Joosten) Date: Sun Jun 8 07:31:13 2008 Subject: gmirror patches In-Reply-To: References: Message-ID: <20080608071316.GC973@iphouse.com> Hi, > Has anybody else had a chance to try the gmirror patches I posted here a > few weeks ago ? > http://www.freebsd.org/cgi/query-pr.cgi?pr=123630 I ran that patch against 7-stable, build flawless. I currently build a kernel, by accident I made a small mistake. I installworld'd but forgot to rebuild/install the kernel, a reboot in between... oh well. That box does collect syslog of abount 8 boxes, mysql in replication modus for backup purposes to a NFS share and is internal fallback mx server so it's somewhat I/O bound. It's a HP LH3 SMP box deployed with gmirror because it lacks scsi raid. So far it runs okay. Any hints I should look for or put into stress ? It's not very important to get this box up ;-) Cheers, Robert From daniel at skytek.it Sun Jun 8 09:06:00 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Sun Jun 8 09:06:07 2008 Subject: kernel panic on em0/taskq In-Reply-To: <2a41acea0806072342q518ac2afo663c91e730c16db@mail.gmail.com> References: <484AFEF1.4040500@skytek.it> <2a41acea0806072342q518ac2afo663c91e730c16db@mail.gmail.com> Message-ID: <484BA0FD.40706@skytek.it> Hello Jack! > > There was a problem in the watchdog path, I don't recall if > it was checked in to STABLE, I will check after the weekend. > > But, there is also the question of why you are in the watchdog > path in the first place. > I tried to apply the latest patch 1.184.2.3 2008/05/21 21:34:05 which includes the watchdog fix you mentioned. Let's see if it helps! No idea of why i'm in the watchdog path, but I forgot to add that this is virtualized VM on VmWare ESX (it emulates em interface)... so i guess it might the cause of why i am in the watchdog path. Do you have any ideas of why i wasn't able to collect dump and the system did not reboot automatically? Thanks, Daniel -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From andy.kosela at gmail.com Sun Jun 8 09:17:08 2008 From: andy.kosela at gmail.com (Andy Kosela) Date: Sun Jun 8 09:17:13 2008 Subject: console access Message-ID: <3cc535c80806080217m413995dej4037fd2aac22ef4b@mail.gmail.com> --On June 7, 2008 2:16:26 PM -0700 Jo Rhett wrote: > On Jun 5, 2008, at 11:35 AM, Paul Schmehl wrote: >> It's not quite that simple. To do that, I have to block out time to >> drive 45 miles during my supposed "off" hours and do the upgrade >> there. Because, if it breaks networking and I'm at home, the server >> will be down for at least an hour until I can drive to the hosting >> company, get access to the server and restore the old kernel. > > Paul, you should arrange with your colocation provider to get an out of > band serial connection to the system, and configure the console to go to > the serial port. We provide that for free at $EMPLOYER and most other > places I know of do it for free or nominal charge. > or if your colocation provider is using any modern server hardware (HP, Dell, IBM) and I bet they do, they should give you lights-out access (HP's ILO2, Dell's DRAC). Then you can even remotely mount iso images from your laptop at home directly on the server (very handy sometimes). -- Andy Kosela ora et labora From dick at nagual.nl Sun Jun 8 09:30:34 2008 From: dick at nagual.nl (Dick Hoogendijk) Date: Sun Jun 8 09:30:37 2008 Subject: 6.2; 6.3; EOL; combustible discussions In-Reply-To: References: Message-ID: <20080608113018.0000228f@westmark> On Sun, 8 Jun 2008 10:17:20 +0800 "Adrian Chadd" wrote: > and users should be happy that there's even a project here they can > get access to without some kind of warez-like upload/download ratio. Although I agree that FreeBSD's availability to the public is great I do not agree with this "you are a user, so just be happy" attitude. If developers get pissed off by (some) user comments I might understand that, but if they can't deal with "users" and their POVs they might better quit being a developer to an -open- project like FreeBSD and start developing products just for themselves. You have developers in 'flavours'; you also have all sorts of users ;-) > further discussion is just going to upset people even further. :) Being/geeting upset is -always- ones own fault. After all, it's only a discussion, not a war. So why be upset about words? -- Dick Hoogendijk -- PGP/GnuPG key: 01D2433D ++ http://nagual.nl/ + SunOS sxde 01/08 ++ From hausen at punkt.de Sun Jun 8 09:45:37 2008 From: hausen at punkt.de (Patrick M. Hausen) Date: Sun Jun 8 09:45:43 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4004D1C8-58E4-46E7-B735-4F1CDC5BCCB4@netconsonance.com> References: <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com> <484808B8.8070506@FreeBSD.org> <5CCF0D6E-56C1-4EBD-B8A6-955311F7851E@netconsonance.com> <20080607204408.GA39103@hugo10.ka.punkt.de> <4004D1C8-58E4-46E7-B735-4F1CDC5BCCB4@netconsonance.com> Message-ID: <20080608094534.GA58022@hugo10.ka.punkt.de> Hello, On Sat, Jun 07, 2008 at 03:11:42PM -0700, Jo Rhett wrote: > On Jun 7, 2008, at 1:44 PM, Patrick M. Hausen wrote: >> Upgrading your systems to 6.3 takes _precisely_ the same amount >> of work as upgrading to "6-STABLE as of today 00:00 GMT". > > No, it doesn't. You can get to 6.3 with freebsd-update. And you can stay > patched with freebsd-update on a -RELEASE. For a corporation to choose to > stick with -RELEASE makes perfect sense, and it specifically what the > -RELEASE versions were intended for. Correct, that's why we are running RELENG_6_3 on ~40 machines. >> People who have issues with RELENG_6_3 should upgrade to RELENG_6 >> which is perfectly supported. > > I'm sorry, but you clearly don't run RELENG_6 on anything. I run it on two > home computers, and grabbing it on any given day and trying to run with it > in production is insanity. That's not true. I'm running FreeBSD since 1994 and I've run RELENG_N in production at various stages including N = 3, 4, 5 and 6. > Lots and lots of things are committed, > reverted, recommitted, reverted and then finally redesigned. Each of those > steps are often committed to the source tree. Big changes that affect various parts of the system are announced by HEADS UP messages on the -stable mainling list. And by naming "today 00:00" I did not mean to suggest an _arbitrary_ state of the source tree but one you are to _pick_ based on commits and mailing list information. For example, when Jack comitted his fixes for em(4), we set the checkout date to just past he did precisely that. cvsup, make world, reboot, test (!), rollout ... I have never ever had a single problem caused by running RELENG_N. We changed that only because as the number of machines increases it pays to run the same software on all of them, and "RELEASE" provides a convenient (!) reference point for that. Yet, if I were affected by a particular bug in RELENG_6_3, I would simply pick my own later reference point at which the bug is fixed. Kind regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J?rgen Egeling AG Mannheim 108285 From andrew at modulus.org Sun Jun 8 09:53:40 2008 From: andrew at modulus.org (Andrew Snow) Date: Sun Jun 8 09:53:45 2008 Subject: console access In-Reply-To: <3cc535c80806080217m413995dej4037fd2aac22ef4b@mail.gmail.com> References: <3cc535c80806080217m413995dej4037fd2aac22ef4b@mail.gmail.com> Message-ID: <484BAC1C.8080300@modulus.org> Andy Kosela wrote: > Then you can even > remotely mount iso images from your laptop at home directly on the > server (very handy sometimes). Incidentally, when I tried to use a Supermicro IPMI card for networked remote media, FreeBSD boot loader crashed the machine (video went haywire and it didnt boot). The same thing happened when trying to use a USB CDROM drive, so I suspect USB boot support is at fault somehow. - Andrew From killing at multiplay.co.uk Sun Jun 8 11:31:13 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Sun Jun 8 11:31:19 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 References: <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com><4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com><4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com><484808B8.8070506@FreeBSD.org><5CCF0D6E-56C1-4EBD-B8A6-955311F7851E@netconsonance.com><20080607204408.GA39103@hugo10.ka.punkt.de><4004D1C8-58E4-46E7-B735-4F1CDC5BCCB4@netconsonance.com> <20080608094534.GA58022@hugo10.ka.punkt.de> Message-ID: <650DAC4C127C447BA6215850F906CC09@multiplay.co.uk> ----- Original Message ----- From: "Patrick M. Hausen" > I have never ever had a single problem caused by running RELENG_N. > We changed that only because as the number of machines increases > it pays to run the same software on all of them, and "RELEASE" > provides a convenient (!) reference point for that. Yet, if I were > affected by a particular bug in RELENG_6_3, I would simply pick > my own later reference point at which the bug is fixed. An alternative to this is to maintain a specific set of patches to -RELEASE for only the issues / fixes that you are experiencing. This has worked very well for us over the years so I can recommend it as well. Either way you get stable release which you can test and certify in your own environment, keeping regression risks to an absolute minimum. 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 postmaster@multiplay.co.uk. From freebsd at byshenk.net Sun Jun 8 11:37:05 2008 From: freebsd at byshenk.net (Greg Byshenk) Date: Sun Jun 8 11:37:10 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4004D1C8-58E4-46E7-B735-4F1CDC5BCCB4@netconsonance.com> References: <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com> <484808B8.8070506@FreeBSD.org> <5CCF0D6E-56C1-4EBD-B8A6-955311F7851E@netconsonance.com> <20080607204408.GA39103@hugo10.ka.punkt.de> <4004D1C8-58E4-46E7-B735-4F1CDC5BCCB4@netconsonance.com> Message-ID: <20080608113701.GF1381@core.byshenk.net> On Sat, Jun 07, 2008 at 03:11:42PM -0700, Jo Rhett wrote: > On Jun 7, 2008, at 1:44 PM, Patrick M. Hausen wrote: > >>This is why EoLing 6.2 and forcing people to upgrade to a release > >>with lots of known issues is a problem. > >People who have issues with RELENG_6_3 should upgrade to RELENG_6 > >which is perfectly supported. > I'm sorry, but you clearly don't run RELENG_6 on anything. I run it > on two home computers, and grabbing it on any given day and trying to > run with it in production is insanity. Lots and lots of things are > committed, reverted, recommitted, reverted and then finally > redesigned. Each of those steps are often committed to the source > tree. The -RELEASE versions prevent this kind of insanity. I can't speak for Patrick, but I can ad that I very definitely _do_ run RELENG_6 on ~40 machines (web, mail, file, and applications servers), and do so without any serious problems. Which is not to say that there are never problems, but that when there have been problems, they have been uncovered during testing. Of course it is true that "grabbing" something and "trying to run with it in production is insanity". But this (at least IMO) has nothing at all to do with RELENG_X _per_ _se_, as it applies equally to X-RELEASE, and also to any production systems running any other OS. Before we roll out a new RELENG_6 build, we test it first to discover any potential problems -- but this is standard practice for _everything_ that goes into production, including changes to Linux, Solaris, and Windows systems, and also changes to samba, apache, or any other software running on the systems. My point here is that it is the "grabbing" something and throwing it into production without testing that is "insanity", and that this has nothing specifically to do with RELENG_6. I might also add that I have machines that "grab" (actually, pretty much randomly -- that is, "on a given day" and without particular concern from me) RELENG_6 and RELENG_7, and even these machines very rarely exhibit any problems. Of course, these are just test machines, and without the full pre-production testing it is possible that there are some problems in these cases that just don't manifest themselves, but my experience (and, I suspect, that of many others) indicates that your description of RELENG_6 as a seething cauldron of uncertainty is inaccurate. > I'm struggling to find a phrase here that can't be taken to be an > insult, so forgive me and try to understand when I say that you really > should try watching the cvs tree for a bit before making a nonsense > comment like that. You don't seem to have struggled very hard. After all, you could have mad the same point by noting that you consider it a mistake to run RELENG_6 in production. And by not doing this, you have undermined your own position, as it seems clear that there are _many_ people and organizations who run RELENG_6 in production (by which I mean, some version of RELENG_6, and not the tracking of daily changes to RELENG_6), which means that your assertion that such is "nonsense" is itself mistaken. Somewhat more generally, this sort of thing may be why you are getting the amount of push-back you see. That is, what you are claiming seems to match the experience of few (if any) others. As you may have noticed from this thread, the general view (a consensus, seemingly, apart from yourself) is that 6.3 is _better_ (more stable, etc.) than 6.2. Given that such is the case (as it seems very much to be), then the response to your statement that 6.3 isn't good enough of "what exactly is wrong?" seems (at least to me) to be entirely reasonable. When one of my people comes to me and says that something is wrong with X (and particularly when my experience is that there is nothing wrong with X), my first response is almost invariably: "what, specifically, is wrong with X?" -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From andy.kosela at gmail.com Sun Jun 8 11:49:36 2008 From: andy.kosela at gmail.com (Andy Kosela) Date: Sun Jun 8 11:49:39 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 Message-ID: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com> On 6/8/08, Freddie Cash wrote: >>On 6/7/08, Jo Rhett wrote: >> The question I raised is simply: given the number of bugs opened and >> fixed since 6.3-RELEASE shipped, why is 6.3 the only supported >> version? Why does it make sense for FreeBSD to stop supporting a >> stable version and force people to choose between two different >> unstable versions? Is this really the right thing to do? > >Define the terms "stable" and "unstable", how you measure said >"stability" and "instability", and what you are comparing them >against. This whole discussion is really interesting as it clearly showcases two common trends in computing (rapid development vs stability) On the one side we got people (let's call them developers or computer scientists) who are more interested in development than stabilization of the existing code base. It's natural for them to think more about new features, researching new ideas and implementing them. It resembles an academic project, research project.Those computer scientists do not care much about stability, they are mainly interested in hacking on the code for the fun of it. It is open source after all as someone wisely remarked. From my own experience most if not all community based projects are more interested in following this trend than stabilization of the code. Although they do care about stability of their code base, their focus is more on implementing new features and moving rapidly forward. In today's quickly changing world we see this trend as prevailing. On the other hand though, there is a trend which focuses on maximum long term stabilization of the code base. Usually we see this trend in high end commercial companies serving the needs of mission critical businesses where even a minute of downtime can cause loss of thousands of dollars or even loss of lives of people (imagine stock exchanges, banks, financial & insurance institutions, army and police facilities, hospitals, nuclear plants etc.). Those types of businesses/institutions truly needs a maximum stable operating system. They really do not care about "new features", but they do care about maximum stability of the existing code, security, and nonstop business continuity even in the face of natural disasters. There is only one operating system I know of that survived 9/11 attacks - this is OpenVMS. It's not uncommon to see VMS uptimes of more than 10 years (you can ask Amsterdam police for evidence). Now that is a true stability! On the other note though, stability is the direct opposition of development and change. Something which is *stable* cannot change or must change very slowly in the long term. On the other hand something which is changing rapidly cannot by the very definition of it be stable but rather is...unstable. Plato said it very wisely in Timaeus: "What is that which always is and has no becoming; and what is that which is always becoming and never is?". In other words one could say - what is that which is always the same and stable and what is that which is always changing and is unstable? This elaborate thinking is directly connected even with the trends in todays computing. When the code base is changing rapidly and quickly you cannot say it's very stable. Something stable is always something heavy tested and unchanging. So on the one hand we got users like Jo who wants long term stabilization, who depends on FreeBSD to run their mission critical systems, and on the other the developers who are more interested in the *development* than maintaining and supporting older releases for many years. I got to agree with the developers -this is open source project with limited resources. In order to offer long term support the whole focus of the project would have to be changed - and you can't force people to do something they don't want to do in the open source world. It's more fun to work on implementing new code, than squashing bugs or fanatically audit the code in search of security flaws in old releases. The open source is moving very rapidly forward and it's not only FreeBSD. Look at Linux. There is more than 10,000 messages each month on LKML. Kernel.org peoples also do not care much about stability (recent problems with vanilla kernels do support my thesis) - they commit so fast and massively that it becomes real hard to maintain this "beast" even for seasoned hackers. But someone who is sane will not be using kernel.org kernels in mission critical production environments but rather commercial distro kernels like Red Hat's versions. Also they won't be using 8-CURRENT on production systems either. Those are more research projects than operating environments for data centers. But when Red Hat is taking kernel.org kernel and put it out as part of their distro they give 7 (read: seven) years support for that particular kernel, userland and any third party application they support. They backport all security and bug fixes to the "so called" stable release during those seven years. That is a long time in the open source world, as in the general computing world. They can do this because they have resources for that - they are operating as a commercial company. In FreeBSD even if you upgraded cleanly base system (this is very easy and fast now with freebsd-update(8)) there is always problem with ports. I'm perfectly aware that developers are more focused on the base system and ports are served on "as is" basis but most of the production systems deployed worldwide are using ports and depends on them most of their time. I also understand ports team in saying that there is no resources to have many branches of ports tree at the same time, but this little example will show that in the long term sometimes things are not working very smoothly for people who are running mission critical systems. Let's say some hypothetical 6.x-RELEASE comes out in January. The Apache port is freezed at hypothetical 2.0.40 version. Now in April someone discloses some very critical security flaw which affects all versions of Apache prior to 2.0.43. Now what you can do? You can update your Apache port to 2.0.43 fixing a security hole. But at the same time you don't know the upstream team changed dramatically some internal things in code, added tons of new features and at the same time introduced a ton of new bugs and possibly new security flaws which will be founded at a later time. Those changes in code can also very well break your applications which depended on the specific code in 2.0.40 version. So you are left with headaches and backup tapes (of course you would first test the upgrade process on the test machines). But my issue here is that ports really do not offer real stability for mission critical systems who often depends for years on specific versions of particular software (like banks). Red Hat in that case backports new security patches to those old stable versions and it seems it is some solution for such businesses. Of course I know there is no resources for creating supported -SECURITY branch of ports tree which would backport those patches. FreeBSD has always been known for its legendary stability and mature code base which is why many commercial companies depend on it every day. "The anomaly" as someone said of long term support for 4.x releases only helped to see FreeBSD as more stable and viable solution than Linux by many businesses. Mission critical systems needs long term support (read: at least backporting security patches) and stable systems that can run for years without interruption. When it comes to stability vs development maybe there is time to rethink FreeBSD overall strategy and goals. Major companies using FreeBSD in their infrastructure like Yahoo! or Juniper Networks would definetly benefit from such moves focused on long term support of stable releases. I honestly think it is in their interest to support, even financially -- Andy Kosela ora et labora From koitsu at FreeBSD.org Sun Jun 8 12:06:55 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Jun 8 12:06:59 2008 Subject: cpufreq broken on core2duo In-Reply-To: <484AEA18.4030901@ispro.net> References: <4847072E.5000709@ispro.net> <484713B2.5030200@ispro.net> <48471834.30905@modulus.org> <200806051040.28319.jhb@freebsd.org> <484AA07A.2010308@ispro.net> <20080607164812.GA11072@eos.sc1.parodius.com> <484AEA18.4030901@ispro.net> Message-ID: <20080608120655.GA50122@eos.sc1.parodius.com> On Sat, Jun 07, 2008 at 11:05:44PM +0300, Evren Yurtesen wrote: > I have tested if it is working or not without using powerd. However you are > right, SpeedStep in bios seem to be adding some ACPI support which looks > like kind of broken. > > In either case, I get error when I have HTT as powerd (powerd -v) is only > able to change 1 CPUs speed (obviously). Perhaps this can be fixed in > future hopefully. I believe you can only adjust the clock frequency of both CPUs/cores on Intel platforms. At least that's how it is under Windows, and under PC BIOSes. If you have a CPU that has dual cores, both cores will have their frequency adjusted. If you have dual physical CPUs that have dual cores, any frequency adjustment should apply to all CPUs. > In the bios, there is also Enhanced C1 support which seems to be reducing > the vcore voltage at the same clock speed. (is this normal even?) Enhanced C1 support allows the CPU to go into a deeper sleep state during idle periods. I recommend enabling it, even on server systems. You can safely enable it on systems using FreeBSD. You might be interested in the utility for Windows called RMClock, which provides an incredible amount of low-level information about CPUs and chipsets. Yes, I know it's for Windows, but if you ever boot Windows, it's a fantastic utility. > This is the motherboard (information from the datacenter): > http://www.supermicro.com/products/motherboard/PD/E7230/PDSML-LN2.cfm > Although kenv | grep smbios show PDSBM can this be or the datacenter is wrong? I can add support for this motherboard to bsdhwmon(8), assuming you can get me a few pieces of information. (Edit: Actually, seems you've already contacted me with this information! Thanks!) I'll need to contact Supermicro to get Winbond interface details, however. That can take a couple weeks. > I just went to bios and says 1.264v so I guess it is safe to assume that > mbmon was showing double. mbmon is showing you invalid values. The fact that it's a value that happens to be double in value is pure chance. mbmon is not properly working with your motherboard. It's that simple. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Sun Jun 8 12:08:53 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Jun 8 12:08:59 2008 Subject: kernel panic on em0/taskq In-Reply-To: <484AFEF1.4040500@skytek.it> References: <484AFEF1.4040500@skytek.it> Message-ID: <20080608120852.GB50122@eos.sc1.parodius.com> On Sat, Jun 07, 2008 at 11:34:41PM +0200, Daniel Ponticello wrote: > Hello, > i'm experiencing periodic kernel panics on a server with FreeBSD > 7.0-STABLE #0: Tue May 20 19:09:43 CEST 2008. > My big problem is that the system is not performing memory dumping and/or > automatic reoboot, > it just stays there. Try adjusting some of these sysctl values: hw.acpi.disable_on_reboot hw.acpi.handle_reboot You're using VMware, which may or may not behave properly anyways. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From doconnor at gsoft.com.au Sun Jun 8 12:11:26 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Sun Jun 8 12:11:31 2008 Subject: console access In-Reply-To: <484BAC1C.8080300@modulus.org> References: <3cc535c80806080217m413995dej4037fd2aac22ef4b@mail.gmail.com> <484BAC1C.8080300@modulus.org> Message-ID: <200806082141.16653.doconnor@gsoft.com.au> On Sun, 8 Jun 2008, Andrew Snow wrote: > Andy Kosela wrote: > > Then you can even > > remotely mount iso images from your laptop at home directly on the > > server (very handy sometimes). > > Incidentally, when I tried to use a Supermicro IPMI card for > networked remote media, FreeBSD boot loader crashed the machine > (video went haywire and it didnt boot). > > The same thing happened when trying to use a USB CDROM drive, so I > suspect USB boot support is at fault somehow. Try a snapshot made after this commit.. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/btx/btx/btx.S?rev=1.46;content-type=text%2Fx-cvsweb-markup (it was MFC'd to RELENG_6 & others on the 18th of March) -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080608/51041929/attachment.pgp From koitsu at FreeBSD.org Sun Jun 8 12:12:34 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Jun 8 12:12:38 2008 Subject: console access In-Reply-To: <484BAC1C.8080300@modulus.org> References: <3cc535c80806080217m413995dej4037fd2aac22ef4b@mail.gmail.com> <484BAC1C.8080300@modulus.org> Message-ID: <20080608121234.GC50122@eos.sc1.parodius.com> On Sun, Jun 08, 2008 at 07:53:32PM +1000, Andrew Snow wrote: > Andy Kosela wrote: >> Then you can even >> remotely mount iso images from your laptop at home directly on the >> server (very handy sometimes). > > Incidentally, when I tried to use a Supermicro IPMI card for networked > remote media, FreeBSD boot loader crashed the machine (video went haywire > and it didnt boot). Supermicro IPMI cards are notoriously buggy. A few of the system engineers at Yahoo! who I know continually bitch and moan about how horrible they are. My advice: do not install the IPMI card which is causing your problems. Additionally, the IPMI card which "piggyback" on top of one of the onboard Ethernet ports are going to force the use of something called ASF (at least in Broadcom land it's called that), where the NIC then has two physical MAC addresses -- yes, you read that right! The OS has to have support for that feature for it to work properly, and your local LAN will probably freak out, ARP-wise. > The same thing happened when trying to use a USB CDROM drive, so I suspect > USB boot support is at fault somehow. Booting FreeBSD off of USB devices is known to be broken; see "BTX, boot2, and loader" section at the below URL: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From andrew at modulus.org Sun Jun 8 12:52:46 2008 From: andrew at modulus.org (Andrew Snow) Date: Sun Jun 8 12:52:51 2008 Subject: console access In-Reply-To: <20080608121234.GC50122@eos.sc1.parodius.com> References: <3cc535c80806080217m413995dej4037fd2aac22ef4b@mail.gmail.com> <484BAC1C.8080300@modulus.org> <20080608121234.GC50122@eos.sc1.parodius.com> Message-ID: <484BD615.2020702@modulus.org> Jeremy Chadwick wrote: > Supermicro IPMI cards are notoriously buggy. A few of the system > engineers at Yahoo! who I know continually bitch and moan about how > horrible they are. My advice: do not install the IPMI card which is > causing your problems. The remote KVM control feature was an important requirement so the card is staying. Luckily it uses the Intel gigabit NIC which seems to work well in 7-STABLE, I have no complaints so far. Every feature works well except virtual media. > Booting FreeBSD off of USB devices is known to be broken; see "BTX, > boot2, and loader" section at the below URL: > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues Thats interesting - I regularly use USB sticks to boot freebsd as its easier for installation on cluster machines/routers that lack CDROM drives. I've used it on, I think, half a dozen different motherboards/architectures and its worked well on all of them, the Supermicro box was the only broken one. Because virtual media emulates a USB device I'm pretty sure thats why it wasnt working - the USB problem, not a problem with the IPMI card. - Andrew From daniel at skytek.it Sun Jun 8 12:58:55 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Sun Jun 8 12:59:02 2008 Subject: kernel panic on em0/taskq In-Reply-To: <20080608120852.GB50122@eos.sc1.parodius.com> References: <484AFEF1.4040500@skytek.it> <20080608120852.GB50122@eos.sc1.parodius.com> Message-ID: <484BD795.80502@skytek.it> Hello, disabling acpi is not an option, since i'm running SMP. I have several other systems running 7.0 Release without problems, so it might be something on 7-Stable. Thanks, Daniel Jeremy Chadwick ha scritto: > On Sat, Jun 07, 2008 at 11:34:41PM +0200, Daniel Ponticello wrote: > >> Hello, >> i'm experiencing periodic kernel panics on a server with FreeBSD >> 7.0-STABLE #0: Tue May 20 19:09:43 CEST 2008. >> My big problem is that the system is not performing memory dumping and/or >> automatic reoboot, >> it just stays there. >> > > Try adjusting some of these sysctl values: > > hw.acpi.disable_on_reboot > hw.acpi.handle_reboot > > You're using VMware, which may or may not behave properly anyways. > > -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From daniel at skytek.it Sun Jun 8 13:07:03 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Sun Jun 8 13:07:06 2008 Subject: kernel panic on em0/taskq In-Reply-To: <484BD795.80502@skytek.it> References: <484AFEF1.4040500@skytek.it> <20080608120852.GB50122@eos.sc1.parodius.com> <484BD795.80502@skytek.it> Message-ID: <484BD97C.5000009@skytek.it> Sorry, I did not read well you suggestion ;) Anyway, the system reboots correctly if I issue the reboot command from command line. Should i adjust those values anyway? Thanks, Daniel Daniel Ponticello ha scritto: > Hello, > disabling acpi is not an option, since i'm running SMP. > I have several other systems running 7.0 Release without problems, > so it might be something on 7-Stable. > > > Thanks, > > Daniel > > > Jeremy Chadwick ha scritto: >> On Sat, Jun 07, 2008 at 11:34:41PM +0200, Daniel Ponticello wrote: >> >>> Hello, >>> i'm experiencing periodic kernel panics on a server with FreeBSD >>> 7.0-STABLE #0: Tue May 20 19:09:43 CEST 2008. >>> My big problem is that the system is not performing memory dumping >>> and/or automatic reoboot, >>> it just stays there. >>> >> >> Try adjusting some of these sysctl values: >> >> hw.acpi.disable_on_reboot >> hw.acpi.handle_reboot >> >> You're using VMware, which may or may not behave properly anyways. >> >> > -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From jaj at hcl-club.lu Sun Jun 8 13:25:05 2008 From: jaj at hcl-club.lu (Jona Joachim) Date: Sun Jun 8 13:25:10 2008 Subject: pkg_delete core dump when removing linux-tiff Message-ID: Hi! pkg_delete core dumps on me when it tries to remove linux-tiff. I can reproduce this reliably. nirvana# pkg_delete linux-tiff-3.7.1 pkg_delete: file '/compat/linux/usr/bin/bmp2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/fax2ps' doesn't exist pkg_delete: file '/compat/linux/usr/bin/fax2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/gif2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/pal2rgb' doesn't exist pkg_delete: file '/compat/linux/usr/bin/ppm2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/ras2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/raw2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/rgb2ycbcr' doesn't exist pkg_delete: file '/compat/linux/usr/bin/thumbnail' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiff2bw' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiff2pdf' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiff2ps' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiff2rgba' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffcmp' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffcp' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffdither' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffdump' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffinfo' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffgt' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffmedian' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffset' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffsplit' doesn't exist pkg_delete: file '/compat/linux/usr/lib/libtiff.so.3' doesn't exist pkg_delete: file '/compat/linux/usr/lib/libtiff.so.3.7.1' doesn't exist pkg_delete: file '/compat/linux/usr/share/doc/libtiff-3.7.1/COPYRIGHT' doesn't exist pkg_delete: file '/compat/linux/usr/share/doc/libtiff-3.7.1/README' doesn't exist pkg_delete: file '/compat/linux/usr/share/doc/libtiff-3.7.1/RELEASE-DATE' doesn't exist pkg_delete: file '/compat/linux/usr/share/doc/libtiff-3.7.1/VERSION' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/bmp2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/fax2ps.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/fax2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/gif2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/pal2rgb.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/ppm2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/ras2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/raw2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/rgb2ycbcr.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/sgi2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/thumbnail.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiff2bw.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiff2pdf.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiff2ps.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiff2rgba.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffcmp.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffcp.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffdither.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffdump.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffinfo.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffgt.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffmedian.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffset.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffsplit.1.gz' doesn't exist Segmentation fault (core dumped) nirvana# I got caught by this when I was removing a large number of packages using pkg_cutleaves. Not sure why all those files are missing, perhaps pkg_delete removed them the first time before core dumping. It doesn't actually unregister the package. FWIW you can find the core dump here: http://www.hcl-club.lu/~jaj/stuff/pkg_delete.core uname -a FreeBSD nirvana.my.domain 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed May 28 19:35:33 CEST 2008 root@nirvana.my.domain:/usr/obj/usr/src/sys/HYPOCENTER i386 Best regards, Jona -- Pond-erosa Puff wouldn't take no guff Water oughta be clean and free So he fought the fight and he set things right With his OpenBSD From koitsu at FreeBSD.org Sun Jun 8 13:31:14 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Jun 8 13:31:18 2008 Subject: kernel panic on em0/taskq In-Reply-To: <484BD97C.5000009@skytek.it> References: <484AFEF1.4040500@skytek.it> <20080608120852.GB50122@eos.sc1.parodius.com> <484BD795.80502@skytek.it> <484BD97C.5000009@skytek.it> Message-ID: <20080608133114.GA61781@eos.sc1.parodius.com> On Sun, Jun 08, 2008 at 03:07:08PM +0200, Daniel Ponticello wrote: > Sorry, I did not read well you suggestion ;) > > Anyway, the system reboots correctly if I issue the reboot command from > command line. > Should i adjust those values anyway? I'd recommend adjusting them and see if the bug (not automatically rebooting on panic) changes. I'm guessing it won't (especially if reboot(8) works fine), but it's worth trying. You're the 2nd person I've seen who has reported this problem (re: FreeBSD not properly rebooting on panic). The other person: http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042250.html I'll add this to my Commonly reported issues Wiki. As for the problem itself, sorry, I have no idea what's causing it. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Sun Jun 8 13:36:41 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Jun 8 13:36:45 2008 Subject: console access In-Reply-To: <484BD615.2020702@modulus.org> References: <3cc535c80806080217m413995dej4037fd2aac22ef4b@mail.gmail.com> <484BAC1C.8080300@modulus.org> <20080608121234.GC50122@eos.sc1.parodius.com> <484BD615.2020702@modulus.org> Message-ID: <20080608133641.GB61781@eos.sc1.parodius.com> On Sun, Jun 08, 2008 at 10:52:37PM +1000, Andrew Snow wrote: > Jeremy Chadwick wrote: >> Supermicro IPMI cards are notoriously buggy. A few of the system >> engineers at Yahoo! who I know continually bitch and moan about how >> horrible they are. My advice: do not install the IPMI card which is >> causing your problems. > > The remote KVM control feature was an important requirement so the card is > staying. Luckily it uses the Intel gigabit NIC which seems to work well in > 7-STABLE, I have no complaints so far. Every feature works well except > virtual media. > >> Booting FreeBSD off of USB devices is known to be broken; see "BTX, >> boot2, and loader" section at the below URL: >> >> http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > Thats interesting - I regularly use USB sticks to boot freebsd as its > easier for installation on cluster machines/routers that lack CDROM drives. > I've used it on, I think, half a dozen different > motherboards/architectures and its worked well on all of them, the > Supermicro box was the only broken one. Okay, so then your original comment ("The same thing happened when trying to use a USB CDROM drive, so I suspect USB boot support is at fault somehow") might actually not be caused by FreeBSD at all? The reason I say that: > Because virtual media emulates a USB device I'm pretty sure thats why it > wasnt working - the USB problem, not a problem with the IPMI card. What Supermicro box is having USB booting problems? I'm currently in a battle with Supermicro regarding the PDSMi+ not properly booting certain models of USB flash drives: http://koitsu.wordpress.com/2008/04/05/supermicro-pdsmi-bios-bugs/ http://koitsu.wordpress.com/2008/04/26/supermicro-pdsmi-bios-bugs-part-2/ Supermicro currently has both of my USB flash drives which I reported (two different) problems with, and they have confirmed the bug, but are "unsure what's causing it". The last time I heard from them was 3 weeks ago, stating "we're still working on it". (I'd really like my USB drives back......) I would not be surprised if the same problem affected USB CDROMs. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From andrew at modulus.org Sun Jun 8 13:46:30 2008 From: andrew at modulus.org (Andrew Snow) Date: Sun Jun 8 13:46:34 2008 Subject: console access In-Reply-To: <20080608133641.GB61781@eos.sc1.parodius.com> References: <3cc535c80806080217m413995dej4037fd2aac22ef4b@mail.gmail.com> <484BAC1C.8080300@modulus.org> <20080608121234.GC50122@eos.sc1.parodius.com> <484BD615.2020702@modulus.org> <20080608133641.GB61781@eos.sc1.parodius.com> Message-ID: <484BE2AE.9060604@modulus.org> Jeremy Chadwick wrote: > Okay, so then your original comment ("The same thing happened when > trying to use a USB CDROM drive, so I suspect USB boot support is at > fault somehow") might actually not be caused by FreeBSD at all? The > reason I say that: OK, good point. I didn't try any other OS, I just tried FreeBSD 6 and 7 off a USB CDROM drive, virtual media CDROM, and virtual media floppy, both of which use USB emulation. I assumed that if I tried, say, a Windows CD, it would just work because that's usually Supermicro's target market. > What Supermicro box is having USB booting problems? Its a rather new X7DWT motherboard (Intel 5400 chipset, Xeon CPU) Good luck with getting your USB drives back :-) - Andrew From doconnor at gsoft.com.au Sun Jun 8 13:49:04 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Sun Jun 8 13:49:10 2008 Subject: console access In-Reply-To: <484BD615.2020702@modulus.org> References: <3cc535c80806080217m413995dej4037fd2aac22ef4b@mail.gmail.com> <20080608121234.GC50122@eos.sc1.parodius.com> <484BD615.2020702@modulus.org> Message-ID: <200806082318.47656.doconnor@gsoft.com.au> On Sun, 8 Jun 2008, Andrew Snow wrote: > Thats interesting - I regularly use USB sticks to boot freebsd as its > easier for installation on cluster machines/routers that lack CDROM > drives. I've used it on, I think, half a dozen different > motherboards/architectures and its worked well on all of them, the > Supermicro box was the only broken one. > > Because virtual media emulates a USB device I'm pretty sure thats why > it wasnt working - the USB problem, not a problem with the IPMI card. Lucky you, every system I've tried it on bar my Dell i8600 laptop failed to boot :) With the btx.S r1.46 commit I was much more successful 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080608/a510f9c5/attachment.pgp From kris at FreeBSD.org Sun Jun 8 13:57:57 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Sun Jun 8 13:58:00 2008 Subject: pkg_delete core dump when removing linux-tiff In-Reply-To: References: Message-ID: <484BE563.90102@FreeBSD.org> Jona Joachim wrote: > Hi! > > pkg_delete core dumps on me when it tries to remove linux-tiff. > I can reproduce this reliably. > FWIW you can find the core dump here: > http://www.hcl-club.lu/~jaj/stuff/pkg_delete.core You need to obtain the backtrace, see the developers handbook. Kris From rwatson at FreeBSD.org Sun Jun 8 15:28:41 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Jun 8 15:28:46 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <4848073C.2060509@rxsec.com> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4848073C.2060509@rxsec.com> Message-ID: <20080608160550.C16871@fledge.watson.org> On Thu, 5 Jun 2008, Chris Marlatt wrote: > Adrian Chadd wrote: >> The project is doing what it can with what people are contributing. If > > What if it can accomplish the same or more by simply reorganizing what it's > already doing? I completely understand the apparent situation - if you look > at it from all angles it appears to be no different than that of the people > apposed to the recent scheduling changes FreeBSD has made. There's a limited > amount of people and time to do everything. It's an order-of-magnitude question. The work required to support a release for 48 months is more than double the work required to support a release for 24 months. The current regular and extended support releases reflect a practical balance with respect to how long a release can be support. We provide a much longer timeline of support for *branches*, however, and that's generally the support mechanism recommended for people looking for 4-6 years of support for a version of FreeBSD. If you look at what other OS vendors do -- Microsoft is a particularly easy example to inspect -- they require occasional large-scale updates while you live on a particular branch. For example, if you're going to keep running Win2k for six years, you must install their service packs, not just hot fixes for specific vulnerabilities. Our minor releases on a branch are a *lot* less disruptive than service packs for Windows, and are much more conservative. Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Sun Jun 8 15:52:38 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Jun 8 15:52:42 2008 Subject: 6.2; 6.3; EOL; combustible discussions In-Reply-To: <8cb6106e0806071938x6a524ba4o969fbc4f0c85206@mail.gmail.com> References: <8cb6106e0806071938x6a524ba4o969fbc4f0c85206@mail.gmail.com> Message-ID: <20080608164928.L16871@fledge.watson.org> On Sat, 7 Jun 2008, Josh Carroll wrote: > While it would be interesting to see the response here, it still doesn't > necessarily provide a solution. It will still involved developers' time to > QA the user-submitted patches, so it won't entirely eliminate the additional > workload for maintainers. There is also zero (enforceable) accountability. > If X people commit to this, what happens when only a fraction of them > actually do end up helping? Just to be clear here, Adrian's claim that if someone else provided patches for 6.2, they would be committed, is incorrect. The cost of committing the patch is almost zero -- the cost of QA'ing the patch, doing freebsd-update rebuilds, preparing security or errata notices, etc, is extremely real, and the reason that we carefully limit the number of releases we support at once. In fact, I'd argue that we have been supporting too many releases at once, as I think our latency for shipping errata notices and advisories is too high. By reducing the number of releases we support, we improve the speed and attention we can give each notice/advisory, which is an important consideration. Robert N M Watson Computer Laboratory University of Cambridge From talon at lpthe.jussieu.fr Sun Jun 8 16:02:38 2008 From: talon at lpthe.jussieu.fr (Michel Talon) Date: Sun Jun 8 16:02:43 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 Message-ID: <20080608154920.GA8266@lpthe.jussieu.fr> Andy Kosela wrote: ... a really beutiful and elaborate post on the subject ... However, being an ordinary user with few machines running FreeBSD, i have seen on my limited sample that 2 machines worked better with 6.3 than 6.2 (two old Athlon machines, which work perfectly OK in fact) and one worked much worse (a P4 which used to be perfectly stable and suddenly panicked 3 times in a week). So i upgraded this last one to 7.0 and it is now working perfectly well without any trouble. The only "gotcha" is the slowness of X problem when compiling, but i live with that. Moral of the story: the developer base of FreeBSD is not large enough to maintain a large number of releases. In my humble opinion, having 8.0 7.0 and 6.* is even too much. The developers are working on 8.0, they still have a very good grasp of 7.0 but 6.* becomes old stuff, more or less forgotten. It then occurs that things are merged to the 6.* branch which are perhaps susceptible of destabilising it. Personnally i have seen the same occurring with 6.0, 5.0 and 4.*, for me the last releases of the 4.* were very poor on my laptop while the early 4.* releases were perfectly OK. I think it is very unreasonable for end users to ask maintaining, e.g. 6.2 ad vitam eternam. The real stable branch is now 7.* and diverting effort to polish the 6.* is a waste of time. People wanting a very stable system should simply use something else, like Debian stable, official RedHat, etc. whose aim is precisely to offer the maximum stability, with only security and bug fixes, and for extended periods of time. The price you pay is obsoleted and "unsexy" systems, which is probably OK for the intended use. On the other hand i have no business running such a system. -- Michel TALON From 000.fbsd at quip.cz Sun Jun 8 17:18:17 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Sun Jun 8 17:18:23 2008 Subject: console access In-Reply-To: <20080608121234.GC50122@eos.sc1.parodius.com> References: <3cc535c80806080217m413995dej4037fd2aac22ef4b@mail.gmail.com> <484BAC1C.8080300@modulus.org> <20080608121234.GC50122@eos.sc1.parodius.com> Message-ID: <484C1468.6020403@quip.cz> Jeremy Chadwick wrote: > On Sun, Jun 08, 2008 at 07:53:32PM +1000, Andrew Snow wrote: [...] > Additionally, the IPMI card which "piggyback" on top of one of the > onboard Ethernet ports are going to force the use of something called > ASF (at least in Broadcom land it's called that), where the NIC then > has two physical MAC addresses -- yes, you read that right! The OS has > to have support for that feature for it to work properly, and your local > LAN will probably freak out, ARP-wise. It would be nice to have it better documented in manpage for bge (I know hw.bge.allow_asf is mentioned, but the words does not make it clear to me). It took me a long time before I discovered that I need to add hw.bge.allow_asf="1" in to loader.conf. Since that my eLOM on Sun Fire X2100 M2 servers works nicely without any lockups (mentioned in manpage) >>The same thing happened when trying to use a USB CDROM drive, so I suspect >>USB boot support is at fault somehow. > > > Booting FreeBSD off of USB devices is known to be broken; see "BTX, > boot2, and loader" section at the below URL: > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues I am using USB flashdisks with FreeBSD installer with GRUB on HW where older BTX failed. Miroslav Lachman From utisoft at googlemail.com Sun Jun 8 18:04:10 2008 From: utisoft at googlemail.com (Chris Rees) Date: Sun Jun 8 18:04:13 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 Message-ID: > Zoran Kolic wrote: > > This thread solves nothing. Two positions are clear. > Also, I recall harder words on openbsd list, with a > lot shorter thread. The whole thing is finished and > should stay in that state. All next posts could be > written, but no need to be sent. Aha, perhaps we need to get Theo in to finish it off! Chris From daniel at skytek.it Sun Jun 8 18:28:45 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Sun Jun 8 18:28:49 2008 Subject: kernel panic on em0/taskq In-Reply-To: <20080608133114.GA61781@eos.sc1.parodius.com> References: <484AFEF1.4040500@skytek.it> <20080608120852.GB50122@eos.sc1.parodius.com> <484BD795.80502@skytek.it> <484BD97C.5000009@skytek.it> <20080608133114.GA61781@eos.sc1.parodius.com> Message-ID: <484C24E4.5040108@skytek.it> I just checked the link you have reported. It looks like the problem is present only on SMP machines with both ULE and 4BSD scheduler. I can confirm that the problem is also present on 6.3-Stable. Basically, it freezes before collecting dump and before being able to reboot. I wish i could have more informations to open a PR. Thanks, Daniel Jeremy Chadwick ha scritto: > On Sun, Jun 08, 2008 at 03:07:08PM +0200, Daniel Ponticello wrote: > >> Sorry, I did not read well you suggestion ;) >> >> Anyway, the system reboots correctly if I issue the reboot command from >> command line. >> Should i adjust those values anyway? >> > > I'd recommend adjusting them and see if the bug (not automatically > rebooting on panic) changes. I'm guessing it won't (especially if > reboot(8) works fine), but it's worth trying. > > You're the 2nd person I've seen who has reported this problem (re: > FreeBSD not properly rebooting on panic). The other person: > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042250.html > > I'll add this to my Commonly reported issues Wiki. As for the problem > itself, sorry, I have no idea what's causing it. > > -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From cliftonr at lava.net Sun Jun 8 18:31:20 2008 From: cliftonr at lava.net (Clifton Royston) Date: Sun Jun 8 18:31:23 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <650DAC4C127C447BA6215850F906CC09@multiplay.co.uk> References: <48472CCF.8080101@FreeBSD.org> <20080608094534.GA58022@hugo10.ka.punkt.de> <650DAC4C127C447BA6215850F906CC09@multiplay.co.uk> Message-ID: <20080608183114.GA3049@lava.net> On Sun, Jun 08, 2008 at 12:18:22PM +0100, Steven Hartland wrote: > ----- Original Message ----- > From: "Patrick M. Hausen" > > >I have never ever had a single problem caused by running RELENG_N. > >We changed that only because as the number of machines increases > >it pays to run the same software on all of them, and "RELEASE" > >provides a convenient (!) reference point for that. Yet, if I were > >affected by a particular bug in RELENG_6_3, I would simply pick > >my own later reference point at which the bug is fixed. > > An alternative to this is to maintain a specific set of patches > to -RELEASE for only the issues / fixes that you are experiencing. > > This has worked very well for us over the years so I can recommend > it as well. I've done this too. I kept a private 4.8 for years updated with driver and security patches from 4.9 et seq. once 4.8 support was discontinued. Just do the source checkout via CVS and create your own CVS branch. It is more work than I'm prepared for now, where the FreeBSD systems I'm supporting is part-time consulting; that's why I decided to jump to a release line. However, it's a reasonable option for someone who's maintaining their own larger groups of systems. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From pschmehl_lists at tx.rr.com Sun Jun 8 18:58:55 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Sun Jun 8 18:59:00 2008 Subject: console access In-Reply-To: <484BAC1C.8080300@modulus.org> References: <3cc535c80806080217m413995dej4037fd2aac22ef4b@mail.gmail.com> <484BAC1C.8080300@modulus.org> Message-ID: --On June 8, 2008 7:53:32 PM +1000 Andrew Snow wrote: > Andy Kosela wrote: >> Then you can even >> remotely mount iso images from your laptop at home directly on the >> server (very handy sometimes). > > Incidentally, when I tried to use a Supermicro IPMI card for networked > remote media, FreeBSD boot loader crashed the machine (video went > haywire and it didnt boot). > > The same thing happened when trying to use a USB CDROM drive, so I > suspect USB boot support is at fault somehow. > Interesting. I have a umass USB drive that causes kernel panics during boot. The rest of the time it works fine. So, I unplug the USB cable to reboot, then plug it back in and mount the drive after I login. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer. From gaijin.k at gmail.com Sun Jun 8 19:04:42 2008 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Sun Jun 8 19:04:48 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: <200806040745.19637.josh@tcbug.org> References: <18501.12329.638264.761303@cs.wpi.edu> <1212506007.48455f97a3788@webmail.vt.edu> <20080604122513.GA24093@eos.sc1.parodius.com> <200806040745.19637.josh@tcbug.org> Message-ID: <1212951813.1139.0.camel@RabbitsDen> On Wed, 2008-06-04 at 07:45 -0500, Josh Paetzel wrote: > On Wednesday 04 June 2008 07:25:13 am Jeremy Chadwick wrote: > > On Tue, Jun 03, 2008 at 11:13:27AM -0400, nlaroche@vt.edu wrote: > > > Quoting nlaroche@vt.edu: > > > > Quoting Jeremy Chadwick : > > > > > Based on my experiences with my workplace-provided T60p, it's safe to > > > > > say I'll never recommend a Lenovo product. The temperatures of these > > > > > laptops are absolutely insane, supported by an incredibly loud fan. > > > > > I'm not interested in a product that can have a GPU reaching > > > > > temperatures of almost 70C **while idling**. > > > > > > > > I purchased a T60p about two months ago and I haven't had any of these > > > > happen (yet?) running Ubuntu 7.10. The machine only gets slightly warm > > > > to the touch after a few hours idling. > > > > > > > > Does your fan run all the time that loud? I'm wondering if there were > > > > changes made at the factory to fix this type of problem if it was wide > > > > spread. > > > > > > > > Regards, > > > > Nick LaRoche > > > > > > That was a T61p not a T60p > > > > It really doesn't matter in this case; T60p, T60p (widescreen), T61p, > > X60p, etc... They all behave the same way when it comes to > > temperatures: incredibly high, sometimes to the point of the system > > shutting off (for some). > > My T60p is really unusable for anything cpu intensive under FreeBSD. Even > with the ibm acpi addons loaded and the fan set to it's highest setting it > only turns at 3700rpm, which isn't enough to keep it from shutting down due > to heat. (eg over 100C) > > I'm interested in whatever cooling solutions people have... > ?You can read through this thread: http://www.freebsd.org/cgi/getmsg.cgi?fetch=141019+0 +/usr/local/www/db/text/2008/freebsd-acpi/20080217.freebsd-acpi which mentions at least two ways to approach it -- the right one is from the referenced message forward. HTH, -- Alexandre "Sunny" Kovalenko (????????? ?????????) From pschmehl_lists at tx.rr.com Sun Jun 8 19:11:39 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Sun Jun 8 19:11:44 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com> References: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com> Message-ID: <4C198A92A6055152F92E8C36@Macintosh.local> --On June 8, 2008 1:49:35 PM +0200 Andy Kosela wrote: > > FreeBSD has always been known for its legendary stability and mature > code base which is why many commercial companies depend on it every > day. "The anomaly" as someone said of long term support for 4.x releases > only helped to see FreeBSD as more stable and viable solution than Linux > by many businesses. Mission critical systems needs long term support > (read: at least backporting security patches) and stable systems that > can run for years without interruption. When it comes to stability vs > development maybe there is time to rethink FreeBSD overall strategy and > goals. Major companies using FreeBSD in their infrastructure like Yahoo! > or Juniper Networks would definetly benefit from such moves focused on > long term support of stable releases. I honestly think it is in their > interest to support, even financially Interesting thoughts. Maybe the time is ripe for a RedHat-like support company for FreeBSD. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer. From pschmehl_lists at tx.rr.com Sun Jun 8 19:25:31 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Sun Jun 8 19:25:36 2008 Subject: 6.2; 6.3; EOL; combustible discussions In-Reply-To: <20080608164928.L16871@fledge.watson.org> References: <8cb6106e0806071938x6a524ba4o969fbc4f0c85206@mail.gmail.com> <20080608164928.L16871@fledge.watson.org> Message-ID: <5A8D6D5A88275154227302D9@Macintosh.local> --On June 8, 2008 4:52:36 PM +0100 Robert Watson wrote: > > Just to be clear here, Adrian's claim that if someone else provided > patches for 6.2, they would be committed, is incorrect. The cost of > committing the patch is almost zero -- the cost of QA'ing the patch, > doing freebsd-update rebuilds, preparing security or errata notices, > etc, is extremely real, and the reason that we carefully limit the > number of releases we support at once. In fact, I'd argue that we have > been supporting too many releases at once, as I think our latency for > shipping errata notices and advisories is too high. By reducing the > number of releases we support, we improve the speed and attention we can > give each notice/advisory, which is an important consideration. > What would be the most beneficial boost to FreeBSD? Would it be cash? Additional developers? Does FreeBSD have anyone who works fulltime (IOW, is paid)? Would more fulltime workers alleviate the issues you've articulated? Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer. From pschmehl_lists at tx.rr.com Sun Jun 8 19:29:56 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Sun Jun 8 19:30:00 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080608154920.GA8266@lpthe.jussieu.fr> References: <20080608154920.GA8266@lpthe.jussieu.fr> Message-ID: --On June 8, 2008 5:49:20 PM +0200 Michel Talon wrote: > > I think it is very unreasonable for end users to ask maintaining, e.g. > 6.2 ad vitam eternam. The real stable branch is now 7.* and diverting > effort to polish the 6.* is a waste of time. People wanting a very > stable system should simply use something else, like Debian stable, > official RedHat, etc. whose aim is precisely to offer the maximum > stability, with only security and bug fixes, and for extended periods of > time. The price you pay is obsoleted and "unsexy" systems, which is > probably OK for the intended use. On the other hand i have no business > running such a system. Please do understand that for some of us, these are not choices. I wiped a FreeBSD machine and bought and installed RedHat because a vendor's software would only run on RedHat. The experience was a painful one. RedHat's updates are a pure PITA. The box now runs FreeBSD again, and I doubt I will ever experiment with something else again. If I can't have FreeBSD, I won't run a server. I don't think I'm alone. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer. From cliftonr at lava.net Sun Jun 8 19:49:03 2008 From: cliftonr at lava.net (Clifton Royston) Date: Sun Jun 8 19:49:19 2008 Subject: 6.2; 6.3; EOL; combustible discussions In-Reply-To: References: Message-ID: <20080608194859.GC3049@lava.net> On Sun, Jun 08, 2008 at 10:17:20AM +0800, Adrian Chadd wrote: > Ok everyone, I think thats enough about this for now. > > I think the developers and users have made their points clear, and > they're no going to agree any more (but they may agree less) over > time. Well, *please* don't assume all users agree with Jo. Some of us actually read the EOL date on 6.2, assumed it meant what it said, and made an informed decision to use 6.2 as the best candidate available at that date, even knowing we'd be forced to upgrade sooner rather than later. If as an admin/user I could give a message to the developers, it would be a very different one: I would like to one day see a -STABLE line, perhaps 8.x, perhaps later, which would by *design* be strong enough and incorporate enough flexibility in its core design that it could be continued for as many as 5 years of minor releases (rather than by *default* as 4.x was due to the difficulty of the SMP model transition and the 5.x stability problems.) If I knew that were an eventual development goal, I'd be even happier with the FreeBSD development team. I have no damn idea how to achieve that goal, and as a software developer I know it's ridiculously, insanely difficult to design to a goal like that, but I do think that continuation is one of the main factors behind the nostalgia for the 4.x line. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From josh at tcbug.org Sun Jun 8 20:43:17 2008 From: josh at tcbug.org (Josh Paetzel) Date: Sun Jun 8 20:43:22 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: <1212951813.1139.0.camel@RabbitsDen> References: <18501.12329.638264.761303@cs.wpi.edu> <200806040745.19637.josh@tcbug.org> <1212951813.1139.0.camel@RabbitsDen> Message-ID: <200806081513.41554.josh@tcbug.org> On Sunday 08 June 2008 02:03:33 pm Alexandre "Sunny" Kovalenko wrote: > On Wed, 2008-06-04 at 07:45 -0500, Josh Paetzel wrote: > > On Wednesday 04 June 2008 07:25:13 am Jeremy Chadwick wrote: > > > On Tue, Jun 03, 2008 at 11:13:27AM -0400, nlaroche@vt.edu wrote: > > > > Quoting nlaroche@vt.edu: > > > > > Quoting Jeremy Chadwick : > > > > > > Based on my experiences with my workplace-provided T60p, it's > > > > > > safe to say I'll never recommend a Lenovo product. The > > > > > > temperatures of these laptops are absolutely insane, supported by > > > > > > an incredibly loud fan. I'm not interested in a product that can > > > > > > have a GPU reaching temperatures of almost 70C **while idling**. > > > > > > > > > > I purchased a T60p about two months ago and I haven't had any of > > > > > these happen (yet?) running Ubuntu 7.10. The machine only gets > > > > > slightly warm to the touch after a few hours idling. > > > > > > > > > > Does your fan run all the time that loud? I'm wondering if there > > > > > were changes made at the factory to fix this type of problem if it > > > > > was wide spread. > > > > > > > > > > Regards, > > > > > Nick LaRoche > > > > > > > > That was a T61p not a T60p > > > > > > It really doesn't matter in this case; T60p, T60p (widescreen), T61p, > > > X60p, etc... They all behave the same way when it comes to > > > temperatures: incredibly high, sometimes to the point of the system > > > shutting off (for some). > > > > My T60p is really unusable for anything cpu intensive under FreeBSD. > > Even with the ibm acpi addons loaded and the fan set to it's highest > > setting it only turns at 3700rpm, which isn't enough to keep it from > > shutting down due to heat. (eg over 100C) > > > > I'm interested in whatever cooling solutions people have... > > ?You can read through this thread: > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=141019+0 > +/usr/local/www/db/text/2008/freebsd-acpi/20080217.freebsd-acpi > > which mentions at least two ways to approach it -- the right one is from > the referenced message forward. > > HTH, So in doing some more research I finally got together the nerve to disassemble my laptop. After cleaning a massive amount of thermal paste off the cpu and heatsink it's operating around 60C after multiple make -j4 buildworlds, where it used to shut down due to going over 100C. It seems I'm not the first person to discover this was the root cause of their heat and noise problems with their Lenovo T60/61 laptop. I've also been able to turn over control of the fan back to the BIOS as opposed to running it full out all the time. -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080608/d2d8503c/attachment.pgp From peterjeremy at optushome.com.au Sun Jun 8 20:55:12 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sun Jun 8 20:55:17 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080608154920.GA8266@lpthe.jussieu.fr> References: <20080608154920.GA8266@lpthe.jussieu.fr> Message-ID: <20080608205506.GI67629@server.vk2pj.dyndns.org> On 2008-Jun-08 17:49:20 +0200, Michel Talon wrote: >and it is now working perfectly well without any trouble. The only >"gotcha" is the slowness of X problem when compiling, but i live with that. Have you tried SCHED_ULE? In my experience, it does a better job of scdeduling than SCHED_4BSD, even on UP machines (YMMV). >which are perhaps susceptible of destabilising it. Personnally i have >seen the same occurring with 6.0, 5.0 and 4.*, for me the last releases >of the 4.* were very poor on my laptop while the early 4.* releases were >perfectly OK. The difficulty with the later 4.x releases was that there were major differences between the 4.x and later kernels and this made it increasingly difficult to backport bugfixes. This is less of an issue with now 4.x is out of the way. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080608/6d80a443/attachment.pgp From msaad at datapipe.com Sun Jun 8 21:26:20 2008 From: msaad at datapipe.com (Mark Saad) Date: Sun Jun 8 21:26:24 2008 Subject: Current status of support for high end SAN hardware In-Reply-To: <3cc535c80806071158h44ec9be1pbe72ca6711016bde@mail.gmail.com> References: <3cc535c80806071158h44ec9be1pbe72ca6711016bde@mail.gmail.com> Message-ID: <484C4E6D.7060306@datapipe.com> Andy I am currently using HP MSA1500cs SAN setups on FreeBSD 7 and 6.3 using qlogic cards in HP DL380G4 and G5 servers. I am not yet using multipath fiber channel which is supported in 7 and I want to test this out soon. As for Redhat ES 4 and 5 I am also using the same hardware setup , I have to say that RedHat ES4 works better for me the Enterprise 5 . ES5 has some odd ball networking issues, when you upgrade from say update 0 -> 1 or 1 -> 2. For some reason Redhat decided that it needed to remove your configs for eth0 as part of the upgrade. I would say to look at using 64Bit FreeBSD 7-RELEASE and ZFS as the filesystem on the SAN. ZFS is hands down better then EXT3+LVM . Andy Kosela wrote: > Hi all, > What is the current status of support for high end SAN hardware in FreeBSD? > I'm especially interested in support for HP EVA/XP disk arrays, Qlogic > HBAs, multipathing. > How FreeBSD compares in this environment to RHEL 5? > > -- > Andy Kosela > ora et labora > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Mark Saad Managed UNIX Support DataPipe Managed Global IT Services () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/emaildisclaimer.aspx for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. From rwatson at FreeBSD.org Sun Jun 8 22:13:37 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Jun 8 22:13:43 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com> References: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com> Message-ID: <20080608230037.F84920@fledge.watson.org> On Sun, 8 Jun 2008, Andy Kosela wrote: >> Define the terms "stable" and "unstable", how you measure said "stability" >> and "instability", and what you are comparing them against. > > This whole discussion is really interesting as it clearly showcases two > common trends in computing (rapid development vs stability) On the one side > we got people (let's call them developers or computer scientists) who are > more interested in development than stabilization of the existing code base. > It's natural for them to think more about new features, researching new > ideas and implementing them. It resembles an academic project, research > project. ... > On the other hand though, there is a trend which focuses on maximum long > term stabilization of the code base. Usually we see this trend in high end > commercial companies serving the needs of mission critical businesses where > even a minute of downtime can cause loss of thousands of dollars or even > loss of lives of people (imagine stock exchanges, banks, financial & > insurance institutions, army and police facilities, hospitals, nuclear > plants etc.). Those types of businesses/institutions truly needs a maximum > stable operating system. They really do not care about "new features", but > they do care about maximum stability of the existing code, security, and > nonstop business continuity even in the face of natural disasters. I think there are some important truths to your observations, but let me present a contrarian view: I think you are presenting a false dichotomy, unnecessarily pitting developers and users at odds with respect to the goals of the project. There are definitely points of conflict along these lines, but much of the time the reason that people use FreeBSD is precisely because there *is* agreement on these points. There are many FreeBSD developers who work on FreeBSD precisely because their employer uses FreeBSD, and hence directly represent interests of long-term support, stability, etc. And indeed, as you observe, these are the interests of large web hosts, appliance companies, etc, being required to build their products. We have a highly branched development in order to reflect the varying degrees of both investment in and tolerance for different levels of feature development vs. stability. If FreeBSD developers only hung around to do adventurous new feature development, we wouldn't have -STABLE branches, errata/security branches, freebsd-update, and so on. Instead, we have a very large infrastructure and a lot of developer time invested in those areas, and this has been growing over time. For example, we introduced RELENG_X_Y errata/security branches in the 4.x timeframe to better serve communities with a low tolerance for feature change. Prior to that time, users had to directly manage patches themselves if they wanted to avoid sliding forward on -STABLE. Likewise, in the mid-5.x timeframe, we added Perforce so that developers wanting to work on projects with very high levels of instability could do so without disrupting HEAD as much, which both improved the pace of development and lead to a more stable product by avoiding allowing the HEAD to become extremely unstable. The recent and rather contentious discussion is not taking place because FreeBSD developers feel that, philosophically, longer support timelines for releases are undesirable. Rather, the argument being made is that, given the underlying assumption of finite resources already committed to particular ends, we should moderate the degree to which we support old releases so that we can keep producing new ones. Don't think that the same trade-offs and hard choices don't have to be made in the development HEAD: in the past, we've pushed back several major features over time due to concerns about stability or availability of developers, which have been far more contentious. Just a thought... :-) Robert N M Watson Computer Laboratory University of Cambridge From talon at lpthe.jussieu.fr Sun Jun 8 22:18:24 2008 From: talon at lpthe.jussieu.fr (Michel Talon) Date: Sun Jun 8 22:18:29 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080608205506.GI67629@server.vk2pj.dyndns.org> References: <20080608154920.GA8266@lpthe.jussieu.fr> <20080608205506.GI67629@server.vk2pj.dyndns.org> Message-ID: <20080608213401.GA74048@lpthe.jussieu.fr> On Mon, Jun 09, 2008 at 06:55:06AM +1000, Peter Jeremy wrote: > On 2008-Jun-08 17:49:20 +0200, Michel Talon wrote: > >and it is now working perfectly well without any trouble. The only > >"gotcha" is the slowness of X problem when compiling, but i live with that. > > Have you tried SCHED_ULE? In my experience, it does a better job of > scdeduling than SCHED_4BSD, even on UP machines (YMMV). Yes, i run with SCHED_ULE, the machine is less interactive than with 6.2 when compiling, but, as i said, i don't care much about that. What i really don't like is panicking, and with 7.0 my machine is perfectly stable. On the other hand, many tasks run very fast under 7.0, so, overall i am very happy with this version. -- Michel TALON From fjwcash at gmail.com Sun Jun 8 22:27:56 2008 From: fjwcash at gmail.com (Freddie Cash) Date: Sun Jun 8 22:28:01 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com> References: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com> Message-ID: On Sun, Jun 8, 2008 at 4:49 AM, Andy Kosela wrote: > On 6/8/08, Freddie Cash wrote: >>>On 6/7/08, Jo Rhett wrote: >>> The question I raised is simply: given the number of bugs opened and >>> fixed since 6.3-RELEASE shipped, why is 6.3 the only supported >>> version? Why does it make sense for FreeBSD to stop supporting a >>> stable version and force people to choose between two different >>> unstable versions? Is this really the right thing to do? >> >>Define the terms "stable" and "unstable", how you measure said >>"stability" and "instability", and what you are comparing them >>against. > > This whole discussion is really interesting as it clearly showcases two > common trends in computing (rapid development vs stability) Like I said, you have to define what you mean by "stable" and "unstable" before the discussion can continue. "stable" can mean many things to many people. You talk about feature stability. Other may talk about "number of open bugs" as being unstable. Others may talk of API/ABI stability. Other may mean "code that don't crash a system". Your view of "stable" meaning "features don't change" is no where near my definition of stable (systems that don't crash, and where I can run binaries from older point releases on newer point releases). The joy of English is that words are overloaded with multiple meanings. And until everyone agrees on which meaning of the words they are using, there's very little point in discussing things ... as everyone will be talking about something different. -- Freddie Cash fjwcash@gmail.com From rwatson at FreeBSD.org Sun Jun 8 22:41:26 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Jun 8 22:41:31 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com> Message-ID: <20080608233332.R84920@fledge.watson.org> On Sun, 8 Jun 2008, Freddie Cash wrote: >>> Define the terms "stable" and "unstable", how you measure said "stability" >>> and "instability", and what you are comparing them against. >> >> This whole discussion is really interesting as it clearly showcases two >> common trends in computing (rapid development vs stability) > > Like I said, you have to define what you mean by "stable" and "unstable" > before the discussion can continue. > > "stable" can mean many things to many people. You talk about feature > stability. Other may talk about "number of open bugs" as being unstable. > Others may talk of API/ABI stability. Other may mean "code that don't crash > a system". > > Your view of "stable" meaning "features don't change" is no where near my > definition of stable (systems that don't crash, and where I can run binaries > from older point releases on newer point releases). I think very few companies that use FreeBSD want it to be like OpenVMS -- otherwise they'd be using OpenVMS. Companies, and users generally, come to FreeBSD not just because they want system stability over time, but also because they expect us to keep producing new (yet mature) features. Sure, they may claim otherwise, but in practice they discover they do want FreeBSD to support the latest rev of an ethernet chipset on a motherboard because the replacement parts they received from their hardware vendor have it, support for larger disk sizes, support for a new POSIX API, being able to boot on systems that require (rather than just support) ACPI, etc. And those changes, perhaps individually incremental, add up to significant changes requiring new releases quite quickly. Again, I wouldn't argue that we couldn't further improve things, but at the same time, we have to recognize that any discussion about "improvement" in a world of finite resources requires a change in the set of trade-offs we accept. This is one reason why such discussions get contention, because one person's easy win from a change becomes another person's loss. Robert N M Watson Computer Laboratory University of Cambridge From oberman at es.net Mon Jun 9 01:10:48 2008 From: oberman at es.net (Kevin Oberman) Date: Mon Jun 9 01:10:50 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: Your message of "Wed, 04 Jun 2008 10:01:47 PDT." <4846CA7B.5070308@FreeBSD.org> Message-ID: <20080609011045.0DDA74500F@ptavv.es.net> > Date: Wed, 04 Jun 2008 10:01:47 -0700 > From: Doug Barton > Sender: owner-freebsd-stable@freebsd.org > > Richard Arends wrote: > > On Wed, Jun 04, 2008 at 07:45:12AM -0500, Josh Paetzel wrote: > > > > Hi, > > > >> I'm interested in whatever cooling solutions people have... > > I didn't follow this thread earlier because I don't have this laptop, > but I wonder if anyone has offered the suggestion to blow out all the > vents and heatsinks with compressed air yet? Even in a fairly "healthy" > environment at home my laptop gets a non-trivial amount of dust buildup. > I blow it clean about once a month and get visible results each time. Amen, Doug. I post this advise fairly routinely. For my ThinkPad, I just remove the keyboard (4 screws) and blow into the exhaust ports. I know that I would be better off with compressed air, but my lungs are hand and available and, the small amount of contamination they input is dwarfed by the massive cloud of dust that blasts out of the air intake in the heat sink assembly. Low tech and only takes about 15 minutes. I do it annually or when the CPU temp hits 90 during a big build (such as buildworld or gnome). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080609/ee95a104/attachment.pgp From alfred at freebsd.org Mon Jun 9 03:24:11 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Mon Jun 9 03:24:14 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <48488D1A.9070105@kutulu.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <48488D1A.9070105@kutulu.org> Message-ID: <20080609032410.GQ48790@elvis.mu.org> Y'know, I've been sort of skimming this thread, and I think a lot of this time could be better spent by just looking at the PRs and giving the original poster tips and encouragement for providing the information needed by FreeBSD to solve his problems. Really... -Alfred * Mike Edenfield [080605 18:04] wrote: > Paul Schmehl wrote: > >I think that's an unfair characterization. He stated that he had > >noted numerous bugs in 6.3 (submitted PRs) that he perceived affected > >him personally and so he chose not to update to 6.3. He then asked if > >6.2 couldn't be extended farther. That seems like a reasonable > >question to ask. A simple, professional answer would have settled the > >matter quickly. > > Part of the problem is that a few of us (including myself) *have* looked > for the PRs he referenced and can't find them. There are only three > critical PR's opened on the hardware devices he mentioned that are filed > specifically against version 6.3: one each for bge, gmirror, and 3ware. > Of those, one of them appears to be sporadic, one of them appears to be > specific to a particular obscure BIOS, and one of them involved a > specific dual-card setup on a specific type of motherboard. And none of > those *specifically* say that they cannot be reproduced on 6.2 -- one of > them is actually filed against version 5 through 7. Since we also know > very little about the specific hardware setup of the OP, it's impossible > to determine if these are, in fact, the PRs he's looking at, or if he's > actually looking at other less-critical PRs that may need to be bumped > up to critical, or if they're misfiled, or who knows what. > > In short, the problem reports that the OP is looking at are not > immediately obvious to someone who doesn't already know what they are, > and he's not doing himself any favors by insisting that everyone else > "already knows" about these problems. If he's seen these bug reports, > presumably he knows what their PR #'s are, or at the very least the > description of the bugs, and it would be many many times faster for him > to just say so than continue to insist that other people read his mind. > > --Mike > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- - Alfred Perlstein From alfred at freebsd.org Mon Jun 9 03:32:51 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Mon Jun 9 03:32:54 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <52E265BB-BBB1-439D-B375-D6C6AA04697C@netconsonance.com> References: <48472DB6.5030909@samsco.org> <6010676B-91B0-4AF8-ACF8-039A59B29331@netconsonance.com> <200806050248.59229.max@love2party.net> <20080605083907.GD1028@server.vk2pj.dyndns.org> <902E9703E6E50776A17E9F92@utd65257.utdallas.edu> <20080605220244.GP1028@server.vk2pj.dyndns.org> <34E9F0D46D7B9F45EDA38F4C@utd65257.utdallas.edu> <48488D1A.9070105@kutulu.org> <52E265BB-BBB1-439D-B375-D6C6AA04697C@netconsonance.com> Message-ID: <20080609033250.GR48790@elvis.mu.org> * Jo Rhett [080607 14:37] wrote: > > Mike, could you do me a favor and provide me with a set of words that > will make what I am trying to say on this topic clear? I keep saying > the same thing over and over again and nobody is hearing me, so could > you perhaps help me translate this? > > These are the raw issues without any friendly wording. > > 1. Bugs in 6.3 that are patched aren't available in any other -RELEASE. Jo, sorry to jump in here, but what are these bugs that you are concerned about? Can you give specific PR#s? Can you confirm that these bugs are still issues? > 2. Bugs in 6.3 outstanding that don't affect 6.2 This is a bit of a stretch honestly, there may be bugs in 6.3 that are also in 6.2, however they have only been reported in 6.3 because of time. > 3. Overall amount of bugs. See previous. > 4. Difference in code base between 6.3 and 6-STABLE is > than 6.2 and > 6.3 Well, that's good! (or should be, see below.) > These combine to produce a release which will never be "stable" for > production needs. Let's not go there. Let's work with what we have. In theory people should only be pushing bugfixes and drivers in the -stable series, however sometimes changes are made for performance too when the risk is "low". Larger changesets in the later versions of -stable for a particular major release is to be expected as the number of users migrating from the previous major release (5.x) start to come over. > Obviously the FreeBSD team(s) involved have to make choices. Perhaps > there's nothing we can do to improve it other than work on the > specific bugs. But does it hurt to ask why 6.2 was dropped so fast? > What the real cost of supporting 6.2 until 6.4 ships is? I can understand your upset, I have been there, I found that later versions of 5.x had regressions for me that forced me to decide to either downgrade to 5.3 or go to 6.x. You may need to stick to 6.2 and keep a local set of patches (this is much easier now with svn and svk). OR you can try 7.x. The fact of the matter is that as an individual you have many options: 1) work to figure out why 6.3 (or -stable) isn't working. 2) stick with 6.2 with your own mods. 3) try 7-stable. Trust me, I know you've been pretty frustrated by this thread, but from my experience you're not going to get what you want, but you may get what you need (if you take my advice). best of luck, -Alfred From smithi at nimnet.asn.au Mon Jun 9 03:48:45 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Mon Jun 9 03:48:49 2008 Subject: Lenovo Thinkpad t61p and FreeBSD? In-Reply-To: <1212951813.1139.0.camel@RabbitsDen> Message-ID: On Sun, 8 Jun 2008, Alexandre "Sunny" Kovalenko wrote: > On Wed, 2008-06-04 at 07:45 -0500, Josh Paetzel wrote: > > On Wednesday 04 June 2008 07:25:13 am Jeremy Chadwick wrote: > > > On Tue, Jun 03, 2008 at 11:13:27AM -0400, nlaroche@vt.edu wrote: > > > > Quoting nlaroche@vt.edu: > > > > > Quoting Jeremy Chadwick : > > > > > > Based on my experiences with my workplace-provided T60p, it's safe to > > > > > > say I'll never recommend a Lenovo product. The temperatures of these > > > > > > laptops are absolutely insane, supported by an incredibly loud fan. > > > > > > I'm not interested in a product that can have a GPU reaching > > > > > > temperatures of almost 70C **while idling**. > > > > > > > > > > I purchased a T60p about two months ago and I haven't had any of these > > > > > happen (yet?) running Ubuntu 7.10. The machine only gets slightly warm > > > > > to the touch after a few hours idling. > > > > > > > > > > Does your fan run all the time that loud? I'm wondering if there were > > > > > changes made at the factory to fix this type of problem if it was wide > > > > > spread. > > > > > > > > > > Regards, > > > > > Nick LaRoche > > > > > > > > That was a T61p not a T60p > > > > > > It really doesn't matter in this case; T60p, T60p (widescreen), T61p, > > > X60p, etc... They all behave the same way when it comes to > > > temperatures: incredibly high, sometimes to the point of the system > > > shutting off (for some). > > > > My T60p is really unusable for anything cpu intensive under FreeBSD. Even > > with the ibm acpi addons loaded and the fan set to it's highest setting it > > only turns at 3700rpm, which isn't enough to keep it from shutting down due > > to heat. (eg over 100C) > > > > I'm interested in whatever cooling solutions people have... > > > ???You can read through this thread: > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=141019+0 > +/usr/local/www/db/text/2008/freebsd-acpi/20080217.freebsd-acpi > > which mentions at least two ways to approach it -- the right one is from > the referenced message forward. Hi Alex, glad to see you're still keeping track of these issues .. In there ume@ says that his patch was committed .. do you know if it was MFC'd back to 7.x? 6.x? Perhaps the docs haven't caught up yet? There are only going to be a lot more of these around .. cheers, Ian From oberman at es.net Mon Jun 9 05:13:47 2008 From: oberman at es.net (Kevin Oberman) Date: Mon Jun 9 05:13:51 2008 Subject: cpufreq broken on core2duo In-Reply-To: Your message of "Sat, 07 Jun 2008 09:48:12 PDT." <20080607164812.GA11072@eos.sc1.parodius.com> Message-ID: <20080609051343.CFD4D45010@ptavv.es.net> > Date: Sat, 7 Jun 2008 09:48:12 -0700 > From: Jeremy Chadwick > Sender: owner-freebsd-stable@freebsd.org > > On Sat, Jun 07, 2008 at 05:51:38PM +0300, Evren Yurtesen wrote: > > By the way, there is another thing I am wondering about. If I enable HTT > > and Intel Enhanced SpeedStep in bios on a 3.00GHZ p4 CPU I see: > > > > cpu0: on acpi0 > > acpi_perf0: on cpu0 > > p4tcc0: on cpu0 > > cpu1: on acpi0 > > est1: on cpu1 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr f2700000f27 > > device_attach: est1 attach returned 6 > > p4tcc1: on cpu1 > > > > dev.cpu.0.freq_levels: 1500/27000 1312/23625 1200/13000 1050/11375 900/9750 > > 750/8125 600/6500 450/4875 300/3250 150/1625 > > dev.acpi_perf.0.freq_settings: 1500/27000 1200/13000 > > dev.cpufreq.0.%driver: cpufreq > > dev.cpufreq.0.%parent: cpu0 > > dev.cpufreq.1.%driver: cpufreq > > dev.cpufreq.1.%parent: cpu1 > > dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 > > 2500/-1 1250/-1 > > dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 > > 2500/-1 1250/-1 > > > > and it does not allow me to set the freq. of the cpu. > > How are you setting the frequency? Are you using powerd? You do not > have to enable SpeedStep in your BIOS to achieve throttling CPU clock > speed. In fact, I would highly recommend leaving EIST/SpeedStep in the > BIOS *disabled*, and let powerd adjust the clock frequency via ACPI. I must strongly recommend against this. EST is MUCH more efficient on its control of power use than simple throttling. So much so that on my systems that support EST, I remove cpufreq from the kernel. (In all cases, throttling means either simple throttling or throttling by using TCC.) I did quite a bit of testing on power management a year or so ago and found that throttling was of value only for controlling CPU temperature. For real power management, EST works far better as it adjust frequency (actual clock rate) and CPU voltage while throttling just stops and starts the clock without changing its actual frequency. (This came as a surprise to me about 5 years ago when I first discovered it.) At idle, throttling does exactly nothing. EST reduces voltage on the CPU and saves power even when idle. At full CPU load, throttling reduces performance and power consumption equally. EST beats it by a slim margin. The big win is at moderate load. Throttling can result is very poor results for aps like video and music which will place a continuous load on the system, but only 20-60% (in the case of my test system). It tended to make the system seem sluggish. EST does a much better job in this case as it lowers CP voltage and clock rate to maximize performance while minimizing power. If your only concern is keeping the system cool, throttling will do the job, but if you want efficient power utilization, use EST if possible. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080609/35e82c47/attachment.pgp From koitsu at FreeBSD.org Mon Jun 9 05:30:35 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Jun 9 05:30:41 2008 Subject: cpufreq broken on core2duo In-Reply-To: <20080609051343.CFD4D45010@ptavv.es.net> References: <20080607164812.GA11072@eos.sc1.parodius.com> <20080609051343.CFD4D45010@ptavv.es.net> Message-ID: <20080609053035.GA6859@eos.sc1.parodius.com> On Sun, Jun 08, 2008 at 10:13:43PM -0700, Kevin Oberman wrote: > > Date: Sat, 7 Jun 2008 09:48:12 -0700 > > From: Jeremy Chadwick > > Sender: owner-freebsd-stable@freebsd.org > > > > On Sat, Jun 07, 2008 at 05:51:38PM +0300, Evren Yurtesen wrote: > > > By the way, there is another thing I am wondering about. If I enable HTT > > > and Intel Enhanced SpeedStep in bios on a 3.00GHZ p4 CPU I see: > > > > > > cpu0: on acpi0 > > > acpi_perf0: on cpu0 > > > p4tcc0: on cpu0 > > > cpu1: on acpi0 > > > est1: on cpu1 > > > est: CPU supports Enhanced Speedstep, but is not recognized. > > > est: cpu_vendor GenuineIntel, msr f2700000f27 > > > device_attach: est1 attach returned 6 > > > p4tcc1: on cpu1 > > > > > > dev.cpu.0.freq_levels: 1500/27000 1312/23625 1200/13000 1050/11375 900/9750 > > > 750/8125 600/6500 450/4875 300/3250 150/1625 > > > dev.acpi_perf.0.freq_settings: 1500/27000 1200/13000 > > > dev.cpufreq.0.%driver: cpufreq > > > dev.cpufreq.0.%parent: cpu0 > > > dev.cpufreq.1.%driver: cpufreq > > > dev.cpufreq.1.%parent: cpu1 > > > dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 > > > 2500/-1 1250/-1 > > > dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 > > > 2500/-1 1250/-1 > > > > > > and it does not allow me to set the freq. of the cpu. > > > > How are you setting the frequency? Are you using powerd? You do not > > have to enable SpeedStep in your BIOS to achieve throttling CPU clock > > speed. In fact, I would highly recommend leaving EIST/SpeedStep in the > > BIOS *disabled*, and let powerd adjust the clock frequency via ACPI. > > I must strongly recommend against this. EST is MUCH more efficient on > its control of power use than simple throttling. So much so that on my > systems that support EST, I remove cpufreq from the kernel. (In all > cases, throttling means either simple throttling or throttling by using > TCC.) The reality of the situation is that users cannot use EIST reliably on FreeBSD. I cannot imagine removing cpufreq would solve the "runtime went backwards" issue. The EIST problem needs to be fixed. If the folks who work on it do not have present-day hardware (C2Ds, etc.), I will be more than happy to purchase them whatever they need. > I did quite a bit of testing on power management a year or so ago and > found that throttling was of value only for controlling CPU temperature. > For real power management, EST works far better as it adjust frequency > (actual clock rate) and CPU voltage while throttling just stops and > starts the clock without changing its actual frequency. (This came as a > surprise to me about 5 years ago when I first discovered it.) As far as I know, the ACPI frequency toggling does in fact adjust the CPU clock rate -- because the values in dev.cpu.0.freq_levels are defined by the ACPI configuration on the machine. I'd confirm this, but looking at the kernel code doesn't help -- I cannot find the definition of the CPUFREQ_LEVELS function or macro. > At idle, throttling does exactly nothing. EST reduces voltage on the > CPU and saves power even when idle. At full CPU load, throttling reduces > performance and power consumption equally. EST beats it by a slim > margin. I thought the power-saving modes of the CPU (C1E/C2E/C3E/C4E) could be used *without* enabling EIST. I don't think FreeBSD has kernel or userland support utilities to enable/disable CPU-level features. Something like RMClock for Windows would be quite useful. (If you have the opportunity to run it, do so; you'll see what I mean, re: all the features being toggleable individually). > The big win is at moderate load. Throttling can result is very poor > results for aps like video and music which will place a continuous load > on the system, but only 20-60% (in the case of my test system). It > tended to make the system seem sluggish. EST does a much better job in > this case as it lowers CP voltage and clock rate to maximize performance > while minimizing power. > > If your only concern is keeping the system cool, throttling will do the > job, but if you want efficient power utilization, use EST if possible. In the case est does not attach (e.g. no EIST support enabled in FreeBSD), the throttling method resorts to simply suspending the system, then yes I completely agree -- EIST is significantly better than that. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From joe at zircon.seattle.wa.us Mon Jun 9 07:46:31 2008 From: joe at zircon.seattle.wa.us (Joe Kelsey) Date: Mon Jun 9 07:46:36 2008 Subject: 6.3-RELEASE versus 5.2-RELEASE Message-ID: <484CD995.3040002@zircon.seattle.wa.us> I think I have finally decoded Jo Rhett's issue. It is very hard to decipher because the poster refuses to exactly identify their problem. The entire problem comes down to the definition of -RELEASE. Jo apparantly feels that they can ONLY run -RELEASE branded code at their workplace. That means that they cannot run any form of -STABLE. Therefore, they can only ever run 6.3-RELEASE and then only if no bugs were fixed after the official branding of 6.3-RELEASE. I cannot speak at all about the branding of 6.3-RELEASE. I run 7.0-STABLE here. What Jo seems to thik is that a certain sequence of events occurred during the 6.3-RELEASE branding. 6.3-RELEASE was marked in the tree. Sometime after this marking event occurred, bugs were ientified and subsequently fixed in the -STABLE branch. These bugs have been identified by Jo as SHOWSTOPPER bugs which will prevent him from ever using 6.3-RELEASE, since by their definition, they can only ever use the exact thing identified by the cvs tag of 6.3-RELEASE. Therefore, by Jo's definition, they can never run 6.3-anything at their shop and are forced to wait for 6.4-RELEASE, whenever that happens. Therefore, they must take on the onerous duty of examining all security fixes target for 6.3 and redo them for 6.2. Basically, they do not wish to do this and protest the EoL status given to 6.2 because they are physically prevented from using 6.3. They refuse to even try to identify whether or not 6.3-RELEASE actually has any bugs that affect them, they just assume that the presence of bugs fixed AFTER the tagging of 6.3-RELEASE in cvs certifies their inability to use the actual 6.3-RELEASE code, since they can apparantly only run binary releases direct from FreeBSD and cannot "roll their own" for some unknown reason. They are also, apparantly, prohibited from testing any code locally due to some unknowable reason. Can anyone verify that some number of bugs related to either a) gmirror, b) bge and/or c)twe were fixed after the release of 6.3? That is as far as I can tell the reason that Jo objets to EoL of 6.2, the fact that 6.3 is unusable due to these late-fixed bugs. /Joe From andrew at modulus.org Mon Jun 9 07:51:00 2008 From: andrew at modulus.org (Andrew Snow) Date: Mon Jun 9 07:51:06 2008 Subject: 6.3-RELEASE versus 5.2-RELEASE In-Reply-To: <484CD995.3040002@zircon.seattle.wa.us> References: <484CD995.3040002@zircon.seattle.wa.us> Message-ID: <484CE0C6.2000308@modulus.org> Joe Kelsey wrote: > The entire problem comes down to the definition of -RELEASE. Jo > apparantly feels that they can ONLY run -RELEASE branded code at their > workplace. That means that they cannot run any form of -STABLE. Interesting, and unfortunate. Empirically, I always felt that the -STABLE branch shortly after each -RELEASE is the most stable. I suspect the reason is large numbers of people install or upgrade to a -RELEASE, discover and report a number of bugs which subsequently get fixed. From john.marshall at riverwillow.com.au Mon Jun 9 08:58:12 2008 From: john.marshall at riverwillow.com.au (John Marshall) Date: Mon Jun 9 08:58:16 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy6.3 In-Reply-To: References: <484736E0.6090004@samsco.org> Message-ID: <20080609084303.GA1229@ctipc01.mby.riverwillow.net.au> Picking one of the many posts from the OP in this thread... On Wed, 04 Jun 2008, 22:33 -0700, Jo Rhett wrote: > I am suggesting that given that the current bug list for 6.3-RELEASE > is both (a) too large and (b) breaks things that work fine in 6.2 ... > that I think pushing 6.2 (the real stable release) into EoL is a bit > rushed. I sympathize with the development costs of maintaining old > versions. Again, I will help in any way I can. It seems to me that the underlying grievance may be lack of faith in the latest RELEASEs; promtping the suggestion that $FAVOURITE_RELEASE support be extended. I believe that the best way to acquire confidence in the FreeBSD RELEASEs is to participate in the release cycles. Those of us who are not developers can make a significant contribution by taking the time to build the BETA and RC builds on our own systems with our own peculiar mix of CPU's, motherboards and peripherals. If we find problems we can feed them back to the team and improve the quality of the release; and then we'll be confident about deploying RELEASE on our systems rather than regarding it with suspicion. > On my return next week I would happily build and provide 6.3-RELEASE > systems for any developer who needs a test environment for reported > bugs that affect hardware I have in my possession. Free boxes, free > bandwidth, power, etc. No problem. Free my time in whatever way I > can help. This is the system which should have been used for building the 6.3 BETAs and RCs. Offering it for others to use for debugging, while a generous gesture and no doubt greatly appreciated, is a bit like shutting the gate after the horse has bolted. This will not achieve a better 6.3-RELEASE. The release has already happened. > But until such time as the current bug list for 6.3 hardware reduces > to somewhere less than 100% likelyhood of experiencing failures after > an upgrade, there's just no way I can take our production environment > forward. Going "bravely forward" to guaranteed failure isn't a great > way to enjoy your job :-( Which means I'll be doing our security > patches by hand. Because it may be time intensive, but it's less > likely to cause a production failure. 6.3-RELEASE will never improve. Since the OP emphasised deploying only RELEASEs, I suggest that his effort should go into making sure that 7.1 meets his requirements BEFORE it is released. For the record, I am running 6.3-RELEASE on hosted systems interstate and internationally and have had no problems at all: locally I am running a mixture of 6.3-RELEASE and 7.0-RELEASE with no problem. I hope this discussion provides a catalyst for more of us to become more involved in pre-RELEASE testing to ensure an even higher standard of RELEASEs from the FreeBSD project. -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080609/6f719d29/attachment.pgp From ivoras at freebsd.org Mon Jun 9 09:03:36 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Jun 9 09:03:39 2008 Subject: TMPFS: File System is Full In-Reply-To: <47713ee10806062148l4a4c4550hcd8c70a422343c2a@mail.gmail.com> References: <47713ee10806061443v3e44576am2facb75df031f47e@mail.gmail.com> <47713ee10806062148l4a4c4550hcd8c70a422343c2a@mail.gmail.com> Message-ID: Lin Jui-Nan Eric wrote: > I think there should be a "lower bound" size limit. Does TMPFS use > kernel-space memory? Yes, tmpfs does use kmem and competes with ZFS. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080609/5d7ed020/signature.pgp From ruben at verweg.com Mon Jun 9 09:44:55 2008 From: ruben at verweg.com (Ruben van Staveren) Date: Mon Jun 9 09:45:01 2008 Subject: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <200806072254.43405.max@love2party.net> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <200806072254.43405.max@love2party.net> Message-ID: <07D0EBB8-77B3-4593-85C5-A38E94DD0DDD@verweg.com> On 7 Jun 2008, at 22:54, Max Laier wrote: > Here is a cluebat for you: Here is another one: Currently 176 messages, posted by 51 unique participants (25 % by Jo himself) Given the fact that at least these 51 persons are actually reading all the mails, and taking some 5 minutes for it you'll see that this thread already consumed a whole man month worth of time. The amount of passive readers might stretch up to a good portion of the subscriber base. I probably do not have to mention this time was better spent on other things. So far I have seen nothing else than the community at large addressing FUD of one poster, which was a genuine remark when it started, but became irrational as there was no room for compromise. I started with RELENG_7 when it was 4 days of age, and impressed by the stability from the start. Yet still we going to get our production servers up to 6.3 and go for 7.1 instead as we make use (by design) of MyISAM tables in MySQL, though I do believe I saw a fix in cvs for the issue mentioned here: http://jeffr-tech.livejournal.com/20425.html Overall, the days of RELENG_4 and RELENG_5 are over and the 15 years or so of cvs history contributes to the quality of development inside the FreeBSD project, which I was using since 2.2.4-stable. Thanks! - Ruben From stefan.lambrev at moneybookers.com Mon Jun 9 12:32:53 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Mon Jun 9 12:32:56 2008 Subject: Current status of support for high end SAN hardware In-Reply-To: <484AE6E1.2050504@skytek.it> References: <3cc535c80806071158h44ec9be1pbe72ca6711016bde@mail.gmail.com> <484AE6E1.2050504@skytek.it> Message-ID: <484D22ED.5060500@moneybookers.com> Daniel Ponticello wrote: > On FreeBSD7, i'm succesfully using Qlogic 4gb fibre channel HBAs (ISP > driver) > attached to Fibre Brocade Switch and IBM DS4700 (14 disks array) using > 4 way multipath > with gmultipath. So far the support in gmultipath is active/passive only? I think in RH5 you can have active/active. Am I right? > > Regards, > > Daniel > > Andy Kosela ha scritto: >> Hi all, >> What is the current status of support for high end SAN hardware in >> FreeBSD? >> I'm especially interested in support for HP EVA/XP disk arrays, Qlogic >> HBAs, multipathing. >> How FreeBSD compares in this environment to RHEL 5? >> >> > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From tinderbox at freebsd.org Mon Jun 9 12:37:27 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 9 12:37:36 2008 Subject: [releng_7 tinderbox] failure on powerpc/powerpc Message-ID: <20080609123718.C268C1B5078@freebsd-stable.sentex.ca> TB --- 2008-06-09 11:19:40 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-06-09 11:19:40 - starting RELENG_7 tinderbox run for powerpc/powerpc TB --- 2008-06-09 11:19:40 - cleaning the object tree TB --- 2008-06-09 11:19:56 - cvsupping the source tree TB --- 2008-06-09 11:19:56 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile TB --- 2008-06-09 11:20:04 - building world (CFLAGS=-O2 -pipe) TB --- 2008-06-09 11:20:04 - cd /src TB --- 2008-06-09 11:20:04 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 9 11:20:05 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jun 9 12:27:15 UTC 2008 TB --- 2008-06-09 12:27:15 - generating LINT kernel config TB --- 2008-06-09 12:27:15 - cd /src/sys/powerpc/conf TB --- 2008-06-09 12:27:15 - /usr/bin/make -B LINT TB --- 2008-06-09 12:27:15 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-06-09 12:27:15 - cd /src TB --- 2008-06-09 12:27:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 9 12:27:16 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/nfsserver/nfs_srvsubs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/nfsserver/nfs_syscalls.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/nlm/nlm_prot_clnt.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/nlm/nlm_prot_impl.c /src/sys/nlm/nlm_prot_impl.c: In function 'nlm_check_idle': /src/sys/nlm/nlm_prot_impl.c:697: error: 'nlm_global_lock' undeclared (first use in this function) /src/sys/nlm/nlm_prot_impl.c:697: error: (Each undeclared identifier is reported only once /src/sys/nlm/nlm_prot_impl.c:697: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-06-09 12:37:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-06-09 12:37:18 - ERROR: failed to build lint kernel TB --- 2008-06-09 12:37:18 - tinderbox aborted TB --- 3843.69 user 367.57 system 4658.09 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-powerpc-powerpc.full From andy.kosela at gmail.com Mon Jun 9 12:41:25 2008 From: andy.kosela at gmail.com (Andy Kosela) Date: Mon Jun 9 12:41:31 2008 Subject: Current status of support for high end SAN hardware In-Reply-To: <20080609103610.GA36227@riffraff.plig.net> References: <3cc535c80806071158h44ec9be1pbe72ca6711016bde@mail.gmail.com> <484C4E6D.7060306@datapipe.com> <20080609103610.GA36227@riffraff.plig.net> Message-ID: <3cc535c80806090541g15c03c24mf1c47a9b92ff166a@mail.gmail.com> On Mon, Jun 9, 2008 at 12:36 PM, Russell Vincent wrote: > > The FreeBSD support for multipath/SAN is fairly poor. It's fiddly > to get to work and boot times are a little variable (into the > minutes) as it tries to discover the devices. Once it is configured > and booted, it just works as long as things don't go wrong. SAN > outages cause the machine to hang up until the issue is resolved > (in which case it just seems to continue) or it doesn't recover at > all and requires a reboot. Note that I don't spend a significant > amount of time on this, so it may be that I could do things a little > better. I have also not tested the failover stuff very well (I > only upgraded this machine to 7-STABLE fairly recently). Disk > access seems to be restricted to a single path at a time. Problem > solving is very tricky as there is very little information to trace > which path/disk refers to which fabric/storage device/LUN. > Russell, Thank you for your insights. It's good to see you have no problems with isp(4) and Qlogic HBAs. Though I'm concerned about multipathing. We run 6.x-RELEASE releases so it seems we have to upgrade to 7.0-RELEASE to achieve that goal. gmultipath(8) code is fairly new so I suppose it's not that mature yet as in Linux. Unfortunately it is only an active/passive approach with no load balancing (the active path is active until a BIO request is failed with EIO or ENXIO) Good support for high end SAN environment is essential in todays data centers, as most servers are connected to storage using FC based storage area network. I hope things will improve as 7.x-STABLE will be polished over time. Mark, I completely agree with you that ZFS is much better than Ext3+LVM2. Ext3 is still lacking internal snapshoting capability, so it's even inferior to UFS2. As a matter of fact I'm watching Oracle's btrfs development as it seems it will change many things on Linux filesystems scene. Though I still fear ZFS on FreeBSD is not as yet mature to the point of using it in a mission critical 24x7 production environments. But it's definetly something to watch out for. -- Andy Kosela ora et labora From tinderbox at freebsd.org Mon Jun 9 12:51:44 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 9 12:51:55 2008 Subject: [releng_6 tinderbox] failure on i386/i386 Message-ID: <20080609125152.95E8E241A2@freebsd-legacy.sentex.ca> TB --- 2008-06-09 11:40:12 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2008-06-09 11:40:12 - starting RELENG_6 tinderbox run for i386/i386 TB --- 2008-06-09 11:40:12 - cleaning the object tree TB --- 2008-06-09 11:40:43 - cvsupping the source tree TB --- 2008-06-09 11:40:43 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/i386/i386/supfile TB --- 2008-06-09 11:40:52 - building world (CFLAGS=-O2 -pipe) TB --- 2008-06-09 11:40:52 - cd /src TB --- 2008-06-09 11:40:52 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2008-06-09 12:34:00 - generating LINT kernel config TB --- 2008-06-09 12:34:00 - cd /src/sys/i386/conf TB --- 2008-06-09 12:34:00 - /usr/bin/make -B LINT TB --- 2008-06-09 12:34:01 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-06-09 12:34:01 - cd /src TB --- 2008-06-09 12:34:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 9 12:34:01 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] objcopy --strip-debug nfsclient.ko ===> nfslockd (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -I/obj/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /src/sys/modules/nfslockd/../../nlm/nlm_prot_clnt.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -I/obj/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c /src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c: In function `nlm_check_idle': /src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c:697: error: `nlm_global_lock' undeclared (first use in this function) /src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c:697: error: (Each undeclared identifier is reported only once /src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c:697: error: for each function it appears in.) *** Error code 1 Stop in /src/sys/modules/nfslockd. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-06-09 12:51:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-06-09 12:51:52 - ERROR: failed to build lint kernel TB --- 2008-06-09 12:51:52 - tinderbox aborted TB --- 3464.66 user 380.66 system 4299.67 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-i386-i386.full From tinderbox at freebsd.org Mon Jun 9 12:55:50 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 9 12:56:05 2008 Subject: [releng_6 tinderbox] failure on amd64/amd64 Message-ID: <20080609125600.3EFBC241A2@freebsd-legacy.sentex.ca> TB --- 2008-06-09 11:22:52 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2008-06-09 11:22:52 - starting RELENG_6 tinderbox run for amd64/amd64 TB --- 2008-06-09 11:22:52 - cleaning the object tree TB --- 2008-06-09 11:23:29 - cvsupping the source tree TB --- 2008-06-09 11:23:30 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile TB --- 2008-06-09 11:23:36 - building world (CFLAGS=-O2 -pipe) TB --- 2008-06-09 11:23:36 - cd /src TB --- 2008-06-09 11:23:36 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2008-06-09 12:40:20 - generating LINT kernel config TB --- 2008-06-09 12:40:20 - cd /src/sys/amd64/conf TB --- 2008-06-09 12:40:20 - /usr/bin/make -B LINT TB --- 2008-06-09 12:40:20 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-06-09 12:40:20 - cd /src TB --- 2008-06-09 12:40:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 9 12:40:20 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] objcopy --strip-debug nfsclient.ko ===> nfslockd (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /src/sys/modules/nfslockd/../../nlm/nlm_prot_clnt.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c /src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c: In function `nlm_check_idle': /src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c:697: error: `nlm_global_lock' undeclared (first use in this function) /src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c:697: error: (Each undeclared identifier is reported only once /src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c:697: error: for each function it appears in.) *** Error code 1 Stop in /src/sys/modules/nfslockd. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-06-09 12:56:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-06-09 12:56:00 - ERROR: failed to build lint kernel TB --- 2008-06-09 12:56:00 - tinderbox aborted TB --- 4486.69 user 532.27 system 5587.97 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full From tinderbox at freebsd.org Mon Jun 9 13:35:14 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jun 9 13:35:27 2008 Subject: [releng_7 tinderbox] failure on sparc64/sparc64 Message-ID: <20080609133509.85EC91B5078@freebsd-stable.sentex.ca> TB --- 2008-06-09 12:25:44 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-06-09 12:25:44 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2008-06-09 12:25:44 - cleaning the object tree TB --- 2008-06-09 12:26:02 - cvsupping the source tree TB --- 2008-06-09 12:26:02 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2008-06-09 12:26:09 - building world (CFLAGS=-O2 -pipe) TB --- 2008-06-09 12:26:09 - cd /src TB --- 2008-06-09 12:26:09 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 9 12:26:10 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jun 9 13:25:00 UTC 2008 TB --- 2008-06-09 13:25:00 - generating LINT kernel config TB --- 2008-06-09 13:25:00 - cd /src/sys/sparc64/conf TB --- 2008-06-09 13:25:00 - /usr/bin/make -B LINT TB --- 2008-06-09 13:25:00 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-06-09 13:25:00 - cd /src TB --- 2008-06-09 13:25:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 9 13:25:00 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/nfsserver/nfs_srvsubs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/nfsserver/nfs_syscalls.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/nlm/nlm_prot_clnt.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/nlm/nlm_prot_impl.c /src/sys/nlm/nlm_prot_impl.c: In function 'nlm_check_idle': /src/sys/nlm/nlm_prot_impl.c:697: error: 'nlm_global_lock' undeclared (first use in this function) /src/sys/nlm/nlm_prot_impl.c:697: error: (Each undeclared identifier is reported only once /src/sys/nlm/nlm_prot_impl.c:697: error: for each function it appears in.) *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-06-09 13:35:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-06-09 13:35:09 - ERROR: failed to build lint kernel TB --- 2008-06-09 13:35:09 - tinderbox aborted TB --- 3645.91 user 357.34 system 4165.30 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full From daniel at skytek.it Mon Jun 9 13:49:32 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Mon Jun 9 13:49:41 2008 Subject: Current status of support for high end SAN hardware In-Reply-To: <484D22ED.5060500@moneybookers.com> References: <3cc535c80806071158h44ec9be1pbe72ca6711016bde@mail.gmail.com> <484AE6E1.2050504@skytek.it> <484D22ED.5060500@moneybookers.com> Message-ID: <484D34F4.4050902@skytek.it> man gmultipath is your friend ;) MULTIPATH ARCHITECTURE This is an active/passive multiple path architecture with no device knowledge or presumptions other than size matching built in. Therefore the user must exercise some care in selecting providers that do indeed represent multiple paths to the same underlying disk device. The reason for this is that there are several criteria across multiple underlying transport types that can indicate identity, but in all respects such identity can rarely be considered definitive. Regards, Daniel Stefan Lambrev ha scritto: > > > Daniel Ponticello wrote: >> On FreeBSD7, i'm succesfully using Qlogic 4gb fibre channel HBAs (ISP >> driver) >> attached to Fibre Brocade Switch and IBM DS4700 (14 disks array) >> using 4 way multipath >> with gmultipath. > So far the support in gmultipath is active/passive only? I think in > RH5 you can have active/active. > Am I right? >> >> Regards, >> >> Daniel >> >> Andy Kosela ha scritto: >>> Hi all, >>> What is the current status of support for high end SAN hardware in >>> FreeBSD? >>> I'm especially interested in support for HP EVA/XP disk arrays, Qlogic >>> HBAs, multipathing. >>> How FreeBSD compares in this environment to RHEL 5? >>> >>> >> > -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From pschmehl_lists at tx.rr.com Mon Jun 9 16:58:03 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Mon Jun 9 16:58:10 2008 Subject: [nvidia | shared irq] umass disconnects [was: panic dd-ing from a USB "disk" ] In-Reply-To: References: <200805081730.m48HUNjh001532@symbion.zaytman.com> Message-ID: <89AE69A6C6BB0B0E02487A45@utd65257.utdallas.edu> --On Friday, June 06, 2008 19:36:46 +0200 "Arno J. Klaassen" wrote: > > > I can easily produce a similar panic on a dual Opteron 185 with > 3G of RAM and running 7-stable-amd64 on a (cheap) nvidia-based MB. > It runs gmirror on atapci1 and I attach a geli-encrypted > disk via usb. Both share irq 23. > > Under heavy load ("periodic security" is enough ) it panics after > having disconnected umass0 ( kgdb trace below ) : > > Unread portion of the kernel message buffer: > umass0: at uhub1 port 1 (addr 2) disconnected > (da1:umass-sim0:0:0:0): lost device > (pass1:umass-sim0:0:0:0): lost device > (pass1:umass-sim0:0:0:0): removing device entry > I have problems with umass during reboot. It causes a kernel panic and a forced reboot. To work around the problem, I disconnect the usb cable to reboot. Once the system comes back up, I can map the drive with no problems. If someone can tell me how to capture the information, I'd be glad to do so. I have no idea how to do it, and, after I disconnect the cable and reboot again, dmesg.boot looks perfectly normal. I've looked for core files but haven't found any. savecore -C returns "No dump exists". This is my workstation, so I can fiddle with it as need be to capture useful information. I just need someone knowledgeable to walk me through it, because this type of work is definitely out of my league. # uname -a FreeBSD utd65257.utdallas.edu 7.0-STABLE FreeBSD 7.0-STABLE #7: Sun Jun 8 15:58:57 CDT 2008 root@utd65257.utdallas.edu:/usr/obj/usr/src/sys/GENERIC i386 I just rebuilt world and kernel again, hoping the latest patches would solve the problem, but it didn't. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From wb at freebie.xs4all.nl Mon Jun 9 17:44:44 2008 From: wb at freebie.xs4all.nl (Wilko Bulte) Date: Mon Jun 9 17:44:49 2008 Subject: Current status of support for high end SAN hardware In-Reply-To: <3cc535c80806090541g15c03c24mf1c47a9b92ff166a@mail.gmail.com> References: <3cc535c80806071158h44ec9be1pbe72ca6711016bde@mail.gmail.com> <484C4E6D.7060306@datapipe.com> <20080609103610.GA36227@riffraff.plig.net> <3cc535c80806090541g15c03c24mf1c47a9b92ff166a@mail.gmail.com> Message-ID: <20080609174437.GB31050@freebie.xs4all.nl> Quoting Andy Kosela, who wrote on Mon, Jun 09, 2008 at 02:41:24PM +0200 .. > On Mon, Jun 9, 2008 at 12:36 PM, Russell Vincent wrote: > > > > The FreeBSD support for multipath/SAN is fairly poor. It's fiddly > > to get to work and boot times are a little variable (into the > > minutes) as it tries to discover the devices. Once it is configured > > and booted, it just works as long as things don't go wrong. SAN > > outages cause the machine to hang up until the issue is resolved > > (in which case it just seems to continue) or it doesn't recover at > > all and requires a reboot. Note that I don't spend a significant > > amount of time on this, so it may be that I could do things a little > > better. I have also not tested the failover stuff very well (I > > only upgraded this machine to 7-STABLE fairly recently). Disk > > access seems to be restricted to a single path at a time. Problem > > solving is very tricky as there is very little information to trace > > which path/disk refers to which fabric/storage device/LUN. > > > > Russell, > Thank you for your insights. It's good to see you have no problems > with isp(4) and Qlogic HBAs. Though I'm concerned about > multipathing. We run 6.x-RELEASE releases so it seems we have > to upgrade to 7.0-RELEASE to achieve that goal. gmultipath(8) > code is fairly new so I suppose it's not that mature yet as in > Linux. Unfortunately it is only an active/passive approach with > no load balancing (the active path is active until a BIO request is > failed with EIO or ENXIO) Well, it is worse than that: HP EVA arrays have 2 different multipath behaviours. VCS 3.x firmware is active/passive, whereas VCS 4.x is active/active. Active/active as well are all XCS firmware versions. All newer EVAs run XCS. To properly do multipathing on active/active EVAs your multipathing software should be aware of the ALUA stuff. On active/active EVAs you should fire your read commands to the right HSV controller, if you take the other HSV things will work, but the controller you sent the read to will have to do a proxy read to the HSV controller that "owns" the LUN. This will be slower that taking the right HSV in one go. It also consumes bandwith on the HSV controller's mirror port(s). Writes do not matter, they are mirrored to the write cache in each HSV anyway. Linux devicemapper is sort-of getting there now. For the longest time HP did not support devicemapper, and for good reasons too. To make things interesting I think I remember Matt (the isp(4) author) telling me that some ispfw(4) versions not getting it right. If the adapter firmware does not properly inform the isp(4) driver of SAN disruptions you are obviously doomed as a multipathing driver that depends on the underlying HBA drivers to feed SAN problems/status upstream. In short: if you use isp(4), always load ispfw(4) too. Getting all the components in a FC SAN to DTRT is unfortunately still a major pain in the backside. hth Wilko -- Wilko Bulte wilko@FreeBSD.org From oberman at es.net Mon Jun 9 17:45:17 2008 From: oberman at es.net (Kevin Oberman) Date: Mon Jun 9 17:45:26 2008 Subject: cpufreq broken on core2duo In-Reply-To: Your message of "Sun, 08 Jun 2008 22:30:35 PDT." <20080609053035.GA6859@eos.sc1.parodius.com> Message-ID: <20080609174512.60E124501A@ptavv.es.net> > Date: Sun, 8 Jun 2008 22:30:35 -0700 > From: Jeremy Chadwick > > On Sun, Jun 08, 2008 at 10:13:43PM -0700, Kevin Oberman wrote: > > > Date: Sat, 7 Jun 2008 09:48:12 -0700 > > > From: Jeremy Chadwick > > > Sender: owner-freebsd-stable@freebsd.org > > > > > > On Sat, Jun 07, 2008 at 05:51:38PM +0300, Evren Yurtesen wrote: > > > > By the way, there is another thing I am wondering about. If I enable HTT > > > > and Intel Enhanced SpeedStep in bios on a 3.00GHZ p4 CPU I see: > > > > > > > > cpu0: on acpi0 > > > > acpi_perf0: on cpu0 > > > > p4tcc0: on cpu0 > > > > cpu1: on acpi0 > > > > est1: on cpu1 > > > > est: CPU supports Enhanced Speedstep, but is not recognized. > > > > est: cpu_vendor GenuineIntel, msr f2700000f27 > > > > device_attach: est1 attach returned 6 > > > > p4tcc1: on cpu1 > > > > > > > > dev.cpu.0.freq_levels: 1500/27000 1312/23625 1200/13000 1050/11375 900/9750 > > > > 750/8125 600/6500 450/4875 300/3250 150/1625 > > > > dev.acpi_perf.0.freq_settings: 1500/27000 1200/13000 > > > > dev.cpufreq.0.%driver: cpufreq > > > > dev.cpufreq.0.%parent: cpu0 > > > > dev.cpufreq.1.%driver: cpufreq > > > > dev.cpufreq.1.%parent: cpu1 > > > > dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 > > > > 2500/-1 1250/-1 > > > > dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 > > > > 2500/-1 1250/-1 > > > > > > > > and it does not allow me to set the freq. of the cpu. > > > > > > How are you setting the frequency? Are you using powerd? You do not > > > have to enable SpeedStep in your BIOS to achieve throttling CPU clock > > > speed. In fact, I would highly recommend leaving EIST/SpeedStep in the > > > BIOS *disabled*, and let powerd adjust the clock frequency via ACPI. > > > > I must strongly recommend against this. EST is MUCH more efficient on > > its control of power use than simple throttling. So much so that on my > > systems that support EST, I remove cpufreq from the kernel. (In all > > cases, throttling means either simple throttling or throttling by using > > TCC.) > > The reality of the situation is that users cannot use EIST reliably on > FreeBSD. I cannot imagine removing cpufreq would solve the "runtime > went backwards" issue. The EIST problem needs to be fixed. If the > folks who work on it do not have present-day hardware (C2Ds, etc.), I > will be more than happy to purchase them whatever they need. > > > I did quite a bit of testing on power management a year or so ago and > > found that throttling was of value only for controlling CPU temperature. > > For real power management, EST works far better as it adjust frequency > > (actual clock rate) and CPU voltage while throttling just stops and > > starts the clock without changing its actual frequency. (This came as a > > surprise to me about 5 years ago when I first discovered it.) > > As far as I know, the ACPI frequency toggling does in fact adjust the > CPU clock rate -- because the values in dev.cpu.0.freq_levels are > defined by the ACPI configuration on the machine. It claims to adjust clock speed, but it actually simply "skips" cycles. The system clocks at its standard rate or that provided by other power management tools. Since throttling (whether done by the external throttling or TCC) will provide 8 "frequencies". If SpeedStep, EST, or PowerNow is available, it will show 8 times the number of "true" frequencies provided by any of those. (Actually, on my system EST provides 16 "frequencies" of which 4 are actual changes in the clock and the others are from 4 voltages it uses. 4**2 = 16. If you see exactly eight "frequencies" with cpufreq, you have no "true" frequency adjustment. > I'd confirm this, but looking at the kernel code doesn't help -- I > cannot find the definition of the CPUFREQ_LEVELS function or macro. > > > At idle, throttling does exactly nothing. EST reduces voltage on the > > CPU and saves power even when idle. At full CPU load, throttling reduces > > performance and power consumption equally. EST beats it by a slim > > margin. > > I thought the power-saving modes of the CPU (C1E/C2E/C3E/C4E) could be > used *without* enabling EIST. I don't think FreeBSD has kernel or > userland support utilities to enable/disable CPU-level features. > Something like RMClock for Windows would be quite useful. (If you have > the opportunity to run it, do so; you'll see what I mean, re: all the > features being toggleable individually). Yes, C-states are not tied to EST or any "frequency-like" things. And they are a really significant factor in power saving. I'll have to look at RMClock. I am not familiar with it. (I don't normally use Windows, but I can boot it on my laptop.) > > The big win is at moderate load. Throttling can result is very poor > > results for aps like video and music which will place a continuous load > > on the system, but only 20-60% (in the case of my test system). It > > tended to make the system seem sluggish. EST does a much better job in > > this case as it lowers CP voltage and clock rate to maximize performance > > while minimizing power. > > > > If your only concern is keeping the system cool, throttling will do the > > job, but if you want efficient power utilization, use EST if possible. > > In the case est does not attach (e.g. no EIST support enabled in > FreeBSD), the throttling method resorts to simply suspending the system, > then yes I completely agree -- EIST is significantly better than that. If you have no better method than throttling, you have to go with it, but it's way to primitive to be a really big help. FWIW, on my ThinkPad (uni-processor), with no cpufreq in the system, I see: dev.cpu.0.freq_levels: 2000/27000 1750/23625 1600/22600 1400/19775 1333/19666 1166/17207 1066/16733 932/14641 800/13800 700/12075 600/10350 500/8625 400/6900 300/5175 200/3450 100/1725 It is running EST and P4TCC is explicitly disabled in loader.conf. Oh, and my testing showed that TCC did a slightly better job than simple throttling, though they do about the same thing, so the difference is probably not significant. With the current code, if P4TCC is available, it will be used in preference to throttling. Both will never be used together. (That was a good way to lock up your system during the time both were used.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080609/f01723ae/attachment.pgp From spomerg at cwu.EDU Mon Jun 9 18:33:21 2008 From: spomerg at cwu.EDU (Gavin Spomer) Date: Mon Jun 9 18:33:25 2008 Subject: 6.2-STABLE => 7.0-STABLE Upgrade root partition more full Message-ID: <484D14F20200009000019CBD@hermes.cwu.edu> >>> Skip Ford 06/06/08 1:39 PM >>> Gavin Spomer wrote: > I successfully did my first FreeBSD upgrade yesterday after looking at the manual, and cross referencing with Googling and getting help from our network engineer here at CWU. Before the upgrade, running df showed: > > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/da0s1a 507630 77662 389358 17% / > devfs 1 1 0 100% /dev > /dev/da0s1e 507630 588 466432 0% /tmp > /dev/da0s1f 268217320 4866120 241893816 2% /usr > /dev/da0s1d 4298926 162066 3792946 4% /var > > Now it shows: > > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/da0s1a 507630 184834 282186 40% / > devfs 1 1 0 100% /dev > /dev/da0s1e 507630 426 466594 0% /tmp > /dev/da0s1f 268217320 5514844 241245092 2% /usr > /dev/da0s1d 4298926 187570 3767442 5% /var > > Notice the the increase in the root partition. Should I have made this partition bigger when I first installed? Is there any cleaning up I can do after version upgrades? I would've thought /usr would be the one that grew more, but then again my /usr partition is fairly sizeable. Does 7.0 just take up a lot more of the root partition than 6.2? 7.0 installs debugging symbols for the kernel and modules by default. You can avoid that by defining INSTALL_NODEBUG during installkernel. If already installed, you can delete the symbol files without causing problems as long as you don't need to debug the kernel. Also, when you install a new kernel, the old kernel is saved as kernel.old so you now have 2 kernels in /boot instead of one. If you're positive the new kernel works fine, the old kernel can be removed as that's only used to recover from a new kernel with problems. But, your space really isn't that close to the limit, IMO. You appear to have enough space to have an old and new kernel installed both with symbols, so I'd leave it as is in case you need to debug something or boot the old kernel. You can always take care of it later if you're about to run out of space. Why do today what you can put off 'til tomorrow? Also, consider reading UPDATING before every upgrade. The entry for 20060118 covers this issue. -- Skip Thanks a bunch for the info, it is helpful. Also, sorry for the lateness of my reply. Any suggestions for selectively reading UPDATING? It IS a rather long file. I'd rather be reading a good R.A. Salvatore novel if I'm going to read for that long. ;) Thanks for you reply as well, Clifton. - Gavin From peter at wemm.org Mon Jun 9 18:34:04 2008 From: peter at wemm.org (Peter Wemm) Date: Mon Jun 9 18:34:09 2008 Subject: 6.3-RELEASE versus 5.2-RELEASE In-Reply-To: <484CD995.3040002@zircon.seattle.wa.us> References: <484CD995.3040002@zircon.seattle.wa.us> Message-ID: On Mon, Jun 9, 2008 at 12:19 AM, Joe Kelsey wrote: > Can anyone verify that some number of bugs related to either a) gmirror, b) > bge and/or c)twe were fixed after the release of 6.3? That is as far as I > can tell the reason that Jo objets to EoL of 6.2, the fact that 6.3 is > unusable due to these late-fixed bugs. I can't speak for gmirror. But I suspect the bigger problem with bge and 3ware is that the drivers attempt to provide coverage for many many variants of hardware. The bge driver covers (at last count) 59 different chips and variants. New variants keep on arriving, with new bugs and new fixes, so our driver requires updates for these *new* chips. There's the catch. The same driver in 6.2 would require the same updates. If Joe's hardware worked with 6.2, it would work with 6.3 as well. The situation is similar with 3ware. There are even two different drivers. twe and twa. twe supports two different hardware interfaces. twa has 4 different hardware interfaces. twa has been getting frequent updates to handle new variations of the 9000 series cards. Again, it seems likely that Joe's hardware would run fine with 6.3-R if it already works with 6.2-R. So far we don't even know which of the 59 variants of bge hardware Jo wants to run with, nor which 3ware driver.. let alone the 3ware variants. I don't recall him mentioning whether it is twe or twa. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From rblayzor.bulk at inoc.net Mon Jun 9 18:48:59 2008 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Mon Jun 9 18:49:04 2008 Subject: BOOTP and no default route Message-ID: <0D67AF88-6593-47F3-9774-BE1875795B80@inoc.net> Is there any way to prevent the BOOTP client from injecting a default route? When I originally set things up our DHCP server would not send a default route because there was no gateway, local only. If you leave out the default route, the server will try proxy-arp when ends up putting a default route to itself in the routing table. The problem is that on startup the servers actually setup static networks with default routes out another interface. The problem is, if the BOOTP client puts in a default route, we cannot easily add another default because one already exists. The only way I've found around this behavior was to error the BOOTP client out and send it a default gateway that does not exist on the local net the DHCP server provides. This causes the BOOTP client not to set a default route and all works fine. Obviously this seems like a cobb/hack and was wondering if there was a BOOTP option or kernel tweak that can be done to tell the BOOTP client not to use proxy-arp. -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From tss at iki.fi Mon Jun 9 19:02:21 2008 From: tss at iki.fi (Timo Sirainen) Date: Mon Jun 9 19:02:48 2008 Subject: Environment clearing broken in 7.0 Message-ID: <1213036854.3904.967.camel@hurina> I think clearing environment using: environ[0] = NULL; has been kind of a semi-standard for a while now. At least Dovecot and Postfix clears their environment this way. But this no longer works in FreeBSD 7.0 (putenv(), environ[0]=NULL, putenv() -> everything is visible again). Was this change intended, or will this be fixed? Looks like I could work around this by using: environ = NULL; but I'm afraid what other OSes that change would break. I guess going through environ and unsetenv()ing everything would work too, but it feels annoyingly slow for such a simple operation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080609/38074106/attachment.pgp From max at love2party.net Mon Jun 9 19:03:06 2008 From: max at love2party.net (Max Laier) Date: Mon Jun 9 19:03:11 2008 Subject: New Mailinglist: freebsd-wip-status@ Message-ID: <200806092102.16651.max@love2party.net> Hello everybody, SHORT SUMMARY: http://lists.freebsd.org/mailman/listinfo/freebsd-wip-status Subscribe today!! Tell all your friends, co-workers and everybody you know who's interested in FreeBSD. Post this on your blog! ;) LONG VERSION: if you've been around lately you might already know about our effort to provide periodical status reports about ongoing FreeBSD related WIPs. The past reports can be found at: http://www.freebsd.org/news/status This system has some shortcomings however. The biggest one is that due to the collection overhead and the high rate of exciting development under the FreeBSD umbrella most of the reports are somewhat outdated by the time they get to "print". Other projects never are announced in the status reports because they happen in-between and fall through the cracks. In order to improve this situation we have created a new mailing list that should receive status reports from now on. This list will be moderated in order to keep it close to the subject. The intend is to make this an inviting place for people with little time to still stay on top of the latest and greatest in and around FreeBSD, but where one can avoid the chatter that comes with the technical debates on the normal lists. For all developers, contributors, conference organizers, 3rd party distributions, SoC-students and whoeverelse has exciting news about their FreeBSD related project this means little work. Most of you already are sending out announcement- and update-emails to lists like current@, net@ or whichever fits your project in order to inform the world about the progress you've made. Now we would like to invite you to BCC: this email to freebsd-wip-status@ as well for maximum exposure. Emails with a lot of gory, technical details are probably not suited for this list, but the usual: "Hey, I've got these cool patches to test. Here is what they do: ..." most certainly is. So this is really like the status reports before, but everybody subscribed can get the news when they happen (and not three month later when the next status reports are due). I hope for your support in bootstrapping this idea. During the next few weeks I'll keep a close eye on the lists I'm subscribed to and will encourage people to forward matching posts to freebsd-wip-status@ You are welcome to do the same. We also plan to keep the status reports as is, but collecting the reports from this new list, too. This should give the best of both worlds, we hope. If you have any questions or would like to help with editing the status reports, please contact monthly@FreeBSD.org (reply-to set) or myself directly. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From fjwcash at gmail.com Mon Jun 9 23:05:43 2008 From: fjwcash at gmail.com (Freddie Cash) Date: Mon Jun 9 23:05:46 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: References: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com> Message-ID: On Mon, Jun 9, 2008 at 3:25 PM, Jo Rhett wrote: > On Jun 8, 2008, at 3:27 PM, Freddie Cash wrote: >> Like I said, you have to define what you mean by "stable" and >> "unstable" before the discussion can continue. >> >> "stable" can mean many things to many people. You talk about feature >> stability. Other may talk about "number of open bugs" as being >> unstable. Others may talk of API/ABI stability. Other may mean "code >> that don't crash a system". >> >> Your view of "stable" meaning "features don't change" is no where near >> my definition of stable (systems that don't crash, and where I can run >> binaries from older point releases on newer point releases). > > I don't care about features, I care about uptime. "stable" in my brain > means that there isn't 150 revisions to the cvs tree in the 2 months post > release regarding kernel and core drivers. "stable" is also overloaded with > meaning "will be around long enough that I can focus on other projects > instead of replacing it nearly instantly with a new release" > > FWIW, since you clearly misunderstood my point of view. Actually, I believe you misunderstood me, as you quoted me out of context, and quoted my reply to someone else. :) My message to you was "define what you mean by stable and unstable". Which, if I follow correctly, you define as "never having any commits to the codebase". I care about uptime as well (along with performance and maintainability). And so far, none of our systems using em(4) cards, bge(4) cards, twa(4) cards, gmirror(8) (although I've since moved those to 7-STABLE with ZFS alongside), running on bare metal or in VMs have any issues with 6.3-RELEASE or 7.0-RELEASE. But, how does "the number of commits since release" have any bearing on uptime of a system you haven't tested? ;) Those seem to be completely unrelated to me. -- Freddie Cash fjwcash@gmail.com From joe at zircon.seattle.wa.us Mon Jun 9 23:25:28 2008 From: joe at zircon.seattle.wa.us (Joe Kelsey) Date: Mon Jun 9 23:25:32 2008 Subject: Closing the Jo Rhett argument Message-ID: <484DBBE7.6080908@zircon.seattle.wa.us> Jo Rhett has clearly stated (in offline reply) that they do not participate in the -BETA and-RC cycles leading up to -RELEASE, so they therefore do not have any issues with -RELEASE and EoL to raise. Actually, they still have the same complaints to raise about EoL, but since they refuse to participate in the -RELEASE process, they do not have valid points to raise. I ask that everyone please stop communicating with the persona known on this list as "Jo Rhett" unless and until they participate in the -BETA, -RC, and -RELEASE process. You cannot raise any sort of valid complaint about -RELEASE, EoL or bugs if you do not participate in finding bugs during the -BETA and -RC stages prior to the -RELEASE. If you instead choose to try to run -RELEASE and find bugs then, then complain about the bugs you found and continue to complain that these bugs were not found by someone else and fixed ahead of time, you have no issues and do not deserve an answer, no matter how much you try to frame it as a "policy" question. /Joe From jaj at hcl-club.lu Tue Jun 10 00:50:45 2008 From: jaj at hcl-club.lu (Jona Joachim) Date: Tue Jun 10 00:50:50 2008 Subject: pkg_delete core dump when removing linux-tiff In-Reply-To: <484BE563.90102@FreeBSD.org> References: <484BE563.90102@FreeBSD.org> Message-ID: <20080610003222.GA3822@nirvana.my.domain> On Sun, Jun 08, 2008 at 03:57:55PM +0200, Kris Kennaway wrote: > Jona Joachim wrote: > > Hi! > > > > pkg_delete core dumps on me when it tries to remove linux-tiff. > > I can reproduce this reliably. > > > FWIW you can find the core dump here: > > http://www.hcl-club.lu/~jaj/stuff/pkg_delete.core > > You need to obtain the backtrace, see the developers handbook. I built pkg_delete with -g but gdb says 'no debugging symbols found'. Is the following information sufficient or do I need to rebuild everything with debugging information turned on? Script started on Tue Jun 10 02:18:04 2008 nirvana% sudo gdb pkg_delete GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... (gdb) run linux-tiff-3.7.1 Starting program: /usr/sbin/pkg_delete linux-tiff-3.7.1 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...pkg_delete: file '/compat/linux/usr/bin/bmp2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/fax2ps' doesn't exist pkg_delete: file '/compat/linux/usr/bin/fax2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/gif2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/pal2rgb' doesn't exist pkg_delete: file '/compat/linux/usr/bin/ppm2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/ras2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/raw2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/rgb2ycbcr' doesn't exist pkg_delete: file '/compat/linux/usr/bin/thumbnail' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiff2bw' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiff2pdf' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiff2ps' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiff2rgba' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffcmp' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffcp' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffdither' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffdump' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffinfo' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffgt' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffmedian' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffset' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffsplit' doesn't exist pkg_delete: file '/compat/linux/usr/lib/libtiff.so.3' doesn't exist pkg_delete: file '/compat/linux/usr/lib/libtiff.so.3.7.1' doesn't exist pkg_delete: file '/compat/linux/usr/share/doc/libtiff-3.7.1/COPYRIGHT' doesn't exist pkg_delete: file '/compat/linux/usr/share/doc/libtiff-3.7.1/README' doesn't exist pkg_delete: file '/compat/linux/usr/share/doc/libtiff-3.7.1/RELEASE-DATE' doesn't exist pkg_delete: file '/compat/linux/usr/share/doc/libtiff-3.7.1/VERSION' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/bmp2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/fax2ps.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/fax2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/gif2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/pal2rgb.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/ppm2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/ras2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/raw2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/rgb2ycbcr.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/sgi2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/thumbnail.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiff2bw.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiff2pdf.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiff2ps.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiff2rgba.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffcmp.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffcp.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffdither.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffdump.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffinfo.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffgt.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffmedian.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffset.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffsplit.1.gz' doesn't exist Program received signal SIGSEGV, Segmentation fault. 0x0804c6b4 in ?? () (gdb) bt #0 0x0804c6b4 in ?? () #1 0xbfbfdd7b in ?? () #2 0x0804efac in ?? () #3 0x08112130 in ?? () #4 0x0811a440 in ?? () #5 0x0810b160 in ?? () #6 0x08112130 in ?? () #7 0x0811a440 in ?? () #8 0xffffffff in ?? () #9 0x00000000 in ?? () #10 0x0810b200 in ?? () #11 0x08112130 in ?? () #12 0x00000000 in ?? () #13 0x08126580 in ?? () #14 0x0804ef9c in ?? () #15 0x081252e4 in ?? () #16 0x081258f8 in ?? () #17 0x081252c4 in ?? () #18 0x0810b160 in ?? () #19 0x00000007 in ?? () #20 0x081258fc in ?? () #21 0x0812534c in ?? () #22 0x00000000 in ?? () #23 0x7261762f in ?? () #24 0x2f62642f in ?? () #25 0x2f676b70 in ?? () #26 0x756e696c in ?? () #27 0x61625f78 in ?? () #28 0x662d6573 in ?? () #29 0x5f342d63 in ?? () #30 0x2b2f3331 in ?? () #31 0x55514552 in ?? () #32 0x44455249 in ?? () #33 0x2e59425f in ?? () #34 0x6c585956 in ?? () #35 0x0000756e in ?? () #36 0x000d7c44 in ?? () #37 0x08052c44 in ?? () #38 0x00001000 in ?? () #39 0xfffffffc in ?? () #40 0x480fb02e in malloc () from /lib/libc.so.7 #41 0x0804a4bb in ?? () #42 0x00000000 in ?? () #43 0x00000000 in ?? () #44 0x080523c0 in optind () #45 0x00000001 in ?? () #46 0x08124a48 in ?? () #47 0x00000002 in ?? () #48 0x00000004 in ?? () #49 0x0810b360 in ?? () #50 0x081121c0 in ?? () #51 0x08114070 in ?? () #52 0x08114078 in ?? () #53 0x00000002 in ?? () #54 0x00000000 in ?? () #55 0x00000000 in ?? () #56 0x00000002 in ?? () #57 0x00000018 in ?? () #58 0x00000014 in ?? () #59 0x08124914 in ?? () #60 0x7273752f in ?? () ---Type to continue, or q to quit--- #61 0x6d6f682f in ?? () #62 0x616a2f65 in ?? () #63 0x0000006a in ?? () #64 0x08124a44 in ?? () #65 0x08124a60 in ?? () #66 0x08124728 in ?? () #67 0x08124734 in ?? () #68 0x0812490c in ?? () #69 0x08124914 in ?? () #70 0x08124910 in ?? () #71 0x08124918 in ?? () #72 0x081242e4 in ?? () #73 0x081248f8 in ?? () #74 0x081242c4 in ?? () #75 0x08124a48 in ?? () #76 0x08124728 in ?? () #77 0x081248fc in ?? () #78 0x0812434c in ?? () #79 0x08124334 in ?? () #80 0x08124928 in ?? () #81 0x08124730 in ?? () #82 0x00000001 in ?? () #83 0x08124924 in ?? () #84 0xbfbfe268 in ?? () #85 0x480d7c5f in fts_set_clientptr () from /lib/libc.so.7 #86 0x0804a931 in ?? () #87 0x08114068 in ?? () #88 0x00000008 in ?? () #89 0xbfbfe648 in ?? () #90 0x48162417 in wcrtomb () from /lib/libc.so.7 #91 0x08049ab7 in ?? () #92 0x08114068 in ?? () #93 0xbfbfe66c in ?? () #94 0x0805109c in __progname () #95 0x00000065 in ?? () #96 0x00003ee1 in ?? () #97 0x02bc41ed in ?? () #98 0x00000000 in ?? () #99 0x00000000 in ?? () #100 0x00010258 in ?? () #101 0x484dc842 in ?? () #102 0x00000000 in ?? () #103 0x484d92b0 in ?? () #104 0x00000000 in ?? () #105 0x484d92b0 in ?? () #106 0x00000000 in ?? () #107 0x00006c00 in ?? () #108 0x00000000 in ?? () #109 0x00000038 in ?? () #110 0x00000000 in ?? () #111 0x00001000 in ?? () #112 0x00000000 in ?? () #113 0xf000f1e2 in ?? () #114 0x00000000 in ?? () #115 0x4369c5b1 in ?? () #116 0x00000000 in ?? () #117 0x00000000 in ?? () #118 0x00000000 in ?? () #119 0x00000000 in ?? () #120 0xbfbfeb5c in ?? () #121 0x00000000 in ?? () ---Type to continue, or q to quit--- #122 0xbfbfeb18 in ?? () #123 0x0804ab0c in ?? () #124 0x00000002 in ?? () #125 0xbfbfeb5c in ?? () #126 0xbfbfe968 in ?? () #127 0x48055660 in dladdr () from /libexec/ld-elf.so.1 Previous frame inner to this frame (corrupt stack?) (gdb) quit The program is running. Exit anyway? (y or n) y nirvana% Script done on Tue Jun 10 02:19:05 2008 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080610/1393926c/attachment.pgp From kris at FreeBSD.org Tue Jun 10 01:14:13 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Jun 10 01:14:16 2008 Subject: pkg_delete core dump when removing linux-tiff In-Reply-To: <20080610003222.GA3822@nirvana.my.domain> References: <484BE563.90102@FreeBSD.org> <20080610003222.GA3822@nirvana.my.domain> Message-ID: <484DD565.2010700@FreeBSD.org> Jona Joachim wrote: > On Sun, Jun 08, 2008 at 03:57:55PM +0200, Kris Kennaway wrote: >> Jona Joachim wrote: >>> Hi! >>> >>> pkg_delete core dumps on me when it tries to remove linux-tiff. >>> I can reproduce this reliably. >>> FWIW you can find the core dump here: >>> http://www.hcl-club.lu/~jaj/stuff/pkg_delete.core >> You need to obtain the backtrace, see the developers handbook. > > I built pkg_delete with -g but gdb says 'no debugging symbols found'. > Is the following information sufficient or do I need to rebuild everything with debugging information turned on? It was probably stripped at install, I think you can set STRIP= (i.e. empty value) but doesn't it also explain this in the handbook? Kris From jrhett at netconsonance.com Tue Jun 10 01:15:53 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue Jun 10 01:15:59 2008 Subject: Closing the Jo Rhett argument In-Reply-To: <484DBBE7.6080908@zircon.seattle.wa.us> References: <484DBBE7.6080908@zircon.seattle.wa.us> Message-ID: <86021481-1BCB-4E16-8DD5-EC14B8597C10@netconsonance.com> On Jun 9, 2008, at 4:25 PM, Joe Kelsey wrote: > Jo Rhett has clearly stated (in offline reply) that they do not > participate in the -BETA and-RC cycles leading up to -RELEASE, so > they therefore do not have any issues with -RELEASE and EoL to raise. > Actually, they still have the same complaints to raise about EoL, > but since they refuse to participate in the -RELEASE process, they > do not have valid points to raise. > > I ask that everyone please stop communicating with the persona known > on this list as "Jo Rhett" unless and until they participate in the - > BETA, -RC, and -RELEASE process. You cannot raise any sort of valid I'd really like to ignore this post because it would appear Joe Kelsey is insane (not kidding, read below). But just in case someone believes this, I have quoted here my entire reply to Joe Kelsey (only one reply). You'll notice that there is no mention of the release cycles. It wasn't part of the topic at all. > Um, no. My post was not titled "I can't upgrade to 6.3" for a > reason. The problem is the very limited EoL times set for the > releases. > > And I'm not talking about reading the CVS logs and "assuming" > anything. I have a customer using the exact same hardware we are > using who is the reporter of some serious problems with 6.3. They > were forced to stop rollout of 6.3 because of them. Their untouched > 6.2 machines continue to run fine. This is why I said "guaranteed > to fail". > > The main problem is the constant release churn. There *were* a lot > of people willing to invest time/money/machines to provide longer > EoL for releases. I was asking for information to determine what > resources were necessary and how to best apply them. (this detail > is necessary because we were going to put together a proposal to > take to our respective $EMPLOYERs and get financial support behind > this) > > I suspect your heart is in the right place, but your actual post is > of the nature of > > 1. Take the stated information and resolve it to something else > 2. Make the stated person sound like an idiot for your own > interpretation of it > 3. repeat again and again for a few more paragraphs. > > Perhaps you should just once assume that the poster is competent, > knows exactly what they saying, and means what they say? I didn't > say "guaranteed to fail" because I had a bad dream about it. I said > it because I have a 6.3 system in the test lab showing the exact > same failure. Why was I not showing the output in this thread? > BECAUSE THE THREAD WAS SUPPOSED TO BE ABOUT POLICY AND SUPPORT > RESOURCES. > > Seriously, next time you find yourself thinking that someone else is > an idiot, take a step back and try, just try to put yourself in > their shoes. Try and imagine that this person is competent, and is > being honest about what they say. And before you ask, I did do this > when I wrote this message. "I suspect your heart is in the right > place". I usually believe this in other people, it makes my world a > happier place to be. The first time mention of BETA and RC cycles came up was in his reply to me, which was full of personal insults and attacks like the following, so I discarded it without reply: > I see no reason to assume competence on your part since you have > demonstrated no competence. ... > I don't need to assume anything about you. You have demonstrated > your idiocy to everyone on the list. Please keep your insane rants > to yourself in the future. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From scf at FreeBSD.org Tue Jun 10 03:38:32 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Tue Jun 10 03:38:37 2008 Subject: Environment clearing broken in 7.0 In-Reply-To: <1213036854.3904.967.camel@hurina> References: <1213036854.3904.967.camel@hurina> Message-ID: On Mon, 9 Jun 2008, Timo Sirainen wrote: > I think clearing environment using: > > environ[0] = NULL; > > has been kind of a semi-standard for a while now. At least Dovecot and > Postfix clears their environment this way. But this no longer works in > FreeBSD 7.0 (putenv(), environ[0]=NULL, putenv() -> everything is > visible again). Was this change intended, or will this be fixed? It is more or less intended. When a program sets an environment variable, the environment is copied for faster/leaner usage. Changing individual values within environ is not checked else every pointer would need to be checked for consistency. What I did was to write the code to detect if environ is replaced (NULL or new array of variables). I suggest reading the two paragraphs from Open Group's getenv()[1] documentation starting at "Conforming applications are required not to modify environ directly, ..." for the rationale in the new design. Obviously, applications are not required to conform, but the documentation talks about what an OS may be doing under the covers to environ. Out of curiosity, do Dovecot and Postfix check that environ is not NULL before setting environ[0]? environ may be set to NULL at the start but not by FreeBSD's /usr/bin/env -i. > Looks like I could work around this by using: > > environ = NULL; That will work on the *BSD's, OpenSolaris and Linux. Also, this will work: environ = calloc(1, sizeof(*environ)); > but I'm afraid what other OSes that change would break. I guess going > through environ and unsetenv()ing everything would work too, but it > feels annoyingly slow for such a simple operation. OpenSolaris does something similar with environ[2]. It also detects in initenv() a replacement of environ but not changes to individual entries. Sean 1. http://www.opengroup.org/onlinepubs/000095399/functions/getenv.html 2. http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/gen/getenv.c -- scf@FreeBSD.org From tss at iki.fi Tue Jun 10 04:14:51 2008 From: tss at iki.fi (Timo Sirainen) Date: Tue Jun 10 04:14:55 2008 Subject: Environment clearing broken in 7.0 In-Reply-To: References: <1213036854.3904.967.camel@hurina> Message-ID: <1213071257.3904.991.camel@hurina> On Mon, 2008-06-09 at 22:27 -0500, Sean C. Farley wrote: > On Mon, 9 Jun 2008, Timo Sirainen wrote: > > > I think clearing environment using: > > > > environ[0] = NULL; > > > > has been kind of a semi-standard for a while now. At least Dovecot and > > Postfix clears their environment this way. But this no longer works in > > FreeBSD 7.0 (putenv(), environ[0]=NULL, putenv() -> everything is > > visible again). Was this change intended, or will this be fixed? > > It is more or less intended. When a program sets an environment > variable, the environment is copied for faster/leaner usage. Changing > individual values within environ is not checked else every pointer would > need to be checked for consistency. What I did was to write the code to > detect if environ is replaced (NULL or new array of variables). OK, so perhaps Sendmail's way of clearing environment would be the best solution: static char *emptyenv[1] = { NULL }; environ = emptyenv; > I suggest reading the two paragraphs from Open Group's getenv()[1] > documentation starting at "Conforming applications are required not to > modify environ directly, ..." for the rationale in the new design. > Obviously, applications are not required to conform, but the > documentation talks about what an OS may be doing under the covers to > environ. How about implementing clearenv()? I'm using it now if it's available. > Out of curiosity, do Dovecot and Postfix check that environ is not NULL > before setting environ[0]? environ may be set to NULL at the start but > not by FreeBSD's /usr/bin/env -i. Yes, both check if it's NULL. (I think I originally copied my code's logic from Postfix.) > > Looks like I could work around this by using: > > > > environ = NULL; > > That will work on the *BSD's, OpenSolaris and Linux. But not on OS X. It crashes there. > Also, this will work: > environ = calloc(1, sizeof(*environ)); Is this any better than using a static emptyenv[1]? BTW. I wonder if this change breaks any applications where not clearing environment could result in a security hole. As far as I know FreeBSD 7.0 is the only modern OS where environ[0]=NULL doesn't work. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080610/1365711a/attachment.pgp From quakenet1 at optusnet.com.au Tue Jun 10 07:07:20 2008 From: quakenet1 at optusnet.com.au (Jerahmy Pocott) Date: Tue Jun 10 07:07:25 2008 Subject: DVD-RW doesn't write Message-ID: <36421019-B667-42FD-8069-98B7BFFED920@optusnet.com.au> Hello all, I'v been trying to get this dvd burner to burn, but there seems to be something wrong with the driver for the controller or the drive.. On boot it is detected as: acd0: DMA limited to UDMA33, controller found non-ATA66 cable acd0: DVDR at ata0-master UDMA33 It is connected to: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf irq 16 at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 The message that the controller found a non-ata66 cable is an error, the cable is most certainly ata66 compatible and I'v switched it out to make sure it wasn't faulty.. The drive is able to mount and read cds/dvds fine, but on trying to use burncd it says: acd0: FAILURE - READ_TRACK_INFO ILLEGAL REQUEST asc=0x24 ascq=0x00 Any further attempts produce the above message with no delay to read from the drive, resetting the ata0 channel makes it check the drive again before producing the message. On loading atapicam module it says: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 So I wasn't able to try cdrecord with it.. I also dropped it back ti PIO4 mode in case there was a DMA issue, but I had the same results in PIO. Any more ideas? J. From wb at freebie.xs4all.nl Tue Jun 10 07:10:51 2008 From: wb at freebie.xs4all.nl (Wilko Bulte) Date: Tue Jun 10 07:10:56 2008 Subject: DVD-RW doesn't write In-Reply-To: <36421019-B667-42FD-8069-98B7BFFED920@optusnet.com.au> References: <36421019-B667-42FD-8069-98B7BFFED920@optusnet.com.au> Message-ID: <20080610071018.GD34459@freebie.xs4all.nl> Quoting Jerahmy Pocott, who wrote on Tue, Jun 10, 2008 at 03:58:37PM +1000 .. > Hello all, > > I'v been trying to get this dvd burner to burn, but there seems to be > something wrong with the driver for the controller or the drive.. > > On boot it is detected as: > acd0: DMA limited to UDMA33, controller found non-ATA66 cable > acd0: DVDR at ata0-master UDMA33 > > It is connected to: > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf irq 16 at device > 31.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > > The message that the controller found a non-ata66 cable is an error, > the cable is most certainly ata66 compatible and I'v switched it out > to make sure it wasn't faulty.. > > The drive is able to mount and read cds/dvds fine, but on trying to > use burncd it says: > acd0: FAILURE - READ_TRACK_INFO ILLEGAL REQUEST asc=0x24 ascq=0x00 > > Any further attempts produce the above message with no delay to read > from the drive, resetting the ata0 channel makes it check the drive > again before producing the message. > > On loading atapicam module it says: > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > > So I wasn't able to try cdrecord with it.. > > I also dropped it back ti PIO4 mode in case there was a DMA issue, but > I had the same results in PIO. > > Any more ideas? Are you sure the drive hardware is OK? I recently had this funny drive that could do everything except write. Very strange but true. -- Wilko Bulte wilko@FreeBSD.org From joe at zircon.seattle.wa.us Tue Jun 10 07:54:00 2008 From: joe at zircon.seattle.wa.us (Joe Kelsey) Date: Tue Jun 10 07:54:05 2008 Subject: DVD-RW doesn't write In-Reply-To: <36421019-B667-42FD-8069-98B7BFFED920@optusnet.com.au> References: <36421019-B667-42FD-8069-98B7BFFED920@optusnet.com.au> Message-ID: <484E2CD7.3070201@zircon.seattle.wa.us> Jerahmy Pocott wrote: > > On loading atapicam module it says: > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 I have never managed to use burncd with any drive. In order to use atapicam, you must enable the pass? devices. My devfs.conf contains: # Commonly used by many ports link acd0 cdrom link acd0 dvd # Allow a user in the wheel group to query the smb0 device #perm smb0 0660 perm xpt0 0660 perm pass0 0660 perm pass1 0660 The xpt0 is left over from other experiments. The pass? is required to allow general access to use of growisofs. /Joe From stefan.lambrev at moneybookers.com Tue Jun 10 08:12:07 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Tue Jun 10 08:12:12 2008 Subject: DVD-RW doesn't write In-Reply-To: <484E2CD7.3070201@zircon.seattle.wa.us> References: <36421019-B667-42FD-8069-98B7BFFED920@optusnet.com.au> <484E2CD7.3070201@zircon.seattle.wa.us> Message-ID: <484E3752.3030702@moneybookers.com> Joe Kelsey wrote: > Jerahmy Pocott wrote: >> >> On loading atapicam module it says: >> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > I have never managed to use burncd with any drive. > > In order to use atapicam, you must enable the pass? devices. My > devfs.conf contains: > > > # Commonly used by many ports > link acd0 cdrom > link acd0 dvd > > # Allow a user in the wheel group to query the smb0 device > #perm smb0 0660 > perm xpt0 0660 > perm pass0 0660 > perm pass1 0660 > > The xpt0 is left over from other experiments. The pass? is required > to allow general access to use of growisofs. Actually xpt is needed too :) I always find ports/sysutils/k3b/pkg-message one of the most helpful "howto" regarding atapicam and burning DVDs > > /Joe > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Best Wishes, Stefan Lambrev ICQ# 24134177 From freebsd-nospam at yaxom.com Tue Jun 10 08:30:04 2008 From: freebsd-nospam at yaxom.com (Greg Black) Date: Tue Jun 10 08:30:08 2008 Subject: DVD-RW doesn't write In-Reply-To: <484E2CD7.3070201@zircon.seattle.wa.us> References: <36421019-B667-42FD-8069-98B7BFFED920@optusnet.com.au> <484E2CD7.3070201@zircon.seattle.wa.us> Message-ID: On 2008-06-10, Joe Kelsey wrote: > I have never managed to use burncd with any drive. Just for the record, I've been using burncd successfully with a variety of drives from the early days of FreeBSD through to at least 7.0-R, so I doubt if the above means very much. Greg From johans at stack.nl Tue Jun 10 08:40:48 2008 From: johans at stack.nl (Johan van Selst) Date: Tue Jun 10 08:40:53 2008 Subject: DVD-RW doesn't write In-Reply-To: References: <36421019-B667-42FD-8069-98B7BFFED920@optusnet.com.au> <484E2CD7.3070201@zircon.seattle.wa.us> Message-ID: <20080610084044.GA19070@mud.stack.nl> Greg Black wrote: > On 2008-06-10, Joe Kelsey wrote: > > I have never managed to use burncd with any drive. > Just for the record, I've been using burncd successfully with a variety > of drives from the early days of FreeBSD through to at least 7.0-R, so I > doubt if the above means very much. I have had lots of problems with burncd as well: it works fine with some CD burners, not with others; and hardly ever with the (cheap) DVD drives that I use. However using atapicam and growisofs as outlined in http://www.freebsd.org/doc/en/books/handbook/creating-dvds.html works just fine with all my hardware. Ciao, Johan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 163 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080610/af366fea/attachment.pgp From eugen at kuzbass.ru Tue Jun 10 08:46:30 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Tue Jun 10 08:46:35 2008 Subject: DVD-RW doesn't write In-Reply-To: <20080610084044.GA19070@mud.stack.nl> References: <36421019-B667-42FD-8069-98B7BFFED920@optusnet.com.au> <484E2CD7.3070201@zircon.seattle.wa.us> <20080610084044.GA19070@mud.stack.nl> Message-ID: <20080610084626.GA19069@svzserv.kemerovo.su> On Tue, Jun 10, 2008 at 10:40:44AM +0200, Johan van Selst wrote: > I have had lots of problems with burncd as well: it works fine with some > CD burners, not with others; and hardly ever with the (cheap) DVD drives > that I use. However using atapicam and growisofs as outlined in > http://www.freebsd.org/doc/en/books/handbook/creating-dvds.html > works just fine with all my hardware. burncd burns CDs fine in RELENG_4. It was and is stll broken in all of RELENG_5 code, ATA maintainer refused to fix it there. It is fixed in RELENG_6, ELENG_7 and HEAD and burns CDs fine again. And yes, do not even think about burning DVDs with burncd, just use atapicam and growisofs. Eugene Grosbein From skip at menantico.com Tue Jun 10 10:10:07 2008 From: skip at menantico.com (Skip Ford) Date: Tue Jun 10 10:10:12 2008 Subject: DVD-RW doesn't write In-Reply-To: References: <36421019-B667-42FD-8069-98B7BFFED920@optusnet.com.au> <484E2CD7.3070201@zircon.seattle.wa.us> Message-ID: <20080610101305.GE858@menantico.com> Greg Black wrote: > On 2008-06-10, Joe Kelsey wrote: > > > I have never managed to use burncd with any drive. > > Just for the record, I've been using burncd successfully with a variety > of drives from the early days of FreeBSD through to at least 7.0-R, so I > doubt if the above means very much. I certainly used to use burncd(8) to burn anything on any drive, but it hasn't worked for me for years now. Last I knew, it was known to be broken for 5.0 with a fix in the works at some point after that, but I've checked occasionally since then with different drives and it's still never worked. Using atapicam(4) with burning tools from ports always works. -- Skip From jaj at hcl-club.lu Tue Jun 10 12:02:44 2008 From: jaj at hcl-club.lu (Jona Joachim) Date: Tue Jun 10 12:02:53 2008 Subject: pkg_delete core dump when removing linux-tiff In-Reply-To: <484DD565.2010700@FreeBSD.org> References: <484BE563.90102@FreeBSD.org> <20080610003222.GA3822@nirvana.my.domain> <484DD565.2010700@FreeBSD.org> Message-ID: <20080610120240.GA2964@nirvana.my.domain> On Tue, Jun 10, 2008 at 03:14:13AM +0200, Kris Kennaway wrote: > Jona Joachim wrote: > > On Sun, Jun 08, 2008 at 03:57:55PM +0200, Kris Kennaway wrote: > >> Jona Joachim wrote: > >>> Hi! > >>> > >>> pkg_delete core dumps on me when it tries to remove linux-tiff. > >>> I can reproduce this reliably. > >>> FWIW you can find the core dump here: > >>> http://www.hcl-club.lu/~jaj/stuff/pkg_delete.core > >> You need to obtain the backtrace, see the developers handbook. > > > > I built pkg_delete with -g but gdb says 'no debugging symbols found'. > > Is the following information sufficient or do I need to rebuild everything with debugging information turned on? > > It was probably stripped at install, I think you can set STRIP= (i.e. > empty value) but doesn't it also explain this in the handbook? Program received signal SIGSEGV, Segmentation fault. 0x48165a73 in strncmp () from /lib/libc.so.7 (gdb) bt #0 0x48165a73 in strncmp () from /lib/libc.so.7 #1 0x0804dad4 in delete_package (ign_err=0, nukedirs=0, pkg=0x8053540) at plist.c:462 #2 0x0804a91d in pkg_do (pkg=0x810b160 "linux-tiff-3.7.1") at perform.c:319 #3 0x08049f50 in pkg_perform (pkgs=0x8113068) at perform.c:112 #4 0x08049b93 in real_main (argc=1, argv=0xbfbfeb98) at main.c:145 #5 0x0804b0d5 in main (argc=2, argv=0xbfbfeb90) at pkgwrap.c:88 (gdb) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080610/c9139be4/attachment.pgp From koitsu at FreeBSD.org Tue Jun 10 12:42:45 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Jun 10 12:42:48 2008 Subject: pkg_delete core dump when removing linux-tiff In-Reply-To: <20080610120240.GA2964@nirvana.my.domain> References: <484BE563.90102@FreeBSD.org> <20080610003222.GA3822@nirvana.my.domain> <484DD565.2010700@FreeBSD.org> <20080610120240.GA2964@nirvana.my.domain> Message-ID: <20080610124245.GA42745@eos.sc1.parodius.com> On Tue, Jun 10, 2008 at 02:02:40PM +0200, Jona Joachim wrote: > On Tue, Jun 10, 2008 at 03:14:13AM +0200, Kris Kennaway wrote: > > Jona Joachim wrote: > > > On Sun, Jun 08, 2008 at 03:57:55PM +0200, Kris Kennaway wrote: > > >> Jona Joachim wrote: > > >>> Hi! > > >>> > > >>> pkg_delete core dumps on me when it tries to remove linux-tiff. > > >>> I can reproduce this reliably. > > >>> FWIW you can find the core dump here: > > >>> http://www.hcl-club.lu/~jaj/stuff/pkg_delete.core > > >> You need to obtain the backtrace, see the developers handbook. > > > > > > I built pkg_delete with -g but gdb says 'no debugging symbols found'. > > > Is the following information sufficient or do I need to rebuild everything with debugging information turned on? > > > > It was probably stripped at install, I think you can set STRIP= (i.e. > > empty value) but doesn't it also explain this in the handbook? > > Program received signal SIGSEGV, Segmentation fault. > 0x48165a73 in strncmp () from /lib/libc.so.7 > (gdb) bt > #0 0x48165a73 in strncmp () from /lib/libc.so.7 > #1 0x0804dad4 in delete_package (ign_err=0, nukedirs=0, pkg=0x8053540) at plist.c:462 > #2 0x0804a91d in pkg_do (pkg=0x810b160 "linux-tiff-3.7.1") at perform.c:319 > #3 0x08049f50 in pkg_perform (pkgs=0x8113068) at perform.c:112 > #4 0x08049b93 in real_main (argc=1, argv=0xbfbfeb98) at main.c:145 > #5 0x0804b0d5 in main (argc=2, argv=0xbfbfeb90) at pkgwrap.c:88 > (gdb) How about 'bt full' ? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jaj at hcl-club.lu Tue Jun 10 13:26:34 2008 From: jaj at hcl-club.lu (Jona Joachim) Date: Tue Jun 10 13:26:39 2008 Subject: pkg_delete core dump when removing linux-tiff In-Reply-To: <20080610124245.GA42745@eos.sc1.parodius.com> References: <484BE563.90102@FreeBSD.org> <20080610003222.GA3822@nirvana.my.domain> <484DD565.2010700@FreeBSD.org> <20080610120240.GA2964@nirvana.my.domain> <20080610124245.GA42745@eos.sc1.parodius.com> Message-ID: <20080610132629.GA15963@nirvana.my.domain> On Tue, Jun 10, 2008 at 05:42:45AM -0700, Jeremy Chadwick wrote: > On Tue, Jun 10, 2008 at 02:02:40PM +0200, Jona Joachim wrote: > > On Tue, Jun 10, 2008 at 03:14:13AM +0200, Kris Kennaway wrote: > > > Jona Joachim wrote: > > > > On Sun, Jun 08, 2008 at 03:57:55PM +0200, Kris Kennaway wrote: > > > >> Jona Joachim wrote: > > > >>> Hi! > > > >>> > > > >>> pkg_delete core dumps on me when it tries to remove linux-tiff. > > > >>> I can reproduce this reliably. > > > >>> FWIW you can find the core dump here: > > > >>> http://www.hcl-club.lu/~jaj/stuff/pkg_delete.core > > > >> You need to obtain the backtrace, see the developers handbook. > > > > > > > > I built pkg_delete with -g but gdb says 'no debugging symbols found'. > > > > Is the following information sufficient or do I need to rebuild everything with debugging information turned on? > > > > > > It was probably stripped at install, I think you can set STRIP= (i.e. > > > empty value) but doesn't it also explain this in the handbook? > > (snip bt) > > How about 'bt full' ? Here you go. linux-tiff depends on graphics/linux-jpeg, which isn't installed however. Something must have gone wrong there, I didn't pkg_delete -f linux-jpeg. GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) run linux-tiff-3.7.1 Starting program: /usr/sbin/pkg_delete linux-tiff-3.7.1 Program received signal SIGSEGV, Segmentation fault. 0x48165a73 in strncmp () from /lib/libc.so.7 (gdb) bt full #0 0x48165a73 in strncmp () from /lib/libc.so.7 No symbol table info available. #1 0x0804dad4 in delete_package (ign_err=0, nukedirs=0, pkg=0x8053540) at plist.c:462 p = 0x8119420 Where = 0x8111130 "/compat/linux" last_file = 0x8119440 "usr/share/man/man1/tiffsv.1.gz" fail = 4294967295 preserve = 0 tmp = "/compat/linux/usr/share/man/man1/tiffsv.1.gz\000gz\000\000\000DATE\000+REQUIRED_BY\0005\000\000¿\211\006\025HXØ\027Hüã¿¿\210ä¿¿ùõ\025H", '\0' , "È{\027H\224ã¿¿", '\0' , "\020\000\000\000\000\000\000\000ôã¿¿", '\0' , "¨Â\022\b\000\000\000\000\020\000\000\000\000\000\000\000ÿÿÿÿ\000\000\000\000ÒD\027H", '\0' , "\020\000\000\000\000\000\000\000\002", '\0' , "¬"... name = 0x810b200 "linux-tiff-3.7.1" prefix = 0x8111130 "/compat/linux" #2 0x0804a91d in pkg_do (pkg=0x810b160 "linux-tiff-3.7.1") at perform.c:319 cfile = (FILE *) 0x48190e80 deporigin = 0x810b360 "graphics/linux-jpeg" deporigins = (char **) 0x81111c0 depnames = (char **) 0x8113070 depmatches = (char ***) 0x8113078 home = "/usr/home/jaj\000\022\b\004\000\000\000D\214\rH\000\000\000\000üÿÿÿüÿÿÿüÿÿÿ\v\000\000\000\\:\022\b0\000\000\000\030\000\000\000\024\000\000\000\0249\022\b\0243\022\b$9\022\b\030\000\000\000\000\000\000\000D:\022\b`:\022\b(7\022\b47\022\b\f9\022\b\0249\022\b\0209\022\b\0309\022\bä2\022\bø8\022\bÄ2\022\bH:\022\b(7\022\bü8\022\bL3\022\b43\022\b(9\022\bÎÊ\004\bøP\022\bh\217\022\b\210â¿¿_\214\rH`:\022\bd:\022\b8ã¿¿Þ\027\025H`:\022\bd:\022\b\004\000\000\000D\214\rH"... p = 0x0 i = 2 len = 16 isinstalled = 1 new_m = 0 dep_count = 2 pre_script = 0x805005c "+DEINSTALL" post_script = 0x0 pre_arg = 0x0 post_arg = 0x0 rb_entry = (struct reqr_by_entry *) 0x8134080 rb_list = (struct reqr_by_head *) 0x8052240 __func__ = "pkg_do" #3 0x08049f50 in pkg_perform (pkgs=0x8113068) at perform.c:112 matched = (char **) 0x8112080 rb = (char **) 0x4807e000 rbtmp = (char **) 0x248 errcode = 0 i = 0 j = 9 err_cnt = 0 rb_entry = (struct reqr_by_entry *) 0x246 rb_list = (struct reqr_by_head *) 0x0 __func__ = "pkg_perform" #4 0x08049b93 in real_main (argc=1, argv=0xbfbfeb98) at main.c:145 ch = -1 error = 135332000 pkgs = (char **) 0xbfbfeb94 start = (char **) 0xbfbfeb90 pkgs_split = 0x0 tmp = 0x804fe53 "/var/db/pkg" stat_s = {st_dev = 101, st_ino = 16097, st_mode = 16877, st_nlink = 700, st_uid = 0, st_gid = 0, st_rdev = 66136, st_atimespec = {tv_sec = 1213102114, tv_nsec = 0}, st_mtimespec = {tv_sec = 1213043376, tv_nsec = 0}, st_ctimespec = {tv_sec = 1213043376, tv_nsec = 0}, st_size = 27648, st_blocks = 56, st_blksize = 4096, st_flags = 0, st_gen = 4026593762, st_lspare = 0, st_birthtimespec = {tv_sec = 1131005361, tv_nsec = 0}} #5 0x0804b0d5 in main (argc=2, argv=0xbfbfeb90) at pkgwrap.c:88 f = (FILE *) 0x0 buffer = " Ú\aH", '\0' , "kU\005HÄô\nHÄô\nH", '\0' , "ä(\aH\200\235\nH\000\000\000\000\000\000\000\000\002\000\002\000;S\005Hpò\aHxè¿¿\024è¿¿\223W\005H\236ô\nHü\234°\006\000ä\aH `\bH\001\000\000\000\000\000\000\000ä(\aH\234#\005H\000\000\000\000\000\000\000\000\000ä\aH4q\aH\000\000\000\000 þ\tH\224è¿¿×Y\005H\236ô\nHü\234°\006àt\aH `\bH\001\000\000\000\000à\aH\000â\aH\000ä\aH `\bH\000\000\000\000\000\000\000\000ä(\aHG·¡\nÜÜ\nH\000\235\nH"... cp = 0xbfbfeb68 "\210ë¿¿\223\230\004\b\002" verstr = 0x4814a252 "ÉÃS\213D$\b\212L$\f\220\212\0308Ùt\a@\204Ûuõ1À[Ã\220\220\220U\211åV\211Æ\017¾" len = 608 (gdb) The program is running. Exit anyway? (y or n) Oh and here is the content of /var/db/pkg/linux-tiff-3.7.1: total 40 -rw-r--r-- 1 root wheel 32 Mar 17 2007 +COMMENT -rw-r--r-- 1 root wheel 4098 Jun 8 14:21 +CONTENTS -rw-r--r-- 1 root wheel 229 Mar 17 2007 +DESC drwxr-xr-x 2 root wheel 512 Jun 9 11:05 . drwxr-xr-x 700 root wheel 27648 Jun 9 22:29 .. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080610/163b9068/attachment.pgp From koitsu at FreeBSD.org Tue Jun 10 13:48:41 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Jun 10 13:48:46 2008 Subject: pkg_delete core dump when removing linux-tiff In-Reply-To: <20080610132629.GA15963@nirvana.my.domain> References: <484BE563.90102@FreeBSD.org> <20080610003222.GA3822@nirvana.my.domain> <484DD565.2010700@FreeBSD.org> <20080610120240.GA2964@nirvana.my.domain> <20080610124245.GA42745@eos.sc1.parodius.com> <20080610132629.GA15963@nirvana.my.domain> Message-ID: <20080610134840.GA44581@eos.sc1.parodius.com> On Tue, Jun 10, 2008 at 03:26:30PM +0200, Jona Joachim wrote: > On Tue, Jun 10, 2008 at 05:42:45AM -0700, Jeremy Chadwick wrote: > > On Tue, Jun 10, 2008 at 02:02:40PM +0200, Jona Joachim wrote: > > > On Tue, Jun 10, 2008 at 03:14:13AM +0200, Kris Kennaway wrote: > > > > Jona Joachim wrote: > > > > > On Sun, Jun 08, 2008 at 03:57:55PM +0200, Kris Kennaway wrote: > > > > >> Jona Joachim wrote: > > > > >>> Hi! > > > > >>> > > > > >>> pkg_delete core dumps on me when it tries to remove linux-tiff. > > > > >>> I can reproduce this reliably. > > > > >>> FWIW you can find the core dump here: > > > > >>> http://www.hcl-club.lu/~jaj/stuff/pkg_delete.core > > > > >> You need to obtain the backtrace, see the developers handbook. > > > > > > > > > > I built pkg_delete with -g but gdb says 'no debugging symbols found'. > > > > > Is the following information sufficient or do I need to rebuild everything with debugging information turned on? > > > > > > > > It was probably stripped at install, I think you can set STRIP= (i.e. > > > > empty value) but doesn't it also explain this in the handbook? > > > > (snip bt) > > > > How about 'bt full' ? > > Here you go. > > linux-tiff depends on graphics/linux-jpeg, which isn't installed however. > Something must have gone wrong there, I didn't pkg_delete -f linux-jpeg. Thanks. A couple things: 1) Can you perform the same pkg_delete but with the -v flag? This should cause quite a bit more output, but will help track this down. 2) Output from cat /var/db/pkg/linux-tiff-3.7.1/+CONTENTS 3) Can you put the below files up someplace on the web, preferrably in a tarball? I'd ask for them, but the mailing list strips attachments. I'm wondering if there's some binary data in one of the files (e.g. interested in why +CONTENTS has a newer mtime than +COMMENT and +DESC). Have you had any filesystem problems as of late? dmesg -a show any filesystem issues or disk issues? > Oh and here is the content of /var/db/pkg/linux-tiff-3.7.1: > > total 40 > -rw-r--r-- 1 root wheel 32 Mar 17 2007 +COMMENT > -rw-r--r-- 1 root wheel 4098 Jun 8 14:21 +CONTENTS > -rw-r--r-- 1 root wheel 229 Mar 17 2007 +DESC > drwxr-xr-x 2 root wheel 512 Jun 9 11:05 . > drwxr-xr-x 700 root wheel 27648 Jun 9 22:29 .. The code in usr.sbin/pkg_install/lib/plist.c which is causing the segfault: 462 if (p->next && p->next->type == PLIST_COMMENT && !strncmp(p->next->name, "MD5:", 4)) { 4) What date are your system sources (specifically src/usr.sbin/pkg_install)? The reason I ask is that there were some recent speed optimisations applied to the pkg_* tools, and I'm curious what "version" of the sources you have. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jaj at hcl-club.lu Tue Jun 10 15:10:37 2008 From: jaj at hcl-club.lu (Jona Joachim) Date: Tue Jun 10 15:10:45 2008 Subject: pkg_delete core dump when removing linux-tiff In-Reply-To: <20080610134840.GA44581@eos.sc1.parodius.com> References: <484BE563.90102@FreeBSD.org> <20080610003222.GA3822@nirvana.my.domain> <484DD565.2010700@FreeBSD.org> <20080610120240.GA2964@nirvana.my.domain> <20080610124245.GA42745@eos.sc1.parodius.com> <20080610132629.GA15963@nirvana.my.domain> <20080610134840.GA44581@eos.sc1.parodius.com> Message-ID: <20080610151033.GA1415@nirvana.my.domain> On Tue, Jun 10, 2008 at 06:48:40AM -0700, Jeremy Chadwick wrote: > On Tue, Jun 10, 2008 at 03:26:30PM +0200, Jona Joachim wrote: > > On Tue, Jun 10, 2008 at 05:42:45AM -0700, Jeremy Chadwick wrote: > > > On Tue, Jun 10, 2008 at 02:02:40PM +0200, Jona Joachim wrote: > > > > On Tue, Jun 10, 2008 at 03:14:13AM +0200, Kris Kennaway wrote: > > > > > Jona Joachim wrote: > > > > > > On Sun, Jun 08, 2008 at 03:57:55PM +0200, Kris Kennaway wrote: > > > > > >> Jona Joachim wrote: > > > > > >>> Hi! > > > > > >>> > > > > > >>> pkg_delete core dumps on me when it tries to remove linux-tiff. > > > > > >>> I can reproduce this reliably. > > > > > >>> FWIW you can find the core dump here: > > > > > >>> http://www.hcl-club.lu/~jaj/stuff/pkg_delete.core > > > > > >> You need to obtain the backtrace, see the developers handbook. > > > > > > > > > > > > I built pkg_delete with -g but gdb says 'no debugging symbols found'. > > > > > > Is the following information sufficient or do I need to rebuild everything with debugging information turned on? > > > > > > > > > > It was probably stripped at install, I think you can set STRIP= (i.e. > > > > > empty value) but doesn't it also explain this in the handbook? > > > > > > (snip bt) > > > > > > How about 'bt full' ? > > > > Here you go. > > > > linux-tiff depends on graphics/linux-jpeg, which isn't installed however. > > Something must have gone wrong there, I didn't pkg_delete -f linux-jpeg. > > Thanks. A couple things: > > 1) Can you perform the same pkg_delete but with the -v flag? This > should cause quite a bit more output, but will help track this down. > > 2) Output from cat /var/db/pkg/linux-tiff-3.7.1/+CONTENTS > > 3) Can you put the below files up someplace on the web, preferrably in a > tarball? I'd ask for them, but the mailing list strips attachments. > I'm wondering if there's some binary data in one of the files (e.g. > interested in why +CONTENTS has a newer mtime than +COMMENT and +DESC). You can find it all in there: http://www.hcl-club.lu/~jaj/stuff/pkg_delete-segv.tar.gz > Have you had any filesystem problems as of late? dmesg -a show any > filesystem issues or disk issues? No, I didn't have any disk issues I'm aware of. dmesg -a doesn't show anything suspect. > > Oh and here is the content of /var/db/pkg/linux-tiff-3.7.1: > > > > total 40 > > -rw-r--r-- 1 root wheel 32 Mar 17 2007 +COMMENT > > -rw-r--r-- 1 root wheel 4098 Jun 8 14:21 +CONTENTS > > -rw-r--r-- 1 root wheel 229 Mar 17 2007 +DESC > > drwxr-xr-x 2 root wheel 512 Jun 9 11:05 . > > drwxr-xr-x 700 root wheel 27648 Jun 9 22:29 .. > > The code in usr.sbin/pkg_install/lib/plist.c which is causing the > segfault: > > 462 if (p->next && p->next->type == PLIST_COMMENT && !strncmp(p->next->name, "MD5:", 4)) { The last line of +CONTENTS has an @comment line with no MD5 following. On Jun 8 (timestamp of +CONTENTS) I was doing a portupgrade -a. > 4) What date are your system sources (specifically > src/usr.sbin/pkg_install)? The reason I ask is that there were some > recent speed optimisations applied to the pkg_* tools, and I'm curious > what "version" of the sources you have. My sources are pretty much up to date. I have the latest changes flz@ checked in one week ago into pkg_install. From jfvogel at gmail.com Tue Jun 10 16:51:53 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Jun 10 16:52:05 2008 Subject: Vlan EVENT patch Message-ID: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> This is a small patch that Sam came up with for me, it will allow drivers to know when a vlan attaches. It is transparent to any code that doesn't want to change, but this will allow my drivers to finally utilize the vlan hardware filter (something Linux has had for ever but we lacked). My test group has done some basic testing of this and it is working great. But we wanted to give any vlan users a chance to see, ask questions, or whatever before its committed. Jack From scf at FreeBSD.org Tue Jun 10 17:17:27 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Tue Jun 10 17:17:34 2008 Subject: Environment clearing broken in 7.0 In-Reply-To: <1213071257.3904.991.camel@hurina> References: <1213036854.3904.967.camel@hurina> <1213071257.3904.991.camel@hurina> Message-ID: On Tue, 10 Jun 2008, Timo Sirainen wrote: > On Mon, 2008-06-09 at 22:27 -0500, Sean C. Farley wrote: >> On Mon, 9 Jun 2008, Timo Sirainen wrote: >> >>> I think clearing environment using: >>> >>> environ[0] = NULL; >>> >>> has been kind of a semi-standard for a while now. At least Dovecot >>> and Postfix clears their environment this way. But this no longer >>> works in FreeBSD 7.0 (putenv(), environ[0]=NULL, putenv() -> >>> everything is visible again). Was this change intended, or will this >>> be fixed? >> >> It is more or less intended. When a program sets an environment >> variable, the environment is copied for faster/leaner usage. >> Changing individual values within environ is not checked else every >> pointer would need to be checked for consistency. What I did was to >> write the code to detect if environ is replaced (NULL or new array of >> variables). > > OK, so perhaps Sendmail's way of clearing environment would be the > best solution: > > static char *emptyenv[1] = { NULL }; > environ = emptyenv; That works too. >> I suggest reading the two paragraphs from Open Group's getenv()[1] >> documentation starting at "Conforming applications are required not >> to modify environ directly, ..." for the rationale in the new design. >> Obviously, applications are not required to conform, but the >> documentation talks about what an OS may be doing under the covers to >> environ. > > How about implementing clearenv()? I'm using it now if it's available. It is a thought. It is not part of SUSv3, but there are many API calls in our libc that are not part of that spec. Interestingly, clearenv() on Linux ends up setting environ=NULL. Also, from the Linux man page: The DG/UX and Tru64 manpages write: If environ has been modified by anything other than the putenv(), getenv(), or clearenv() functions, then clearenv() will return an error and the process environment will remain unchanged. Hopefully, no libraries on these systems are manipulating environ else clearenv() will not work. >> Out of curiosity, do Dovecot and Postfix check that environ is not >> NULL before setting environ[0]? environ may be set to NULL at the >> start but not by FreeBSD's /usr/bin/env -i. > > Yes, both check if it's NULL. (I think I originally copied my code's > logic from Postfix.) Good. I asked because I could see myself making that mistake awhile back before I truly understood how environ interacted with applications from start (exec()) to finish. >>> Looks like I could work around this by using: >>> >>> environ = NULL; >> >> That will work on the *BSD's, OpenSolaris and Linux. > > But not on OS X. It crashes there. Grrrr. >> Also, this will work: >> environ = calloc(1, sizeof(*environ)); > > Is this any better than using a static emptyenv[1]? Not exactly but see below about Haiku as an example. > BTW. I wonder if this change breaks any applications where not > clearing environment could result in a security hole. As far as I know > FreeBSD 7.0 is the only modern OS where environ[0]=NULL doesn't work. OpenSolaris also does not detect environ[0]=NULL. Haiku[1], like MacOS, does not handle environ=NULL. *sigh* To support the most OS's I recommend the environ replacement such as in the static environ above. IMHO, mixing direct usage of the internals of environ and calling *env() is not safe. I really wish that environ could not be touched directly by any application. To be safe with all implementations of environ, I recommend using a method that replaces environ with a NULL terminated array such as you have with emptyenv. This will work on all platforms. Oops! Actually, it may break on Haiku since it will realloc() environ if it has copied environ previously with a call to putenv(), setenv() or unsetenv(). No guarantees, but I will do some research about detecting a NULL at environ[0] as another means of clearing the environment and/or writing an implementation of clearenv(). Of course, you will still have problems on OpenSolaris. What are you planning to do there, or does it support cleanenv()? Does anyone know why clearenv() was rejected? There is hardly a peep on the OpenGroup web site. To consolidate the notes: environ = NULL does not work on: 1. MacOS/Darwin 2. Haiku environ[0] = NULL does not work on: 1. FreeBSD 7+ 2. OpenSolaris static char *emptyenv[1] = { NULL }; environ = emptyenv; does not work on: 1. Haiku 2. MacOS? environ = calloc(1, sizeof(*environ)); should work on all assuming NULL was not returned. cleanenv() works on all systems that support it with caveats concerning: 1. DG/UX and Tru64 Sean 1. http://dev.haiku-os.org/browser/haiku/trunk/src/system/libroot/posix/stdlib/env.c -- scf@FreeBSD.org From jimpc at geihoma.demon.co.uk Tue Jun 10 17:20:56 2008 From: jimpc at geihoma.demon.co.uk (Jim McGuire) Date: Tue Jun 10 17:21:00 2008 Subject: pkg-config Message-ID: <20080610164527.GA1008@geihoma.demon.co.uk> yesterday, as a newbie in his dotage, i was trying to get packages, re cups, under freebsd 7.0... got the message that pkg-config later than 0.22, which is available in packages, was needed... please advise of any workaround.... but should not packages be internally consistent? From nakal at web.de Tue Jun 10 17:26:49 2008 From: nakal at web.de (Martin) Date: Tue Jun 10 17:26:54 2008 Subject: DVD-RW doesn't write In-Reply-To: References: <36421019-B667-42FD-8069-98B7BFFED920@optusnet.com.au> <484E2CD7.3070201@zircon.seattle.wa.us> Message-ID: <20080610185521.1560974b@zelda.local> Am Tue, 10 Jun 2008 18:03:21 +1000 schrieb Greg Black : > Just for the record, I've been using burncd successfully with a > variety of drives from the early days of FreeBSD through to at least > 7.0-R, so I doubt if the above means very much. Hi. I have 2 drives here that don't work properly. Burning CDs/DVDs is quite broken on both of them. First drive (LG HL-DT-ST DVDRAM GSA-4167B DL13): I can burn a CD with 5x as maximal speed. cdrecord reports something about DMA not working as expected. A can be burnt, too, but also very slow. Most drives have difficulties to read a DVD burnt with this drive. One workaround would be to enable burnfree, but this results in the DVD being unreadable. I have severe problems playing DVD movies (originals!). Even trying to insert such a DVD results in extreme slow system, load going up through the ceiling so that my mouse cursor does not move anymore. Forcing an eject will crash the whole system. Second drive is the one in my Thinkpad T60p: I can burn CDs. Also only very slowly. I can burn DVDs but they will be unreadable everywhere. Systems are: FreeBSD-7-STABLE i386 and amd64. I had problems with CD/DVD burning since 5.2 AFAIR somewhere in RC phase. I reported them and till now waiting patiently for corrections ;) New is that playing movies can make your system unusable. I just wanted to say "Me too!". -- Thanks, Martin From scf at FreeBSD.org Tue Jun 10 17:28:05 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Tue Jun 10 17:28:10 2008 Subject: DVD-RW doesn't write In-Reply-To: <36421019-B667-42FD-8069-98B7BFFED920@optusnet.com.au> References: <36421019-B667-42FD-8069-98B7BFFED920@optusnet.com.au> Message-ID: On Tue, 10 Jun 2008, Jerahmy Pocott wrote: *snip* > The drive is able to mount and read cds/dvds fine, but on trying to > use burncd it says: > acd0: FAILURE - READ_TRACK_INFO ILLEGAL REQUEST asc=0x24 ascq=0x00 > > Any further attempts produce the above message with no delay to read > from the drive, resetting the ata0 channel makes it check the drive > again before producing the message. > > On loading atapicam module it says: > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > > So I wasn't able to try cdrecord with it.. I had problems with burncd and my DVD drive when burning CD-RW's. When I tried atapicam and cdrecord, it gave me problems. I believe it was using burncd prior to atapicam that caused it because it works now if I do not use burncd first. You could try a reboot and use atapicam first; the DVD drive may be in a funny state. Just a guess. Sean -- scf@FreeBSD.org From jfvogel at gmail.com Tue Jun 10 17:30:37 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Jun 10 17:30:42 2008 Subject: Vlan EVENT patch In-Reply-To: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> References: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> Message-ID: <2a41acea0806101030xa9f0689k663709a4595b1771@mail.gmail.com> On 6/10/08, Jack Vogel wrote: > This is a small patch that Sam came up with for me, it will allow > drivers to know > when a vlan attaches. > > It is transparent to any code that doesn't want to change, but this > will allow my > drivers to finally utilize the vlan hardware filter (something Linux has had > for > ever but we lacked). > > My test group has done some basic testing of this and it is working great. > But we wanted to give any vlan users a chance to see, ask questions, or > whatever before its committed. > > Jack > Sigh, sorry, here's the actual patch :) Jack -------------- next part -------------- A non-text attachment was scrubbed... Name: vlan.patch Type: text/x-patch Size: 1394 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080610/08448448/vlan.bin From tss at iki.fi Tue Jun 10 17:37:08 2008 From: tss at iki.fi (Timo Sirainen) Date: Tue Jun 10 17:37:12 2008 Subject: Environment clearing broken in 7.0 In-Reply-To: References: <1213036854.3904.967.camel@hurina> <1213071257.3904.991.camel@hurina> Message-ID: <1213119395.3904.1047.camel@hurina> On Tue, 2008-06-10 at 12:17 -0500, Sean C. Farley wrote: > >> I suggest reading the two paragraphs from Open Group's getenv()[1] > >> documentation starting at "Conforming applications are required not > >> to modify environ directly, ..." for the rationale in the new design. > >> Obviously, applications are not required to conform, but the > >> documentation talks about what an OS may be doing under the covers to > >> environ. > > > > How about implementing clearenv()? I'm using it now if it's available. > > It is a thought. It is not part of SUSv3, but there are many API calls > in our libc that are not part of that spec. > > Interestingly, clearenv() on Linux ends up setting environ=NULL. Also, > from the Linux man page: > > The DG/UX and Tru64 manpages write: If environ has been modified by > anything other than the putenv(), getenv(), or clearenv() functions, > then clearenv() will return an error and the process environment > will remain unchanged. > > Hopefully, no libraries on these systems are manipulating environ else > clearenv() will not work. I don't think there's any other reason to do it than clearing it. > > BTW. I wonder if this change breaks any applications where not > > clearing environment could result in a security hole. As far as I know > > FreeBSD 7.0 is the only modern OS where environ[0]=NULL doesn't work. > > OpenSolaris also does not detect environ[0]=NULL. Haiku[1], like MacOS, > does not handle environ=NULL. *sigh* To support the most OS's I > recommend the environ replacement such as in the static environ above. Oh. I don't have OpenSolaris installed, but I would have thought that since it worked in Solaris 10 it would have worked in OpenSolaris too. > No guarantees, but I will do some research about detecting a NULL at > environ[0] as another means of clearing the environment and/or writing > an implementation of clearenv(). Of course, you will still have > problems on OpenSolaris. What are you planning to do there, or does it > support cleanenv()? I've changed my code now to do: > environ = calloc(1, sizeof(*environ)); should work on all assuming NULL > was not returned. Hopefully that'll work for a few years. (I also use clearenv() if detected by configure.) > Does anyone know why clearenv() was rejected? There is hardly a peep > on > the OpenGroup web site. No idea, but I don't really understand why it returns int instead of void. It shouldn't do more than free memory. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080610/48cd6e5c/attachment.pgp From dick at nagual.nl Tue Jun 10 18:56:26 2008 From: dick at nagual.nl (Dick Hoogendijk) Date: Tue Jun 10 18:56:31 2008 Subject: Closing the Jo Rhett argument In-Reply-To: <86021481-1BCB-4E16-8DD5-EC14B8597C10@netconsonance.com> References: <484DBBE7.6080908@zircon.seattle.wa.us> <86021481-1BCB-4E16-8DD5-EC14B8597C10@netconsonance.com> Message-ID: <20080610205610.00002cbe@westmark> On Mon, 9 Jun 2008 17:52:24 -0700 Jo Rhett wrote: > The first time mention of BETA and RC cycles came up was in his > reply to me, which was full of personal insults and attacks like the > following, so I discarded it without reply: > > > I see no reason to assume competence on your part since you have > > demonstrated no competence. > ... > > I don't need to assume anything about you. You have demonstrated > > your idiocy to everyone on the list. Please keep your insane > > rants to yourself in the future. If the above quotes are true, the writer should be ashamed of himself. Your POV has stirred some dust ;-) But to call you names is weird. BTW ever meet a sane person? And, did you like it? Whatever my pov on you issues are I don't think people should start insulting one another. -- Dick Hoogendijk -- PGP/GnuPG key: 01D2433D ++ http://nagual.nl/ + SunOS sxde 01/08 ++ From liste.bsd at gmail.com Tue Jun 10 19:51:59 2008 From: liste.bsd at gmail.com (Daniele Bastianini) Date: Tue Jun 10 19:52:04 2008 Subject: broken re(4) In-Reply-To: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> Message-ID: Il giorno 27/mag/08, alle ore 16:52, Gerrit K?hn ha scritto: > Hi folks, > > I have four identical ITX boards from Jetway here, each having two > re(4) > onboard nics: > > re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec > rev=0x10 > hdr=0x00 vendor = 'Realtek Semiconductor' > device = 'RTL8169/8110 Family Gigabit Ethernet NIC' > class = network > subclass = ethernet > re1@pci0:0:11:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec > rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' > device = 'RTL8169/8110 Family Gigabit Ethernet NIC' > class = network > subclass = ethernet > atapci0@pci0:0:15:0: class=0x01018f card=0x31491106 chip=0x31491106 > rev=0x80 > > > I run FreeBSD 7-stable from early March 08 on three of these > machines and noticed no problems with networking with that so far. > Some days ago I installed a fourth machine with 7-stable from early > May > (and some days later -because of the problems described below- to May > 17th). With this new machine I see several networking problems. The > most > prominent are these two: > > - heavy networking traffic (in this case backup via tar & NFS) > causes hangs > for about 10s-30s and sometimes also leads to watchdog timeouts: > May 27 09:04:07 protoserve kernel: re0: watchdog timeout > May 27 09:04:07 protoserve kernel: re0: link state changed to DOWN > May 27 09:04:10 protoserve kernel: re0: link state changed to UP > > - copying large files (more than some 100MB) via ssh/scp drops the > connection due to "corrupted MAC on input": > Disconnecting: Corrupted MAC on input. > lost connection I had the same problem. I fixed it (for now) making a buildworld with *default date=2008.03.01.00.00.00 in my src csup configuration. I'm not so skilled to investigate in the sources but the problem is after this date. Regards Daniele Bastianini From bermejator at hotmail.com Wed Jun 11 00:27:23 2008 From: bermejator at hotmail.com (Ruben Lara) Date: Wed Jun 11 00:27:28 2008 Subject: /usr/obj/usr/src/tmp/usr/bin/ld: crti.o: No such file Message-ID: Hi, While make buildworld to upgrade: BerMeJo% uname -a FreeBSD BERMEJO-BSD 7.0-RELEASE FreeBSD 7.0-RELEASE #2: Fri Mar 14 20:46:53 CET 2008 root@BERMEJO-BSD:/usr/obj/usr/src/sys/BERMEJO-BSD i386 Get next error: ..... cc -fpic -DPIC -O -pipe -march=athlon-mp -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c crypt_xdr.c -o crypt_xdr.So building static c library building special pic c library building shared library libc.so.7 ranlib libc_pic.a ranlib libc.a /usr/obj/usr/src/tmp/usr/bin/ld: crti.o: No such file: No such file or direct error *** Error code 2 1 error *** Error code 2 1 error BerMeJo% Anybody can help me? Thank you in advance. Rub?n Lara BerMeJo _________________________________________________________________ MSN Video. http://video.msn.com/?mkt=es-es From pyunyh at gmail.com Wed Jun 11 01:04:37 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Jun 11 01:04:42 2008 Subject: broken re(4) In-Reply-To: References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> Message-ID: <20080611010223.GB3529@cdnetworks.co.kr> On Tue, Jun 10, 2008 at 09:26:44PM +0200, Daniele Bastianini wrote: > > Il giorno 27/mag/08, alle ore 16:52, Gerrit K?hn ha scritto: > > >Hi folks, > > > >I have four identical ITX boards from Jetway here, each having two > >re(4) > >onboard nics: > > > >re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec > >rev=0x10 > >hdr=0x00 vendor = 'Realtek Semiconductor' > > device = 'RTL8169/8110 Family Gigabit Ethernet NIC' > > class = network > > subclass = ethernet > >re1@pci0:0:11:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec > >rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' > > device = 'RTL8169/8110 Family Gigabit Ethernet NIC' > > class = network > > subclass = ethernet > >atapci0@pci0:0:15:0: class=0x01018f card=0x31491106 chip=0x31491106 > >rev=0x80 > > > > > >I run FreeBSD 7-stable from early March 08 on three of these > >machines and noticed no problems with networking with that so far. > >Some days ago I installed a fourth machine with 7-stable from early > >May > >(and some days later -because of the problems described below- to May > >17th). With this new machine I see several networking problems. The > >most > >prominent are these two: > > > >- heavy networking traffic (in this case backup via tar & NFS) > >causes hangs > >for about 10s-30s and sometimes also leads to watchdog timeouts: > >May 27 09:04:07 protoserve kernel: re0: watchdog timeout > >May 27 09:04:07 protoserve kernel: re0: link state changed to DOWN > >May 27 09:04:10 protoserve kernel: re0: link state changed to UP > > > >- copying large files (more than some 100MB) via ssh/scp drops the > >connection due to "corrupted MAC on input": > >Disconnecting: Corrupted MAC on input. > >lost connection > > I had the same problem. > I fixed it (for now) making a buildworld with > *default date=2008.03.01.00.00.00 in my src csup configuration. > > I'm not so skilled to investigate in the sources but the problem is > after this date. > I guess you're using RELENG_7. Would you try a WIP in the following URL? http://people.freebsd.org/~yongari/re/re.HEAD.20080610 Please also make sure to post dmesg output related with re(4). -- Regards, Pyun YongHyeon From dennis_flynn at yahoo.com Wed Jun 11 03:47:01 2008 From: dennis_flynn at yahoo.com (Dennis Flynn) Date: Wed Jun 11 03:47:06 2008 Subject: FreeBSD 7.0 Stable and the CP2101 driver Message-ID: <437286.30504.qm@web54011.mail.re2.yahoo.com> I/m new to FreeBSD (but not Unix in general) and I am setting up an embedded server to acquire data from a weather station. The data comes from the weather station console via the USB port on the server. The USB device is a Silicon Labs CP2102 USB to UART Bridge Controller. Apparently this driver has been added to FreeBSD 7.0-STABLE - http://people.freebsd.org/~bmah/relnotes/7-STABLE/relnotes.html. I tried installing the update, e.g. "freebsd-update -r 7.0-STABLE fetch", then "freebsd-update -r 7.0-STABLE upgrade". Seemed to work. But I do not seem to have the device driver loaded when I plug in the USB device. I get the folowwing in the messages log: Jun 10 16:48:02 wx kernel: ugen0: on uhub0 But I don't see a device that I think I should see, like /dev/ttyU0. If I do a "uname -a" I see the following: FreeBSD wx.dennis-flynn.net 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 That doesn't seem right to me. Shouldn't I see something like 7.0-RELEASE-p1 or 7.0-STABLE? Did I do something wrong in my update to RELEASE? How do I know if I'm running the STABLE kernel with the driver I want? How can I tell if the driver (uslcom) is there and/or loaded? Thanks in advance for all help. -Dennis Dennis Flynn Home Work From chat95 at mac.com Wed Jun 11 05:37:01 2008 From: chat95 at mac.com (Maho NAKATA) Date: Wed Jun 11 05:37:06 2008 Subject: Auto bridge for qemu network In-Reply-To: <6601D6DC-AD09-4028-A25A-59899C9A57E4@gmail.com> References: <20080513054223.2CAC95B4B@mail.bitblocks.com> <6601D6DC-AD09-4028-A25A-59899C9A57E4@gmail.com> Message-ID: <20080611.143518.232910747.chat95@mac.com> From: bazzoola Subject: Auto bridge for qemu network [was: kqemu support: not compiled] Date: Thu, 15 May 2008 03:06:25 -0400 > Thanks for updating the port! > > I have few suggestions: > > #cat /etc/rc.conf > [...] > #KQEMU for qemu > kqemu_enable="YES" > > #Bridge for qemu > cloned_interfaces="bridge0" > ifconfig_bridge0="up addm sk0" > autobridge_interfaces="bridge0" > autobridge_bridge0="tap*" > > This should take care of the network connection between qemu virtual > host and the host instead of doing it manually. Assuming that qemu is > using tap and the default "if" on the host is sk0. > > Also, is it possible to update this page, it has some outdated info: > http://people.freebsd.org/~maho/qemu/qemu.html > *It is the 1st answer from google when asked "freebsd qemu" > Thanks and sorry for inconvenience. bazzoola had already asked me to create a wiki. Now I have some time to do so. I created an account long before, but I cannot edit. Of course I've already asked this issue simon@. -- Nakata Maho http://accc.riken.jp/maho/ From jcw at highperformance.net Wed Jun 11 05:40:22 2008 From: jcw at highperformance.net (Jason C. Wells) Date: Wed Jun 11 05:40:27 2008 Subject: FreeBSD 7.0 Stable and the CP2101 driver In-Reply-To: <437286.30504.qm@web54011.mail.re2.yahoo.com> References: <437286.30504.qm@web54011.mail.re2.yahoo.com> Message-ID: <484F5D80.1000803@highperformance.net> Dennis Flynn wrote: > That doesn't seem right to me. Shouldn't I see something like > 7.0-RELEASE-p1 or 7.0-STABLE? Did I do something wrong in my update > to RELEASE? How do I know if I'm running the STABLE kernel with the > driver I want? How can I tell if the driver (uslcom) is there and/or > loaded? To tell if a driver is loaded: dmesg | grep uslcom You'll also want to know about kldstat(1). I've never used freebsd-update. I do suspect that the standard MO in FreeBSD land is to _not_ update the kernel unless explicitly requested. You might want to snoop around the docs with that in mind. Also, FreeBSD may support your driver, but not build it into the GENERIC kernel by default. If the driver you want does not appear in the GENERIC kernel, then you will have to compile a kernel or load a kernel module. There is good documentation on building a kernel in the handbook. Regards, Jason From gerrit at pmp.uni-hannover.de Wed Jun 11 07:25:01 2008 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Wed Jun 11 07:25:06 2008 Subject: broken re(4) In-Reply-To: <3C916EEA-5A2B-4C88-B834-0F47D7D525FA@gmail.com> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <3C916EEA-5A2B-4C88-B834-0F47D7D525FA@gmail.com> Message-ID: <20080611092457.82c83083.gerrit@pmp.uni-hannover.de> On Tue, 10 Jun 2008 20:43:04 +0200 Daniele Bastianini wrote about Re: broken re(4): DB> > - copying large files (more than some 100MB) via ssh/scp drops the DB> > connection due to "corrupted MAC on input": DB> > Disconnecting: Corrupted MAC on input. DB> > lost connection DB> I had the same problem. DB> I fixed it (for now) making a buildworld with DB> *default date=2008.03.01.00.00.00 in my src csup configuration. DB> I'm not so skilled to investigate in the sources but the problem is DB> after this date. For me all versions from cvs and all patches from Pyun are working now, after I have solved the issue with the bad riser card. I still think it's funny that the riser causes this kind of trouble for the networking chips. On the other hand, I have not been able to get more than about 10MByte/s through the interfaces of this particular system. I have 1GBit-networking equipment, and the other systems (which are used as router) have no problem doing a throughput of >20MB/s. Even bonding the two interfaces using lagg(4) does not improve the performance - where else could be the bottleneck? The only difference here is that I have the extra SATA-controller with disks in there. However, the disks appear to be as fast as I can expect from a SATA150-interface. cu Gerrit From pyunyh at gmail.com Wed Jun 11 07:35:25 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Jun 11 07:35:37 2008 Subject: Vlan EVENT patch In-Reply-To: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> References: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> Message-ID: <20080611073313.GF3529@cdnetworks.co.kr> On Tue, Jun 10, 2008 at 09:51:53AM -0700, Jack Vogel wrote: > This is a small patch that Sam came up with for me, it will allow > drivers to know > when a vlan attaches. > > It is transparent to any code that doesn't want to change, but this > will allow my > drivers to finally utilize the vlan hardware filter (something Linux has had for > ever but we lacked). > Just curious, is there any rule how to use that new capability? Because drivers will receive events whenever VLAN tags are added/removed they would know how to act for these events. If promiscuous mode is on for interface, driver should not filter any VLAN tagged frames, right? If users want to disable VLAN hardware filtering feature what is best way to perform this? Introducing a new flag like IFCAP_VLAN_HWFILT or add a new sysctl that control this feature? I guess VIA Rhine III also have VLAN hardware filtering capability so it would be even better if we have a way to share common part. > My test group has done some basic testing of this and it is working great. > But we wanted to give any vlan users a chance to see, ask questions, or > whatever before its committed. > > Jack -- Regards, Pyun YongHyeon From mav at FreeBSD.org Wed Jun 11 09:36:17 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Jun 11 09:36:21 2008 Subject: Crashes in devfs. Possibly on interface creation/destruction. In-Reply-To: <20080605110447.GB94309@deviant.kiev.zoral.com.ua> References: <48470853.6080807@FreeBSD.org> <20080605110447.GB94309@deviant.kiev.zoral.com.ua> Message-ID: <484F9C8E.1080202@FreeBSD.org> Kostik Belousov wrote: > Try the following patch. It is against current, there might be further > races at the device destruction, but may be not. Also, please note that > devfs in RELENG_6 and RELENG_7/CURRENT are diverged enough to make MFC > of most bugfixes to RELENG_6 nearly impossible. > > diff --git a/sys/kern/kern_conf.c b/sys/kern/kern_conf.c > index e9d0f7b..af9a47d 100644 > --- a/sys/kern/kern_conf.c > +++ b/sys/kern/kern_conf.c > @@ -825,9 +825,9 @@ make_dev_alias(struct cdev *pdev, const char *fmt, ...) > va_end(ap); > > devfs_create(dev); > + dev_dependsl(pdev, dev); > clean_unrhdrl(devfs_inos); > dev_unlock(); > - dev_depends(pdev, dev); > > notify_create(dev); Looks reasonable. For RELENG_6 it also applies with minor differences. Put it to the production. As soon as problem shows itself not very often, positive result probably will be seen only after several weeks of successive operation. Thank you. -- Alexander Motin From lists at lozenetz.org Wed Jun 11 10:09:41 2008 From: lists at lozenetz.org (Anton - Valqk) Date: Wed Jun 11 10:09:46 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com> References: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com> Message-ID: <484FA07E.60103@lozenetz.org> Just my 5cents (some thoughts), I fully agree with the lines below. As noticed below there is more attention to developing new features, than making releases rock solid stable. As mentioned in reply posts the 3 branches 6.X 7.X and 8.X takes too many resources and is very hard to support. I, personally, will be waiting for 7.2 release (noticed that .2 over few (3-4 years)) are most stable ones. My main drama with FreeBSD is that ports don't have -SECURITY patches, and if I there is a bug in php I have to rerbuild and populate the latest version. Another _very important_ thing is that there is no binary support to packages that has vulns, and you have to rebuild them from ports. Just a simple example: I have 4-5 fbsd machines and about 15-20 debian stable machines. To administer fbsd machines when there are ports bugs(bugs in ports I use) it takes me at least about 4times more time than update _all_ debian machines... Well...I have other things to do too, too many... now guess what I will choose? I'll use debian, and that's not because I don't have will to use freebsd, it's simply because I do my tasks 4 times slower than when I choose debian. Someone will say "FreeBSD is not for you, then back off". That's not the point, I like fbsd, but as more busy I get, as less I'll be able to use it, takes too much of my time. Once I've told that there is no binary support (but I didn't expressed myself correctly). There is no ports VULNS binary support. If there is (and I've never heard of it), I'll be very happy someone to point me out this, because I'll continue running fbsd. Ah, another thing, I'm waiting for virtualization networking layer for jails for quite long. I've tested it on a test server, worked perfect, but on production I don't want to patch my base. there are few other features to jals that never got commited in base, and as I said I don't want to patch it... in linux (debian for me) there is xen that works with 'new' intel hardware virtualization, that's another red point for debian.... there are other things that I'll leave unsaid....so... that's all for now. sorry for my bad english, it's not my native. these are just my thoughts and don't want to force anyone to agree with them, but I'll be happy to read your thoughts on this. cheers, valqk. Andy Kosela wrote: > On 6/8/08, Freddie Cash wrote: > >>> On 6/7/08, Jo Rhett wrote: >>> The question I raised is simply: given the number of bugs opened and >>> fixed since 6.3-RELEASE shipped, why is 6.3 the only supported >>> version? Why does it make sense for FreeBSD to stop supporting a >>> stable version and force people to choose between two different >>> unstable versions? Is this really the right thing to do? >>> >> Define the terms "stable" and "unstable", how you measure said >> "stability" and "instability", and what you are comparing them >> against. >> > > This whole discussion is really interesting as it clearly showcases two > common trends in computing (rapid development vs stability) On the one > side we got people (let's call them developers or computer scientists) > who are more interested in development than stabilization of the existing > code base. It's natural for them to think more about new features, > researching new ideas and implementing them. It resembles an > academic project, research project.Those computer scientists do not > care much about stability, they are mainly interested in hacking on the > code for the fun of it. It is open source after all as someone wisely > remarked. From my own experience most if not all community based > projects are more interested in following this trend than stabilization of > the code. Although they do care about stability of their code base, their > focus is more on implementing new features and moving rapidly forward. > In today's quickly changing world we see this trend as prevailing. > > On the other hand though, there is a trend which focuses on maximum > long term stabilization of the code base. Usually we see this trend in high > end commercial companies serving the needs of mission critical > businesses where even a minute of downtime can cause loss of > thousands of dollars or even loss of lives of people (imagine stock > exchanges, banks, financial & insurance institutions, army and police > facilities, hospitals, nuclear plants etc.). Those types of > businesses/institutions truly needs a maximum stable operating system. > They really do not care about "new features", but they do care about > maximum stability of the existing code, security, and nonstop business > continuity even in the face of natural disasters. There is only one operating > system I know of that survived 9/11 attacks - this is OpenVMS. > It's not uncommon to see VMS uptimes of more than 10 years (you can ask > Amsterdam police for evidence). Now that is a true stability! On the other > note though, stability is the direct opposition of development and change. > Something which is *stable* cannot change or must change very slowly in > the long term. On the other hand something which is changing rapidly cannot > by the very definition of it be stable but rather is...unstable. Plato said it > very wisely in Timaeus: "What is that which always is and has no becoming; > and what is that which is always becoming and never is?". In other words > one could say - what is that which is always the same and stable and what > is that which is always changing and is unstable? This elaborate thinking > is directly connected even with the trends in todays computing. When the > code base is changing rapidly and quickly you cannot say it's very stable. > Something stable is always something heavy tested and unchanging. > > So on the one hand we got users like Jo who wants long term stabilization, > who depends on FreeBSD to run their mission critical systems, and on the > other the developers who are more interested in the *development* than > maintaining and supporting older releases for many years. I got to agree > with the developers -this is open source project with limited resources. In > order to offer long term support the whole focus of the project would have > to be changed - and you can't force people to do something they don't want > to do in the open source world. > It's more fun to work on implementing new code, than squashing bugs or > fanatically audit the code in search of security flaws in old releases. The > open source is moving very rapidly forward and it's not only FreeBSD. Look > at Linux. There is more than 10,000 messages each month on LKML. > Kernel.org peoples also do not care much about stability (recent problems > with vanilla kernels do support my thesis) - they commit so fast and massively > that it becomes real hard to maintain this "beast" even for seasoned hackers. > But someone who is sane will not be using kernel.org kernels in mission critical > production environments but rather commercial distro kernels like Red Hat's > versions. Also they won't be using 8-CURRENT on production systems either. > Those are more research projects than operating environments for data > centers. But when Red Hat is taking kernel.org kernel and put it out as part > of their distro they give 7 (read: seven) years support for that particular > kernel, userland and any third party application they support. They backport > all security and bug fixes to the "so called" stable release during those seven > years. That is a long time in the open source world, as in the general > computing world. They can do this because they have resources for > that - they are operating as a commercial company. > > In FreeBSD even if you upgraded cleanly base system (this is very easy > and fast now with freebsd-update(8)) there is always problem with ports. > I'm perfectly aware that developers are more focused on the base system > and ports are served on "as is" basis but most of the production systems > deployed worldwide are using ports and depends on them most of their time. > I also understand ports team in saying that there is no resources to have > many branches of ports tree at the same time, but this little example will > show that in the long term sometimes things are not working very smoothly > for people who are running mission critical systems. Let's say some > hypothetical 6.x-RELEASE comes out in January. The Apache port is > freezed at hypothetical 2.0.40 version. Now in April someone discloses > some very critical security flaw which affects all versions of Apache prior > to 2.0.43. Now what you can do? You can update your Apache port to > 2.0.43 fixing a security hole. But at the same time you don't know the > upstream team changed dramatically some internal things in code, added > tons of new features and at the same time introduced a ton of new bugs > and possibly new security flaws which will be founded at a later time. > Those changes in code can also very well break your applications which > depended on the specific code in 2.0.40 version. So you are left with > headaches and backup tapes (of course you would first test the upgrade > process on the test machines). But my issue here is that ports really do > not offer real stability for mission critical systems who often depends for > years on specific versions of particular software (like banks). Red Hat in > that case backports new security patches to those old stable versions and > it seems it is some solution for such businesses. Of course I know there is > no resources for creating supported -SECURITY branch of ports tree which > would backport those patches. > > FreeBSD has always been known for its legendary stability and mature > code base which is why many commercial companies depend on it every > day. "The anomaly" as someone said of long term support for 4.x releases > only helped to see FreeBSD as more stable and viable solution than Linux by > many businesses. Mission critical systems needs long term support (read: at > least backporting security patches) and stable systems that can run for years > without interruption. When it comes to stability vs development maybe there is > time to rethink FreeBSD overall strategy and goals. Major companies using > FreeBSD in their infrastructure like Yahoo! or Juniper Networks would > definetly benefit from such moves focused on long term support of stable > releases. I honestly think it is in their interest to support, even financially > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From mh at kernel32.de Wed Jun 11 11:44:10 2008 From: mh at kernel32.de (Marian Hettwer) Date: Wed Jun 11 11:44:14 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3 In-Reply-To: <484FA07E.60103@lozenetz.org> References: <484FA07E.60103@lozenetz.org> Message-ID: Hi there, some thoughts to your problem in regards to Debian administration time needed vs. FreeBSD administration time needed. I believe I can make a point there, since I have 600 debian boxes under my hood but still am a FreeBSD advocate ;-) On Wed, 11 Jun 2008 12:53:02 +0300, Anton - Valqk wrote: > > My main drama with FreeBSD is that ports don't have -SECURITY patches, > and if I there is a bug in php > I have to rerbuild and populate the latest version. Thats unfortunatly true. But there is a way around. As soon as you have several FreeBSD boxes, I'd advise you to install your own FreeBSD box for packages building. So if you need to update your php installations, go to your build box (which has the very same versions of programs installed as your production boxes), update your ports tree and do a "make package" of your new php port. If the new php package works fine on your build box, roll it out via "pkg_add -r $NEWPHPTHINGY" and off you go. > Another _very important_ thing is that there is no binary support to > packages that has vulns, > and you have to rebuild them from ports. > Well, its one time doing a make package... Even debian has no plus point there (at least in our environment at work). We pretty much always need our Apache 2 custom build, not the way the Debian projects build it. Thus we have a Debian build box around and build our own Apache 2.2 package. This is, indeed, the same amount of effort you would have when using FreeBSD. IMO the overhead in Debian to build a package is higher than in FreeBSD, but YMMV. > Just a simple example: > I have 4-5 fbsd machines and about 15-20 debian stable machines. > To administer fbsd machines when there are ports bugs(bugs in ports I > use) it takes me at > least about 4times more time than update _all_ debian machines... depends on the way you go. Genereally speaking, you really really want a build and test machine before you deploy a security update or even a new version of your software (in this case: php). Even with Debian boxes you really shouldn't just "apt-get upgrade && apt-get update" but test before! > Well...I have other things to do too, too many... now guess what I will > choose? > I'll use debian, and that's not because I don't have will to use > freebsd, it's simply because I do my tasks 4 times slower than when I > choose debian. hhmm... I really can't agree on that statement. If you do your admin work in a clean and sane way, most of the time spend for updating boxes is spent on testing the change before upgrading. The difference between a "debuild" for building a new package, and then apt-get upgrade / update them on your box vs. "make package" and pkg_add -r them on your box is really slim... > Someone will say "FreeBSD is not for you, then back off". That's not the I wouldn't say that :) > > Once I've told that there is no binary support (but I didn't expressed > myself correctly). There is no ports VULNS binary support. > If there is (and I've never heard of it), I'll be very happy someone to > point me out this, because I'll continue running fbsd. > If you take a close look onto how the debian project is backporting security fixes you would probably agree that pretty often it's more desireable to jump to a newer version of that software than instead just security fixing it. Examples needed? MySQL 4.1.11 was the "stable" MySQL 4.1 in Debian Sarge. Of course it got security fixed, but not bugfixed. You get a secure version of MySQL 4.1 in Debian but not a stable one, because important bugfixes are missing. I'd rather upgrade to the latest MySQL 4.1.xx instead. And of course, do your testing before jumping version numbers. I hope that my impressions will help you in working with FreeBSD in a server environment. Cheerio, Marian From andy.kosela at gmail.com Wed Jun 11 12:36:32 2008 From: andy.kosela at gmail.com (Andy Kosela) Date: Wed Jun 11 12:36:38 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3 In-Reply-To: References: <484FA07E.60103@lozenetz.org> Message-ID: <3cc535c80806110536w1c8af6efq8d5470ce6de8cb38@mail.gmail.com> Robert, Thank you for your insights. I think that this agreement between users and developers does occur. The proper balance between rapid development vs long term stability is the platform through which such agreement can be achieved. It's up to the Core Team to reasonably steer the Project in such a way as to achieve the greatest results. FreeBSD has always been focused on creating simple, stable and reliable operating system for system administrators and let's keep it that way. Longer term support for -RELEASE gives many companies a stable platform to develop and maintain their infrastructure. I think 5 years support for major FreeBSD release (like major 6 or 7) would be really perfect for many of us. On Wed, Jun 11, 2008 at 1:26 PM, Marian Hettwer wrote: > But there is a way around. As soon as you have several FreeBSD boxes, I'd > advise you to install your own FreeBSD box for packages building. > So if you need to update your php installations, go to your build box > (which has the very same versions of programs installed as your production > boxes), update your ports tree and do a "make package" of your new php > port. > If the new php package works fine on your build box, roll it out via > "pkg_add -r $NEWPHPTHINGY" and off you go. I think Anton raised a valid and reasonable point here by analyzing my previous statements. Every data center environment test the upgrade process before deploying it on production machines, but my point circulated around the whole different theme. Backporting Backporting security and bug fixes to *STABLE* versions of ports would definetly render the whole ports framework infrastructure more solid and trustworthy for organizations that need mission critical stable and reliable environment to work in. Creating -SECURITY branch of ports tree with support *just* for common server applications like apache, postfix, mysql or vsftpd (definetly not for all available ports) would very well encourage more companies now stuck with the only alternative (redhat/centos or debian) to trust this ports tree branch in deploying their applications which very often needs specific versions of the software to run properly. Right now it's sometimes very risky to jump to the latest available upstream version as it very often breaks compatibility with older versions. I've been toying with the idea to create such -SECURITY branch, at least just for ports I use extensively. I'm not aware of no such project (open source, commercial) that is doing that. I'm curious how many people out there would be also interested in such an idea. > If you take a close look onto how the debian project is backporting > security fixes you would probably agree that pretty often it's more > desireable to jump to a newer version of that software than instead just > security fixing it. > Examples needed? > MySQL 4.1.11 was the "stable" MySQL 4.1 in Debian Sarge. Of course it got > security fixed, but not bugfixed. You get a secure version of MySQL 4.1 in > Debian but not a stable one, because important bugfixes are missing. > I'd rather upgrade to the latest MySQL 4.1.xx instead. > And of course, do your testing before jumping version numbers. Redhat/CentOS is more reliable here as backports involves both security and bug fixes, plus even new hardware enhancements. -- Andy Kosela ora et labora From olli at lurza.secnetix.de Wed Jun 11 15:26:33 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed Jun 11 15:26:36 2008 Subject: broken re(4) In-Reply-To: <20080611092457.82c83083.gerrit@pmp.uni-hannover.de> Message-ID: <200806111526.m5BFQT2p059130@lurza.secnetix.de> Gerrit K?hn wrote: > On the other hand, I have not been able to get more than about 10MByte/s > through the interfaces of this particular system. I have 1GBit-networking > equipment, and the other systems (which are used as router) have no > problem doing a throughput of >20MB/s. Even bonding the two interfaces > using lagg(4) does not improve the performance - where else could be the > bottleneck? A few questions or hints ... - What is the CPU usage during your network test (user, sys, intr, idle)? - Do you see errors in "netstat -i"? - Do you use jumbo frames? - Is polling enabled? - Are there any network-related sysctls (/etc/sysctl.conf) or kernel settings? Have you enabled kernel debugging features (INVARIANTS, WITNESS etc.)? - Do you have any packet filter rules (PF, IPF, IPFW)? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is the only current language making COBOL look good." -- Bertrand Meyer From gerrit at pmp.uni-hannover.de Wed Jun 11 15:37:59 2008 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Wed Jun 11 15:38:04 2008 Subject: broken re(4) In-Reply-To: <200806111526.m5BFQT2p059130@lurza.secnetix.de> References: <20080611092457.82c83083.gerrit@pmp.uni-hannover.de> <200806111526.m5BFQT2p059130@lurza.secnetix.de> Message-ID: <20080611173755.e381fcf0.gerrit@pmp.uni-hannover.de> On Wed, 11 Jun 2008 17:26:29 +0200 (CEST) Oliver Fromme wrote about Re: broken re(4): OF> > On the other hand, I have not been able to get more than about OF> > 10MByte/s through the interfaces of this particular system. I have OF> > 1GBit-networking equipment, and the other systems (which are used OF> > as router) have no problem doing a throughput of >20MB/s. Even OF> > bonding the two interfaces using lagg(4) does not improve the OF> > performance - where else could be the bottleneck? OF> A few questions or hints ... OF> - What is the CPU usage during your network test (user, OF> sys, intr, idle)? I will test and report that tomorrow. OF> - Do you see errors in "netstat -i"? None. OF> - Do you use jumbo frames? No. OF> - Is polling enabled? No. I tested polling on a lot of different machines earlier and never found it to improve performance so far (same for jumbo frames, btw). OF> - Are there any network-related sysctls (/etc/sysctl.conf) OF> or kernel settings? Have you enabled kernel debugging OF> features (INVARIANTS, WITNESS etc.)? No, stock GENERIC, only with a lot of things disabled. OF> - Do you have any packet filter rules (PF, IPF, IPFW)? No, not on this machine. The faster machines are router/firewalls, they do filtering; so it should be something different... cu Gerrit From jack at jarasoft.net Wed Jun 11 15:39:20 2008 From: jack at jarasoft.net (Jack Raats) Date: Wed Jun 11 15:39:33 2008 Subject: FreeBSD 7 and Apache 1.3.41 PROBLEM Message-ID: <087EAA726CFA4573BF9B39E69A5F3AE8@jarasoft.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On a server I was running FreeBSD 6.3-STABLE together with apache 1.3.41 without any problem. After upgrading FreeBSD to FreeBSD 7.0-STABLE using a source upgrade, compiling, and a full recompile of all the ports apache refuses to start, or starts and exits with a .core dump. In httpd-error.log [Wed Jun 11 17:01:04 2008] [info] mod_unique_id: using ip addr 10.10.10.10 [Wed Jun 11 17:01:05 2008] [info] (2)No such file or directory: make_sock: for port 80, setsockopt: (SO_ACCEPTFILTER) [Wed Jun 11 17:01:05 2008] [warn] pid file /var/run/httpd.pid overwritten -- Unclean shutdown of previous Apache run? After hashing out #LoadModule unique_id_module libexec/apache/mod_unique_id.so #AddModule mod_unique_id.c Apache starts normally Can anyone explain this? Jack -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) - GPGrelay v0.959 iD8DBQFIT+8bPh5RwW/NzC4RAn9aAKCVKIvHFmFzpeaveqvHYbXjIRrhuACg0vxr f5f3FDGYigHPRaqGz+ZkDok= =TZvG -----END PGP SIGNATURE----- From rwatson at FreeBSD.org Wed Jun 11 15:49:51 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Jun 11 15:49:57 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <484FA07E.60103@lozenetz.org> References: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com> <484FA07E.60103@lozenetz.org> Message-ID: <20080611164704.J40102@fledge.watson.org> On Wed, 11 Jun 2008, Anton - Valqk wrote: > I fully agree with the lines below. > As noticed below there is more attention to developing new features, > than making releases rock solid stable. ... > Ah, another thing, > I'm waiting for virtualization networking layer for jails for quite long. > I've tested it on a test server, worked perfect, but on production I don't > want to patch my base. > there are few other features to jals that never got commited in base, and as > I said I don't want to patch it... The reason that the virtualization patches aren't in the tree is precisely *because* we care about stability and are willing to slow down feature development in order to accomplish it. Some features take years to stabilize, and just because a patch works OK in your environment doesn't mean it will work in everyone's. Moderating the rate at which we adopt agressive new features is part of an intentional strategy to avoid letting development trees destabilize to a point where it's unproductive. Robert N M Watson Computer Laboratory University of Cambridge From lists at lozenetz.org Wed Jun 11 15:51:09 2008 From: lists at lozenetz.org (Anton - Valqk) Date: Wed Jun 11 15:51:19 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3 In-Reply-To: References: <484FA07E.60103@lozenetz.org> Message-ID: <484FF461.6000306@lozenetz.org> Thanks for the answer! I'm glad someone answered me a human way, because two times before, I wasn't answered that way (well... my posts were angry and incomplete but...that's why i didn't continued to post...my bad). now on topic: Marian Hettwer wrote: > Hi there, > > some thoughts to your problem in regards to Debian administration time > needed vs. FreeBSD administration time needed. > I believe I can make a point there, since I have 600 debian boxes under my > hood but still am a FreeBSD advocate ;-) > > > On Wed, 11 Jun 2008 12:53:02 +0300, Anton - Valqk > wrote: > >> My main drama with FreeBSD is that ports don't have -SECURITY patches, >> and if I there is a bug in php >> I have to rerbuild and populate the latest version. >> > Thats unfortunatly true. > But there is a way around. As soon as you have several FreeBSD boxes, I'd > advise you to install your own FreeBSD box for packages building. > So if you need to update your php installations, go to your build box > (which has the very same versions of programs installed as your production > boxes), update your ports tree and do a "make package" of your new php > port. > If the new php package works fine on your build box, roll it out via > "pkg_add -r $NEWPHPTHINGY" and off you go. > > I do have a build server(well a jail but works for me), also I have test eviornment (jailed too). I use this jail to build all my pkgs and use pkg_add -r (sweeet!!). For most of the ports this works, but sometimes something in make package breaks and i get a port installed partially (last case - apache22 got installed but no /usr/local/etc/rc.d/apache22 rc script, previous - pg_ctl never got installed) and in +CONTENTS file the missing files claimed to be there. I've had to rebuild that kind of port so I can install it again (after pkg_delete) to have the port working. This happens most often when I do make install package-recursive (so I can get all needed ports installed). I've tried to tell this in ports@ and I was answered that "everything is working for us" or kind of. no one tried to investigate... Another strange thing is that when I use php-extensions to build all that I need (this takes most of my time when build/install new php) breaks because of the ?'bug'? described few lines above. as I said noone got interested in this problem... I have another complain from fbsd but I'll tell about it at the end. >> Another _very important_ thing is that there is no binary support to >> packages that has vulns, >> and you have to rebuild them from ports. >> >> > Well, its one time doing a make package... > Even debian has no plus point there (at least in our environment at work). > We pretty much always need our Apache 2 custom build, not the way the > Debian projects build it. Thus we have a Debian build box around and build > our own Apache 2.2 package. > This is, indeed, the same amount of effort you would have when using > FreeBSD. > IMO the overhead in Debian to build a package is higher than in FreeBSD, > but YMMV. > If you build packages from source then debian just sux (much more complex and long procedure), but there is a tell - "if you do it with debian - do it THE DEBIAN WAY"... :-). I totally agree with that, but on all debian machines I use packages provided from debian, because they've made it very modular, and I was able to config them the way I need and everything is working for me. In 99.99% of the cases when I do apt-get dist-upgrade the machine works like a charm after it, and that's a fact (in fbsd when make installworld too, but not for ports - which is the focus here). Actually that's what *BSD prouds with - building everything from source (like gentoo), well it's a must to be simplified then (debian where everything is supposed to be used from bin .deb) :). About the bug fixes, I think if that's a SECURITY backport it shouldn't fix bugs, because I've saw few devs deploying an app and the were using 'known bug' in ruby to work with. so they were unable to use higher version of ruby that got this bug fixed. (we'll obviously a developer mistake in design but if it's in a production will take months to redesign - not an option). Which is why maybe it's better not to fix bugs but just vulns in SECURITY backports (according to me of course) - if you need that bug fixed, then install new version. > > >> Just a simple example: >> I have 4-5 fbsd machines and about 15-20 debian stable machines. >> To administer fbsd machines when there are ports bugs(bugs in ports I >> use) it takes me at >> least about 4times more time than update _all_ debian machines... >> > depends on the way you go. > Genereally speaking, you really really want a build and test machine before > you deploy a security update or even a new version of your software (in > this case: php). > Even with Debian boxes you really shouldn't just "apt-get upgrade && > apt-get update" but test before! > > >> Well...I have other things to do too, too many... now guess what I will >> choose? >> I'll use debian, and that's not because I don't have will to use >> freebsd, it's simply because I do my tasks 4 times slower than when I >> choose debian. >> > hhmm... I really can't agree on that statement. > If you do your admin work in a clean and sane way, most of the time spend > for updating boxes is spent on testing the change before upgrading. The > difference between a "debuild" for building a new package, and then apt-get > upgrade / update them on your box vs. "make package" and pkg_add -r them on > your box is really slim... > > If you build from src on debian - yes, but as I explained i use debian .debs and for me it's much faster, because on fbsd ports I have the problem described before, and is very common case to rebuild and rebuild port until it puts all the files in the .tgz :( >> Someone will say "FreeBSD is not for you, then back off". That's not the >> > I wouldn't say that :) > > >> Once I've told that there is no binary support (but I didn't expressed >> myself correctly). There is no ports VULNS binary support. >> If there is (and I've never heard of it), I'll be very happy someone to >> point me out this, because I'll continue running fbsd. >> >> > If you take a close look onto how the debian project is backporting > security fixes you would probably agree that pretty often it's more > desireable to jump to a newer version of that software than instead just > security fixing it. > Examples needed? > MySQL 4.1.11 was the "stable" MySQL 4.1 in Debian Sarge. Of course it got > security fixed, but not bugfixed. You get a secure version of MySQL 4.1 in > Debian but not a stable one, because important bugfixes are missing. > I'd rather upgrade to the latest MySQL 4.1.xx instead. > And of course, do your testing before jumping version numbers. > > I hope that my impressions will help you in working with FreeBSD in a > server environment. > > Cheerio, > Marian So, a story happened recently: I've had a disk down (ad2) of course it was in gmirror and the situation was 'ah, damn, but it's ok'... but... when I rebooted the server it occured that ad2 was ACTIVE and maybe last fresh and ad0 was DIRTY, ad2 didn't failed at 100% it was responding and found by the bios (and kernel) but when files were requested it timed out. The problem occured when tried to boot from the second disk (ad0) attached with ad2 (at this moment i didn't know that it fails when disk io occurs). because the ad2 was fresh and ad0 was dirty the gmirror failed to mount and boot OS because it was trying to sync data from partly failed disk, and it wasn't able to. I've shutdowned the machine, plugged out the ad2 disk and fired up again hoping gmirror will be smart enough to boot from ad0... but no luck, I was forced to mount root filesystem with no mirror (ad0s1a) and run the server in no mirror mode so I can have this critical machine running while I find a new disk (few hours later I got it). And the nightmare's just began... when I placed the new disk, the gmirrored volume was still trying to sync from ad2, ofcourse, the ad2 had no info on it (thanks god gmirror was smart enough to not copy the empty disk). I've had to rebuild the whole gmirror partiions, copy the info from a non-mirrored disk (ad0) and etc.etc... you know the procedure... this took me more than 10 hours and about 5hours downtime on a critical machine.... I suppose this has something to do with the priority in gmirror but I don't have the broken disk to test - it's being replaced because it's in warranty.... but anyways... 10 hours lost and 5hours downtime... now I'm purchaseing a 3ware hw raid because I know that I can't trust gmirror... Another strange thing, I've used to use apache22-worker cutom compiled and thread_safe perl, the apache-worker stopped working on a jail (only on one!) and I had to add replacements ot pthread.so in /etc/libmap, I've been adviced not to use worker (as I did) but why the heck after upgrading from 6.3-STABLE to 6.3-STABLE-p3 I got my apache broken and also cron stopped working. strange uh? and all this is in only one jail (I'm using ez-jail to update the world)... if anyone can help me to fix my cron without reinstalling this jail I'd be thanksful! too long mail, that's enough :) cheers, valqk. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From rwatson at FreeBSD.org Wed Jun 11 15:54:03 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Jun 11 15:54:08 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3 In-Reply-To: <3cc535c80806110536w1c8af6efq8d5470ce6de8cb38@mail.gmail.com> References: <484FA07E.60103@lozenetz.org> <3cc535c80806110536w1c8af6efq8d5470ce6de8cb38@mail.gmail.com> Message-ID: <20080611165009.O40102@fledge.watson.org> On Wed, 11 Jun 2008, Andy Kosela wrote: > Redhat/CentOS is more reliable here as backports involves both security and > bug fixes, plus even new hardware enhancements. In the FreeBSD environment, we call the place that gets a blend of security and bug fixes, plus new minor feature and driver enhancements "-STABLE", and the releases that pick up these changes "point releases". They happen more requently and with less risk than major releases, but still see enough development to represent functional improvements. I guess here's my concern: we offer a spectrum of choice for "I want the most bleeding edge" to "I want no feature changes, just security fixes", and several points in between. We can argue about the exact placement of this points, but the reality is that the balance we have today seems to work well for many developers and users, and reflects a fairly carefully planned use of the available revision control and distribution technology. The place for volunteers to come in is where they see an obvious niche for improvement -- for example, a few years ago this guy named Colin Percival turned up with a binary update system. After a couple of years of enhancement, breaking it in, etc, it's now a standard tool for maintaining FreeBSD systems, and he's our security officer. Similar opportunities exist for offering easier updates to packages, etc, but require people who have a clear need and the technical ability to do the work to turn up and do it. Robert N M Watson Computer Laboratory University of Cambridge From koitsu at FreeBSD.org Wed Jun 11 15:54:21 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Jun 11 15:54:24 2008 Subject: FreeBSD 7 and Apache 1.3.41 PROBLEM In-Reply-To: <087EAA726CFA4573BF9B39E69A5F3AE8@jarasoft.net> References: <087EAA726CFA4573BF9B39E69A5F3AE8@jarasoft.net> Message-ID: <20080611155420.GA65168@eos.sc1.parodius.com> On Wed, Jun 11, 2008 at 05:28:26PM +0200, Jack Raats wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On a server I was running FreeBSD 6.3-STABLE together with apache 1.3.41 without any problem. > > After upgrading FreeBSD to FreeBSD 7.0-STABLE using a source upgrade, compiling, and a full recompile of all the ports apache refuses to start, or starts and exits with a .core dump. > > In httpd-error.log > [Wed Jun 11 17:01:04 2008] [info] mod_unique_id: using ip addr 10.10.10.10 > [Wed Jun 11 17:01:05 2008] [info] (2)No such file or directory: make_sock: for port 80, setsockopt: (SO_ACCEPTFILTER) > [Wed Jun 11 17:01:05 2008] [warn] pid file /var/run/httpd.pid overwritten -- Unclean shutdown of previous Apache run? > > After hashing out > #LoadModule unique_id_module libexec/apache/mod_unique_id.so > #AddModule mod_unique_id.c > > Apache starts normally > > Can anyone explain this? If by "this" you're referring to the setsockopt() error, yes. If by "this" you're referring to the coredump, no, not without more information. The problem in your error logs indicate some sort of issue relating to the accept filter in FreeBSD, which Apache can use (accf_http). I don't think Apache 1.3.x has this functionality (rc-script-wise), but on 2.2.x on RELENG_6, we use this in rc.conf to load the accept module prior to Apache starting: apache22_http_accept_enable="yes" You can try loading the module yourself using "kldload accf_http.ko", then restarting (stop/start, not graceful or restart!) Apache. P.S. -- I've removed freebsd-questions@ from the CC, since cross- posting is looked down upon. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jespasac at minibofh.org Wed Jun 11 16:07:09 2008 From: jespasac at minibofh.org (Jordi Espasa Clofent) Date: Wed Jun 11 16:07:16 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <48481A02.2050502@minibofh.org> References: <4846B64F.4090700@minibofh.org> <484775D4.4090509@p6m7g8.com> <48481A02.2050502@minibofh.org> Message-ID: <484FF478.8010405@minibofh.org> It seems a php-extensions bug. If you comment the mhash.so in /usr/local/etc/php/extensions.ini as: ;entension=mhash.so all works fine and you don't get anymore httpd crash (signal 11) if you use 'apachectl graceful'. Maybe will be a good idea to open PR for this? I hope it helps someone.... (I'm very surprised that this isn't a documented bug in 7.0 yet) -- Thanks, Jordi Espasa Clofent From koitsu at FreeBSD.org Wed Jun 11 16:10:48 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Jun 11 16:10:56 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <484FF478.8010405@minibofh.org> References: <4846B64F.4090700@minibofh.org> <484775D4.4090509@p6m7g8.com> <48481A02.2050502@minibofh.org> <484FF478.8010405@minibofh.org> Message-ID: <20080611161048.GA66773@eos.sc1.parodius.com> On Wed, Jun 11, 2008 at 05:51:20PM +0200, Jordi Espasa Clofent wrote: > It seems a php-extensions bug. > If you comment the mhash.so in /usr/local/etc/php/extensions.ini as: > > ;entension=mhash.so > > all works fine and you don't get anymore httpd crash (signal 11) if you > use 'apachectl graceful'. > > Maybe will be a good idea to open PR for this? > > I hope it helps someone.... (I'm very surprised that this isn't a > documented bug in 7.0 yet) Many people have reported that the *order* of the extensions in extensions.ini has adverse (positive) effects on PHP segfaults on FreeBSD. I myself haven't ever run into extension ordering issues like those described (and we've done hosting for years), but I don't doubt those who have experienced such. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From mh at kernel32.de Wed Jun 11 16:17:34 2008 From: mh at kernel32.de (Marian Hettwer) Date: Wed Jun 11 16:17:40 2008 Subject: CLARITY re: challenge: end of life for 6.2 is prematurewithbuggy 6.3 In-Reply-To: <484FF461.6000306@lozenetz.org> References: <484FF461.6000306@lozenetz.org> Message-ID: On Wed, 11 Jun 2008 18:50:57 +0300, Anton - Valqk wrote: > Thanks for the answer! > I'm glad someone answered me a human way, > because two times before, I wasn't answered that way > (well... my posts were angry and incomplete but...that's why i didn't > continued to post...my bad). > Well then, lets continue answering in a human way. Which is, funnily enough, usually the more productive way too ;-) > now on topic: > yeah! >> Thats unfortunatly true. >> But there is a way around. As soon as you have several FreeBSD boxes, > I'd >> advise you to install your own FreeBSD box for packages building. >> So if you need to update your php installations, go to your build box >> (which has the very same versions of programs installed as your > production >> boxes), update your ports tree and do a "make package" of your new php >> port. >> If the new php package works fine on your build box, roll it out via >> "pkg_add -r $NEWPHPTHINGY" and off you go. >> >> > I do have a build server(well a jail but works for me), also I have test > eviornment (jailed too). > I use this jail to build all my pkgs and use pkg_add -r (sweeet!!). > For most of the ports this works, but sometimes something in make > package breaks and i get a port installed partially > (last case - apache22 got installed but no /usr/local/etc/rc.d/apache22 > rc script, previous - pg_ctl never got installed) > and in +CONTENTS file the missing files claimed to be there. hm... sounds like a bug to me. On the other hand, you have to try to get it to be reproducable. If it's a one timer then yes, it's annoying, but really really hard to reproduce and therefor to fix. > I've had to rebuild that kind of port so I can install it again (after > pkg_delete) to have the port working. yeah, annoying. > This happens most often when I do make install package-recursive (so I > can get all needed ports installed). If you can reproduce it step by step, it may be worth posting to ports@ again with what you did and what happened. Either you're doing something wrong, or something is broken. However, it needs to be reproducable. At least in your environment. As a starter, so to say :) The more detailed your steps are written down, the more likely someone will either follow those steps or give you a direct hint on "humm, could be something bad over there... hm hm). > Another strange thing is that when I use php-extensions to build all > that I need (this takes most of my time when build/install new php) > breaks because of the ?'bug'? described few lines above. as I said noone > got interested in this problem... I can't say anything specific about the php problem you said. I'm not using php, or well, very rarely. I'll give it a try to update it the make package way next time. Unluckily this is a one-box only system. hmmm... If I find the time to test, I'll drop you mail. But time is rare (admin life vs. normal life). To cut that short: Yeah, I can understand that this is annoying. But I'm sure as hell: - if it's a bug it can be fixed - if it's a user error, it can be changed - and all this has happened to me when trying to build my own debian packages too ;) And it happened to me with Gentoo, too. Nothing new at all. Just the regular annoyances in sysadmins life. IMO :) >>> Another _very important_ thing is that there is no binary support to >>> packages that has vulns, >>> and you have to rebuild them from ports. >>> >>> >> Well, its one time doing a make package... >> Even debian has no plus point there (at least in our environment at > work). >> We pretty much always need our Apache 2 custom build, not the way the >> Debian projects build it. Thus we have a Debian build box around and > build >> our own Apache 2.2 package. >> This is, indeed, the same amount of effort you would have when using >> FreeBSD. >> IMO the overhead in Debian to build a package is higher than in FreeBSD, >> but YMMV. >> > If you build packages from source then debian just sux (much more > complex and long procedure), but there is a tell - "if you do it with > debian - do it THE DEBIAN WAY"... :-). I am doing it the debian way. Using the debian source package and try to update from there. Still its a more complex procedure then upgrading a FreeBSD port. I just can't use the prebuilt debian packages. So where's the Debian way from that point?! > I totally agree with that, but on all debian machines I use packages > provided from debian, because they've made it very modular, > and I was able to config them the way I need and everything is working > for me. You're lucky then :) > In 99.99% of the cases when I do apt-get dist-upgrade the machine works > like a charm after it, and that's a fact (in fbsd when make installworld > too, but not for ports - which is the focus here). Right. One should never mix up, that Debian is, well, a kernel and a whole lot of software, whereas in FreeBSD you really have a line between the base OS and later installed software (ports). > Actually that's what *BSD prouds with - building everything from source > (like gentoo), well it's a must to be simplified then (debian where > everything is supposed to be used from bin .deb) :). > I really don't think that *BSD is proud about building everything from source. Since we now even have freebsd-update to binary update FreeBSD itself. And you usally find prebuilt packages too. No, No. IMO FreeBSD isn't proud about building everything from source :) I do have that feeling about Gentoo users, though *g* > > About the bug fixes, I think if that's a SECURITY backport it shouldn't > fix bugs, because I've saw few devs deploying an app and the were using > 'known bug' in ruby to work with. > so they were unable to use higher version of ruby that got this bug > fixed. (we'll obviously a developer mistake in design but if it's in a > production will take months to redesign - not an option). hhhmm... but then you're really in trouble. This is a situation... well, hell no. I don't wanna be in this game. A bug in a peace of software can lead to uncontrolled shutdown or could even evolve into a security whole. If possible I don't want bugs. If there's an application which just runs with the buggy version of ruby (perl, python, whatever), then lets start beating the devs. Literally speaking ;) > Which is why maybe it's better not to fix bugs but just vulns in > SECURITY backports (according to me of course) - if you need that bug > fixed, then install new version. > Opinions really will vary on this topic. In my MySQL example, we want to have the bugfixed version, 'cause those bugs are really bad. Same counts for Apache (not as often as MySQL, though). >> hhmm... I really can't agree on that statement. >> If you do your admin work in a clean and sane way, most of the time > spend >> for updating boxes is spent on testing the change before upgrading. The >> difference between a "debuild" for building a new package, and then > apt-get >> upgrade / update them on your box vs. "make package" and pkg_add -r them > on >> your box is really slim... >> >> > If you build from src on debian - yes, but as I explained i use debian > .debs and for me it's much faster, because on fbsd ports I have the > problem described before, > and is very common case to rebuild and rebuild port until it puts all > the files in the .tgz :( Well yes, thats true. However, take a look at the Latest packages on FreeBSD's ftp mirror. There are new versions available pretty often. On the other hand, you said, you want to have the same version, just security fixed. Well, I bet the FreeBSD ports team just can't do that, due to a lack of manpower. Really. Throw in a whole lotta money to employ a few people, or do it your own. The existing team is doing a wonderful job in keeping the ports tree up to date and trying to keep the pr-database as low as possible. But from what I know the existing team really doesn't look like it can handle -security branches of the ports tree. > > So, a story happened recently: > I've had a disk down (ad2) of course it was in gmirror and the situation > was 'ah, damn, but it's ok'... > but... when I rebooted the server it occured that ad2 was ACTIVE and > maybe last fresh and ad0 was DIRTY, > ad2 didn't failed at 100% it was responding and found by the bios (and > kernel) but when files were requested it timed out. > The problem occured when tried to boot from the second disk (ad0) > attached with ad2 (at this moment i didn't know that it fails when disk > io occurs). > because the ad2 was fresh and ad0 was dirty the gmirror failed to mount > and boot OS because it was trying to sync data from partly failed disk, > and it wasn't able to. > I've shutdowned the machine, plugged out the ad2 disk and fired up again > hoping gmirror will be smart enough to boot from ad0... but no luck, > I was forced to mount root filesystem with no mirror (ad0s1a) and run > the server in no mirror mode so I can have this critical machine running > while I find a new disk (few hours later I got it). > And the nightmare's just began... when I placed the new disk, the > gmirrored volume was still trying to sync from ad2, ofcourse, the ad2 > had no info on it (thanks god gmirror was smart enough to not copy the > empty disk). > I've had to rebuild the whole gmirror partiions, copy the info from a > non-mirrored disk (ad0) and etc.etc... you know the procedure... this > took me more than 10 hours and about 5hours downtime on a critical > machine.... Shocking story. huuu... I can't comment on that story though, because - at work, we're on Debian with hardware raids, no software raid even there - my own experiments with gmirror never lead to such a scenario. I should try to beat the disk to death, next time I test gmirror ;) > I suppose this has something to do with the priority in gmirror but I > don't have the broken disk to test - it's being replaced because it's in > warranty.... but anyways... 10 hours lost and 5hours downtime... > now I'm purchaseing a 3ware hw raid because I know that I can't trust > gmirror... > We don't trust LVM and co either. But don't ask me why. I believe it's more like a "feeling" than real facts. So I better don't start to discuss this matter. > Another strange thing, I've used to use apache22-worker cutom compiled > and thread_safe perl, the apache-worker stopped working on a jail (only > on one!) and I had to add replacements ot pthread.so in /etc/libmap, > I've been adviced not to use worker (as I did) but why the heck after > upgrading from 6.3-STABLE to 6.3-STABLE-p3 I got my apache broken and > also cron stopped working. To few facts. Never happened to me and without details I really can't comment. > strange uh? and all this is in only one jail (I'm using ez-jail to > update the world)... if anyone can help me to fix my cron without > reinstalling this jail I'd be thanksful! > You should open another mail thread on that topic and try to gather as much facts as you can. Cheers, Marian From mh at kernel32.de Wed Jun 11 16:20:03 2008 From: mh at kernel32.de (Marian Hettwer) Date: Wed Jun 11 16:20:13 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature withbuggy6.3 In-Reply-To: <20080611165009.O40102@fledge.watson.org> References: <20080611165009.O40102@fledge.watson.org> Message-ID: <97e6a5a3b509e35b8bfdab138ecf6b19@localhost> On Wed, 11 Jun 2008 16:54:02 +0100 (BST), Robert Watson wrote: > The place for volunteers to come in is where they see an obvious niche for > improvement -- for example, a few years ago this guy named Colin Percival > turned up with a binary update system. After a couple of years of > enhancement, breaking it in, etc, it's now a standard tool for maintaining > FreeBSD systems, and he's our security officer. Similar opportunities > exist > for offering easier updates to packages, etc, but require people who have > a > clear need and the technical ability to do the work to turn up and do it. > Very Well Spoken! :) Fact is, that it's okay to ask about a security branch for ports/packages. And if the answer is, no, we don't have enough manpower, then the road is clear. Either throw loads of money around you, or start doing it yourself and see wether someone hops on :) Cheers, ./Marian From eugen at kuzbass.ru Wed Jun 11 16:41:29 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Wed Jun 11 16:41:34 2008 Subject: FreeBSD 7 and Apache 1.3.41 PROBLEM In-Reply-To: <20080611155420.GA65168@eos.sc1.parodius.com> References: <087EAA726CFA4573BF9B39E69A5F3AE8@jarasoft.net> <20080611155420.GA65168@eos.sc1.parodius.com> Message-ID: <20080611164123.GA36521@svzserv.kemerovo.su> On Wed, Jun 11, 2008 at 08:54:20AM -0700, Jeremy Chadwick wrote: > The problem in your error logs indicate some sort of issue relating to > the accept filter in FreeBSD, which Apache can use (accf_http). > > I don't think Apache 1.3.x has this functionality (rc-script-wise) It has. Eugene Grosbein From jfvogel at gmail.com Wed Jun 11 16:52:25 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Wed Jun 11 16:52:30 2008 Subject: Vlan EVENT patch In-Reply-To: <20080611073313.GF3529@cdnetworks.co.kr> References: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> <20080611073313.GF3529@cdnetworks.co.kr> Message-ID: <2a41acea0806110952n2851415dyf3b3213249779bf1@mail.gmail.com> On Wed, Jun 11, 2008 at 12:33 AM, Pyun YongHyeon wrote: > On Tue, Jun 10, 2008 at 09:51:53AM -0700, Jack Vogel wrote: > > This is a small patch that Sam came up with for me, it will allow > > drivers to know > > when a vlan attaches. > > > > It is transparent to any code that doesn't want to change, but this > > will allow my > > drivers to finally utilize the vlan hardware filter (something Linux has had for > > ever but we lacked). > > > > Just curious, is there any rule how to use that new capability? > Because drivers will receive events whenever VLAN tags are > added/removed they would know how to act for these events. If > promiscuous mode is on for interface, driver should not filter any > VLAN tagged frames, right? > If users want to disable VLAN hardware filtering feature what is > best way to perform this? Introducing a new flag like > IFCAP_VLAN_HWFILT or add a new sysctl that control this feature? > I guess VIA Rhine III also have VLAN hardware filtering capability > so it would be even better if we have a way to share common part. All the patch does is have the vlan driver generate events when it attaches or detaches from a NIC, there are no rules, however I can tell you what I'm coding into this in the Intel drivers. The way it works is the driver registers a callback for each event, I will call that [igb,em,ixgbe]_register_vlan(), and unregister obviously. Right now, the drivers just generically enable VLAN capability because there is never a trigger to know IF and WHEN you need to do so, but with this change the VLAN capability will only get turned on by the registration routine. Most significantly, now when the pseudo device it gives the driver the VLAN tag, this will mean the driver will be able from the start to use the VFTA, the hardware filter, for each vlan attach the driver will add the ID into this table. The unregister event will turn the table entry off, and if this is the last VLAN being detached it will then disable the features. Oh yes, these routines will also take care of the size change of the frame due to the tag. I already have the changes in place in the igb drive, and they are working great. I do not understand why you think you need a flag to disable this, yes it could be done, but why? If you need to do some sort of debugging won't a system not using vlans and in promiscuous mode do just fine? It just seems to violate the whole reason for doing vlans in the first place, however perhaps I am missing something? I do not believe the Linux driver has some way to disable use of the table but I'll double check on that. Remember, this change requires NO driver changes unless they wish to take advantage of the ability. Cheers, Jack From wojtek at wojtek.tensor.gdynia.pl Wed Jun 11 17:07:16 2008 From: wojtek at wojtek.tensor.gdynia.pl (Wojciech Puchar) Date: Wed Jun 11 17:07:21 2008 Subject: FreeBSD 7 and Apache 1.3.41 PROBLEM In-Reply-To: <087EAA726CFA4573BF9B39E69A5F3AE8@jarasoft.net> References: <087EAA726CFA4573BF9B39E69A5F3AE8@jarasoft.net> Message-ID: <20080611190609.H60134@wojtek.tensor.gdynia.pl> > In httpd-error.log > [Wed Jun 11 17:01:04 2008] [info] mod_unique_id: using ip addr 10.10.10.10 > [Wed Jun 11 17:01:05 2008] [info] (2)No such file or directory: make_sock: for port 80, setsockopt: (SO_ACCEPTFILTER) > [Wed Jun 11 17:01:05 2008] [warn] pid file /var/run/httpd.pid overwritten -- Unclean shutdown of previous Apache run? > > After hashing out > #LoadModule unique_id_module libexec/apache/mod_unique_id.so > #AddModule mod_unique_id.c > > Apache starts normally > > Can anyone explain this? are you sure you use the same apache version as with 6.*? From bsdlist at cogeco.ca Wed Jun 11 18:03:09 2008 From: bsdlist at cogeco.ca (Paul) Date: Wed Jun 11 18:03:13 2008 Subject: Areca Raid 6 ARC-1231 Raid 6 Slow LS Listing Performance on large directory Message-ID: <20080611173211.A899C1E9E@fep5.cogeco.net> Hello, I have a RAID-6 Partition with the Areca ARC-1231 card on a S5000PAL Intel system with 6 disks as part of the raid volume. The system has been set up as Write-back cache and the raid card has a 2 GIG memory cache on it. It is installed on Freebsd 7.0 STABLE with SCHED_ULE enabled. I have a folder with a lot of small and big files in it that total 3009 files. In the user system we have 2200 users in the password file. 1) When I do a ls -lh on the raid 6 array with 6 disks in the array it takes aver 16 seconds before it starts to display anything on the screen. 2) While running a tar command on another shell, the time goes to 28 seconds for the same list to start showing. 3) When I do a ls (with no other options) it starts to list right away. 4) When I do a ls -ln it displays right away as well pointing to the slowdown being the mapping of the users in the db lookup. I have the same directory with the same number of files on a Raid 5 SCSI partition on Freebsd 4.X and it only takes 2 seconds to start displaying the list with the command ls -lh. Any ideas why it takes so long for this on Freebsd 7.0 stable? The partition this folder is on it /dev/da0s1f with a total size of 1.7T and a usage of 63G Any suggestions or help on this would be greatly appreciated. Thanks, Paul From pschmehl_lists at tx.rr.com Wed Jun 11 18:22:36 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Wed Jun 11 18:22:43 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3 In-Reply-To: <20080611165009.O40102@fledge.watson.org> References: <484FA07E.60103@lozenetz.org> <3cc535c80806110536w1c8af6efq8d5470ce6de8cb38@mail.gmail.com> <20080611165009.O40102@fledge.watson.org> Message-ID: <4E2C3BF30A4BC75D1D837828@utd65257.utdallas.edu> --On Wednesday, June 11, 2008 16:54:02 +0100 Robert Watson wrote: > > On Wed, 11 Jun 2008, Andy Kosela wrote: > >> Redhat/CentOS is more reliable here as backports involves both security and >> bug fixes, plus even new hardware enhancements. > > In the FreeBSD environment, we call the place that gets a blend of security > and bug fixes, plus new minor feature and driver enhancements "-STABLE", and > the releases that pick up these changes "point releases". They happen more > requently and with less risk than major releases, but still see enough > development to represent functional improvements. > > I guess here's my concern: we offer a spectrum of choice for "I want the most > bleeding edge" to "I want no feature changes, just security fixes", and > several points in between. We can argue about the exact placement of this > points, but the reality is that the balance we have today seems to work well > for many developers and users, and reflects a fairly carefully planned use of > the available revision control and distribution technology. > > The place for volunteers to come in is where they see an obvious niche for > improvement -- for example, a few years ago this guy named Colin Percival > turned up with a binary update system. After a couple of years of > enhancement, breaking it in, etc, it's now a standard tool for maintaining > FreeBSD systems, and he's our security officer. Similar opportunities exist > for offering easier updates to packages, etc, but require people who have a > clear need and the technical ability to do the work to turn up and do it. > >From a security standport, backporting fixes to previous versions of ports creates a difficulty. It's much harder to tell, for example, if a RedHat "port" is vulnerable or not, because RedHat uses their own proprietary versioning system to define "where" a particular "port" is at. So, while your system might *say* it's running php version 5.2, it's really *not* vulnerable because in RedHatese it's version 5.2.1.6.92000.p-2.1 (I'm just making that up.) If this idea ever gets off the ground, I *hope* the folks involved with find a rational, logical way to define the versioning so that it's not hieroglyphics to the average person. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. From rwatson at FreeBSD.org Wed Jun 11 18:36:29 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Jun 11 18:36:35 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3 In-Reply-To: <4E2C3BF30A4BC75D1D837828@utd65257.utdallas.edu> References: <484FA07E.60103@lozenetz.org> <3cc535c80806110536w1c8af6efq8d5470ce6de8cb38@mail.gmail.com> <20080611165009.O40102@fledge.watson.org> <4E2C3BF30A4BC75D1D837828@utd65257.utdallas.edu> Message-ID: <20080611193123.N40102@fledge.watson.org> On Wed, 11 Jun 2008, Paul Schmehl wrote: > From a security standport, backporting fixes to previous versions of ports > creates a difficulty. It's much harder to tell, for example, if a RedHat > "port" is vulnerable or not, because RedHat uses their own proprietary > versioning system to define "where" a particular "port" is at. > > So, while your system might *say* it's running php version 5.2, it's really > *not* vulnerable because in RedHatese it's version 5.2.1.6.92000.p-2.1 (I'm > just making that up.) > > If this idea ever gets off the ground, I *hope* the folks involved with find > a rational, logical way to define the versioning so that it's not > hieroglyphics to the average person. I hope not to offend the ports folks in saying this, but it seems clear to me that the narrower scope and better-defined components of the base system have (over time) lead to a much easier incremental upgrade path than ports and packages. It's not clear to me how you could apply the same level of attention to something as large as the ports collection, except perhaps to select a subset of ports you care "more" about, and provide a higher quality of service for them. In effect, try to find a semantically richer middle ground between "it's someone else's problem, our role is primarily to bundle" and "it's entirely our problem and in revision control". We already do this for some ports, in that the people involved in adapting and maintaining some of the larger/more critical parts, such as X.org, KDE, Gnome, and quite a few others, spend vast amounts of time ensuring that things work well, but largely without the help of revision control in the ports tree. I'm not proposing we incorporate X.org into CVS (SVN?) or the like, but perhaps there is a way we could better present the choices reflected there. That doesn't help users of random tiny software packages, and I'm not sure anything can, but perhaps we can provide a smoother incremental maintenance path for some key packages. Mind you, ports really isn't my area, so I am at significant risk speculating in this area. Experience with the base system shows that the real work is always in the details, and hardly ever in the big ideas, and so only by truly implementing a system and trying it out can you determine whether it really works in practice. It's easy to wave ones hands at a high level (as I've done), but it's the proof-of-concept that matters. Robert N M Watson Computer Laboratory University of Cambridge From mike at sentex.net Wed Jun 11 18:50:44 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Jun 11 18:50:48 2008 Subject: Areca Raid 6 ARC-1231 Raid 6 Slow LS Listing Performance on large directory In-Reply-To: <20080611173211.A899C1E9E@fep5.cogeco.net> References: <20080611173211.A899C1E9E@fep5.cogeco.net> Message-ID: <200806111811.m5BIBMkl074039@lava.sentex.ca> At 01:32 PM 6/11/2008, Paul wrote: >Any ideas why it takes so long for this on Freebsd 7.0 stable? > >The partition this folder is on it /dev/da0s1f with a total size of >1.7T and a usage of 63G > >Any suggestions or help on this would be greatly appreciated. Couple of things to check In /etc/nsswitch.conf try changing to group: files passwd: files and check to make sure vfs.ufs.dirhash_maxmem is > than vfs.ufs.dirhash_mem. If vfs.ufs.dirhash_mem is hit the max, increase the maxmem value ---Mike From gpalmer at freebsd.org Wed Jun 11 19:36:30 2008 From: gpalmer at freebsd.org (Gary Palmer) Date: Wed Jun 11 19:36:32 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3 In-Reply-To: <20080611193123.N40102@fledge.watson.org> References: <484FA07E.60103@lozenetz.org> <3cc535c80806110536w1c8af6efq8d5470ce6de8cb38@mail.gmail.com> <20080611165009.O40102@fledge.watson.org> <4E2C3BF30A4BC75D1D837828@utd65257.utdallas.edu> <20080611193123.N40102@fledge.watson.org> Message-ID: <20080611193628.GC998@in-addr.com> On Wed, Jun 11, 2008 at 07:36:28PM +0100, Robert Watson wrote: > > On Wed, 11 Jun 2008, Paul Schmehl wrote: > > >From a security standport, backporting fixes to previous versions of ports > >creates a difficulty. It's much harder to tell, for example, if a RedHat > >"port" is vulnerable or not, because RedHat uses their own proprietary > >versioning system to define "where" a particular "port" is at. > > > >So, while your system might *say* it's running php version 5.2, it's > >really *not* vulnerable because in RedHatese it's version > >5.2.1.6.92000.p-2.1 (I'm just making that up.) > > > >If this idea ever gets off the ground, I *hope* the folks involved with > >find a rational, logical way to define the versioning so that it's not > >hieroglyphics to the average person. > > I hope not to offend the ports folks in saying this, but it seems clear to > me that the narrower scope and better-defined components of the base system > have (over time) lead to a much easier incremental upgrade path than ports > and packages. > > It's not clear to me how you could apply the same level of attention to > something as large as the ports collection, except perhaps to select a > subset of ports you care "more" about, and provide a higher quality of > service for them. In effect, try to find a semantically richer middle > ground between "it's someone else's problem, our role is primarily to > bundle" and "it's entirely our problem and in revision control". We > already do this for some ports, in that the people involved in adapting and > maintaining some of the larger/more critical parts, such as X.org, KDE, > Gnome, and quite a few others, spend vast amounts of time ensuring that > things work well, but largely without the help of revision control in the > ports tree. I'm not proposing we incorporate X.org into CVS (SVN?) or the > like, but perhaps there is a way we could better present the choices > reflected there. That doesn't help users of random tiny software packages, > and I'm not sure anything can, but perhaps we can provide a smoother > incremental maintenance path for some key packages. > > Mind you, ports really isn't my area, so I am at significant risk > speculating in this area. Experience with the base system shows that the > real work is always in the details, and hardly ever in the big ideas, and > so only by truly implementing a system and trying it out can you determine > whether it really works in practice. It's easy to wave ones hands at a > high level (as I've done), but it's the proof-of-concept that matters. I think a large part of the shortcomings of the ports infrastructure when it comes to security releases could be mitigated if there was a rapid building and availability of packages on FTP mirrors to prevent everyone from doing "portupgrade -P" and then having to wait for the build as the packages don't show up for days, and people can't wait that long for the fix. I know a discussion was recently started about package distribution and how to address its shortcomings and hopefully the need for rapid security package distribution will be taken into account Regards, Gary From dougb at FreeBSD.org Wed Jun 11 19:53:50 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Wed Jun 11 19:53:54 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080611193628.GC998@in-addr.com> References: <484FA07E.60103@lozenetz.org> <3cc535c80806110536w1c8af6efq8d5470ce6de8cb38@mail.gmail.com> <20080611165009.O40102@fledge.watson.org> <4E2C3BF30A4BC75D1D837828@utd65257.utdallas.edu> <20080611193123.N40102@fledge.watson.org> <20080611193628.GC998@in-addr.com> Message-ID: <48502D4B.3040201@FreeBSD.org> Gary Palmer wrote: > I think a large part of the shortcomings of the ports infrastructure when > it comes to security releases could be mitigated if there was a rapid > building and availability of packages on FTP mirrors to prevent everyone > from doing "portupgrade -P" and then having to wait for the build as > the packages don't show up for days, and people can't wait that long > for the fix. I raised that issue recently on freebsd-ports@ and was told that there are no resources for that right now, although everyone agreed that it is definitely something that would be nice-to-have. Doug -- This .signature sanitized for your protection From bsdlist at cogeco.ca Wed Jun 11 20:03:43 2008 From: bsdlist at cogeco.ca (Paul) Date: Wed Jun 11 20:03:48 2008 Subject: Areca Raid 6 ARC-1231 Raid 6 Slow LS Listing Performance on large directory In-Reply-To: <200806111811.m5BIBMkl074039@lava.sentex.ca> References: <20080611173211.A899C1E9E@fep5.cogeco.net> <200806111811.m5BIBMkl074039@lava.sentex.ca> Message-ID: <20080611200342.A53901DEF@fep1.cogeco.net> At 02:11 PM 11/06/2008, Mike Tancsa wrote: >>Any ideas why it takes so long for this on Freebsd 7.0 stable? >> >>The partition this folder is on it /dev/da0s1f with a total size >>of 1.7T and a usage of 63G >> >>Any suggestions or help on this would be greatly appreciated. > >Couple of things to check > >In /etc/nsswitch.conf try changing to > >group: files >passwd: files > >and check to make sure >vfs.ufs.dirhash_maxmem is > than vfs.ufs.dirhash_mem. If >vfs.ufs.dirhash_mem is hit the max, increase the maxmem value > > ---Mike Thanks a lot for the quick reply. Changing from compat to files fixes the problem. It is now superfast when running ls -lh. Thanks again! Cheers Paul From pgollucci at p6m7g8.com Wed Jun 11 20:15:57 2008 From: pgollucci at p6m7g8.com (Philip M. Gollucci) Date: Wed Jun 11 20:16:03 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <484FF478.8010405@minibofh.org> References: <4846B64F.4090700@minibofh.org> <484775D4.4090509@p6m7g8.com> <48481A02.2050502@minibofh.org> <484FF478.8010405@minibofh.org> Message-ID: <48503020.7010600@p6m7g8.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jordi Espasa Clofent wrote: | It seems a php-extensions bug. | If you comment the mhash.so in /usr/local/etc/php/extensions.ini as: | | ;entension=mhash.so | | all works fine and you don't get anymore httpd crash (signal 11) if you | use 'apachectl graceful'. | | Maybe will be a good idea to open PR for this? | | I hope it helps someone.... (I'm very surprised that this isn't a | documented bug in 7.0 yet) It might make more sense to follow up with php..... Just b/c it happens in 7.x and not 6.x doesn't mean its a FreeBSD issue. - -- - ------------------------------------------------------------------------ Philip M. Gollucci (philip@ridecharge.com) o:703.549.2050x206 Senior System Admin - Riderway, Inc. http://riderway.com / http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iD8DBQFIUDAgdbiP+9ubjBwRAskiAJ993ELYL3AP5HkVtDSk2JQx9OuJzACfdORO rnTL1Ecdd4MNwlcrNKhwLYM= =lX0o -----END PGP SIGNATURE----- From mike at sentex.net Wed Jun 11 20:26:39 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Jun 11 20:26:45 2008 Subject: Areca Raid 6 ARC-1231 Raid 6 Slow LS Listing Performance on large directory In-Reply-To: <20080611200342.A53901DEF@fep1.cogeco.net> References: <20080611173211.A899C1E9E@fep5.cogeco.net> <200806111811.m5BIBMkl074039@lava.sentex.ca> <20080611200342.A53901DEF@fep1.cogeco.net> Message-ID: <200806112026.m5BKQaOB074653@lava.sentex.ca> At 04:04 PM 6/11/2008, Paul wrote: >Changing from compat to files fixes the problem. > >It is now superfast when running ls -lh. Hi, Not sure, but a more "proper" fix might be to look at the nscd caching daemon. Take a look at nscd and nscd.conf. I havent used it myself, but I seem to recall others suggesting this as a "fix" as well. ---Mike From andy.kosela at gmail.com Wed Jun 11 20:50:36 2008 From: andy.kosela at gmail.com (Andy Kosela) Date: Wed Jun 11 20:50:39 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3 Message-ID: <3cc535c80806111350x237e2a4ewe1429b7a3f5b720@mail.gmail.com> On Wed, Jun 11 2008, Robert Watson wrote: On Wed, 11 Jun 2008, Paul Schmehl wrote: >> From a security standport, backporting fixes to previous versions of ports >> creates a difficulty. It's much harder to tell, for example, if a RedHat >> "port" is vulnerable or not, because RedHat uses their own proprietary >> versioning system to define "where" a particular "port" is at. >> >> So, while your system might *say* it's running php version 5.2, it's really >> *not* vulnerable because in RedHatese it's version 5.2.1.6.92000.p-2.1 (I'm >> just making that up.) >> >> If this idea ever gets off the ground, I *hope* the folks involved with find >> a rational, logical way to define the versioning so that it's not >> hieroglyphics to the average person. Egyptian hieroglyphics was a very noble system the secret of which was, in the days of old, in the possession only of the Hierogrammatists, or initiated Egyptian priests. Many occult alphabets and ciphers derived its origin from egyptian sacred ciphers, as also everything we know as cryptography today. I guess our english alphabet would be equally strange and uknown to them. But reading widely available documentation on Redhat's versioning system would definetly help in understanding its details. Everything after second - (dash) like in ftp-0.17-33 is Redhat's release version. In this case this is thirty third release or patch. It is similar to FreeBSD's naming convention. You can check changelog and see what has changed since release 1 by issuing: $ rpm -q --changelog So the system is very clear and precise, just like FreeBSD system. The only difference is that upstream version of the package changes a lot more often than on redhat/centos. > We already do this for some >ports, in that the people involved in adapting and maintaining some of the >larger/more critical parts, such as X.org, KDE, Gnome, and quite a few others, >spend vast amounts of time ensuring that things work well, but largely without >the help of revision control in the ports tree. I'm not proposing we >incorporate X.org into CVS (SVN?) or the like, but perhaps there is a way we >could better present the choices reflected there. That doesn't help users of >random tiny software packages, and I'm not sure anything can, but perhaps we >can provide a smoother incremental maintenance path for some key packages. I think that most system administrators who maintain many FreeBSD servers in data center environments do not really care about "X.org, KDE, Gnome" and other desktop applications having those -SECURITY patches backported. The real concern here is about common server applications. I think that cutting edge users who run FreeBSD on their workstations are perfectly aware that things can sometimes break, and to a degree they accept that risk. But system administrators running mission critical nonstop systems 24/7 cannot accept such risk with the server ports they are using. So if anything can be improved in ease of upgrading, backporting etc. this is the main area to investigate, so as to make FreeBSD the most stable and reliable Unix operating system out there. -- Andy Kosela ora et labora From newsletter at purecomponents.com Wed Jun 11 22:10:05 2008 From: newsletter at purecomponents.com (PureComponents Newsletter) Date: Wed Jun 11 22:10:10 2008 Subject: PureComponents Ultimate Suite V2008.1 - 79 .NET WinForms Components for $79 Message-ID: PureComponents Ultimate Suite V2008.1 - The cheapest component suite there is! PureComponents offer you component suite for excellent price of 1 USD per component. Purchase the set of 79 components for 79 USD. Purchase 1 year subscription by June 30, and save 30%! http://www.purecomponents.com/ ------------------------------------------------------------------------------------------------------------------------ If you would not like to receive these messages, please visit: http://www.purecomponents.com/unsubscribe.aspx From pyunyh at gmail.com Thu Jun 12 00:11:54 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Jun 12 00:12:08 2008 Subject: Vlan EVENT patch In-Reply-To: <2a41acea0806110952n2851415dyf3b3213249779bf1@mail.gmail.com> References: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> <20080611073313.GF3529@cdnetworks.co.kr> <2a41acea0806110952n2851415dyf3b3213249779bf1@mail.gmail.com> Message-ID: <20080612000943.GA7250@cdnetworks.co.kr> On Wed, Jun 11, 2008 at 09:52:23AM -0700, Jack Vogel wrote: > On Wed, Jun 11, 2008 at 12:33 AM, Pyun YongHyeon wrote: > > On Tue, Jun 10, 2008 at 09:51:53AM -0700, Jack Vogel wrote: > > > This is a small patch that Sam came up with for me, it will allow > > > drivers to know > > > when a vlan attaches. > > > > > > It is transparent to any code that doesn't want to change, but this > > > will allow my > > > drivers to finally utilize the vlan hardware filter (something Linux has had for > > > ever but we lacked). > > > > > > > Just curious, is there any rule how to use that new capability? > > Because drivers will receive events whenever VLAN tags are > > added/removed they would know how to act for these events. If > > promiscuous mode is on for interface, driver should not filter any > > VLAN tagged frames, right? > > If users want to disable VLAN hardware filtering feature what is > > best way to perform this? Introducing a new flag like > > IFCAP_VLAN_HWFILT or add a new sysctl that control this feature? > > I guess VIA Rhine III also have VLAN hardware filtering capability > > so it would be even better if we have a way to share common part. > > All the patch does is have the vlan driver generate events when it attaches > or detaches from a NIC, there are no rules, however I can tell you what > I'm coding into this in the Intel drivers. > > The way it works is the driver registers a callback for each event, I will > call that [igb,em,ixgbe]_register_vlan(), and unregister obviously. > > Right now, the drivers just generically enable VLAN capability because > there is never a trigger to know IF and WHEN you need to do so, but > with this change the VLAN capability will only get turned on by the > registration routine. > > Most significantly, now when the pseudo device it gives the driver > the VLAN tag, this will mean the driver will be able from the start > to use the VFTA, the hardware filter, for each vlan attach the driver > will add the ID into this table. > > The unregister event will turn the table entry off, and if this is the > last VLAN being detached it will then disable the features. > > Oh yes, these routines will also take care of the size change of > the frame due to the tag. I already have the changes in place in > the igb drive, and they are working great. > > I do not understand why you think you need a flag to disable this, > yes it could be done, but why? If you need to do some sort of > debugging won't a system not using vlans and in promiscuous > mode do just fine? > I guess this would be the same reason why FreeBSD have a way to disable checksum offload for buggy hardware. Diabling all hardware VLAN assistance due to broken VLAN filtering doesn't look right. > It just seems to violate the whole reason for doing vlans in the > first place, however perhaps I am missing something? I do not > believe the Linux driver has some way to disable use of the table > but I'll double check on that. > > Remember, this change requires NO driver changes unless they > wish to take advantage of the ability. Yes. > > Cheers, > > Jack Thanks. -- Regards, Pyun YongHyeon From doconnor at gsoft.com.au Thu Jun 12 01:46:31 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Jun 12 01:46:35 2008 Subject: Areca Raid 6 ARC-1231 Raid 6 Slow LS Listing Performance on large directory In-Reply-To: <200806112026.m5BKQaOB074653@lava.sentex.ca> References: <20080611173211.A899C1E9E@fep5.cogeco.net> <20080611200342.A53901DEF@fep1.cogeco.net> <200806112026.m5BKQaOB074653@lava.sentex.ca> Message-ID: <200806121116.21657.doconnor@gsoft.com.au> On Thu, 12 Jun 2008, Mike Tancsa wrote: > At 04:04 PM 6/11/2008, Paul wrote: > >Changing from compat to files fixes the problem. > > > >It is now superfast when running ls -lh. > > Hi, > Not sure, but a more "proper" fix might be to look at the > nscd caching daemon. Take a look at nscd and nscd.conf. I havent used > it myself, but I seem to recall others suggesting this as a "fix" as > well. Why is 'compat' so slow? (ie what's the difference between it and file anyway) -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080612/b1c420be/attachment-0001.pgp From doconnor at gsoft.com.au Thu Jun 12 01:48:49 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Jun 12 01:49:04 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <20080611161048.GA66773@eos.sc1.parodius.com> References: <4846B64F.4090700@minibofh.org> <484FF478.8010405@minibofh.org> <20080611161048.GA66773@eos.sc1.parodius.com> Message-ID: <200806121118.45137.doconnor@gsoft.com.au> On Thu, 12 Jun 2008, Jeremy Chadwick wrote: > I myself haven't ever run into extension ordering issues like those > described (and we've done hosting for years), but I don't doubt those > who have experienced such. I am currently experiencing this :( In the past I shuffled the order until it worked but that's not a real solution. Also if you have gone from 6.x to 7.x make sure that you don't have any old stuff linked against libc.so.6 loaded into a binary using libc.so.7. It mostly works except with threaded programs and then *kaboom* -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080612/b87b8a1d/attachment.pgp From adrian at freebsd.org Thu Jun 12 02:24:51 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Thu Jun 12 02:24:55 2008 Subject: Areca Raid 6 ARC-1231 Raid 6 Slow LS Listing Performance on large directory In-Reply-To: <20080611173211.A899C1E9E@fep5.cogeco.net> References: <20080611173211.A899C1E9E@fep5.cogeco.net> Message-ID: 2008/6/12 Paul : > 1) When I do a ls -lh on the raid 6 array with 6 disks in the array it takes > aver 16 seconds before it starts to display anything on the screen. > 2) While running a tar command on another shell, the time goes to 28 seconds > for the same list to start showing. > 3) When I do a ls (with no other options) it starts to list right away. > 4) When I do a ls -ln it displays right away as well pointing to the > slowdown being the mapping of the users in the db lookup. > > I have the same directory with the same number of files on a Raid 5 SCSI > partition on Freebsd 4.X and it only takes 2 seconds to start displaying the > list with the command ls -lh. > > Any ideas why it takes so long for this on Freebsd 7.0 stable? > > The partition this folder is on it /dev/da0s1f with a total size of 1.7T > and a usage of 63G > > Any suggestions or help on this would be greatly appreciated. Could you please do a couple of other tests, if you're able to? I've got a PR to look into this issue. Could you see if using a smaller password file makes the ls start/run quicker? Could you possibly run ls inside "truss" on both FreeBSD-4 and FreeBSD-7 and email me a snippet of the output (say, a few hundred lines) ? Something like: truss ls >foo 2>&1 Thanks, Adrian -- Adrian Chadd - adrian@freebsd.org From adrian at freebsd.org Thu Jun 12 02:25:42 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Thu Jun 12 02:25:46 2008 Subject: Areca Raid 6 ARC-1231 Raid 6 Slow LS Listing Performance on large directory In-Reply-To: <20080611173211.A899C1E9E@fep5.cogeco.net> References: <20080611173211.A899C1E9E@fep5.cogeco.net> Message-ID: 2008/6/12 Paul : > 1) When I do a ls -lh on the raid 6 array with 6 disks in the array it takes > aver 16 seconds before it starts to display anything on the screen. > 2) While running a tar command on another shell, the time goes to 28 seconds > for the same list to start showing. > 3) When I do a ls (with no other options) it starts to list right away. > 4) When I do a ls -ln it displays right away as well pointing to the > slowdown being the mapping of the users in the db lookup. > > I have the same directory with the same number of files on a Raid 5 SCSI > partition on Freebsd 4.X and it only takes 2 seconds to start displaying the > list with the command ls -lh. > > Any ideas why it takes so long for this on Freebsd 7.0 stable? > > The partition this folder is on it /dev/da0s1f with a total size of 1.7T > and a usage of 63G > > Any suggestions or help on this would be greatly appreciated. Could you please do a couple of other tests, if you're able to? I've got a PR to look into this issue. Could you see if using a smaller password file makes the ls start/run quicker? Could you possibly run ls inside "truss" on both FreeBSD-4 and FreeBSD-7 and email me a snippet of the output (say, a few hundred lines) ? Something like: truss ls >foo 2>&1 Thanks, Adrian -- Adrian Chadd - adrian@freebsd.org From pyunyh at gmail.com Thu Jun 12 03:24:39 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Jun 12 03:24:45 2008 Subject: broken re(4) In-Reply-To: <20080611092457.82c83083.gerrit@pmp.uni-hannover.de> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <3C916EEA-5A2B-4C88-B834-0F47D7D525FA@gmail.com> <20080611092457.82c83083.gerrit@pmp.uni-hannover.de> Message-ID: <20080612032228.GD7250@cdnetworks.co.kr> On Wed, Jun 11, 2008 at 09:24:57AM +0200, Gerrit K?hn wrote: > On Tue, 10 Jun 2008 20:43:04 +0200 Daniele Bastianini > wrote about Re: broken re(4): > > DB> > - copying large files (more than some 100MB) via ssh/scp drops the > DB> > connection due to "corrupted MAC on input": > DB> > Disconnecting: Corrupted MAC on input. > DB> > lost connection > > DB> I had the same problem. > DB> I fixed it (for now) making a buildworld with > DB> *default date=2008.03.01.00.00.00 in my src csup configuration. > > DB> I'm not so skilled to investigate in the sources but the problem is > DB> after this date. > > For me all versions from cvs and all patches from Pyun are working now, > after I have solved the issue with the bad riser card. I still think it's > funny that the riser causes this kind of trouble for the networking chips. > > On the other hand, I have not been able to get more than about 10MByte/s > through the interfaces of this particular system. I have 1GBit-networking > equipment, and the other systems (which are used as router) have no > problem doing a throughput of >20MB/s. Even bonding the two interfaces > using lagg(4) does not improve the performance - where else could be the > bottleneck? Before checking performance of network controller you had to rule out other factors like disk I/O. Use one of benchmark programs in ports/benchmark. > The only difference here is that I have the extra SATA-controller with > disks in there. However, the disks appear to be as fast as I can expect > from a SATA150-interface. > -- Regards, Pyun YongHyeon From lists at pingle.org Thu Jun 12 03:30:55 2008 From: lists at pingle.org (Jim Pingle) Date: Thu Jun 12 03:31:04 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <200806121118.45137.doconnor@gsoft.com.au> References: <4846B64F.4090700@minibofh.org> <484FF478.8010405@minibofh.org> <20080611161048.GA66773@eos.sc1.parodius.com> <200806121118.45137.doconnor@gsoft.com.au> Message-ID: <48509419.6060206@pingle.org> Daniel O'Connor wrote: > On Thu, 12 Jun 2008, Jeremy Chadwick wrote: >> I myself haven't ever run into extension ordering issues like those >> described (and we've done hosting for years), but I don't doubt those >> who have experienced such. > > I am currently experiencing this :( > In the past I shuffled the order until it worked but that's not a real > solution. > [snip] I've mentioned this on the lists a couple times, but I have a shell script I worked out that puts the extensions into a known-working order. http://www.pingle.org/2007/09/22/php-crashes-extensions-workaround It's based on things I've come across with respect to this issue over the last couple years. It's not a new problem by a long shot. It's been happening to me for years with PHP4 and PHP5, Apache 1.3.x and 2.x. See also my previous posts on my site: http://www.pingle.org/2006/10/18/php-crashes-extensions http://www.pingle.org/2007/05/13/php-crashes-extensions-2 And some previous threads on the topic: http://lists.freebsd.org/pipermail/freebsd-stable/2006-November/030951.html http://lists.freebsd.org/mailman/htdig/freebsd-ports/2006-November/036849.html (I thought there were more but I can't find them at the moment...) I need to see if I can improve the script any (suggestions are most welcome) then open a PR to see if it -- or logic like it -- can be included in the php-extensions meta port. Jim From zhpalt at gmail.com Thu Jun 12 03:57:25 2008 From: zhpalt at gmail.com (Pallt) Date: Thu Jun 12 03:57:31 2008 Subject: Under gnome-2.22.2, can not lock the screen Message-ID: <1213241519.54120.9.camel@Tiger.domain> Hi! The version of the freebsd is 7.0-stable(June 9 2008), and the gnome was also updated to 2.22.2. But, I can not lock the screen, when I click the "Lock Screen" button under System Menu?(The acpi can works well). I can't find the right way to let it work. Thanks any way From doconnor at gsoft.com.au Thu Jun 12 05:15:38 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Jun 12 05:15:47 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <48509419.6060206@pingle.org> References: <4846B64F.4090700@minibofh.org> <200806121118.45137.doconnor@gsoft.com.au> <48509419.6060206@pingle.org> Message-ID: <200806121445.30864.doconnor@gsoft.com.au> On Thu, 12 Jun 2008, Jim Pingle wrote: > I need to see if I can improve the script any (suggestions are most > welcome) then open a PR to see if it -- or logic like it -- can be > included in the php-extensions meta port. Adding the script to the port seems like the way to go (baring an upstream fix but it seems like a difficult problem to solve). Unfortunately it doesn't help me :( If I disable everything except either pgsql or mhash (either separately or together) Apache crashes with.. #0 0x28ad6d40 in ?? () #1 0x281c6f2e in _pthread_main_np () from /lib/libc.so.7 #2 0x2819fa0c in puts () from /lib/libc.so.7 #3 0x281a0177 in gethostbyname () from /lib/libc.so.7 #4 0x08069a12 in ap_get_local_host () #5 0x08068b9c in ap_fini_vhost_config () #6 0x0805639c in ap_read_config () #7 0x0805f133 in standalone_main () #8 0x08060c1f in main () I don't understand why gethostbyname() would call puts() - and why that would then crash! Seems like some threading related wrinkle though as pgsql & mhash are the only extensions I have that are linked to libthr.so -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080612/a537c6a6/attachment.pgp From koitsu at FreeBSD.org Thu Jun 12 05:59:19 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Jun 12 05:59:26 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <200806121445.30864.doconnor@gsoft.com.au> References: <4846B64F.4090700@minibofh.org> <200806121118.45137.doconnor@gsoft.com.au> <48509419.6060206@pingle.org> <200806121445.30864.doconnor@gsoft.com.au> Message-ID: <20080612055919.GA27267@eos.sc1.parodius.com> On Thu, Jun 12, 2008 at 02:45:21PM +0930, Daniel O'Connor wrote: > On Thu, 12 Jun 2008, Jim Pingle wrote: > > I need to see if I can improve the script any (suggestions are most > > welcome) then open a PR to see if it -- or logic like it -- can be > > included in the php-extensions meta port. > > Adding the script to the port seems like the way to go (baring an > upstream fix but it seems like a difficult problem to solve). > > Unfortunately it doesn't help me :( > If I disable everything except either pgsql or mhash (either separately > or together) Apache crashes with.. > > #0 0x28ad6d40 in ?? () > #1 0x281c6f2e in _pthread_main_np () from /lib/libc.so.7 > #2 0x2819fa0c in puts () from /lib/libc.so.7 > #3 0x281a0177 in gethostbyname () from /lib/libc.so.7 > #4 0x08069a12 in ap_get_local_host () > #5 0x08068b9c in ap_fini_vhost_config () > #6 0x0805639c in ap_read_config () > #7 0x0805f133 in standalone_main () > #8 0x08060c1f in main () > > I don't understand why gethostbyname() would call puts() - and why that > would then crash! I can't explain why it's calling puts() directly either. Bad RAM could cause something bizarre like this, or a corrupt/broken binary. The libc code I'm looking at (src/lib/libc/net/gethostnameadr.c and gethostbydns.c) don't call puts) don't appear to call puts() directly. Of course, there may be macros used which do this. There are some places in the resolver code where printing to stdout or stderr can occur. I'd expect to see a longer stack trace (meaning more functions between gethostbyname() and puts()) if that were the case, though. There's a decent document on how to debug httpd below. You'll need to start httpd with -X or with "MaxClients 1", to keep it from forking. You can do that through gdb if you want, or (what I prefer, since I'm not very good with gdb) use truss. http://httpd.apache.org/dev/debugging.html If you go the truss route, be sure to use -a -s 4096. You'd be able to see what actual string is being output via puts(), assuming it gets as far as to start writing data to the fd. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From pluknet at gmail.com Thu Jun 12 06:47:20 2008 From: pluknet at gmail.com (pluknet) Date: Thu Jun 12 06:47:24 2008 Subject: FreeBSD 7.0 Stable and the CP2101 driver In-Reply-To: <437286.30504.qm@web54011.mail.re2.yahoo.com> References: <437286.30504.qm@web54011.mail.re2.yahoo.com> Message-ID: 2008/6/11 Dennis Flynn : [trim] > I tried installing the update, e.g. "freebsd-update -r 7.0-STABLE fetch", then "freebsd-update -r 7.0-STABLE upgrade". Seemed to work. But I do not seem to have the device driver loaded when I plug in the USB device. I get the folowwing in the messages log: > > Jun 10 16:48:02 wx kernel: ugen0: on uhub0 > > But I don't see a device that I think I should see, like /dev/ttyU0. If I do a "uname -a" I see the following: > > FreeBSD wx.dennis-flynn.net 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > That doesn't seem right to me. Shouldn't I see something like 7.0-RELEASE-p1 or 7.0-STABLE? Did I do something wrong in my update to RELEASE? How do I know if I'm running the STABLE kernel with the driver I want? How can I tell if the driver (uslcom) is there and/or loaded? > uslcom(4) appeared somewhere in 7.0-STABLE in GENERIC, and you are running 7.0-RELEASE, that is older. freebsd-update works only with releases (plus sec.patches), and 7.0-STABLE is not a release (obviously because you cannot definitely say to what date it corresponds). So you should update it to STABLE manually or wait until 7.1 is out. wbr, pluknet From gerrit at pmp.uni-hannover.de Thu Jun 12 06:58:14 2008 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Thu Jun 12 06:58:18 2008 Subject: broken re(4) In-Reply-To: <20080612032228.GD7250@cdnetworks.co.kr> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <3C916EEA-5A2B-4C88-B834-0F47D7D525FA@gmail.com> <20080611092457.82c83083.gerrit@pmp.uni-hannover.de> <20080612032228.GD7250@cdnetworks.co.kr> Message-ID: <20080612085810.072d705d.gerrit@pmp.uni-hannover.de> On Thu, 12 Jun 2008 12:22:28 +0900 Pyun YongHyeon wrote about Re: broken re(4): PY> Before checking performance of network controller you had to rule PY> out other factors like disk I/O. Use one of benchmark programs in PY> ports/benchmark. I already did simple benchmarking by using "dd if=/dev/zero of=file" which gave me several 10s of MByte/s under all circumstances. Can you recommend one of the benchmarking programs for more detailed testing? cu Gerrit From pyunyh at gmail.com Thu Jun 12 07:03:36 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Jun 12 07:03:43 2008 Subject: broken re(4) In-Reply-To: <20080612085810.072d705d.gerrit@pmp.uni-hannover.de> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <3C916EEA-5A2B-4C88-B834-0F47D7D525FA@gmail.com> <20080611092457.82c83083.gerrit@pmp.uni-hannover.de> <20080612032228.GD7250@cdnetworks.co.kr> <20080612085810.072d705d.gerrit@pmp.uni-hannover.de> Message-ID: <20080612070126.GF7250@cdnetworks.co.kr> On Thu, Jun 12, 2008 at 08:58:10AM +0200, Gerrit K?hn wrote: > On Thu, 12 Jun 2008 12:22:28 +0900 Pyun YongHyeon wrote > about Re: broken re(4): > > PY> Before checking performance of network controller you had to rule > PY> out other factors like disk I/O. Use one of benchmark programs in > PY> ports/benchmark. > > I already did simple benchmarking by using "dd if=/dev/zero of=file" which > gave me several 10s of MByte/s under all circumstances. > Can you recommend one of the benchmarking programs for more detailed > testing? > Try netperf or iperf in ports/benchmark. > > cu > Gerrit -- Regards, Pyun YongHyeon From doconnor at gsoft.com.au Thu Jun 12 07:05:50 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Jun 12 07:05:58 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <20080612055919.GA27267@eos.sc1.parodius.com> References: <4846B64F.4090700@minibofh.org> <200806121445.30864.doconnor@gsoft.com.au> <20080612055919.GA27267@eos.sc1.parodius.com> Message-ID: <200806121635.36998.doconnor@gsoft.com.au> On Thu, 12 Jun 2008, Jeremy Chadwick wrote: > > I don't understand why gethostbyname() would call puts() - and why > > that would then crash! > > I can't explain why it's calling puts() directly either. Bad RAM > could cause something bizarre like this, or a corrupt/broken binary. Yeah.. I have rebuilt lots of stuff, although not libc. This machine has build world, kernel, KDE, etc.. I am pretty sure the hardware is OK as none of the builds had an issue. > The libc code I'm looking at (src/lib/libc/net/gethostnameadr.c and > gethostbydns.c) don't call puts) don't appear to call puts() > directly. Of course, there may be macros used which do this. I had a look - there certainly isn't anywhere obvious it's hapening. I guess the only thing now is to rebuild with debugging. > There are some places in the resolver code where printing to stdout > or stderr can occur. I'd expect to see a longer stack trace (meaning > more functions between gethostbyname() and puts()) if that were the > case, though. > > There's a decent document on how to debug httpd below. You'll need > to start httpd with -X or with "MaxClients 1", to keep it from > forking. You can do that through gdb if you want, or (what I prefer, > since I'm not very good with gdb) use truss. OK thanks. > http://httpd.apache.org/dev/debugging.html > > If you go the truss route, be sure to use -a -s 4096. You'd be able > to see what actual string is being output via puts(), assuming it > gets as far as to start writing data to the fd. Hmm I had a go with gdb but it doesn't work properly.. I got this.. [midget 16:33] /tmp/work/usr/ports/www/apache13-modssl/work/apache_1.3.41 >sudo gdb src/httpd Password: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) run -X Starting program: /data/tmp/work/usr/ports/www/apache13-modssl/work/apache_1.3.41/src/httpd -X [New LWP 100212] [New Thread 0x819d300 (LWP 100212)] [New LWP 100212] suspend error: generic error [Switching to LWP 100212] Stopped due to shared library event (gdb) info thread Cannot find new threads: generic error (gdb) bt #0 0x2807fda0 in r_debug_state () from /libexec/ld-elf.so.1 #1 0x2808367d in dlclose () from /libexec/ld-elf.so.1 #2 0x28706164 in zend_hash_apply_deleter () from /usr/local/libexec/apache/libphp5.so #3 0x287063a8 in zend_hash_graceful_reverse_destroy () from /usr/local/libexec/apache/libphp5.so #4 0x286fc89e in zend_shutdown () from /usr/local/libexec/apache/libphp5.so #5 0x286bb5bf in php_module_shutdown () from /usr/local/libexec/apache/libphp5.so #6 0x286bb66b in php_module_shutdown_wrapper () from /usr/local/libexec/apache/libphp5.so #7 0x28776aaa in apache_php_module_shutdown_wrapper () from /usr/local/libexec/apache/libphp5.so #8 0x080524d9 in ap_clear_pool (a=0x8106010) at alloc.c:1937 #9 0x0805f0f6 in standalone_main (argc=Variable "argc" is not available. ) at http_main.c:5480 #10 0x08060c1f in main (argc=-716130182, argv=0x1) at http_main.c:5883 I tried truss and it seemed to be taking a long time (5-10 minutes) and generating a lot of seemingly identical logging :( -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080612/4f7514e1/attachment.pgp From koitsu at FreeBSD.org Thu Jun 12 07:28:12 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Jun 12 07:28:18 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <200806121635.36998.doconnor@gsoft.com.au> References: <4846B64F.4090700@minibofh.org> <200806121445.30864.doconnor@gsoft.com.au> <20080612055919.GA27267@eos.sc1.parodius.com> <200806121635.36998.doconnor@gsoft.com.au> Message-ID: <20080612072812.GA35851@eos.sc1.parodius.com> On Thu, Jun 12, 2008 at 04:35:26PM +0930, Daniel O'Connor wrote: > On Thu, 12 Jun 2008, Jeremy Chadwick wrote: > > > I don't understand why gethostbyname() would call puts() - and why > > > that would then crash! > > > > I can't explain why it's calling puts() directly either. Bad RAM > > could cause something bizarre like this, or a corrupt/broken binary. > > Yeah.. I have rebuilt lots of stuff, although not libc. Huh? > This machine has build world, kernel, KDE, etc.. I am pretty sure the hardware is OK as none of the builds had an issue. libc is part of world. *Every* program relies (is linked with) on libc. > > If you go the truss route, be sure to use -a -s 4096. You'd be able > > to see what actual string is being output via puts(), assuming it > > gets as far as to start writing data to the fd. > > Hmm I had a go with gdb but it doesn't work properly.. I got this.. > [midget 16:33] /tmp/work/usr/ports/www/apache13-modssl/work/apache_1.3.41 >sudo gdb src/httpd > Password: > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > (gdb) run -X > Starting program: /data/tmp/work/usr/ports/www/apache13-modssl/work/apache_1.3.41/src/httpd -X > [New LWP 100212] > [New Thread 0x819d300 (LWP 100212)] > [New LWP 100212] > suspend error: generic error > [Switching to LWP 100212] > Stopped due to shared library event > (gdb) info thread > Cannot find new threads: generic error > (gdb) bt > #0 0x2807fda0 in r_debug_state () from /libexec/ld-elf.so.1 > #1 0x2808367d in dlclose () from /libexec/ld-elf.so.1 > #2 0x28706164 in zend_hash_apply_deleter () > from /usr/local/libexec/apache/libphp5.so > #3 0x287063a8 in zend_hash_graceful_reverse_destroy () > from /usr/local/libexec/apache/libphp5.so > #4 0x286fc89e in zend_shutdown () from /usr/local/libexec/apache/libphp5.so > #5 0x286bb5bf in php_module_shutdown () from /usr/local/libexec/apache/libphp5.so > #6 0x286bb66b in php_module_shutdown_wrapper () > from /usr/local/libexec/apache/libphp5.so > #7 0x28776aaa in apache_php_module_shutdown_wrapper () > from /usr/local/libexec/apache/libphp5.so > #8 0x080524d9 in ap_clear_pool (a=0x8106010) at alloc.c:1937 > #9 0x0805f0f6 in standalone_main (argc=Variable "argc" is not available. > ) at http_main.c:5480 > #10 0x08060c1f in main (argc=-716130182, argv=0x1) at http_main.c:5883 I can't say much about this, but I'm willing to bet it's the result of some Apache + PHP weirdness. I've never known gdb on FreeBSD to be as reliable/useful as, say, on Linux or Solaris. Always odd/strange things happening with gdb on FreeBSD. > I tried truss and it seemed to be taking a long time (5-10 minutes) and > generating a lot of seemingly identical logging :( Okay, let's backtrack here. The OP states that he can induce a segfault of httpd when doing "apachectl graceful". Is that the exact problem you're seeing, or are you seeing problems where PHP/Apache segfaults during operation? I just want to be clear. If the latter, then truss "generating lots of seemingly identical logging" is probably expected. I'm guessing it's select() or poll() or something related to kqueue/kevent, as it'd be waiting for I/O on the HTTP socket. You'd have to submit the HTTP request to the PHP script to get it to crash. In either case, you may have to resort to using ktrace + kdump, which may or may not help narrow this down. Use "ktrace -i -t+ httpd -X" (I hope that'll work; I'm not sure if ktrace allows you to pass arguments to a command), which will start populating a file called ktrace.out. You should then do the "apachectl graceful" in another window (or if the latter, submit the HTTP request), and ktrace may exit when the segfault happens (I'm not sure about this; it may sit there indefinitely). In the case it doesn't exit, and you've confirmed the core happened (check "dmesg"), you should ^C the ktrace and then do "ktrace -C" just to be sure nothing got wedged. You'll then have to use kdump to decode the contents of ktrace.out. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From doconnor at gsoft.com.au Thu Jun 12 08:18:34 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Jun 12 08:18:42 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <20080612072812.GA35851@eos.sc1.parodius.com> References: <4846B64F.4090700@minibofh.org> <200806121635.36998.doconnor@gsoft.com.au> <20080612072812.GA35851@eos.sc1.parodius.com> Message-ID: <200806121748.28133.doconnor@gsoft.com.au> On Thu, 12 Jun 2008, Jeremy Chadwick wrote: > > Yeah.. I have rebuilt lots of stuff, although not libc. > > Huh? Sorry, I meant that I have to explicitly rebuilt it since I did a buildworld to make sure it wasn't fubar'd somehow. I haven't done that mainly because I find it extremely unlikely it would only break Apache in this manner but nothing else. I might rebuild it to get debug symbols though.. > > This machine has build world, kernel, KDE, etc.. I am pretty sure > > the hardware is OK as none of the builds had an issue. > > libc is part of world. *Every* program relies (is linked with) on > libc. Yes, sorry for my confusing turn of phrase! :) > > #10 0x08060c1f in main (argc=-716130182, argv=0x1) at > > http_main.c:5883 > > I can't say much about this, but I'm willing to bet it's the result > of some Apache + PHP weirdness. I've never known gdb on FreeBSD to > be as reliable/useful as, say, on Linux or Solaris. Always > odd/strange things happening with gdb on FreeBSD. Yeah :( > > I tried truss and it seemed to be taking a long time (5-10 minutes) > > and generating a lot of seemingly identical logging :( > > Okay, let's backtrack here. > > The OP states that he can induce a segfault of httpd when doing > "apachectl graceful". Is that the exact problem you're seeing, or > are you seeing problems where PHP/Apache segfaults during operation? > I just want to be clear. > > If the latter, then truss "generating lots of seemingly identical > logging" is probably expected. I'm guessing it's select() or poll() > or something related to kqueue/kevent, as it'd be waiting for I/O on > the HTTP socket. You'd have to submit the HTTP request to the PHP > script to get it to crash. > > In either case, you may have to resort to using ktrace + kdump, which > may or may not help narrow this down. > > Use "ktrace -i -t+ httpd -X" (I hope that'll work; I'm not sure if > ktrace allows you to pass arguments to a command), which will start > populating a file called ktrace.out. You should then do the > "apachectl graceful" in another window (or if the latter, submit the > HTTP request), and ktrace may exit when the segfault happens (I'm not > sure about this; it may sit there indefinitely). > > In the case it doesn't exit, and you've confirmed the core happened > (check "dmesg"), you should ^C the ktrace and then do "ktrace -C" > just to be sure nothing got wedged. > > You'll then have to use kdump to decode the contents of ktrace.out. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080612/675d6a8d/attachment.pgp From doconnor at gsoft.com.au Thu Jun 12 08:20:54 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Jun 12 08:20:58 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <20080612072812.GA35851@eos.sc1.parodius.com> References: <4846B64F.4090700@minibofh.org> <200806121635.36998.doconnor@gsoft.com.au> <20080612072812.GA35851@eos.sc1.parodius.com> Message-ID: <200806121750.50756.doconnor@gsoft.com.au> [This is a continuation of my last message, I accidentally mashed the send key] On Thu, 12 Jun 2008, Jeremy Chadwick wrote: > > I tried truss and it seemed to be taking a long time (5-10 minutes) > > and generating a lot of seemingly identical logging :( > > Okay, let's backtrack here. > > The OP states that he can induce a segfault of httpd when doing > "apachectl graceful". Is that the exact problem you're seeing, or > are you seeing problems where PHP/Apache segfaults during operation? > I just want to be clear. No, I don't see a problem with 'apachectl graceful' - it doesn't get that far. > If the latter, then truss "generating lots of seemingly identical > logging" is probably expected. I'm guessing it's select() or poll() > or something related to kqueue/kevent, as it'd be waiting for I/O on > the HTTP socket. You'd have to submit the HTTP request to the PHP > script to get it to crash. I get a crash when Apache starts up. I wasn't sure if it was related to OPs problem or not, I should have been clearer though. > In either case, you may have to resort to using ktrace + kdump, which > may or may not help narrow this down. > > Use "ktrace -i -t+ httpd -X" (I hope that'll work; I'm not sure if > ktrace allows you to pass arguments to a command), which will start Yes ktrace does allow that. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080612/7dc89d73/attachment.pgp From lists at lozenetz.org Thu Jun 12 08:32:46 2008 From: lists at lozenetz.org (Anton - Valqk) Date: Thu Jun 12 08:32:51 2008 Subject: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 In-Reply-To: <20080611164704.J40102@fledge.watson.org> References: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com> <484FA07E.60103@lozenetz.org> <20080611164704.J40102@fledge.watson.org> Message-ID: <4850DF22.9080802@lozenetz.org> Robert Watson wrote: > > On Wed, 11 Jun 2008, Anton - Valqk wrote: > >> I fully agree with the lines below. >> As noticed below there is more attention to developing new features, >> than making releases rock solid stable. > ... >> Ah, another thing, >> I'm waiting for virtualization networking layer for jails for quite >> long. >> I've tested it on a test server, worked perfect, but on production I >> don't want to patch my base. >> there are few other features to jals that never got commited in base, >> and as I said I don't want to patch it... > > The reason that the virtualization patches aren't in the tree is > precisely *because* we care about stability and are willing to slow > down feature development in order to accomplish it. Some features take > years to stabilize, and just because a patch works OK in your > environment doesn't mean it will work in everyone's. Moderating the > rate at which we adopt agressive new features is part of an > intentional strategy to avoid letting development trees destabilize to > a point where it's unproductive. > I totally agree with that point, just commented that it's been year(s) since its appearence an maybe not enought effort in it (just an outsider thought, can't know if it is) and the fueature is a really really great and nice one! > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From gmiller at classic-games.com Thu Jun 12 08:37:17 2008 From: gmiller at classic-games.com (Greg Miller) Date: Thu Jun 12 08:37:21 2008 Subject: Adesso AKB-430UG keyboard on 7.0 Message-ID: <4850DCA8.6000709@classic-games.com> I'm using an AKB-430UG USB keyboard ("Win-Touch Pro") on FreeBSD 7.0-release-p1, or trying to. The keyboard works fine in Windows, but with FreeBSD I get the same sort of problems people have described previous with the Genius SlimStar Pro: the keys behave as if CTRL is always pressed. I'd hate to have to switch to a different keyboard, because it took me years to find a good alternative to my old Cirque Input Center keyboard/glidepoint combo. -- http://www.velocityvector.com/ | http://www.classic-games.com/ I'd rather hunt with Dick Cheney than ride with Ted Kennedy. From lists at lozenetz.org Thu Jun 12 08:59:48 2008 From: lists at lozenetz.org (Anton - Valqk) Date: Thu Jun 12 08:59:55 2008 Subject: CLARITY re: challenge: end of life for 6.2 is prematurewithbuggy 6.3 In-Reply-To: References: <484FF461.6000306@lozenetz.org> Message-ID: <4850E577.4000503@lozenetz.org> Thanks for the answer, so lets tell what I think :) Marian Hettwer wrote: > On Wed, 11 Jun 2008 18:50:57 +0300, Anton - Valqk > wrote: > >> Thanks for the answer! >> I'm glad someone answered me a human way, >> because two times before, I wasn't answered that way >> (well... my posts were angry and incomplete but...that's why i didn't >> continued to post...my bad). >> >> > Well then, lets continue answering in a human way. Which is, funnily > enough, usually the more productive way too ;-) > > >> now on topic: >> >> > yeah! > > >>> Thats unfortunatly true. >>> But there is a way around. As soon as you have several FreeBSD boxes, >>> >> I'd >> >>> advise you to install your own FreeBSD box for packages building. >>> So if you need to update your php installations, go to your build box >>> (which has the very same versions of programs installed as your >>> >> production >> >>> boxes), update your ports tree and do a "make package" of your new php >>> port. >>> If the new php package works fine on your build box, roll it out via >>> "pkg_add -r $NEWPHPTHINGY" and off you go. >>> >>> >>> >> I do have a build server(well a jail but works for me), also I have test >> eviornment (jailed too). >> I use this jail to build all my pkgs and use pkg_add -r (sweeet!!). >> For most of the ports this works, but sometimes something in make >> package breaks and i get a port installed partially >> (last case - apache22 got installed but no /usr/local/etc/rc.d/apache22 >> rc script, previous - pg_ctl never got installed) >> and in +CONTENTS file the missing files claimed to be there. >> > hm... sounds like a bug to me. On the other hand, you have to try to get it > to be reproducable. If it's a one timer then yes, it's annoying, but really > really hard to reproduce and therefor to fix. > > the problem is that I don't have enought time to setup a testing server and find out when the problem occurs, because it's random seen, on 10-15th build of the new port this happens, I've noticed that if I make #> make deinstall distclean install pakcage-recursive the problem occurs much more rare compared to just #> make deinstall ditsclean package-recursive I simply currently don't have time for test setup ;( >> I've had to rebuild that kind of port so I can install it again (after >> pkg_delete) to have the port working. >> > yeah, annoying. > > >> This happens most often when I do make install package-recursive (so I >> can get all needed ports installed). >> > If you can reproduce it step by step, it may be worth posting to ports@ > again with what you did and what happened. > Either you're doing something wrong, or something is broken. > However, it needs to be reproducable. At least in your environment. As a > starter, so to say :) > The more detailed your steps are written down, the more likely someone will > either follow those steps or give you a direct hint on "humm, could be > something bad over there... hm hm). > > I understand that, that's why I didn't posted again because, as I said i don't have time to sitdown and setup and try to reproduce it. >> Another strange thing is that when I use php-extensions to build all >> that I need (this takes most of my time when build/install new php) >> breaks because of the ?'bug'? described few lines above. as I said noone >> got interested in this problem... >> > I can't say anything specific about the php problem you said. I'm not using > php, or well, very rarely. I'll give it a try to update it the make package > way next time. > Unluckily this is a one-box only system. hmmm... If I find the time to > test, I'll drop you mail. But time is rare (admin life vs. normal life). > > To cut that short: Yeah, I can understand that this is annoying. But I'm > sure as hell: > - if it's a bug it can be fixed > - if it's a user error, it can be changed > - and all this has happened to me when trying to build my own debian > packages too ;) > And it happened to me with Gentoo, too. > Nothing new at all. Just the regular annoyances in sysadmins life. IMO :) > > agree with that, just my effort with debian is much smaller than fbsd ports. >>>> Another _very important_ thing is that there is no binary support to >>>> packages that has vulns, >>>> and you have to rebuild them from ports. >>>> >>>> >>>> >>> Well, its one time doing a make package... >>> Even debian has no plus point there (at least in our environment at >>> >> work). >> >>> We pretty much always need our Apache 2 custom build, not the way the >>> Debian projects build it. Thus we have a Debian build box around and >>> >> build >> >>> our own Apache 2.2 package. >>> This is, indeed, the same amount of effort you would have when using >>> FreeBSD. >>> IMO the overhead in Debian to build a package is higher than in FreeBSD, >>> but YMMV. >>> >>> >> If you build packages from source then debian just sux (much more >> complex and long procedure), but there is a tell - "if you do it with >> debian - do it THE DEBIAN WAY"... :-). >> > I am doing it the debian way. Using the debian source package and try to > update from there. Still its a more complex procedure then upgrading a > FreeBSD port. > I just can't use the prebuilt debian packages. So where's the Debian way > from that point?! > deb-src ;-) that's why I like debian when using standartized .debs and prefer fbsd when need custom stuff. > >> I totally agree with that, but on all debian machines I use packages >> provided from debian, because they've made it very modular, >> and I was able to config them the way I need and everything is working >> for me. >> > You're lucky then :) > > >> In 99.99% of the cases when I do apt-get dist-upgrade the machine works >> like a charm after it, and that's a fact (in fbsd when make installworld >> too, but not for ports - which is the focus here). >> > Right. One should never mix up, that Debian is, well, a kernel and a whole > lot of software, whereas in FreeBSD you really have a line between the base > OS and later installed software (ports). > > agree :) >> Actually that's what *BSD prouds with - building everything from source >> (like gentoo), well it's a must to be simplified then (debian where >> everything is supposed to be used from bin .deb) :). >> >> > I really don't think that *BSD is proud about building everything from > source. Since we now even have freebsd-update to binary update FreeBSD > itself. And you usally find prebuilt packages too. > No, No. IMO FreeBSD isn't proud about building everything from source :) > > I do have that feeling about Gentoo users, though *g* > > about gentoo :) YES YES YES ~:) they are VERY proud to build everything from src... :) about fbsd - the most opinions I've heard are argumented with that you get 3-12% percents performance from building srcs with cpu and machine optimizations. That's why I said it. >> About the bug fixes, I think if that's a SECURITY backport it shouldn't >> fix bugs, because I've saw few devs deploying an app and the were using >> 'known bug' in ruby to work with. >> so they were unable to use higher version of ruby that got this bug >> fixed. (we'll obviously a developer mistake in design but if it's in a >> production will take months to redesign - not an option). >> > hhhmm... but then you're really in trouble. This is a situation... well, > hell no. I don't wanna be in this game. > A bug in a peace of software can lead to uncontrolled shutdown or could > even evolve into a security whole. > If possible I don't want bugs. > If there's an application which just runs with the buggy version of ruby > (perl, python, whatever), then lets start beating the devs. Literally > speaking ;) > > agree but when you host VPSes you can't beat the devs... :( >> Which is why maybe it's better not to fix bugs but just vulns in >> SECURITY backports (according to me of course) - if you need that bug >> fixed, then install new version. >> >> > Opinions really will vary on this topic. > In my MySQL example, we want to have the bugfixed version, 'cause those > bugs are really bad. > Same counts for Apache (not as often as MySQL, though). > > right, everything depends on the situations. >>> hhmm... I really can't agree on that statement. >>> If you do your admin work in a clean and sane way, most of the time >>> >> spend >> >>> for updating boxes is spent on testing the change before upgrading. The >>> difference between a "debuild" for building a new package, and then >>> >> apt-get >> >>> upgrade / update them on your box vs. "make package" and pkg_add -r them >>> >> on >> >>> your box is really slim... >>> >>> >>> >> If you build from src on debian - yes, but as I explained i use debian >> .debs and for me it's much faster, because on fbsd ports I have the >> problem described before, >> and is very common case to rebuild and rebuild port until it puts all >> the files in the .tgz :( >> > Well yes, thats true. > However, take a look at the Latest packages on FreeBSD's ftp mirror. There > are new versions available pretty often. > On the other hand, you said, you want to have the same version, just > security fixed. > Well, I bet the FreeBSD ports team just can't do that, due to a lack of > manpower. > Really. Throw in a whole lotta money to employ a few people, or do it your > own. > The existing team is doing a wonderful job in keeping the ports tree up to > date and trying to keep the pr-database as low as possible. > But from what I know the existing team really doesn't look like it can > handle -security branches of the ports tree. > > pretty often? I'm testing almost everytime when portaudit (resp. jailaudit) says there are vluns in some ports, and never get new fixed versions, anyway, I understand that there is not enough manpower that's why I simply say that I'm not satisfied with the current situation, but yes, the ports crew is making a great job. I'm not forcing anyone to do anything, I rescue myself how I can, simply telling my opinion. :) >> So, a story happened recently: >> I've had a disk down (ad2) of course it was in gmirror and the situation >> was 'ah, damn, but it's ok'... >> but... when I rebooted the server it occured that ad2 was ACTIVE and >> maybe last fresh and ad0 was DIRTY, >> ad2 didn't failed at 100% it was responding and found by the bios (and >> kernel) but when files were requested it timed out. >> The problem occured when tried to boot from the second disk (ad0) >> attached with ad2 (at this moment i didn't know that it fails when disk >> io occurs). >> because the ad2 was fresh and ad0 was dirty the gmirror failed to mount >> and boot OS because it was trying to sync data from partly failed disk, >> and it wasn't able to. >> I've shutdowned the machine, plugged out the ad2 disk and fired up again >> hoping gmirror will be smart enough to boot from ad0... but no luck, >> I was forced to mount root filesystem with no mirror (ad0s1a) and run >> the server in no mirror mode so I can have this critical machine running >> while I find a new disk (few hours later I got it). >> And the nightmare's just began... when I placed the new disk, the >> gmirrored volume was still trying to sync from ad2, ofcourse, the ad2 >> had no info on it (thanks god gmirror was smart enough to not copy the >> empty disk). >> I've had to rebuild the whole gmirror partiions, copy the info from a >> non-mirrored disk (ad0) and etc.etc... you know the procedure... this >> took me more than 10 hours and about 5hours downtime on a critical >> machine.... >> > Shocking story. huuu... > I can't comment on that story though, because > - at work, we're on Debian with hardware raids, no software raid even there > - my own experiments with gmirror never lead to such a scenario. I should > try to beat the disk to death, next time I test gmirror ;) > > >> I suppose this has something to do with the priority in gmirror but I >> don't have the broken disk to test - it's being replaced because it's in >> warranty.... but anyways... 10 hours lost and 5hours downtime... >> now I'm purchaseing a 3ware hw raid because I know that I can't trust >> gmirror... >> >> > We don't trust LVM and co either. > But don't ask me why. I believe it's more like a "feeling" than real facts. > So I better don't start to discuss this matter. > I've just got my 3ware raid, I'll get 2 more spare ones and I'm migrating to hw raids too. :) I think the same now. > > >> Another strange thing, I've used to use apache22-worker cutom compiled >> and thread_safe perl, the apache-worker stopped working on a jail (only >> on one!) and I had to add replacements ot pthread.so in /etc/libmap, >> I've been adviced not to use worker (as I did) but why the heck after >> upgrading from 6.3-STABLE to 6.3-STABLE-p3 I got my apache broken and >> also cron stopped working. >> > To few facts. Never happened to me and without details I really can't > comment. > > >> strange uh? and all this is in only one jail (I'm using ez-jail to >> update the world)... if anyone can help me to fix my cron without >> reinstalling this jail I'd be thanksful! >> >> > You should open another mail thread on that topic and try to gather as much > facts as you can. > same problem here, much less effort to migrate to apache22-prefork instead debugging :( - simply no time, I've posted a thread about cron but got stuck, because ktrace doesn't work for the debugging and that's a production and can't compile with debugging symbols.... > > Cheers, > Marian > > > cheer, valqk. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From gerrit at pmp.uni-hannover.de Thu Jun 12 09:21:24 2008 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Thu Jun 12 09:21:29 2008 Subject: broken re(4) In-Reply-To: <20080612070126.GF7250@cdnetworks.co.kr> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <3C916EEA-5A2B-4C88-B834-0F47D7D525FA@gmail.com> <20080611092457.82c83083.gerrit@pmp.uni-hannover.de> <20080612032228.GD7250@cdnetworks.co.kr> <20080612085810.072d705d.gerrit@pmp.uni-hannover.de> <20080612070126.GF7250@cdnetworks.co.kr> Message-ID: <20080612112120.d1b8d059.gerrit@pmp.uni-hannover.de> On Thu, 12 Jun 2008 16:01:26 +0900 Pyun YongHyeon wrote about Re: broken re(4): PY> > I already did simple benchmarking by using "dd if=/dev/zero PY> > of=file" which gave me several 10s of MByte/s under all PY> > circumstances. Can you recommend one of the benchmarking programs PY> > for more detailed testing? PY> Try netperf or iperf in ports/benchmark. The machine in question as client: ------------------------------------------------------------ Client connecting to 130.75.117.1, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local 130.75.117.112 port 56513 connected with 130.75.117.1 port 5001 [ 3] 0.0-10.0 sec 211 MBytes 177 Mbits/sec On the server side: ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 64.0 KByte (default) ------------------------------------------------------------ [ 4] local 130.75.117.1 port 5001 connected with 130.75.117.112 port 56513 [ 4] 0.0-10.3 sec 211 MBytes 172 Mbits/sec As server: ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 64.0 KByte (default) ------------------------------------------------------------ [ 4] local 130.75.117.112 port 5001 connected with 130.75.117.1 port 53843 [ 4] 0.0-10.1 sec 399 MBytes 331 Mbits/sec On the client side: ------------------------------------------------------------ Client connecting to 130.75.117.112, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local 130.75.117.1 port 53843 connected with 130.75.117.112 port 5001 [ 3] 0.0-10.1 sec 399 MBytes 331 Mbits/sec Hm, being a server seems to work better? The machine on the other side is also having a re-interface and usually transfers data with 20-30MByte/s. The ITX machine I'm testing is using both of it's re-interfaces in a lagg-configuration right now (laggproto loadbalance). Is this the expected performance? cu Gerrit From gavin at FreeBSD.org Thu Jun 12 09:49:17 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Thu Jun 12 09:49:22 2008 Subject: Adesso AKB-430UG keyboard on 7.0 In-Reply-To: <4850DCA8.6000709@classic-games.com> References: <4850DCA8.6000709@classic-games.com> Message-ID: <1213264148.65108.6.camel@buffy.york.ac.uk> On Thu, 2008-06-12 at 03:22 -0500, Greg Miller wrote: > I'm using an AKB-430UG USB keyboard ("Win-Touch Pro") on FreeBSD > 7.0-release-p1, or trying to. The keyboard works fine in Windows, but > with FreeBSD I get the same sort of problems people have described > previous with the Genius SlimStar Pro: the keys behave as if CTRL is > always pressed. > > I'd hate to have to switch to a different keyboard, because it took me > years to find a good alternative to my old Cirque Input Center > keyboard/glidepoint combo. Can you try the following patch please? --- ukbd.c 2008-06-02 14:09:45.000000000 +0100 +++ ukbd.c 2008-06-12 10:44:16.000000000 +0100 @@ -1423,6 +1423,7 @@ init_keyboard(ukbd_state_t *state, int *type, int flags) { usb_endpoint_descriptor_t *ed; + usbd_status err; *type = KB_OTHER; @@ -1447,6 +1448,14 @@ printf("ukbd: unexpected endpoint\n"); return EINVAL; } + + err = usbd_set_protocol(state->ks_iface, 0); + if (err) { + printf("ukbd: set boot protocol failed\n"); + return EIO; + } else { + DPRINTFN(5, ("boot protocol set\n")); + } /* Ignore if SETIDLE fails since it is not crucial. */ usbd_set_idle(state->ks_iface, 0, 0); Thanks, Gavin From gmiller at classic-games.com Thu Jun 12 10:42:24 2008 From: gmiller at classic-games.com (Greg Miller) Date: Thu Jun 12 10:42:28 2008 Subject: Adesso AKB-430UG keyboard on 7.0 In-Reply-To: <1213264148.65108.6.camel@buffy.york.ac.uk> References: <4850DCA8.6000709@classic-games.com> <1213264148.65108.6.camel@buffy.york.ac.uk> Message-ID: <4850FD50.10503@classic-games.com> Gavin Atkinson wrote: > On Thu, 2008-06-12 at 03:22 -0500, Greg Miller wrote: >> I'm using an AKB-430UG USB keyboard ("Win-Touch Pro") on FreeBSD >> 7.0-release-p1, or trying to. The keyboard works fine in Windows, but >> with FreeBSD I get the same sort of problems people have described >> previous with the Genius SlimStar Pro: the keys behave as if CTRL is >> always pressed. > Can you try the following patch please? With this patch, it works great as a keyboard. However, the GlidePoint touchpad isn't being detected as a USB mouse and the data is being interpreted as keystrokes. From gavin at FreeBSD.org Thu Jun 12 10:51:33 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Thu Jun 12 10:51:38 2008 Subject: Adesso AKB-430UG keyboard on 7.0 In-Reply-To: <4850FD50.10503@classic-games.com> References: <4850DCA8.6000709@classic-games.com> <1213264148.65108.6.camel@buffy.york.ac.uk> <4850FD50.10503@classic-games.com> Message-ID: <1213267885.65108.8.camel@buffy.york.ac.uk> On Thu, 2008-06-12 at 05:41 -0500, Greg Miller wrote: > Gavin Atkinson wrote: > > > On Thu, 2008-06-12 at 03:22 -0500, Greg Miller wrote: > >> I'm using an AKB-430UG USB keyboard ("Win-Touch Pro") on FreeBSD > >> 7.0-release-p1, or trying to. The keyboard works fine in Windows, but > >> with FreeBSD I get the same sort of problems people have described > >> previous with the Genius SlimStar Pro: the keys behave as if CTRL is > >> always pressed. > > > > Can you try the following patch please? > > With this patch, it works great as a keyboard. However, the GlidePoint > touchpad isn't being detected as a USB mouse and the data is being > interpreted as keystrokes. Can you confirm that the GlidePoint was working correctly before the patch? Gavin From rb at gid.co.uk Thu Jun 12 10:53:59 2008 From: rb at gid.co.uk (Bob Bishop) Date: Thu Jun 12 10:54:03 2008 Subject: PAE vs USB Message-ID: <27CFC8F5-F83E-445D-A430-24C3E76A5B72@gid.co.uk> Hi, Is anyone successfully using USB (particularly umass) under PAE on 7.0R? Or, can anyone say for sure that it's not safe? TIA -- Bob Bishop +44 (0)118 940 1243 rb@gid.co.uk fax +44 (0)118 940 1295 From ivoras at freebsd.org Thu Jun 12 10:57:09 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Jun 12 10:57:13 2008 Subject: PAE vs USB In-Reply-To: <27CFC8F5-F83E-445D-A430-24C3E76A5B72@gid.co.uk> References: <27CFC8F5-F83E-445D-A430-24C3E76A5B72@gid.co.uk> Message-ID: Bob Bishop wrote: > Hi, > > Is anyone successfully using USB (particularly umass) under PAE on 7.0R? > > Or, can anyone say for sure that it's not safe? TIA I'm using it on 6-STABLE (PAE+SMP). No problems so far, but it's not very heavily used. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080612/6075e2d2/signature.pgp From lists at pingle.org Thu Jun 12 11:21:31 2008 From: lists at pingle.org (Jim Pingle) Date: Thu Jun 12 11:21:42 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <200806121445.30864.doconnor@gsoft.com.au> References: <4846B64F.4090700@minibofh.org> <200806121118.45137.doconnor@gsoft.com.au> <48509419.6060206@pingle.org> <200806121445.30864.doconnor@gsoft.com.au> Message-ID: <485106B6.7050805@pingle.org> Daniel O'Connor wrote: > On Thu, 12 Jun 2008, Jim Pingle wrote: >> I need to see if I can improve the script any (suggestions are most >> welcome) then open a PR to see if it -- or logic like it -- can be >> included in the php-extensions meta port. > > Adding the script to the port seems like the way to go (baring an > upstream fix but it seems like a difficult problem to solve). > > Unfortunately it doesn't help me :( > If I disable everything except either pgsql or mhash (either separately > or together) Apache crashes with.. > > #0 0x28ad6d40 in ?? () > #1 0x281c6f2e in _pthread_main_np () from /lib/libc.so.7 > #2 0x2819fa0c in puts () from /lib/libc.so.7 > #3 0x281a0177 in gethostbyname () from /lib/libc.so.7 > #4 0x08069a12 in ap_get_local_host () > #5 0x08068b9c in ap_fini_vhost_config () > #6 0x0805639c in ap_read_config () > #7 0x0805f133 in standalone_main () > #8 0x08060c1f in main () > > I don't understand why gethostbyname() would call puts() - and why that > would then crash! > > Seems like some threading related wrinkle though as pgsql & mhash are > the only extensions I have that are linked to libthr.so > I'm afraid I wouldn't be much help with this one in that case. I have a vague recollection of gethostbyname() crashing for someone else, though. I thought it had something to do with the ServerName directive and/or an entry in /etc/hosts -- but unfortunately I don't recall the specifics and my Google-fu seems to be failing me this morning. Jim From andrewd at webzone.net.au Thu Jun 12 12:57:43 2008 From: andrewd at webzone.net.au (Andrew D) Date: Thu Jun 12 12:57:49 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <485106B6.7050805@pingle.org> References: <4846B64F.4090700@minibofh.org> <200806121118.45137.doconnor@gsoft.com.au> <48509419.6060206@pingle.org> <200806121445.30864.doconnor@gsoft.com.au> <485106B6.7050805@pingle.org> Message-ID: <48511ABE.9040207@webzone.net.au> Jim Pingle wrote: > Daniel O'Connor wrote: >> On Thu, 12 Jun 2008, Jim Pingle wrote: >>> I need to see if I can improve the script any (suggestions are most >>> welcome) then open a PR to see if it -- or logic like it -- can be >>> included in the php-extensions meta port. >> >> Adding the script to the port seems like the way to go (baring an >> upstream fix but it seems like a difficult problem to solve). >> >> Unfortunately it doesn't help me :( >> If I disable everything except either pgsql or mhash (either >> separately or together) Apache crashes with.. >> >> #0 0x28ad6d40 in ?? () >> #1 0x281c6f2e in _pthread_main_np () from /lib/libc.so.7 >> #2 0x2819fa0c in puts () from /lib/libc.so.7 >> #3 0x281a0177 in gethostbyname () from /lib/libc.so.7 >> #4 0x08069a12 in ap_get_local_host () >> #5 0x08068b9c in ap_fini_vhost_config () >> #6 0x0805639c in ap_read_config () >> #7 0x0805f133 in standalone_main () >> #8 0x08060c1f in main () >> >> I don't understand why gethostbyname() would call puts() - and why >> that would then crash! >> >> Seems like some threading related wrinkle though as pgsql & mhash are >> the only extensions I have that are linked to libthr.so >> > > I'm afraid I wouldn't be much help with this one in that case. I have a > vague recollection of gethostbyname() crashing for someone else, though. > I thought it had something to do with the ServerName directive and/or an > entry in /etc/hosts -- but unfortunately I don't recall the specifics > and my Google-fu seems to be failing me this morning. > I'm 99.5% sure that the ServerName Directive has to resolve. > Jim > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From doconnor at gsoft.com.au Thu Jun 12 13:16:17 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Jun 12 13:16:22 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <485106B6.7050805@pingle.org> References: <4846B64F.4090700@minibofh.org> <200806121445.30864.doconnor@gsoft.com.au> <485106B6.7050805@pingle.org> Message-ID: <200806122246.09852.doconnor@gsoft.com.au> On Thu, 12 Jun 2008, Jim Pingle wrote: > > Seems like some threading related wrinkle though as pgsql & mhash > > are the only extensions I have that are linked to libthr.so > > I'm afraid I wouldn't be much help with this one in that case. I have > a vague recollection of gethostbyname() crashing for someone else, > though. I thought it had something to do with the ServerName > directive and/or an entry in /etc/hosts -- but unfortunately I don't > recall the specifics and my Google-fu seems to be failing me this > morning. I did some googling on the stack trace and found.. http://www.nabble.com/php5-and-postgresql-8.2-8.3-td16744979.html I think I'll try switching to Apache 2.. (Right after I upgrade my mail system so I can ditch any 6.x cruft ) -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080612/caae0382/attachment.pgp From ivoras at freebsd.org Thu Jun 12 14:05:54 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Jun 12 14:06:02 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <485106B6.7050805@pingle.org> References: <4846B64F.4090700@minibofh.org> <200806121118.45137.doconnor@gsoft.com.au> <48509419.6060206@pingle.org> <200806121445.30864.doconnor@gsoft.com.au> <485106B6.7050805@pingle.org> Message-ID: Jim Pingle wrote: >> Seems like some threading related wrinkle though as pgsql & mhash are >> the only extensions I have that are linked to libthr.so Do you really need threading in pgsql and mhash? Some years ago I had the same problem with apache crashing misterously (not on restart, though) which I've traced to having threading libraries hard-referenced in PHP libraries. If you're not absolutely sure you need it, remove threading libraries from your PHP libraries (for pgsql there's a make config option). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080612/14f1d8a5/signature.pgp From scf at FreeBSD.org Thu Jun 12 15:05:14 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Thu Jun 12 15:05:20 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <200806121118.45137.doconnor@gsoft.com.au> References: <4846B64F.4090700@minibofh.org> <484FF478.8010405@minibofh.org> <20080611161048.GA66773@eos.sc1.parodius.com> <200806121118.45137.doconnor@gsoft.com.au> Message-ID: On Thu, 12 Jun 2008, Daniel O'Connor wrote: > On Thu, 12 Jun 2008, Jeremy Chadwick wrote: >> I myself haven't ever run into extension ordering issues like those >> described (and we've done hosting for years), but I don't doubt those >> who have experienced such. > > I am currently experiencing this :( In the past I shuffled the order > until it worked but that's not a real solution. > > Also if you have gone from 6.x to 7.x make sure that you don't have > any old stuff linked against libc.so.6 loaded into a binary using > libc.so.7. > > It mostly works except with threaded programs and then *kaboom* Also, please try rebuilding PHP5 that has this fix[1] (in ports tree after June 9th). It may or may not help your issue. Sean 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/123911 -- scf@FreeBSD.org From fbsd2 at yahoo.com Thu Jun 12 15:29:13 2008 From: fbsd2 at yahoo.com (fbsd2) Date: Thu Jun 12 15:33:47 2008 Subject: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ? Message-ID: <372128.56919.qm@web51502.mail.re2.yahoo.com> Greetings list, Given recent EOL announcements, I'm trying to upgrade an ancient machine from 5.5 to 7. It has 80 Mb total in the root partition, /home/, /var/, /usr/, and /tmp/ on other partitions, and NFS mounts /usr/src, /usr/obj, and /usr/ports from a slightly newer/faster box. I've seen http://www.freebsd.org/releases/7.0R/relnotes.html and http://marc.info/?l=freebsd-stable&m=121278826119286&w=2 which seem to suggest that even with INSTALL_NODEBUG during buildkernel, 7 might not fit in an 80 Mb /. Must I partition a new disk to give more space to /, or can I find more space by deleting /stand/, /modules/, and possibly /rescue/ to shoehorn a custom 7.x kernel in the available space? TIA Alex __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mistry.7 at osu.edu Thu Jun 12 18:33:16 2008 From: mistry.7 at osu.edu (Anish Mistry) Date: Thu Jun 12 18:33:21 2008 Subject: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ? In-Reply-To: <372128.56919.qm@web51502.mail.re2.yahoo.com> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> Message-ID: <200806121416.46040.mistry.7@osu.edu> On Thursday 12 June 2008, fbsd2 wrote: > Greetings list, > > Given recent EOL announcements, I'm trying to upgrade an ancient > machine from 5.5 to 7. It has 80 Mb total in the root partition, > /home/, /var/, /usr/, and /tmp/ on other partitions, and NFS mounts > /usr/src, /usr/obj, and /usr/ports from a slightly newer/faster > box. I've seen > > http://www.freebsd.org/releases/7.0R/relnotes.html and > http://marc.info/?l=freebsd-stable&m=121278826119286&w=2 > > which seem to suggest that even with INSTALL_NODEBUG during > buildkernel, 7 might not fit in an 80 Mb /. Must I partition a new > disk to give more space to /, or can I find more space by deleting > /stand/, /modules/, and possibly /rescue/ to shoehorn a custom 7.x > kernel in the available space? TIA It should fit, though you may have issues with kernel.old pushing you over the limit. -- Anish Mistry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080612/5be531ac/attachment.pgp From illoai at gmail.com Thu Jun 12 18:42:06 2008 From: illoai at gmail.com (illoai@gmail.com) Date: Thu Jun 12 18:42:09 2008 Subject: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ? In-Reply-To: <372128.56919.qm@web51502.mail.re2.yahoo.com> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> Message-ID: 2008/6/12 fbsd2 : > Greetings list, > > Given recent EOL announcements, I'm trying to upgrade an ancient machine from 5.5 to 7. It has 80 Mb total in the root partition, /home/, /var/, /usr/, and /tmp/ on other partitions, and NFS mounts /usr/src, /usr/obj, and /usr/ports from a slightly newer/faster box. I've seen > > http://www.freebsd.org/releases/7.0R/relnotes.html and > http://marc.info/?l=freebsd-stable&m=121278826119286&w=2 > > which seem to suggest that even with INSTALL_NODEBUG during buildkernel, 7 might not fit in an 80 Mb /. Must I partition a new disk to give more space to /, or can I find more space by deleting /stand/, /modules/, and possibly /rescue/ to shoehorn a custom 7.x kernel in the available space? TIA > If you know you do not need the modules, by all means, to do away with them is space back to you. If you are building from source, you can use the: MODULES_OVERRIDE= variable in /etc/make.conf When you are at the # make installworld stage you can likely delete /stand (I believe it is not used on >=6.x) (Though I am not sitting at the machine now) I believe that / on my 7.x box is about 46M. -- -- From attos.janus at gmail.com Thu Jun 12 20:35:25 2008 From: attos.janus at gmail.com (Attos) Date: Thu Jun 12 20:35:29 2008 Subject: How to upgrade openssl after upgrading from 6.2 to 7.0 In-Reply-To: <5297d6fd0806111510p15358eb0idc03c81d9fe38e87@mail.gmail.com> References: <5297d6fd0806111510p15358eb0idc03c81d9fe38e87@mail.gmail.com> Message-ID: <5297d6fd0806121308s3c5185ebs9717b8c14f7a7deb@mail.gmail.com> Hello list, I just upgraded my workstation from 6.2 to 7.0 but I haven't been able to upgrade all the ports. OpenSSL is giving me problems when trying to upgrade (with portupgrade). The message I get is that the it's marked as ignore because it conflicts with the base: # portupgrade security/openssl-stable ** Port marked as IGNORE: security/openssl-stable: Conflicts with version in the base ** Listing the failed packages (-:ignored / *:skipped / !:failed) - security/openssl-stable (marked as IGNORE) How do I fix this? TIA -- Attos Janus From oberman at es.net Thu Jun 12 20:56:30 2008 From: oberman at es.net (Kevin Oberman) Date: Thu Jun 12 20:56:33 2008 Subject: How to upgrade openssl after upgrading from 6.2 to 7.0 In-Reply-To: Your message of "Thu, 12 Jun 2008 16:08:33 EDT." <5297d6fd0806121308s3c5185ebs9717b8c14f7a7deb@mail.gmail.com> Message-ID: <20080612205629.3D0ED4500E@ptavv.es.net> > Date: Thu, 12 Jun 2008 16:08:33 -0400 > From: Attos > Sender: owner-freebsd-stable@freebsd.org > > Hello list, > I just upgraded my workstation from 6.2 to 7.0 but I haven't been able > to upgrade all the ports. > OpenSSL is giving me problems when trying to upgrade (with > portupgrade). The message I get is that the it's marked as ignore > because it conflicts with the base: > > # portupgrade security/openssl-stable > ** Port marked as IGNORE: security/openssl-stable: > Conflicts with version in the base > ** Listing the failed packages (-:ignored / *:skipped / !:failed) > - security/openssl-stable (marked as IGNORE) > > How do I fix this? You don't. openssl-stable is the same version of openssl that is already in the base system in 7.0, so you should remove the port (pkg_deinstall openssl-\*). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080612/822d805e/attachment.pgp From patfbsd at davenulle.org Thu Jun 12 23:08:31 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Thu Jun 12 23:08:35 2008 Subject: [7-STABLE] ping -s 4000 with ipsec panic Message-ID: <20080613004847.09f9b089@baby-jane-lamaiziere-net.local> [FreeBSD 7-STABLE/i386] Hello, I've got a 100 % reproductible panic with ipsec when using a 'ping -s 4000'. It works without ipsec My ipsec setup is very simple, i just use setkey: /etc/ipsec.conf flush; spdflush; add 192.168.1.21 192.168.1.200 esp 1011 -E rijndael-cbc "0123456789012345"; add 192.168.1.200 192.168.1.21 esp 1012 -E rijndael-cbc "0123456789012345"; spdadd 192.168.1.200 192.168.1.21 any -P out ipsec esp/transport//require; spdadd 192.168.1.21 192.168.1.200 any -P in ipsec esp/transport//require; I tried to use des-cbc with the same panic. -------------------- Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4100be00 fault code = supervisor read, page not present instruction pointer = 0x20:0xc079985e stack pointer = 0x28:0xd61a0744 frame pointer = 0x28:0xd61a076c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1175 (ping) trap number = 12 panic: page fault Uptime: 9m5s Physical memory: 503 MB Dumping 87 MB: 72 56 40 24 8 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0556273 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc055646f in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc079b91c in trap_fatal (frame=0xd61a0704, eva=1090567680) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc079bba0 in trap_pfault (frame=0xd61a0704, usermode=0, eva=1090567680) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc079c529 in trap (frame=0xd61a0704) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0789f2b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc079985e in generic_bcopy () at /usr/src/sys/i386/i386/support.s:498 #8 0xc1f7267e in ?? () #9 0x8fb82d87 in ?? () #10 0x361fe9de in ?? () #11 0x39402686 in ?? () #12 0x00000fa0 in ?? () #13 0xc29cf380 in ?? () #14 0xc2ea9654 in ?? () #15 0x00000000 in ?? () #16 0xd61a095c in ?? () #17 0xc0700746 in crypto_invoke (cap=0x8, crp=0xd61a0950, hint=-1616994916) at cryptodev_if.h:53 Previous frame inner to this frame (corrupt stack?) (kgdb) ------------- Thansk, regards. From kris at FreeBSD.org Thu Jun 12 23:57:36 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu Jun 12 23:57:39 2008 Subject: [7-STABLE] ping -s 4000 with ipsec panic In-Reply-To: <20080613004847.09f9b089@baby-jane-lamaiziere-net.local> References: <20080613004847.09f9b089@baby-jane-lamaiziere-net.local> Message-ID: <4851B7EF.7060905@FreeBSD.org> Patrick Lamaizi?re wrote: > generic_bcopy () at /usr/src/sys/i386/i386/support.s:498 #8 0xc1f7267e > in ?? () #9 0x8fb82d87 in ?? () > #10 0x361fe9de in ?? () > #11 0x39402686 in ?? () > #12 0x00000fa0 in ?? () > #13 0xc29cf380 in ?? () > #14 0xc2ea9654 in ?? () > #15 0x00000000 in ?? () > #16 0xd61a095c in ?? () > #17 0xc0700746 in crypto_invoke (cap=0x8, crp=0xd61a0950, > hint=-1616994916) at cryptodev_if.h:53 > Previous frame inner to this frame (corrupt stack?) > (kgdb) Unfortunately the trace is bogus. Try to rebuild with -O instead of -O2 and reproduce the panic. Kris From pldrouin at pldrouin.net Fri Jun 13 06:04:05 2008 From: pldrouin at pldrouin.net (Pierre-Luc Drouin) Date: Fri Jun 13 06:04:10 2008 Subject: boot0 is hanging... Message-ID: <48520DD5.7080409@pldrouin.net> Hi, I just did two different installations of 7.0-stable on a new machine and I have some issues with the boot0 boot loader. I have two identical drives on that machine. The first two slices on the drives are supposed to be bootable and they are mirrored with gmirror: gmirror label -v -h -b load boot1 ad4s1a ad6s1a gmirror label -v -h -b load boot2 ad6s2a ad4s2a The problem I have is that I can only boot the second slice from ad6, not from ad4. boot0 does nothing when I press F2 from the menu for the first drive. I don't get any error message. It does nothing until I select another item in the menu. I can boot the first slice from either ad4 or ad6. I have tried rebuilding the raid and changing the priority of the drive with gmirror, but it didn't change anything. I also tried to remove ad6s2a from the mirror, but it didn't fix it either. To install boot0, I used: sysctl kern.geom.debugflags=16 boot0cfg -B -m 0x3 -s 1 ad4 boot0cfg -B -m 0x3 -s 1 ad6 What could be causing this exactly? Thank you! From jespasac at minibofh.org Fri Jun 13 07:15:03 2008 From: jespasac at minibofh.org (Jordi Espasa Clofent) Date: Fri Jun 13 07:15:08 2008 Subject: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED] In-Reply-To: <20080611161048.GA66773@eos.sc1.parodius.com> References: <4846B64F.4090700@minibofh.org> <484775D4.4090509@p6m7g8.com> <48481A02.2050502@minibofh.org> <484FF478.8010405@minibofh.org> <20080611161048.GA66773@eos.sc1.parodius.com> Message-ID: <48521E74.90708@minibofh.org> > Many people have reported that the *order* of the extensions in > extensions.ini has adverse (positive) effects on PHP segfaults on > FreeBSD. > > I myself haven't ever run into extension ordering issues like those > described (and we've done hosting for years), but I don't doubt those > who have experienced such. Yes Jeremy, I known. I also don't doubt your words, but in my case the order of the extensions seems not any effect. The only solution has been comment the mentioned mbash extension. -- Thanks, Jordi Espasa Clofent From gmiller at classic-games.com Fri Jun 13 08:57:32 2008 From: gmiller at classic-games.com (Greg Miller) Date: Fri Jun 13 08:57:36 2008 Subject: Adesso AKB-430UG keyboard on 7.0 In-Reply-To: <1213267885.65108.8.camel@buffy.york.ac.uk> References: <4850DCA8.6000709@classic-games.com> <1213264148.65108.6.camel@buffy.york.ac.uk> <4850FD50.10503@classic-games.com> <1213267885.65108.8.camel@buffy.york.ac.uk> Message-ID: <48523634.4000909@classic-games.com> Gavin Atkinson wrote: > On Thu, 2008-06-12 at 05:41 -0500, Greg Miller wrote: >> Gavin Atkinson wrote: >> >>> On Thu, 2008-06-12 at 03:22 -0500, Greg Miller wrote: >>>> I'm using an AKB-430UG USB keyboard ("Win-Touch Pro") on FreeBSD >>>> 7.0-release-p1, or trying to. The keyboard works fine in Windows, but >>>> with FreeBSD I get the same sort of problems people have described >>>> previous with the Genius SlimStar Pro: the keys behave as if CTRL is >>>> always pressed. >> >>> Can you try the following patch please? >> With this patch, it works great as a keyboard. However, the GlidePoint >> touchpad isn't being detected as a USB mouse and the data is being >> interpreted as keystrokes. > > Can you confirm that the GlidePoint was working correctly before the > patch? No. Connecting the keyboard generates a console message indicating the ukbd device attached, but doesn't generate a ums attach message, so I'm thinking that it doesn't work with or without the patch. -- http://www.velocityvector.com/ | http://www.classic-games.com/ I'd rather hunt with Dick Cheney than ride with Ted Kennedy. From timothy.wilson87 at gmail.com Fri Jun 13 09:06:46 2008 From: timothy.wilson87 at gmail.com (Timothy Wilson) Date: Fri Jun 13 09:06:51 2008 Subject: ZFS version 8 on stable? Message-ID: Hello everyone, I know -stable is supposed to be, well, stable, but I seem to be in a bit of a pickle. I'm trying to import my zfs file system from a Macintosh machine. It was created at version 8. Being new to zfs, I did not realise that FreeBSD would be running at a lower version; I thought zfs was zfs! Of course, trying to import my zpool fails, complaining that the version is too new. freebsd# zpool import bigstore cannot import 'bigstore': pool is formatted using a newer ZFS version So either I want to downgrade the zpool, or upgrade zfs on FreeBSD. Does anyone know if I'll be able to import zfs v8, or am I wasting my time? I'd prefer to follow -stable, but if I must follow -current, then golly goshkins, I'll have no choice! Kind regards, Timothy. From koitsu at FreeBSD.org Fri Jun 13 09:32:25 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Jun 13 09:32:29 2008 Subject: ZFS version 8 on stable? In-Reply-To: References: Message-ID: <20080613093225.GA45459@eos.sc1.parodius.com> On Fri, Jun 13, 2008 at 06:40:22PM +1000, Timothy Wilson wrote: > Hello everyone, > > I know -stable is supposed to be, well, stable, but I seem to be in a > bit of a pickle. > > I'm trying to import my zfs file system from a Macintosh machine. It > was created at version 8. Being new to zfs, I did not realise that > FreeBSD would be running at a lower version; I thought zfs was zfs! Of > course, trying to import my zpool fails, complaining that the version > is too new. > > freebsd# zpool import bigstore > cannot import 'bigstore': pool is formatted using a newer ZFS version > > So either I want to downgrade the zpool, or upgrade zfs on FreeBSD. > Does anyone know if I'll be able to import zfs v8, or am I wasting my > time? I'd prefer to follow -stable, but if I must follow -current, > then golly goshkins, I'll have no choice! I don't know what the current migration status is of ZFS on FreeBSD to a newer version. I don't think -CURRENT/HEAD has a newer ZFS either, so I think you're out of luck with regards to an "easy" migration. If I was in your shoes, I would not downgrade the pool -- I would simply stop using ZFS and use a filesystem that is fully compatible between OS X and FreeBSD. *cue someone chiming in with the usual "ZFS is experimental on FreeBSD, blah blah blah" rhetoric* :-) Summary: you're out of luck. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From kris at FreeBSD.org Fri Jun 13 09:54:04 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Fri Jun 13 09:54:11 2008 Subject: ZFS version 8 on stable? In-Reply-To: References: Message-ID: <485243BB.7050604@FreeBSD.org> Timothy Wilson wrote: > Hello everyone, > > I know -stable is supposed to be, well, stable, but I seem to be in a > bit of a pickle. > > I'm trying to import my zfs file system from a Macintosh machine. It > was created at version 8. Being new to zfs, I did not realise that > FreeBSD would be running at a lower version; I thought zfs was zfs! Of > course, trying to import my zpool fails, complaining that the version > is too new. > > freebsd# zpool import bigstore > cannot import 'bigstore': pool is formatted using a newer ZFS version > > So either I want to downgrade the zpool, or upgrade zfs on FreeBSD. > Does anyone know if I'll be able to import zfs v8, or am I wasting my > time? I'd prefer to follow -stable, but if I must follow -current, > then golly goshkins, I'll have no choice! It is planned to update to a newer ZFS release in HEAD, but this has not happened yet (let alone in 7.x). I don't know if it is possible to downgrade a pool - you should check the ZFS documentation/support materials. Kris From kometen at gmail.com Fri Jun 13 09:56:21 2008 From: kometen at gmail.com (Claus Guttesen) Date: Fri Jun 13 09:56:26 2008 Subject: ZFS version 8 on stable? In-Reply-To: <20080613093225.GA45459@eos.sc1.parodius.com> References: <20080613093225.GA45459@eos.sc1.parodius.com> Message-ID: >> So either I want to downgrade the zpool, or upgrade zfs on FreeBSD. >> Does anyone know if I'll be able to import zfs v8, or am I wasting my >> time? I'd prefer to follow -stable, but if I must follow -current, >> then golly goshkins, I'll have no choice! > > I don't know what the current migration status is of ZFS on FreeBSD to a > newer version. I don't think -CURRENT/HEAD has a newer ZFS either, so I > think you're out of luck with regards to an "easy" migration. > > If I was in your shoes, I would not downgrade the pool -- I would simply > stop using ZFS and use a filesystem that is fully compatible between OS > X and FreeBSD. *cue someone chiming in with the usual "ZFS is > experimental on FreeBSD, blah blah blah" rhetoric* :-) I tried to create a zfs-pool on Solaris and was unable to import it to FreeBSD. So there are still some issues in relation to OS-platform-migrations. But other than that is this not a somewhat pessimistic approach not to try things out? :-) Many years ago (os x 10.0 or 10.1 I think) I tried to create an UFS-volume on os x but this was not recognized by FreeBSD (ver. 4.x). What other fs-type will work between os x and FreeBSD? FAT comes to my mind. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From dick at nagual.nl Fri Jun 13 10:07:55 2008 From: dick at nagual.nl (dick hoogendijk) Date: Fri Jun 13 10:08:01 2008 Subject: ZFS version 8 on stable? In-Reply-To: References: Message-ID: <26867.82.92.9.111.1213351707.squirrel@nagual.nl> Timothy Wilson wrote: > I'm trying to import my zfs file system from a Macintosh machine. It > was created at version 8. Being new to zfs, I did not realise that > FreeBSD would be running at a lower version; I thought zfs was zfs! Of > course, trying to import my zpool fails, complaining that the version > is too new. Have you tried to send a snapshot on you Mac and receive that snapshot on your FreeBSD machine? -- Dick Hoogendijk -- PGP/GnuPG key: F86289CE ++ http://nagual.nl/ | SunOS 10u5 05/08 ++ From pldrouin at pldrouin.net Fri Jun 13 12:34:43 2008 From: pldrouin at pldrouin.net (Pierre-Luc Drouin) Date: Fri Jun 13 12:34:48 2008 Subject: boot0 is hanging... Message-ID: <4852695D.5030206@pldrouin.net> Hi, I just did two different installations of 7.0-stable on a new machine and I have some issues with the boot0 boot loader. I have two identical drives on that machine. The first two slices on the drives are supposed to be bootable and they are mirrored with gmirror: gmirror label -v -h -b load boot1 ad4s1a ad6s1a gmirror label -v -h -b load boot2 ad6s2a ad4s2a The problem I have is that I can only boot the second slice from ad6, not from ad4. boot0 does nothing when I press F2 from the menu for the first drive. I don't get any error message. It does nothing until I select another item in the menu. I can boot the first slice from either ad4 or ad6. I have tried rebuilding the raid and changing the priority of the drive with gmirror, but it didn't change anything. I also tried to remove ad6s2a from the mirror, but it didn't fix it either. To install boot0, I used: sysctl kern.geom.debugflags=16 boot0cfg -B -m 0x3 -s 1 ad4 boot0cfg -B -m 0x3 -s 1 ad6 What could be causing this exactly? Thank you! From lists at loveturtle.net Fri Jun 13 14:13:25 2008 From: lists at loveturtle.net (Dillon Kass) Date: Fri Jun 13 14:13:29 2008 Subject: ZFS version 8 on stable? In-Reply-To: References: Message-ID: <48527C29.20508@loveturtle.net> There's nothing you can do right now except for wait. By default the zfs implementation on osx will create a zfs version 6 zpool (to retain compat with the read-only kext that ships with 10.5) but once you've upgraded you can't go back. There is a newer version of zfs for freebsd but it hasn't been commited yet. See http://kerneltrap.org/FreeBSD/BSDCan_2008_ZFS_Internals Your only option is to wait until this is committed or patches are offered at least. pjd is the man so it shouldn't be too long :-) Timothy Wilson wrote: > Hello everyone, > > I know -stable is supposed to be, well, stable, but I seem to be in a > bit of a pickle. > > I'm trying to import my zfs file system from a Macintosh machine. It > was created at version 8. Being new to zfs, I did not realise that > FreeBSD would be running at a lower version; I thought zfs was zfs! Of > course, trying to import my zpool fails, complaining that the version > is too new. > > freebsd# zpool import bigstore > cannot import 'bigstore': pool is formatted using a newer ZFS version > > So either I want to downgrade the zpool, or upgrade zfs on FreeBSD. > Does anyone know if I'll be able to import zfs v8, or am I wasting my > time? I'd prefer to follow -stable, but if I must follow -current, > then golly goshkins, I'll have no choice! > > Kind regards, > Timothy. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From rwatson at FreeBSD.org Fri Jun 13 21:16:18 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Jun 13 21:16:23 2008 Subject: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ? In-Reply-To: <372128.56919.qm@web51502.mail.re2.yahoo.com> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> Message-ID: <20080613221247.J95545@fledge.watson.org> On Thu, 12 Jun 2008, fbsd2 wrote: > Given recent EOL announcements, I'm trying to upgrade an ancient machine > from 5.5 to 7. It has 80 Mb total in the root partition, /home/, /var/, > /usr/, and /tmp/ on other partitions, and NFS mounts /usr/src, /usr/obj, and > /usr/ports from a slightly newer/faster box. I've seen > > http://www.freebsd.org/releases/7.0R/relnotes.html and > http://marc.info/?l=freebsd-stable&m=121278826119286&w=2 > > which seem to suggest that even with INSTALL_NODEBUG during buildkernel, 7 > might not fit in an 80 Mb /. Must I partition a new disk to give more space > to /, or can I find more space by deleting /stand/, /modules/, and possibly > /rescue/ to shoehorn a custom 7.x kernel in the available space? TIA My Kerberos server runs 7-STABLE and has a 93M root with 25M free. It's a bit tight -- I have to remember to disable the installation of debugging symbols for the kernel and modules, for example. However, it does work fine, and that's even with modules installed. The bigger problem is my old /var now that I have audit enabled. Robert N M Watson Computer Laboratory University of Cambridge From dmagda at ee.ryerson.ca Fri Jun 13 23:11:29 2008 From: dmagda at ee.ryerson.ca (David Magda) Date: Fri Jun 13 23:11:34 2008 Subject: ZFS version 8 on stable? In-Reply-To: <48527C29.20508@loveturtle.net> References: <48527C29.20508@loveturtle.net> Message-ID: On Jun 13, 2008, at 09:54, Dillon Kass wrote: > Your only option is to wait until this is committed or patches are > offered at least. > pjd is the man so it shouldn't be too long :-) Another option could be to see if you can help with the coding. :) From patfbsd at davenulle.org Fri Jun 13 23:52:33 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Fri Jun 13 23:52:38 2008 Subject: [7-STABLE] ping -s 4000 with ipsec panic In-Reply-To: <4851B7EF.7060905@FreeBSD.org> References: <20080613004847.09f9b089@baby-jane-lamaiziere-net.local> <4851B7EF.7060905@FreeBSD.org> Message-ID: <20080614015229.1c4afbe7@baby-jane-lamaiziere-net.local> Le Fri, 13 Jun 2008 01:57:35 +0200, Kris Kennaway a ?crit : Hello, [...] > > #17 0xc0700746 in crypto_invoke (cap=0x8, crp=0xd61a0950, > > hint=-1616994916) at cryptodev_if.h:53 > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) > > Unfortunately the trace is bogus. Try to rebuild with -O instead of > -O2 and reproduce the panic. Hmm, i've got no luck with -O. I made few tests and the panic occurs with a -s of 3989 bytes. ping -s 3988 => ok ping -s 3989 => panic The coredump seems to be ok. http://user.lamaiziere.net/patrick/coredump.txt I will try with a kernel and DEBUG_REDZONE and INVARIANT. ----------------------- Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x9350ef1e fault code = supervisor read, page not present instruction pointer = 0x20:0xc05a0579 stack pointer = 0x28:0xd61635cc frame pointer = 0x28:0xd61635d0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1101 (ping) trap number = 12 panic: page fault Uptime: 7m47s Physical memory: 503 MB Dumping 88 MB: 73 57 41 25 9 #0 doadump () at pcpu.h:195 in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0556273 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc055646f in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc079b91c in trap_fatal (frame=0xd616358c, eva=2471554846) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc079bba0 in trap_pfault (frame=0xd616358c, usermode=0, eva=2471554846) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc079c529 in trap (frame=0xd616358c) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0789f2b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc05a0579 in mb_dupcl (n=0xc2b02000, m=0xc2b02d00) at /usr/src/sys/kern/uipc_mbuf.c:293 #8 0xc05a157a in m_copym (m=0xc2b02d00, off0=2980, len=3, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:570 #9 0xc0614055 in ip_fragment (ip=0xc2e5a038, m_frag=0xd61636d0, mtu=1500, if_hwassist_flags=7, sw_csum=0) at /usr/src/sys/netinet/ip_output.c:728 #10 0xc0614d38 in ip_output (m=0xc2b02600, opt=0x0, ro=0xd6163694, flags=2, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:567 #11 0xc06acd9d in ipsec_process_done (m=0xc2b02600, isr=0xc2bacd80) at /usr/src/sys/netipsec/ipsec_output.c:177 #12 0xc06bbf5c in esp_output_cb (crp=0xc2e5c708) at /usr/src/sys/netipsec/xform_esp.c:965 #13 0xc06ff730 in crypto_done (crp=0xc2e5c708) at /usr/src/sys/opencrypto/crypto.c:1148 #14 0xc0702afe in swcr_process (dev=0xc29cf380, crp=0xc2e5c708, hint=0) at /usr/src/sys/opencrypto/cryptosoft.c:975 #15 0xc0700746 in crypto_invoke (cap=0xc29cf380, crp=0xc2e5c708, hint=0) at cryptodev_if.h:53 #16 0xc070118c in crypto_dispatch (crp=0xc2e5c708) at /usr/src/sys/opencrypto/crypto.c:798 #17 0xc06bc5c6 in esp_output (m=0xc2b02600, isr=0xc2bacd80, mp=0x0, skip=20, protoff=9) at /usr/src/sys/netipsec/xform_esp.c:875 #18 0xc06ad112 in ipsec4_process_packet (m=0xc2b02600, isr=0xc2bacd80, flags=32, tunalready=0) at /usr/src/sys/netipsec/ipsec_output.c:491 #19 0xc0612f95 in ip_ipsec_output (m=0xd6163b04, inp=0xc2e07870, flags=0xd6163b10, error=0xd6163ae4, ro=0xd6163b0c, iproute=0xd6163ac8, dst=0xd6163ae0, ia=0xd6163adc, ifp=0xd6163aec) at /usr/src/sys/netinet/ip_ipsec.c:331 #20 0xc0614ab9 in ip_output (m=0xc2b02600, opt=0x0, ro=0xd6163ac8, flags=32, imo=0x0, inp=0xc2e07870) at /usr/src/sys/netinet/ip_output.c:420 #21 0xc0615e1b in rip_output (m=0xc2b02600, so=0xc2ddfad4, dst=352430272) at /usr/src/sys/netinet/raw_ip.c:336 #22 0xc0615efc in rip_send (so=0xc2ddfad4, flags=0, m=0xc2b02600, nam=0xc29f9800, control=0x0, td=0xc2b77000) at /usr/src/sys/netinet/raw_ip.c:806 #23 0xc05a97f5 in sosend_generic (so=0xc2ddfad4, addr=0xc29f9800, uio=0xd6163be8, top=0xc2b02600, control=0x0, flags=0, td=0xc2b77000) at /usr/src/sys/kern/uipc_socket.c:1240 #24 0xc05a580f in sosend (so=0xc2ddfad4, addr=0xc29f9800, uio=0xd6163be8, top=0x0, control=0x0, flags=0, td=0xc2b77000) at /usr/src/sys/kern/uipc_socket.c:1286 #25 0xc05abf16 in kern_sendit (td=0xc2b77000, s=3, mp=0xd6163c64, flags=0, control=0x0, segflg=UIO_USERSPACE) at /usr/src/sys/kern/uipc_syscalls.c:789 #26 0xc05af031 in sendit (td=0xc2b77000, s=3, mp=0xd6163c64, flags=0) at /usr/src/sys/kern/uipc_syscalls.c:730 #27 0xc05af148 in sendto (td=0xc2b77000, uap=0xd6163cfc) at /usr/src/sys/kern/uipc_syscalls.c:841 #28 0xc079bef5 in syscall (frame=0xd6163d38) at /usr/src/sys/i386/i386/trap.c:1035 #29 0xc0789f90 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #30 0x00000033 in ?? () (kgdb) quit -------------- Thanks, regards. From goran.lowkrantz at ismobile.com Sat Jun 14 05:37:55 2008 From: goran.lowkrantz at ismobile.com (Goran Lowkrantz) Date: Sat Jun 14 05:38:00 2008 Subject: Unusually large directory - 2.0 peta bytes Message-ID: While preparing to upgrade to latest stable, I ran some scripts to verify that the target was OK and found something that I think I need to fix but have no clue to how. This is the essence of what I found: # ls /usr/local/lib/perl5/site_perl/5.8.8/mach/auto/APR/PerlIO/* autosplit.ix # ls -la /usr/local/lib/perl5/site_perl/5.8.8/mach/auto/APR/PerlIO/* ls: : No such file or directory ls: autosplit.ix: No such file or directory total 8 drwxr-xr-x 2 root wheel 2251799813685760 Jun 14 04:06 . drwxr-xr-x 2 root wheel 2251799813685760 Jun 14 04:06 . drwxr-xr-x 24 root wheel 512 Mar 29 10:33 .. drwxr-xr-x 24 root wheel 512 Mar 29 10:33 .. # stat /usr/local/lib/perl5/site_perl/5.8.8/mach/auto/APR/PerlIO 163 5229427 drwxr-xr-x 2 root wheel 20894350 2251799813685760 "Jun 14 07:07:43 2008" "Jun 14 04:06:44 2008" "Jun 14 04:06:44 2008" "Mar 29 10:33:10 2008" 4096 4 0 /usr/local/lib/perl5/site_perl/5.8.8/mach/auto/APR/PerlIO # stat /usr/local/lib/perl5/site_perl/5.8.8/mach/auto/APR/PerlIO/autosplit.ix stat: /usr/local/lib/perl5/site_perl/5.8.8/mach/auto/APR/PerlIO/autosplit.ix: stat: No such file or directory # od -c /usr/local/lib/perl5/site_perl/5.8.8/mach/auto/APR/PerlIO | more 0000000 s 313 O \0 \f \0 004 001 . \0 \0 \0 1 313 O \0 0000020 364 001 004 002 . . \0 \0 t 313 O \0 024 \0 \b \t 0000040 P e r l I O . s o \0 217 300 u 313 O \0 0000060 324 001 \b \t P e r l I O . b s \0 217 300 0000100 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0001000 \0 \0 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0001020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0002000 \0 \0 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0002020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0003000 \0 \0 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0003020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0004000 v 313 O \0 \f \0 004 001 . \0 \0 \0 335 312 O \0 0004020 \f \0 004 002 . . \0 \0 w 313 O \0 350 001 \b \f 0004040 a u t o s p l i t . i x \0 231 - 351 0004060 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0005000 \0 \0 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0005020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0006000 \0 \0 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0006020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0007000 \0 \0 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0007020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0010000 177 E L F 001 001 001 \t \0 \0 \0 \0 \0 \0 \0 \0 0010020 003 \0 003 \0 001 \0 \0 \0 240 \t \0 \0 4 \0 \0 \0 0010040 330 025 \0 \0 \0 \0 \0 \0 4 \0 \0 003 \0 ( \0 This does not look like a directory, it looks like a shared library, PerlIO.so, that somehow got the directory bit set. First, am I correct in my analysis? Second, how do I remove the directory bit so I can delete the file? Host info, dmesg.boot attached: # uname -a FreeBSD balder.glz.hidden-powers.com 6.3-STABLE FreeBSD 6.3-STABLE #1: Thu Feb 28 02:14:05 CET 2008 root@midgard.glz.hidden-powers.com:/usr/obj/usr/src/sys/BALDER i386 Cheers, G?ran ................................................... the future isMobile Goran Lowkrantz System Architect, isMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Lule?, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ............................................... -------------- next part -------------- A non-text attachment was scrubbed... Name: dmesg.boot Type: application/octet-stream Size: 7426 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080614/596ce421/dmesg.obj From imp at bsdimp.com Sat Jun 14 06:25:41 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Jun 14 06:25:45 2008 Subject: Texas Instruments Card Reader. In-Reply-To: <1207010488.30698.42.camel@laptop2.herveybayaustralia.com.au> References: <20080330.005823.-432836004.imp@bsdimp.com> <1207010488.30698.42.camel@laptop2.herveybayaustralia.com.au> Message-ID: <20080614.0