Re: Stability of 11.1S

[Dewayne Geraghty]

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Stability of 11.1S

[Freddie Cash]

On Wed, Mar 21, 2018 at 7:59 AM, Warner Losh  wrote:

> On Wed, Mar 21, 2018 at 7:32 AM, George Mitchell 
> wrote:
>
> > On 03/21/18 04:51, Eitan Adler wrote:
> > > On 19 March 2018 at 22:59, Dewayne Geraghty
> > >  wrote:
> > >> [...]
> > >> PS Normally I would bisect, but we're converting 2 large PROLOG
> > applications
> > >> to erlang... (prayers welcome)
> > > [...]
> >
> > What next, converting a FORTH application to LISP?  (Sorry, couldn't
> > resist ...)
>
>
> Back in college we had a gentleman who was working on his FORTH LISP
> interpreter But I can't recall if it was a FORTH interpreter written in
> LISP or a LISP interpreter written in FORTH.
>

​What happened to his first three LISP interpreters?  ;)  If at first you
don't succeed, try try try try again?

Sorry, that one was just too easy, could not resist.​ :D
​
I'll see myself out now.  :)​



-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Stability of 11.1S

[Warner Losh]

On Wed, Mar 21, 2018 at 7:32 AM, George Mitchell 
wrote:

> On 03/21/18 04:51, Eitan Adler wrote:
> > On 19 March 2018 at 22:59, Dewayne Geraghty
> >  wrote:
> >> [...]
> >> PS Normally I would bisect, but we're converting 2 large PROLOG
> applications
> >> to erlang... (prayers welcome)
> > [...]
>
> What next, converting a FORTH application to LISP?  (Sorry, couldn't
> resist ...)


Back in college we had a gentleman who was working on his FORTH LISP
interpreter But I can't recall if it was a FORTH interpreter written in
LISP or a LISP interpreter written in FORTH.

Warner
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Stability of 11.1S

[George Mitchell]

On 03/21/18 04:51, Eitan Adler wrote:
> On 19 March 2018 at 22:59, Dewayne Geraghty
>  wrote:
>> [...]
>> PS Normally I would bisect, but we're converting 2 large PROLOG applications
>> to erlang... (prayers welcome)
> [...]

What next, converting a FORTH application to LISP?  (Sorry, couldn't
resist ...)-- George



signature.asc
Description: OpenPGP digital signature

Re: Stability of 11.1S

[Eitan Adler]

On 19 March 2018 at 22:59, Dewayne Geraghty
 wrote:
> Hi Eitan,
> Agreed.   Unfortunately all I have is that it abruptly shuts down.  Both
> under load (10,8,?) - during a full package rebuild (~1200 ports); and
> during periods of idleness between 1am-2am.  From our console.log there are
> approximately 6 MARK entries in the logs, so it can be idle for that period
> of time (2 hours) before halting, abruptly.

There has been some additional conversation but just wanted to pick
something to reply to:

I will take full ownership if something I've MFCed caused breakage.
That said I'm somewhat stuck unless I am able to reproduce the issue,
or at least guess as to the cause.


> PS Normally I would bisect, but we're converting 2 large PROLOG applications
> to erlang... (prayers welcome)

Both fun languages.



-- 
Eitan Adler
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Stability of 11.1S

[Marek Zarychta]

On Tue, Mar 20, 2018 at 11:10:47AM -0700, Jeremy Chadwick wrote:
> (Please keep me CC'd as I am not subscribed to -stable)
> 
> I haven't seen any issues, but that means very little.  Details:
> 
> Two boxes -- one bare metal, one VPS (QEMU):
> 
> $ uname -a
> FreeBSD XXX 11.1-STABLE FreeBSD 11.1-STABLE #0 r330529: Tue Mar  
> 6 11:36:04 PST 2018 
> root@XXX:/usr/obj/usr/src/sys/X7SBA_RELENG_11_amd64  amd64
> $ uptime
> 10:33a.m.  up 13 days, 18:10, 2 users, load averages: 0.15, 0.19, 0.16
> 
> $ uname -a
> FreeBSD  11.1-STABLE FreeBSD 11.1-STABLE #0 r330753: Sat Mar 
> 10 21:34:20 PST 2018 
> root@:/usr/obj/usr/src/sys/_RELENG_11_amd64  amd64
> $ uptime
> 10:33a.m.  up 9 days, 10:46, 1 user, load averages: 0.31, 0.35, 0.31
> 
> Systems were updated recently because I wanted to test Meltdown/Spectre
> mitigation (more on that below).  Prior to that, bare metal was running
> 9.x with 200+ day uptimes, VPS was running 10.x with 80-90 day uptimes
> (VPS providers' HV crashed, i.e. not FreeBSD issues).
> 
> Since load averages on FreeBSD 10.x onward cannot be trusted[1][2], I
> have to explain the general system specs and loads:
> 
> Bare metal box is an Intel Core 2 Quad Q9550, 8GB RAM, doing very little
> other than running Apache + lots of cron jobs for systems stuff + ZFS
> with several disks (but not OS disk; that's a dedicated SSD w/ UFS + SU
> (not SUJ).  The cron jobs tend to stress the network and disk I/O a bit;
> ZFS gets used every day, but only "heavily" during LAN file copies
> to/from it (Samba is involved), and during nightly backups with rsync.
> 
> VPS box is some form of QEMU-based Intel Haswell CPU, 1GB RAM, doing
> general things like Apache + postfix + SpamAssassin + some other
> daemons, and a lot of Perl.  Swap is used heavily on this machine.
> Disks are all vtblk, and I use multiple to get capacity for the needed
> space for /usr/src and /usr/obj.  Everything is UFS + SU (not SUJ).
> 
> Things off the top of my head that might be relevant to you:
> 
> 1. r329462 added Meltdown/Spectre mitigation[3][4].
> 
> Bare metal box has the below in /boot/loader.conf, since this is a
> machine that does not need either given its environment:
> 
> # Disable PTI (Meltdown mitigation) and IBRS (Spectre mitigation); these
> # are not relevant on this bare-metal system given its environment and
> # use case.  Details of these tunables is here:
> # https://lists.freebsd.org/pipermail/freebsd-stable/2018-March/088526.html
> #
> vm.pmap.pti="0"
> hw.ibrs_disable="1"
> 
> VPS box has no tunings of this sort, and ends up with the below, because
> the hosting provider has no done BIOS + QEMU updates to add IBRS
> support (they're very aware of it + have attempted it twice but
> apparently it didn't go well):
> 
> vm.pmap.pti: 1
> hw.ibrs_disable: 1
> hw.ibrs_active: 0
> 
> 2. If your CPU is an AMD Ryzen, there is a VERY long discussion on
> -stable about problems with Ryzen manifesting itself in a very
> uncomfortable way, leading to system lock-ups[5].  There are unofficial
> patches you can try.  I would recommend chiming in there and not here,
> if relevant to your systems.
> 
> And yes, the massive number of MFCs that eadler@ is doing make tracking
> down exact things more tedious than normal, especially when you have
> sweeping commits like this one[6][7] (which, AFAIK, was acting as a
> major blocker for several other MFCs and causing general merge
> problems).
> 
> However, I commend his efforts; it's a massive undertaking (I would say
> full-time job).  We stable users must accept that we are running
> stable/11 for a reason -- not only to get fixes faster, but to act a
> form of "guinea pig" that don't want the risks of HEAD/CURRENT.  The
> more people using stable/11 the better overall feedback devs can get on
> bugs/issues before making it into the next -RELEASE.  This is exactly
> why, for those of you who have known me over the years, I actually
> "track" or "follow" commits as they come across.  I do this by using the
> FreshBSD site[8] alongside manual review of svnlite update output.  I
> generally know what files/bits are relevant to my interests.
> 
> Hope this gives you some things to think about.  Good luck!
> 
> [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173541#c8
> [2]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173541#c22
> [3]: 
> https://lists.freebsd.org/pipermail/freebsd-stable/2018-February/088396.html
> [4]: https://lists.freebsd.org/pipermail/freebsd-stable/2018-March/088526.html
> [5]: 
> https://lists.freebsd.org/pipermail/freebsd-stable/2018-January/thread.html#88174
> [6]: http://www.freshbsd.org/commit/freebsd/r330897
> [7]: https://svnweb.freebsd.org/base?view=revision=330897
> [8]: http://www.freshbsd.org/?branch=RELENG_11=freebsd
> 

I follow STABLE uprgrading regularly bunch of servers, routers, PCs,
laptop and even sometimes Raspberry Pi, always using builds made with
meta 

Re: Stability of 11.1S

[Ian Lepore]

On Tue, 2018-03-20 at 10:50 +, Pete French wrote:
> 
> On 20/03/2018 01:05, Dewayne Geraghty wrote:
> > 
> > We rebuild 11.1-Stable at least every two weeks.  Our build on the 7th
> > Feb is in use on our development boxes, however the rebuild on 22nd
> > resulted in frequent crashes and our reverting to FreeBSD 11.1-STABLE
> > r329008.  Is anyone actually running a Stable that was built after 22nd
> > Feb?  Could you please share the revision number?
> r330769 works fine for me. I usually upgrade on a Monday, though
> am holding off this week as am waiting for r330745 to land in STABLE,
> but it works fine for me always.
> 
> 
> > 
> > Because the churn in
> > https://lists.freebsd.org/pipermail/svn-src-stable-11/2018-March/ is
> > high we haven't been able to sight if a problem was identified and
> > fixed; so we're really looking for a functioning stable that we can
> > resume tracking.
> I use this to eyeball whats gone into STABLE, its a daily read for me as 
> I find keeping up with the mailing list tricky too.
> 
> 
> http://www.freshbsd.org/?branch=RELENG_11=freebsd;;
> 
> -pete.

I meant to get that done over the weekend but didn't actually get to it
until today.  I've MFC'd it to 11 as r331262, and I'm checking to see
whether it should go back to 10-stable as well.

-- Ian
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Stability of 11.1S

[Jeremy Chadwick]

(Please keep me CC'd as I am not subscribed to -stable)

I haven't seen any issues, but that means very little.  Details:

Two boxes -- one bare metal, one VPS (QEMU):

$ uname -a
FreeBSD XXX 11.1-STABLE FreeBSD 11.1-STABLE #0 r330529: Tue Mar  6 
11:36:04 PST 2018 
root@XXX:/usr/obj/usr/src/sys/X7SBA_RELENG_11_amd64  amd64
$ uptime
10:33a.m.  up 13 days, 18:10, 2 users, load averages: 0.15, 0.19, 0.16

$ uname -a
FreeBSD  11.1-STABLE FreeBSD 11.1-STABLE #0 r330753: Sat Mar 10 
21:34:20 PST 2018 
root@:/usr/obj/usr/src/sys/_RELENG_11_amd64  amd64
$ uptime
10:33a.m.  up 9 days, 10:46, 1 user, load averages: 0.31, 0.35, 0.31

Systems were updated recently because I wanted to test Meltdown/Spectre
mitigation (more on that below).  Prior to that, bare metal was running
9.x with 200+ day uptimes, VPS was running 10.x with 80-90 day uptimes
(VPS providers' HV crashed, i.e. not FreeBSD issues).

Since load averages on FreeBSD 10.x onward cannot be trusted[1][2], I
have to explain the general system specs and loads:

Bare metal box is an Intel Core 2 Quad Q9550, 8GB RAM, doing very little
other than running Apache + lots of cron jobs for systems stuff + ZFS
with several disks (but not OS disk; that's a dedicated SSD w/ UFS + SU
(not SUJ).  The cron jobs tend to stress the network and disk I/O a bit;
ZFS gets used every day, but only "heavily" during LAN file copies
to/from it (Samba is involved), and during nightly backups with rsync.

VPS box is some form of QEMU-based Intel Haswell CPU, 1GB RAM, doing
general things like Apache + postfix + SpamAssassin + some other
daemons, and a lot of Perl.  Swap is used heavily on this machine.
Disks are all vtblk, and I use multiple to get capacity for the needed
space for /usr/src and /usr/obj.  Everything is UFS + SU (not SUJ).

Things off the top of my head that might be relevant to you:

1. r329462 added Meltdown/Spectre mitigation[3][4].

Bare metal box has the below in /boot/loader.conf, since this is a
machine that does not need either given its environment:

# Disable PTI (Meltdown mitigation) and IBRS (Spectre mitigation); these
# are not relevant on this bare-metal system given its environment and
# use case.  Details of these tunables is here:
# https://lists.freebsd.org/pipermail/freebsd-stable/2018-March/088526.html
#
vm.pmap.pti="0"
hw.ibrs_disable="1"

VPS box has no tunings of this sort, and ends up with the below, because
the hosting provider has no done BIOS + QEMU updates to add IBRS
support (they're very aware of it + have attempted it twice but
apparently it didn't go well):

vm.pmap.pti: 1
hw.ibrs_disable: 1
hw.ibrs_active: 0

2. If your CPU is an AMD Ryzen, there is a VERY long discussion on
-stable about problems with Ryzen manifesting itself in a very
uncomfortable way, leading to system lock-ups[5].  There are unofficial
patches you can try.  I would recommend chiming in there and not here,
if relevant to your systems.

And yes, the massive number of MFCs that eadler@ is doing make tracking
down exact things more tedious than normal, especially when you have
sweeping commits like this one[6][7] (which, AFAIK, was acting as a
major blocker for several other MFCs and causing general merge
problems).

However, I commend his efforts; it's a massive undertaking (I would say
full-time job).  We stable users must accept that we are running
stable/11 for a reason -- not only to get fixes faster, but to act a
form of "guinea pig" that don't want the risks of HEAD/CURRENT.  The
more people using stable/11 the better overall feedback devs can get on
bugs/issues before making it into the next -RELEASE.  This is exactly
why, for those of you who have known me over the years, I actually
"track" or "follow" commits as they come across.  I do this by using the
FreshBSD site[8] alongside manual review of svnlite update output.  I
generally know what files/bits are relevant to my interests.

Hope this gives you some things to think about.  Good luck!

[1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173541#c8
[2]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173541#c22
[3]: 
https://lists.freebsd.org/pipermail/freebsd-stable/2018-February/088396.html
[4]: https://lists.freebsd.org/pipermail/freebsd-stable/2018-March/088526.html
[5]: 
https://lists.freebsd.org/pipermail/freebsd-stable/2018-January/thread.html#88174
[6]: http://www.freshbsd.org/commit/freebsd/r330897
[7]: https://svnweb.freebsd.org/base?view=revision=330897
[8]: http://www.freshbsd.org/?branch=RELENG_11=freebsd

-- 
| Jeremy Chadwick   j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Making life hard for others since 1977. PGP 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to 

Re: Stability of 11.1S

[Pete French]

On 20/03/2018 01:05, Dewayne Geraghty wrote:

We rebuild 11.1-Stable at least every two weeks.  Our build on the 7th
Feb is in use on our development boxes, however the rebuild on 22nd
resulted in frequent crashes and our reverting to FreeBSD 11.1-STABLE
r329008.  Is anyone actually running a Stable that was built after 22nd
Feb?  Could you please share the revision number?


r330769 works fine for me. I usually upgrade on a Monday, though
am holding off this week as am waiting for r330745 to land in STABLE,
but it works fine for me always.



Because the churn in
https://lists.freebsd.org/pipermail/svn-src-stable-11/2018-March/ is
high we haven't been able to sight if a problem was identified and
fixed; so we're really looking for a functioning stable that we can
resume tracking.


I use this to eyeball whats gone into STABLE, its a daily read for me as 
I find keeping up with the mailing list tricky too.



http://www.freshbsd.org/?branch=RELENG_11=freebsd;

-pete.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Stability of 11.1S

[Dewayne Geraghty]

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Stability of 11.1S

[Eitan Adler]

On 19 March 2018 at 18:05, Dewayne Geraghty
 wrote:
> We rebuild 11.1-Stable at least every two weeks.  Our build on the 7th
> Feb is in use on our development boxes, however the rebuild on 22nd
> resulted in frequent crashes and our reverting to FreeBSD 11.1-STABLE
> r329008.  Is anyone actually running a Stable that was built after 22nd
> Feb?  Could you please share the revision number?
>
> Because the churn in
> https://lists.freebsd.org/pipermail/svn-src-stable-11/2018-March/ is
> high we haven't been able to sight if a problem was identified and
> fixed; so we're really looking for a functioning stable that we can
> resume tracking.

Hi,

I can't help identify the problem and if it was fixed without any
information. Can you at least let us know what kind of crashes are you
seeing? Kernel panics?SIGBUS? Something else?

It would be best if you could bisect to the revision causing you problems.

Note that despite the name, STABLE is a development branch and users
of the branch are expected to be able to provide some help tracking
down issues.

-- 
Eitan Adler
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Stability of 11.1S

[David Wolfskill]

On Tue, Mar 20, 2018 at 12:05:33PM +1100, Dewayne Geraghty wrote:
> We rebuild 11.1-Stable at least every two weeks.  Our build on the 7th
> Feb is in use on our development boxes, however the rebuild on 22nd
> resulted in frequent crashes and our reverting to FreeBSD 11.1-STABLE 
> r329008.  Is anyone actually running a Stable that was built after 22nd
> Feb?  Could you please share the revision number?

These are lightly loaded, but the two "production" boxes at home run
a stable/11 snapshot, built weekly.

Details on the process may be found at
; the page with
historical information (including "uname" output for each snapshot run)
is .  (Each of the
two machines runs from the same sources as listed for "albert".)

(My laptop & build machine run a daily snapshot of stable/11, as well as
building & smoke-testing a daily snapshot of head.  The above-cited
"weekly snapshot" is actually a "daily snapshot" that is sampled only
weekly -- on Sunday morning.)

> ... 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
An investigator who doesn't make a perp nervous isn't doing his job.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Stability problems with 7-stable (after 7.1 - 7.2 - 7-stable)

[Alexander Leidinger]

Quoting Boris Samorodov b...@ipt.ru (from Thu, 17 Dec 2009 20:55:44 +0300):


Ivan Voras ivo...@freebsd.org writes:

Alexander Leidinger wrote:

Hi,

please CC me on replies.


Seems you were not CCed...


I'm now subscribed to stable@, thanks for forwarding this.


I have a system which was at 7.1-pX. After the update to 7.2-p5 it
started to exhibit deadlocks after some minutes of uptime.

With 7.1 (generic kernel) it was running fine, with 7.2 generic the
problems started directly.

The system is now at 7-stable with a custom kernel
(http://www.Leidinger.net/test/ALCATRAZ), basically generic without
unneeded drivers plus witness/invariants/sw-watchdog.

The system is an AMD Dual Core with NVidia MCP61 chipset
(http://www.Leidinger.net/test/dmesg.alcatraz), 2 GB RAM, 2
harddisks and FreeBSD 32bit install.


Some generic things to try:
- did you monitor the system with something (top or systat
-vm) to see if there is something unusual, like interrupt storms?


When I had the initial problems, I asked for a KVM-switch to be  
connected to the system (not a free service). In SU mode I didn't see  
any problem. When starting the system but not the jails, I didn't see  
any problem (cvsup/buildworld/...). When I started the jails, I  
started to see the problems.



- no physical access is a problem; If you do manage it, I'd
say try running single user for some time with systat -vm just to see
what happens.


This is not an option now.


I would not trust ZFS in 7-stable since it lags a bit behind patches
done to 8 but 7.2 should be fine - at least I don't have any such
problems with it (though no AMD boxes to test them with it).


Ivan, the system started out to be without ZFS, just after I started  
to see deadlocks I switched to ZFS. This _improved_ the situation. Now  
the system survives between 3h and about 11h without a deadlock. If I  
run every 5 minutes a script which logs 4 text lines to the root (UFS)  
and runs 3x sync + sleep 5 + 3x sync the frequency of deadlocks  
increases.



If you haven't updated your ZFS pools, I'd suggest reverting back to
7.1, then building or downloading an 8.0 kernel and try it with 7.1
userland (reboot -k ...) simply to see if it helps.


IIRC there where KBI changes (ifconfig?) which prevents me to go back  
to 7.1 without access to the console. As this is a production machine  
(it hosts not only my blog/website/mails, but stuff from other persons  
too), the goal is to stabilize this system now.


Kib analyzed 2 crashdumps I had (watchdog triggered) and he thinks  
they are because of ZFS deadlocks. So the initial problem (without  
ZFS) is not know yet, but this info will hopefully allow to stabilize  
the system further (see also my mail about at least 57 unmerged ZFS  
patches).


Bye,
Alexander.

--
Universities are places of knowledge.  The freshman each bring a little
in with them, and the seniors take none away, so knowledge accumulates.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Stability problems with 7-stable (after 7.1 - 7.2 - 7-stable)

[Ivan Voras]

Alexander Leidinger wrote:

Hi,

please CC me on replies.

I have a system which was at 7.1-pX. After the update to 7.2-p5 it 
started to exhibit deadlocks after some minutes of uptime.


With 7.1 (generic kernel) it was running fine, with 7.2 generic the 
problems started directly.


The system is now at 7-stable with a custom kernel 
(http://www.Leidinger.net/test/ALCATRAZ), basically generic without 
unneeded drivers plus witness/invariants/sw-watchdog.


The system is an AMD Dual Core with NVidia MCP61 chipset 
(http://www.Leidinger.net/test/dmesg.alcatraz), 2 GB RAM, 2 harddisks 
and FreeBSD 32bit install.


Some generic things to try:
	- did you monitor the system with something (top or systat -vm) to see 
if there is something unusual, like interrupt storms?
	- no physical access is a problem; If you do manage it, I'd say try 
running single user for some time with systat -vm just to see what happens.


I would not trust ZFS in 7-stable since it lags a bit behind patches 
done to 8 but 7.2 should be fine - at least I don't have any such 
problems with it (though no AMD boxes to test them with it).


If you haven't updated your ZFS pools, I'd suggest reverting back to 
7.1, then building or downloading an 8.0 kernel and try it with 7.1 
userland (reboot -k ...) simply to see if it helps.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Stability of ICH7 sata on FreeBSD 6.1 ?

[Mike Jakubik]

Dominic Marks wrote:

Jerome Sobecki wrote:

Hi all,

We have here some Supermicro Superserver 5015P-TR
(http://www.supermicro.com/products/system/1U/5015/SYS-5015P-TR.cfm)

Those servers, with a ICH7 controler, are currently working with FreeBSD
6.1 and everything seems ok, except that it's the third time, on two
different machines, that the system crash because it lost is hard drive.
  


I have two Supermicro PDSMi MB servers in productions and i am also 
experiencing mysterious disk loses. The system continues to function 
fine, as i am using gmirror, however something strange is going on. 
Sometimes the disks come back, sometimes i need to reboot the system to 
get them back. I am using Seagate ST3160812AS 3.AAE drives. The drives 
reports no SMART errors, and the cables are secure. The drives are 
attached to a hot swap back plane.



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

Re: Stability of ICH7 sata on FreeBSD 6.1 ?

[Miroslav Lachman]

Mike Jakubik wrote:


Dominic Marks wrote:


Jerome Sobecki wrote:


Hi all,

We have here some Supermicro Superserver 5015P-TR
(http://www.supermicro.com/products/system/1U/5015/SYS-5015P-TR.cfm)

Those servers, with a ICH7 controler, are currently working with FreeBSD
6.1 and everything seems ok, except that it's the third time, on two
different machines, that the system crash because it lost is hard drive.
  



I have two Supermicro PDSMi MB servers in productions and i am also 
experiencing mysterious disk loses. The system continues to function 
fine, as i am using gmirror, however something strange is going on. 
Sometimes the disks come back, sometimes i need to reboot the system to 
get them back. I am using Seagate ST3160812AS 3.AAE drives. The drives 
reports no SMART errors, and the cables are secure. The drives are 
attached to a hot swap back plane.


I have same problem on ASUS RS120 with Seagate ST3250820AS/3.AAC drives 
(disk loses, system reboots, slow read/write speed), but I think this is 
drive problem - all drives has high Reallocated_Sector_Ct value in SMART 
(above 130 reallocated sectors after few weeks, some drives has more 
then 100 after few days).
Please let me now, if you also have nonzero Reallocated_Sector_Ct in 
smartctl -A output.

I will test those servers with brand new Samsung drives, hope that it helps.

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

Re: Stability of ICH7 sata on FreeBSD 6.1 ?

[Mike Jakubik]

Miroslav Lachman wrote:
I have same problem on ASUS RS120 with Seagate ST3250820AS/3.AAC 
drives (disk loses, system reboots, slow read/write speed), but I 
think this is drive problem - all drives has high 
Reallocated_Sector_Ct value in SMART (above 130 reallocated sectors 
after few weeks, some drives has more then 100 after few days).
Please let me now, if you also have nonzero Reallocated_Sector_Ct in 
smartctl -A output.
I will test those servers with brand new Samsung drives, hope that it 
helps.


I don't think you have the same problem, in your case it sounds like a 
bad hard drive. On my servers, all the hard drives are less than two 
months old, and are completely error free according to SMART.



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

Re: Stability of ICH7 sata on FreeBSD 6.1 ?

[Dominic Marks]

Jerome Sobecki wrote:

Hi all,

We have here some Supermicro Superserver 5015P-TR
(http://www.supermicro.com/products/system/1U/5015/SYS-5015P-TR.cfm)

Those servers, with a ICH7 controler, are currently working with FreeBSD
6.1 and everything seems ok, except that it's the third time, on two
different machines, that the system crash because it lost is hard drive.
  

We have a Subversion sever on a Dell box with an ICH7 chipset.
No problems so far (with Western Digital drives).

Dominic

The logs we get on console during the last crash (ad4s1g is /var, so we
don't have any other logs):
g_vsf_done() :ad4s1g[WRITE(offset=35657547776, length=16384)]error = 6
[...]
g_vsf_done() :ad4s1g[WRITE(offset=35662495744, length=16384)]error = 6
g_vsf_done() :ad4s1g[READ(offset=23900815360, , length=16384)]error = 6
handle_workitem_freeblocks: block count

The logs we have in /var/log/message during another crash :
Jul 26 19:34:07 munster2 kernel: ad6: FAILURE - device detached
Jul 26 19:34:07 munster2 kernel: subdisk6: detached
Jul 26 19:34:07 munster2 kernel: ad6: detached

When the machine crash, the led of the lost DD is fixed on, and a soft
reboot doesn't allow to get the disk back : an electric shutdown is
necessary.

Before the crash, servers had more than 1 mounth of uptime in
production, and others are still ok...

information about the machine :

vieux-lille2% uname -v 
FreeBSD 6.1-STABLE #3: Thu Jun  8 12:47:45 CEST 2006
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC 


It's right it was not up to date, but I didn't see cvs commit about that
problem (but maybe I simply miss it)

Does anyone had that problem ? Do you think updating the system from 6.1
sources will be enought ?

I let you dmesg, if it could help... :
vieux-lille2% dmesg
Copyright (c) 1992-2006 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights
reserved.
FreeBSD 6.1-STABLE #3: Thu Jun  8 12:47:45 CEST 2006
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) 4 CPU 3.40GHz (3400.15-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf43  Stepping = 3
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x649dSSE3,RSVD2,MON,DS_CPL,EST,CNTX-ID,CX16,b14
  AMD Features=0x2010NX,LM
  Logical CPUs per core: 2
real memory  = 1072562176 (1022 MB)
avail memory = 1040637952 (992 MB)
ACPI APIC Table: PTLTD  APIC  
ioapic0 Version 2.0 irqs 0-23 on motherboard
ioapic1 Version 2.0 irqs 24-47 on motherboard
ioapic2 Version 2.0 irqs 48-71 on motherboard
kbd1 at kbdmux0
acpi0: PTLTD   RSDT on motherboard
acpi0: Power Button (fixed)
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
cpu0: ACPI CPU on acpi0
acpi_throttle0: ACPI CPU Throttling on cpu0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0
pci1: ACPI PCI bus on pcib1
pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1
pci2: ACPI PCI bus on pcib2
pci1: base peripheral, interrupt controller at device 0.1 (no driver attached)
pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1
pci3: ACPI PCI bus on pcib3
pci1: base peripheral, interrupt controller at device 0.3 (no driver attached)
pcib4: ACPI PCI-PCI bridge irq 17 at device 28.0 on pci0
pci4: ACPI PCI bus on pcib4
pcib5: ACPI PCI-PCI bridge irq 17 at device 28.4 on pci0
pci5: ACPI PCI bus on pcib5
em0: Intel(R) PRO/1000 Network Connection Version - 3.2.18 port 0x4000-0x401f 
mem 0xed20-0xed21 irq 16 at device 0.0 on pci5
em0: Ethernet address: 00:30:48:84:89:58
pcib6: ACPI PCI-PCI bridge irq 16 at device 28.5 on pci0
pci6: ACPI PCI bus on pcib6
em1: Intel(R) PRO/1000 Network Connection Version - 3.2.18 port 0x5000-0x501f 
mem 0xed30-0xed31 irq 17 at device 0.0 on pci6
em1: Ethernet address: 00:30:48:84:89:59
uhci0: UHCI (generic) USB controller port 0x3000-0x301f irq 23 at
device 29.0 on pci0
uhci0: [GIANT-LOCKED]
usb0: UHCI (generic) USB controller on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1: UHCI (generic) USB controller port 0x3020-0x303f irq 19 at
device 29.1 on pci0
uhci1: [GIANT-LOCKED]
usb1: UHCI (generic) USB controller on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2: UHCI (generic) USB controller port 0x3040-0x305f irq 18 at
device 29.2 on pci0
uhci2: [GIANT-LOCKED]
usb2: UHCI (generic) USB controller on uhci2
usb2: USB revision 1.0
uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhci3: UHCI (generic) USB controller port 0x3060-0x307f irq 

Re: Stability problems vith FreeBSD 5.2.1-RELEASE-p14

[Adrian Wontroba]

On Sun, Oct 02, 2005 at 07:54:25PM +0200, Jurij Kovacic wrote:
 The panic  message is ussually somewhere along these lines:
 panic: kmem_malloc(4096) kmem map too small: 48496066400 total allocated
 cpuid =0
 boot() called on cpu#0
 ...

A similar problem is described in
http://lists.freebsd.org/pipermail/freebsd-doc/2004-May/004262.html
which recommends setting VM_KMEM_SIZE_MAX 419430400 for machines with
large amounts of memory.

Worked for me on a recent 5-STABLE. Might work for your rather elderly
release.

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

Re: Stability problems vith FreeBSD 5.2.1-RELEASE-p14

[Kris Kennaway]

On Sun, Oct 02, 2005 at 07:54:25PM +0200, Jurij Kovacic wrote:
 Hello!
 
 We are running FreeBSD 5.2.1-RELEASE-p14 with SMP kernell on one of our 
 servers and are experiencing stability problems; the server has the 
 tendency to reboot itself for no apparent reason at least once per month.

As you may know, 5.2.1 was an early adopter release not intended for
production use.  It's not surprising you have encountered one of the
bugs in it.  Update to a supported, production-quality release like
5.4.

Kris


pgpAZxAqXUSmn.pgp
Description: PGP signature

Re: Stability problems vith FreeBSD 5.2.1-RELEASE-p14

[David Kirchner]

On 10/2/05, Kris Kennaway [EMAIL PROTECTED] wrote:
 On Sun, Oct 02, 2005 at 07:54:25PM +0200, Jurij Kovacic wrote:
  Hello!
 
  We are running FreeBSD 5.2.1-RELEASE-p14 with SMP kernell on one of our
  servers and are experiencing stability problems; the server has the
  tendency to reboot itself for no apparent reason at least once per month.

 As you may know, 5.2.1 was an early adopter release not intended for
 production use.  It's not surprising you have encountered one of the
 bugs in it.  Update to a supported, production-quality release like
 5.4.

 Kris

Also note that 5.4-RELEASE has a severe crash bug related when you use
PAE and 4GB+ RAM (which may be what the OP is running in to, actually)
so if you want to be able to use all of your memory without crashes,
you'll need to either upgrade to 5-STABLE or apply a small patch
(search the mail archive for PAE and pmap.c).
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: stability nvidia drivers?

[Stijn Hoop]

On Wed, Dec 04, 2002 at 10:06:11AM +, Tarquin McDowell wrote:
 On Wed, Dec 04, 2002 at 09:47:39AM +0100, Stijn Hoop wrote:
  Anyone getting any better results? Is there something I can do to fix
  this? The drivers are of no use to me if they are this unreliable.
  More info available on request, of course.
 
 I had a problem on my Gforcce 2MX400 where the first GL app I ran would be ok,
 but running any GL apps after that would cause a core dump (and sometimes a
 hard lock of the machine). A problem I noticed, though, was that
 sysctl -a | grep nv was showing a selected AGP rate of x4. I was able to
 change that value to x1 by making a change as documented on the Nvidia
 FreeBSD FAQ page:
 
 Try lowering your AGP rate in the BIOS or nvidia_os_registry.c. If you want
 to use nvidia_os_registry.c to do this, find the line that reads 
 { ReqAGPRate, Force AGP Rate, 4, 0 }, and change the last 0 to 1. Now you
 will be able to set the sysctl hw.nvidia.registry.ReqAGPRate to the value of
 the desired AGP rate. You will of course need to rebuild/reinstall/reload the
 kernel driver before attempting to set the sysctl.
 
 This fixed all my problems -- the driver seems to be very stable now.

Yes, that's it! Thanks for the pointer, this solved all the coredumps!

a happy

--Stijn

-- 
Q: Why is Batman better than Bill Gates?
A: Batman was able to beat the Penguin.



msg52157/pgp0.pgp
Description: PGP signature

Re: Stability

[Marko Cuk]

Roman Shterenzon wrote:


 I've a perfectly good PR about vinum (panics) open. There's no even single
 follow up (kern/22103).
 I couldn't stand it any longer, so I'm not able to recreate it since I'm
 using raid1 on those disks now. I waited for almost one month but
 aparently nothing was done. (I opened one PR before that but it was badly
 formatted and had to become closed).

 I understand that people have other things to do, and FreeBSD is volunteer
 project, but we shall face the truth - the man page for vinum should state
 that RAID5 is experimental and prone to crashes. It should be emphasized
 that it shouldn't be used in sensitive environmets.
 I know other people for whom it rendered their servers unusable.

 I managed 8( to crash it today as well. I'll probably move to hardware
 raid solution instead, I'm quite fed up with vinum.


Wich good hardware solution is supported under FreeBSD ?

 I've a crash dump of today, perhaps I'll open another PR.


I've had crash before one hour, and I've only doing cvsup ports  Yesterday I
was changing speed of ipfw pipe and it crashed after a second. I cannot imagine
such things.

I can't have 20 days of uptime because of so many crashes.

Yes, I know a solution for stable FreeBSD. Leave it completly alone and don't do
anything.

It's no good. Fbsd is 4.1.

Cuk





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: Stability

[Alfred Perlstein]

* Marko Cuk [EMAIL PROTECTED] [001108 01:52] wrote:
 
 
 Roman Shterenzon wrote:
 
 
  I've a perfectly good PR about vinum (panics) open. There's no even single
  follow up (kern/22103).
  I couldn't stand it any longer, so I'm not able to recreate it since I'm
  using raid1 on those disks now. I waited for almost one month but
  aparently nothing was done. (I opened one PR before that but it was badly
  formatted and had to become closed).
 
  I understand that people have other things to do, and FreeBSD is volunteer
  project, but we shall face the truth - the man page for vinum should state
  that RAID5 is experimental and prone to crashes. It should be emphasized
  that it shouldn't be used in sensitive environmets.
  I know other people for whom it rendered their servers unusable.
 
  I managed 8( to crash it today as well. I'll probably move to hardware
  raid solution instead, I'm quite fed up with vinum.
 
 
 Wich good hardware solution is supported under FreeBSD ?

AMI MegaRAID and Mylex are a good bet, they are very stable for me.


 
  I've a crash dump of today, perhaps I'll open another PR.
 
 
 I've had crash before one hour, and I've only doing cvsup ports  Yesterday I
 was changing speed of ipfw pipe and it crashed after a second. I cannot imagine
 such things.
 
 I can't have 20 days of uptime because of so many crashes.
 
 Yes, I know a solution for stable FreeBSD. Leave it completly alone and don't do
 anything.
 
 It's no good. Fbsd is 4.1.

This isn't a useful bug report, please see:

http://www.freebsd.org/handbook/kerneldebug.html

Furthermore, I'm sorry FreeBSD isn't stable for you, but things
like vinum and ipfw pipe are quite new to FreeBSD, with good bug
reports these features could be made more stable, but right now I
wouldn't recommend twiddling too much with vinum in RAID 5 mode
(RAID 0/1 is fine).

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: Stability

[Roman Shterenzon]

On Sat, 4 Nov 2000, Bosko Milekic wrote:

  Hi Marko,
 
 On Sat, 4 Nov 2000, Marko Cuk wrote:
 
  Hello !!
  
  Can anyone explain me, why is FreeBSD known as powerful sistem with
  industrial strenghth and rock stability, but I manage to crash it several
  times.
 
  The bridge code in 4.1x is unstable in conjuction with ipfw, I had several
  problems with Vinum and Raid5 and maschine crashed every day if I used
  something od previously mentioned things.
 
   I personally did notice some problems with bridging as well, and I
   fixed one panic situation in -CURRENT about a month ago. I still have a
   Problem-Report assigned to me and am very interested in tracking more of
   these down, but really need help from folks running -STABLE as well, and
   that can afford to provide some debugging information.
   Hence, if you have a complaint about the stability of some component,
   please realize that there is very little that developers can do about it
   without proper evidence and data. Take a look at the handbook:

I've a perfectly good PR about vinum (panics) open. There's no even single
follow up (kern/22103).
I couldn't stand it any longer, so I'm not able to recreate it since I'm
using raid1 on those disks now. I waited for almost one month but
aparently nothing was done. (I opened one PR before that but it was badly
formatted and had to become closed).

I understand that people have other things to do, and FreeBSD is volunteer
project, but we shall face the truth - the man page for vinum should state 
that RAID5 is experimental and prone to crashes. It should be emphasized
that it shouldn't be used in sensitive environmets.
I know other people for whom it rendered their servers unusable.

I managed 8( to crash it today as well. I'll probably move to hardware
raid solution instead, I'm quite fed up with vinum.

   to find out exactly what's looked for. In short, you should at least
   provide a backtrace following the panic/page fault/whatever it is you're
   seeing.

I've a crash dump of today, perhaps I'll open another PR.

--Roman Shterenzon, UNIX System Administrator and Consultant
[ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: Stability

[Chris BeHanna]

On Sat, 4 Nov 2000, Marko Cuk wrote:

 Hello !!
 
 Can anyone explain me, why is FreeBSD known as powerful sistem with
 industrial strenghth and rock stability, but I manage to crash it several
 times.
 
 The bridge code in 4.1x is unstable in conjuction with ipfw, I had several
 problems with Vinum and Raid5 and maschine crashed every day if I used
 something od previously mentioned things.

Perfectly valid question.  My own datapoint is that I'm running
bridging code and ipfw, but not vinum, and my machine stays up, modulo
an mbuf leakage problem.

(Note:  I'm going to have a couple of weeks off from work for
medical leave, but I just finished the 100Mbps backbone in my
house, so maybe I can help track down the mbuf problem--and my
lingering SB16 no sound problem.)

--
Chris BeHanna
Software Engineer (at yourfit.com)
[EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: Stability and versions - was Re: Let 3.x die ASAP?

[Richard Wackerbarth]

On Fri, 31 Mar 2000, J McKitrick wrote:
 "STABLE" refers to the code base, NOT the stability of systems running
 it.
 Simple concept, deep meaning.  Newbies should understand  ...

And therein lies the problem. Newbies don't understand much of anything
about this (or any other) project. The approach with the "common English",
(or French, German, etc.) point of view. If they, for whatever reason, select
an inappropriate branch, they are very likely to conclude that FreeBSD is
a "toy" or otherwise non-serious project and turn their attention to another
system. This further hurts FreeBSD because they will also spread word of
their poor experience to others.

As has often been said, "You only get one chance to make a good first
impression". Unless the developers wake up and realize that "market share"
is important and take steps to improve it, FreeBSD will continue to be a "back
water" inconsequential sand box. We desperately need more companies to 
consider FreeBSD as their first choice for corporate servers.
Market share is significantly affected by first impressions. We need to do
EVERYTHING possible to make that first experience a good one -- 
Especially when it doesn't affect the ultimate performance of the system.

Quit thinking of FreeBSD from the developer's point of view. Think of it
from the new user's viewpoint. Give them what they expect. The developers
are better capable of adapting. And any "fossils" who want to argue "we've
always done it that way" need to move over. OS's today are not what they
were five, much less thirty, years ago. If you want things like they used to be,
stick with BSD 4.4 (if you can still find any hardware to run it) and program
in COBOL.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: Stability and versions - was Re: Let 3.x die ASAP?

[J McKitrick]

I think one simple solution is to 'hide' the -current distro, or make
it a little less accessible.  That seems like a good first step.  No
one who can't figure it out needs tobe running it anyway, and it
certainly won't hurt the development effort.  Then, of course, keep
whipping 4.x into shape, tack on a decent, if not graphical, interface
and let it sell itself.  Er, raher, give itself away.

jm
-- 

Jonathon McKitrick -- [EMAIL PROTECTED] 
"You're the guy from the Hambuger Train, right?"



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

RE: Stability problems in 3.3-R?

[Christopher Michaels]

Well, I had 3.3-RC on my box and now I have 3.3-RELEASE.  I had no problems
at all except for one and that I tracked down to what I'll call user error.
I also have similar hardware as you do.

k6/2-300, 64mb ram, fic 503+ w/ VIA MVP4 chipset.

It may help to get a panic and possibly a crash dump to the list to get
someone's opinion on the errors your getting.

But to answer your original question, I don't believe there are issues
specific to 3.3-RC (or release) with your hardware that would cause frequent
(if any) panics.

-Chris

 -Original Message-
 From: Donald Burr [SMTP:[EMAIL PROTECTED]]
 Sent: Friday, September 24, 1999 7:06 AM
 To:   FreeBSD Questions
 Cc:   [EMAIL PROTECTED]
 Subject:  Stability problems in 3.3-R?
 
 I just installed FreeBSD 3.3 on my machine (AMD K6-2/350, EPoX
 EP-MVP4A motherboard [VIA MVP4 chipset], 128 MB RAM).  (Actually, I am
 running 3.3-RC, `make world'ed about 1 week before release
 date)
 
 However, my machine is now crashing at least once a day, sometimes more
 than once a day.  There is no regularity to the crashes, they seem to
 happen during periods of heavy use just as equally as during idle times.
 I've tried killing almost all of my daemons and servers, but that doesn't
 seem to help at all.
 
 I'm beginning to suspect hardware instability.  HOWEVER, I have been
 reading some messages in freebsd-stable and there seem to be other people
 having stability problems with their boxen under 3.3, whereas the same
 hardware works perfectly under 3.2.  So I'm wondering if there any
 known stability issues with 3.3-RC, and will a cvsup and upgrade
 to 3.3-STABLE help me out?
 
 Comments, anyone?  Thanks!
 (Please reply via email if possible)
 -- 
 Donald Burr [EMAIL PROTECTED] *NEW!* FreeBSD Dev.   | FreeBSD: The
 WWW: http://www.Powered-By.AC/ *NEW!*  ICQ #16997506| Power to
 Address: P.O. Box 91212, Santa Barbara, CA 93190-1212   | Serve! http://
 Phone: (805) 957-9666FAX: (800) 492-5954| www.freebsd.org/
 
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-stable" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message