mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Mark Lord <lkml@rtr.ca>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>,
	Frederik Deweerdt <deweerdt@free.fr>
Subject: Re: 2.6.19-rc3-git7:  BUG: mutex warning sysfs_dir_open
Date: Mon, 06 Nov 2006 16:13:50 +0100	[thread overview]
Message-ID: <s5hwt68fw0h.wl%tiwai@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0610310929090.25218@g5.osdl.org>

At Tue, 31 Oct 2006 09:53:35 -0800 (PST),
Linus Torvalds wrote:
> 
> 
> 
> On Tue, 31 Oct 2006, Mark Lord wrote:
> > 
> > I found this in my syslog just now:
> > 
> > kernel: BUG: warning at kernel/mutex.c:132/__mutex_lock_common()
> 
> That's the "spin_lock_mutex()" debugging (kernel/mutex-debug.h), and it's 
> one of either
> 
> 	DEBUG_LOCKS_WARN_ON(in_interrupt());
> or
> 	DEBUG_LOCKS_WARN_ON(l->magic != l);
> 
> where the much more likely one is the "l->magic" one triggering, because 
> your bug that follows is:
> 
> > kernel: BUG: unable to handle kernel paging request at virtual address 6e726574
> 
> 64726574 is "tern", for whatever that's worth, and that EIP is in 
> "__list_add()", which comes from list_add_tail(), and so it looks like the 
> mutex "lock->lock_list" is also totally buggered (which would certainly 
> fit with the lock "magic" field being crud too).
> 
> > kernel: Call Trace:
> > kernel:  [<c035d76e>] __mutex_lock_slowpath+0x8e/0x260
> > kernel:  [<c035d961>] mutex_lock+0x21/0x30
> > kernel:  [<c01a0286>] sysfs_dir_open+0x26/0x60
> 
> This would be
> 
> 	mutex_lock(&dentry->d_inode->i_mutex);
> 
> in sysfs_dir_open(), so you would seem to have an inode that is 
> overwritten by crud (or it could be a dentry with a bogus d_inode 
> pointer, of course).
> 
> There's a ton of stuff with "tern" in it, mostly "Internal", so sadly even 
> the nice string pattern doesn't seem to be all that helpful.
> 
> Is this somewhat reproducible? 
> 
> HOWEVER, google does find a clue. We've had reports of something somewhat 
> similar before: googling for "__mutex_lock_slowpath" and "sysfs_dir_open" 
> shows for example
> 
> 	http://lkml.org/lkml/2006/8/18/72
> 
> where the thread ended up first blaming sound, but then deciding that 
> maybe it was DRM-related. However, you don't seem to have any AGP or DRM 
> support at all, so maybe it really _is_ a sound problem.
> 
> Mark - can you verify that you don't have any DRM support in your kernel?
> 
> Frederic, Takashi, did that bug-report ever get resolved?

IIRC, in Frederik's case, it turned out to be irrelevant from the
sound stuff since the bug occured even before loading ALSA modules.

Of course, it still _might_ be a sound problem :)

It'd be nice if we can see what sysfs entry triggers bugs...


Takashi

      parent reply	other threads:[~2006-11-06 15:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-31 17:19 Mark Lord
2006-10-31 17:53 ` Linus Torvalds
2006-10-31 17:57   ` Mark Lord
2006-11-06 15:13   ` Takashi Iwai [this message]

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=s5hwt68fw0h.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=akpm@osdl.org \
    --cc=deweerdt@free.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@rtr.ca \
    --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

all inboxes | Powered by JetHome®