Date: Thu, 05 Jun 2008 11:14:20 -0500 From: Paul Schmehl <pschmehl_lists@tx.rr.com> To: freebsd-stable@freebsd.org Subject: Re: challenge: end of life for 6.2 is premature with buggy 6.3 Message-ID: <CE0D857CF3C54017B29052F0@utd65257.utdallas.edu> In-Reply-To: <200806051023.56065.jhb@freebsd.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <200806051023.56065.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--On Thursday, June 05, 2008 10:23:55 -0400 John Baldwin <jhb@freebsd.org> 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: <Broadcom NetXtreme II BCM5708 1000Base-T (B1), v0.9.6> mem 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci9 bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz miibus0: <MII bus> on bce0 bce0: Ethernet address: 00:13:72:fb:2a:ad bce1: <Broadcom NetXtreme II BCM5708 1000Base-T (B1), v0.9.6> mem 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci5 bce1: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz miibus1: <MII bus> on bce1 bce1: Ethernet address: 00:13:72:fb:2a:ab # grep bce0 /var/log/messages May 2 09:10:31 www kernel: bce0: link state changed to DOWN May 2 09:10:39 www kernel: bce0: link state changed to UP May 25 07:49:49 www kernel: bce0: link state changed to DOWN May 25 07:50:31 www kernel: bce0: link state changed to UP May 26 21:28:36 www kernel: bce0: link state changed to DOWN May 26 21:28:40 www kernel: bce0: link state changed to UP May 27 13:13:21 www kernel: bce0: link state changed to DOWN May 27 13:13:31 www kernel: bce0: link state changed to UP It's been like that since the server was installed. So, if I upgrade to 6.3 or 7.0, am I still going to experience these problems? Is the server going to stop working entirely? How can I know that for sure before starting an upgrade? 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CE0D857CF3C54017B29052F0>