recent instability

Two days ago, I upgraded to 3.99.18 from 17 April.  Since
then, my laptop
has frozen once and spontaneously rebooted once.  Has anyone
else seen
that sort of instability?

		--Steven M. Bellovin, http://www.cs.columbi
a.edu/~smb

On Wed, 19 Apr 2006 19:53:53 -0400
"Steven M. Bellovin" <smbcs.columbia.edu> wrote:

> Two days ago, I upgraded to 3.99.18 from 17 April. 
Since then, my
> laptop has frozen once and spontaneously rebooted once.
 Has anyone
> else seen that sort of instability?
> 
> 		--Steven M. Bellovin, http://www.cs.columbi
a.edu/~smb
> 

I get freezes from mplayer sometimes. I can't yet track
down what it
is. no kb, no mouse, nada. I think its a freeze,
not just a UI lock. Interestingly, the fn+<F-key>
tasks to blank screen
still works, but suspend/resume keys don't.

I still can't resume X from console mode (ie run X twice
without
reboot inbetween), it locks hard. I wish I knew a way to
prevent that.
recover from a zzz/sleep is fine, its only when I drop out
of X to
console mode it refuses to resume into X.

-G

Steven M. Bellovin wrote:
> Two days ago, I upgraded to 3.99.18 from 17 April. 
Since then, my laptop
> has frozen once and spontaneously rebooted once.  Has
anyone else seen
> that sort of instability?
>
> 		--Steven M. Bellovin, http://www.cs.columbi
a.edu/~smb
>   

Maybe you should stop kicking it into the freezer.     (Sorry,
couldn't resist...)

I don't actually use NetBSD i386 (or amd64), so I can't
comment usefully.

    -- Garrett

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecom
puter.com/
Phone: 951 325-2134  Fax: 951 325-2191

On Thu, 20 Apr 2006, George Michaelson wrote:

> I get freezes from mplayer sometimes. I can't yet
track down what it is. 
> no kb, no mouse, nada. I think its a freeze, not just a
UI lock. 
> Interestingly, the fn+<F-key> tasks to blank
screen still works, but 
> suspend/resume keys don't.

I'm getting that, too (on a much older 3.99.13 build,
though). Sometimes I 
can tell that it went into the debugger (typing 'reboot'
actually reboots 
it) but other times it freezes hard (num lock doesn't work,
etc).

-- 
Tyler Mitchell

On Wed, Apr 19, 2006 at 07:53:53PM -0400, Steven M. Bellovin
wrote:
> Two days ago, I upgraded to 3.99.18 from 17 April. 
Since then, my laptop
> has frozen once and spontaneously rebooted once.  Has
anyone else seen
> that sort of instability?
> 
> 		--Steven M. Bellovin, http://www.cs.columbi
a.edu/~smb

On Wed, Apr 19, 2006 at 07:53:53PM -0400, Steven M. Bellovin
wrote:
> Two days ago, I upgraded to 3.99.18 from 17 April. 
Since then, my laptop
> has frozen once and spontaneously rebooted once.  Has
anyone else seen
> that sort of instability?

In light of this, would it be a good idea to regularly make
"known-to-work"
tags on -HEAD?  I think DragonFly also does this.  This
would make it
easier for people to run -current, if they can't or don't
want to update
and rebuild their systems frequently.  

	Geert

On Thu, 20 Apr 2006, Geert Hendrickx wrote:

> In light of this, would it be a good idea to regularly
make "known-to-work"
> tags on -HEAD?  I think DragonFly also does this.  This
would make it
> easier for people to run -current, if they can't or
don't want to update
> and rebuild their systems frequently.  

Who would do this?

It apparently works for the developer who made the commits
(that break for 
someone else).

 Jeremy C. Reed

echo ':6DB6=88>?;69876tA=AC8BB5tA6487><' | tr
'4-F' 'wu rofIn.lkigemca'

Jeremy C. Reed wrote:
> It apparently works for the developer who made the
commits (that break for 
> someone else).

This reminds me of a question that has been nagging me for a
bit: how
many distinct platforms does a typical developer test on
before committing,
or have access to for testing at all? I, for example, have
only i386 hw
here.

Perhaps NetBSD should have KNOWN_GOOD_<port> tags
added independently
as versions are determined to work on different ports.

The trick would be a good definition of the tag semantics.
KNOWN_GOOD
is really a misleading name--it's more like
not-yet-known-bad, and
has at least two important parameters: not yet known bad
after testing
by how many users and for how long.  Perhaps the tag should
be called
something like CONFIDENCE_1W100_macppc, added as soon as a
version has
seen 1 week's use under normal workloads by 100 macppc
users without noticing
any regression. It sounds like a good candidate for
automation, with a
command like send-sr (for sending "success
reports" rather than problem
reports , and a
receiving process that, upon receiving 100 1-week
success reports for <port>, would move the
CONFIDENCE_1W100_<port> tag,
leaving a CONFIDENCE_1W100_<port>_PREVIOUS tag in its
original place.
Should reports of a significant regression cause the tag to
move back?
One would think the answer should be yes.

The idea obviously generalizes to a small family of
confidence tags that
differ by number of users or duration of testing, and people
could match
their level of risk aversion to the tag they choose to sync
to.

The scheme would require send-sr to unambiguously know the
date/time
(for -D in cvs) of the checkout from which the running
system was
built, which could be kept in a file somewhere in the tree
that is
updated by a commit-script whenever anything is committed
anywhere.
In fact, that seems likely to be functionality we might
already have
though I've not stumbled on it yet--do we have such a
thing? send-sr
should probably also verify that the checked-out sources all
correspond
to the recorded revision date.

I don't know enough about svn to guess if such a scheme
would be easier
or harder in svn. It doesn't seem infeasible in cvs.

Thinking about it, I would actually call such a facility
useful. Does
anybody else think so?  Any thoughts on what values for
duration and
number-of-users would make reasonably meaningful tags?

-Chap

Actually, what this really sounds to me like, is we need
some kind of
automatic regression test suite that picks up nightlies and
runs them. 
If a test suite passes for a build, it could auto-tag them.

A website listing regression failures would be helpful, too.

You wouldn't be able to cover everything this way (e.g.
kind of hard to
test all the different hardware combos), but it would be a
good start,
at least.

    - Garrett

Chapman Flack wrote:
> Jeremy C. Reed wrote:
>> It apparently works for the developer who made the
commits (that
>> break for someone else).
>
> This reminds me of a question that has been nagging me
for a bit: how
> many distinct platforms does a typical developer test
on before
> committing,
> or have access to for testing at all? I, for example,
have only i386 hw
> here.
>
> Perhaps NetBSD should have KNOWN_GOOD_<port> tags
added independently
> as versions are determined to work on different ports.
>
> The trick would be a good definition of the tag
semantics. KNOWN_GOOD
> is really a misleading name--it's more like
not-yet-known-bad, and
> has at least two important parameters: not yet known
bad after testing
> by how many users and for how long.  Perhaps the tag
should be called
> something like CONFIDENCE_1W100_macppc, added as soon
as a version has
> seen 1 week's use under normal workloads by 100 macppc
users without
> noticing
> any regression. It sounds like a good candidate for
automation, with a
> command like send-sr (for sending "success
reports" rather than problem
> reports , and a
receiving process that, upon receiving 100 1-week
> success reports for <port>, would move the
CONFIDENCE_1W100_<port> tag,
> leaving a CONFIDENCE_1W100_<port>_PREVIOUS tag in
its original place.
> Should reports of a significant regression cause the
tag to move back?
> One would think the answer should be yes.
>
> The idea obviously generalizes to a small family of
confidence tags that
> differ by number of users or duration of testing, and
people could match
> their level of risk aversion to the tag they choose to
sync to.
>
> The scheme would require send-sr to unambiguously know
the date/time
> (for -D in cvs) of the checkout from which the running
system was
> built, which could be kept in a file somewhere in the
tree that is
> updated by a commit-script whenever anything is
committed anywhere.
> In fact, that seems likely to be functionality we might
already have
> though I've not stumbled on it yet--do we have such a
thing? send-sr
> should probably also verify that the checked-out
sources all correspond
> to the recorded revision date.
>
> I don't know enough about svn to guess if such a
scheme would be easier
> or harder in svn. It doesn't seem infeasible in cvs.
>
> Thinking about it, I would actually call such a
facility useful. Does
> anybody else think so?  Any thoughts on what values for
duration and
> number-of-users would make reasonably meaningful tags?
>
> -Chap


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecom
puter.com/
Phone: 951 325-2134  Fax: 951 325-2191

On Thu, Apr 20, 2006 at 08:25:18PM -0700, Garrett D'Amore
wrote:
> Actually, what this really sounds to me like, is we
need some kind of
> automatic regression test suite that picks up nightlies
and runs them.
> If a test suite passes for a build, it could auto-tag
them.
> 
> A website listing regression failures would be helpful,
too.
> 
> You wouldn't be able to cover everything this way
(e.g. kind of hard
> to test all the different hardware combos), but it
would be a good
> start, at least.

This seems overkill for what I was looking for.  These tags
shouldn't
occur weekly or even mothly.  Maybe they should just be
feature-based.
Imagine a user who would want to experiment with tmpfs, or
needs some
new driver from -current.  He wouldn't want to use an
"arbitrary"
checkout of -HEAD which could be unstable, or even not
build, because of
an unrelated problem.  He just would like to checkout some
tag which was
set after the commit of the feature/driver/fix he
wants/needs, and use
that.  Of course there would be no guarantees for for this
tag being
"good" (it's -current after all), it would just
be an indication, to
help/stimulate the testing community.  

	Geert