On Wed, 2006-04-05 at 19:38 +1000, Nick Piggin wrote:
> Ian Kumlien wrote:
> >>Ian Kumlien wrote:
> >>
> >>
> >>>Yes, i run a tainted kernel! either live with it or ignore this mail
> >>>=)
> >>
> >>>starting swap lead to a deadlock within 15 mins
> >>
> >>>I have never had the energy to perform a full memtext86+
> >>
> >>It would be useful if you could perform a memtest overnight one night,
> >>then run a non-patched and non-tained 2.6.16.1 kernel, and try to
> >>reproduce the problems.
> >
> >
> > As i said, i really doubt that the memory is at fault here, it has done
> > several passes over the memory but not all tests. I can give it a go
> > though, but i really doubt it'll find anything.
> >
>
> If it doesn't cost you much time (ie. do it overnight) it could save some
> developers a lot of time.
Yes, i'll try to do it this weekend... Since i need to keep this box
running most of the time.
> > The kernel i run is a plain 2.6.16.1 from kernel.org (i have heard that
> > you can actually compile gentoos own these days)
>
> OK, good.
Kernel.org, it's the only flavor =)
> > Since this is my *cough* desktop, running it without that ability is
> > kinda a show stopper, thats why i included the thing above.
>
> But if the problem can be reproduced in 15 minutes, it shouldn't be
> too hard to get a trace without nvidia loaded.
The major bit is, this worked with single core with reiser... Someone
else reported problems with XFS lately though, i'll have to read all
about it...
> > But the thing is, my laptop runs with the same compiler, "same" nvidia
> > driver and the "same" kernel ("same" as in 32 bit not 64 bit).
> > Eventhough "same" in this case usually means nothing, i doubt that one
> > would have a serius bug and the other wouldn't, ie it's most likley a
> > bug related to 64 bits or one or more of the drivers involved.
> >
> > The only errors i get in dmesg atm is:
> > KERNEL: assertion (!sk->sk_forward_alloc) failed at net/core/stream.c
> > (283)
> > KERNEL: assertion (!sk->sk_forward_alloc) failed at net/ipv4/af_inet.c
> > (150)
> >
> > Which is related to TSO, from what i gather, but i can't turn off tso on
> > forcedeth... (i suspected this to cause corruption a while back....)
>
> If your network hardware or driver is flakey, try compiling a kernel
> without that as well before reproducing this swap problem.
Well, flakey and flakey, it's been running with pretty heavy network and
io load for 4 days now... (with forcedeth, but there is no ethtool
interface for disabling TSO, if that is the problem)
The sky2 driver tended to just die and lockup the box after a while, but
i haven't tested Stepehns recent changes yet since i want something
reliable first, to i have a base for comparison.
Oh, Btw:
free
total used free shared buffers
cached
Mem: 3056436 3039052 17384 0 4804
2001672
-/+ buffers/cache: 1032576 2023860
Swap: 0 0 0
If the memory was faulty, i'd have a corrupt filesystem by now imho...
=)
Btw, sorry about being unclear, i spotted it after i mailed, but...
Running without nvidia drivers on a nvdidia card is pretty horrible on a
desktop machine, the kind of resolutions you can get would have been ok
on a amiga, but with X, everything is sooo much bigger... =P
Also, sorry about the CC comment, but it took a day for your mail to hit
my inbox, ie a day after it appeared on lkml, must be the greylists
being overly efficient... =P
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
Attachment:
signature.asc
Description: This is a digitally signed message part
- References:
- Re: [OOPS] related to swap?
- From: Ian Kumlien <[email protected]>
- Re: [OOPS] related to swap?
- From: Nick Piggin <[email protected]>
- Re: [OOPS] related to swap?
- Prev by Date: Re: Linux 2.6.17-rc1
- Next by Date: Re: [PATCH 2/4] coredump: speedup SIGKILL sending
- Previous by thread: Re: [OOPS] related to swap?
- Next by thread: Re: [OOPS] related to swap?
- Index(es):
 |