--On Thursday, June 05, 2008 10:23:55 -0400 John Baldwin <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]:/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.

_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to