mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Grzegorz Kulewski <kangur@polcom.net>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org, Con Kolivas <kernel@kolivas.org>,
	ck@vds.kolivas.org, Linus Torvalds <torvalds@osdl.org>
Subject: Re: BUG in tmpfs
Date: Thu, 19 Jan 2006 14:50:19 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.63.0601191432200.8060@alpha.polcom.net> (raw)
In-Reply-To: <20060119031455.GA15738@kroah.com>

On Wed, 18 Jan 2006, Greg KH wrote:

> On Thu, Jan 19, 2006 at 01:14:56AM +0100, Grzegorz Kulewski wrote:
>> Hi,
>>
>> I managed to get something like this:
>>
>> kernel BUG at mm/shmem.c:836!
>> Jan 17 23:31:42 kangur [4312977.009000] CPU:    0
>> Jan 17 23:31:42 kangur [4312977.009000] EIP:    0060:[<b014a429>]
>> Tainted: P      VLI
>
> Can you duplicate this on a 2.6.15 or newer kernel, without a closed
> source driver loaded?

1. Well, as I said in my message I am not able to reproduce this on demand 
at all. It is the first time it ever happened to me in two months. If 
somebody is interested I can try very hardly to reproduce it but I would 
not expect success.

2. As to the tainted kernel. Well, I know it is tainted (by something 
like madwifi or nvidia loaded by coldplug and not even used from bootup). 
So this is very unlikely that this is the cause. But of course I can not 
guarantee that. But because of #1 -  I am not able to reproduce it with 
untainted kernel - I sent it to this list. Maybe it will make some bells 
ring in some smart head, especially if that head knows how those functions 
and data structures are supposed to work. If no - well - what could I do 
more?

I don't have infrastructure for making 24/7 stress tests of tmpfs (or 
anything other). But maybe if somebody has some spare machines he could 
try doing it because I am seeing different oopses/crashes/bugs in tmpfs on 
different kernel (on x86 and x86-64) from time to time. They are _very_ 
hard to reproduce and are probably also fixed from time to time (maybe by 
other not related changes not because somebody spoted bug in real life). 
Something like making whole system compiles and upgrades in a loop till 
error happens will proably be enough to catch most such errors after some 
time and doing it continously could prevent any regressions in newer 
kernels. All I could do is to try compiling that gcc 3 to 5 times a day 
with all proprietary modules not loaded (and that means real pain on 
desktop system btw).


Thanks,

Grzegorz Kulewski

  reply	other threads:[~2006-01-19 13:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-19  0:14 Grzegorz Kulewski
2006-01-19  3:14 ` Greg KH
2006-01-19 13:50   ` Grzegorz Kulewski [this message]
2006-01-19 18:12     ` Hugh Dickins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.63.0601191432200.8060@alpha.polcom.net \
    --to=kangur@polcom.net \
    --cc=ck@vds.kolivas.org \
    --cc=greg@kroah.com \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome