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):