On Wed, 14 Jul 2004 14:04:39 -0700, Andrey Petrov <petrov@netbsd.org> wrote:
> On Tue, Jul 13, 2004 at 07:57:22PM -0400, Sean Davis wrote:
> > On Tue, 13 Jul 2004 17:48:38 -0600 (MDT), Rick Kelly
> > <rmk@toad.rmkhome.com> wrote:
> > > Sean Davis said:
> > >
> > > >Did it just hang, or did you hit the "sleep sleeps forever" bug?
> > > >I hit that recently on my Ultra 1, running -current. I haven't hit it
> > > >with 2.0_BETA on the same machine, though, and I've only hit it once
> > > >on my Ultra 5 (current) which has been running 24/7 for a long time
> > > >now.
> > >
> > > I have an Ultra 5 that was hitting "sleep sleeps forever" with 1.6.2.
> > > Longest uptime was about 80 days between sleeps. It's running 2.0_BETA
> > > now and I'll just have to wait and see.
> >
> > The one time that my Ultra 5 hit it, it had been up for something like
> > 70 days. So maybe the reason I haven't hit it isn't because I'm lucky,
> > but because I tend to update the box often enough that it's rarely up
> > for more than a month, now... Has there been any progress in finding
> > the cause of the bug? Has anybody compared our sparc64 code with, say,
> 
> It seems to be load and configuration dependant as I've never seen it
> on my machines. It would help if problem were reproducable and problem
> machine were easily accessible.
> 
> > FreeBSD or OpenBSD, which aren't affected by it (as far as I know)?
> 
> I looked (and in linux too), we diverged with OpenBSD quite a bit due to our SA,
> FreeBSD was originated from BSDI core with our drivers so is quite different from
> the beginning. You won't find a fix for the problem comparing sources.
> 
>         Andrey
> 

I wasn't implying that a fix would be obvious. What I meant was that
there is something that they are obviously doing right and we are
obviously doing wrong, if we're the only OS affected by this bug.

-- 
Sean