From: Andrew Morton <akpm@linux-foundation.org>
To: "J.J. Green" <j.j.green@sheffield.ac.uk>
Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org
Subject: Re: sparc64 / bbc_i2c.c
Date: Sun, 25 Feb 2007 12:47:54 +0000 [thread overview]
Message-ID: <20070225044754.1d849a8d.akpm@linux-foundation.org> (raw)
In-Reply-To: <1171978032.18442.11.camel@lax.shef.ac.uk>
> On Tue, 20 Feb 2007 13:27:12 +0000 "J.J. Green" <j.j.green@sheffield.ac.uk> wrote:
> Hi all
>
> I got bitten by this problem on sparc64 (a blade 1000)
>
> http://ubuntuforums.org/showthread.php?t)7474
>
> summary :
>
> modprobe bbc
>
> runs kenvctrld which uses 100% of a CPU for 5 seconds,
> then 0% for 5 seconds, then 100% .. and so on. The author
> cited above suggests removing the line
>
> remove_wait_queue(&bp->wq, &wait);
>
> in the function
>
> static int wait_for_pin(struct bbc_i2c_bus *bp, u8 *status)
>
> Is there a better way?
>
> I can test patches if that would be helpful.
>
The code around there looks relatively unbuggy to me. Removing that
remove_wait_queue() would be very bad - it would cause later stack
corruption.
msleep_interruptible() certainly shouldn't consume CPU like that. Do we
know where the CPU time is being spent? The output of:
readprofile -r
sleep 10
readprofile -n -v -m /boot/System.map | sort -n -k 3 | tail -40
would tell us.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: "J.J. Green" <j.j.green@sheffield.ac.uk>
Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org
Subject: Re: sparc64 / bbc_i2c.c
Date: Sun, 25 Feb 2007 04:47:54 -0800 [thread overview]
Message-ID: <20070225044754.1d849a8d.akpm@linux-foundation.org> (raw)
In-Reply-To: <1171978032.18442.11.camel@lax.shef.ac.uk>
> On Tue, 20 Feb 2007 13:27:12 +0000 "J.J. Green" <j.j.green@sheffield.ac.uk> wrote:
> Hi all
>
> I got bitten by this problem on sparc64 (a blade 1000)
>
> http://ubuntuforums.org/showthread.php?t=297474
>
> summary :
>
> modprobe bbc
>
> runs kenvctrld which uses 100% of a CPU for 5 seconds,
> then 0% for 5 seconds, then 100% .. and so on. The author
> cited above suggests removing the line
>
> remove_wait_queue(&bp->wq, &wait);
>
> in the function
>
> static int wait_for_pin(struct bbc_i2c_bus *bp, u8 *status)
>
> Is there a better way?
>
> I can test patches if that would be helpful.
>
The code around there looks relatively unbuggy to me. Removing that
remove_wait_queue() would be very bad - it would cause later stack
corruption.
msleep_interruptible() certainly shouldn't consume CPU like that. Do we
know where the CPU time is being spent? The output of:
readprofile -r
sleep 10
readprofile -n -v -m /boot/System.map | sort -n -k 3 | tail -40
would tell us.
next prev parent reply other threads:[~2007-02-25 12:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-20 13:27 sparc64 / bbc_i2c.c J.J. Green
2007-02-25 12:47 ` Andrew Morton [this message]
2007-02-25 12:47 ` Andrew Morton
2007-02-25 13:33 ` Emanuele Rocca
2007-02-25 13:33 ` Emanuele Rocca
2007-02-25 23:58 ` J.J.Green
2007-02-25 23:58 ` J.J.Green
2007-02-26 18:12 ` David Miller
2007-02-26 18:12 ` David Miller
2007-02-27 5:22 ` Joerg Friedrich
2007-02-27 5:22 ` Joerg Friedrich
2007-02-27 5:29 ` David Miller
2007-02-27 5:29 ` David Miller
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=20070225044754.1d849a8d.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=j.j.green@sheffield.ac.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=sparclinux@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.