2005-09-02 16:55:36

by Jim Cromie

Subject: 13-mm1: firmware_loading_store goes berserk on boot.

during boot, kernel get caught in a hi-speed loop, issuing these msgs.
from the logs, it appears that the 'repeated' catcher is getting
overwhelmed,
perhaps by message trucation which breaks the pattern.
Ive edited large chunks of repeats that made it into the log.

Sep 2 07:59:36 harpo kernel: firmware_loading_store: unexpected value (0)
Sep 2 07:59:37 harpo last message repeated 83 times
Sep 2 08:01:41 harpo kernel: firmware_loading_store: unexpected value
(0)ected value (0)
Sep 2 08:01:41 harpo kernel: firmware_loading_store: unexpected value (0)
Sep 2 08:01:45 harpo last message repeated 174017 times
Sep 2 08:05:01 harpo last message repeated 36471 times
Sep 2 08:05:01 harpo crond(pam_unix)[13845]: session opened for user
root by (uid=0)
Sep 2 08:05:01 harpo kernel: firmware_loading_store: unexpected value (0)
Sep 2 08:05:01 harpo last message repeated 94 times
Sep 2 08:05:12 harpo last message repeated 420578 times
Sep 2 08:05:17 harpo last message repeated 175067 times

Ill send .config etc to anyone interested.

thx

2005-09-02 17:12:33

by Hugh Dickins

Subject: Re: 13-mm1: firmware_loading_store goes berserk on boot.

On Fri, 2 Sep 2005, Jim Cromie wrote:
>
> during boot, kernel get caught in a hi-speed loop, issuing these msgs.
> from the logs, it appears that the 'repeated' catcher is getting overwhelmed,
> perhaps by message trucation which breaks the pattern.
> Ive edited large chunks of repeats that made it into the log.
>
> Sep 2 07:59:36 harpo kernel: firmware_loading_store: unexpected value (0)
> Sep 2 07:59:37 harpo last message repeated 83 times

Might this be another of the things fixed by patch Andrew posted earlier?
He wrote...

Or revert gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch.
Obviously if you write 30\n and the write returns 2 then the shell will
then try to write the \n. That returns zero and the shell tries again, ad
infinitum.

Rant. It took me two full days to weed out and fix all the crap people
sent me to get -mm1 into a state where it vaguely compiled and booted. And
it's untested nonsense like this which wrecks the whole effort for many
testers.

I suppose this is as good as anything....


From: Andrew Morton <[email protected]>

Signed-off-by: Andrew Morton <[email protected]>
---

fs/sysfs/file.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)

diff -puN fs/sysfs/file.c~gregkh-driver-sysfs-strip_leading_trailing_whitespace-fix fs/sysfs/file.c
--- devel/fs/sysfs/file.c~gregkh-driver-sysfs-strip_leading_trailing_whitespace-fix 2005-09-02 04:01:40.000000000 -0700
+++ devel-akpm/fs/sysfs/file.c 2005-09-02 04:05:02.000000000 -0700
@@ -202,13 +202,14 @@ fill_write_buffer(struct sysfs_buffer *
* passing the buffer that we acquired in fill_write_buffer().
*/

-static int
-flush_write_buffer(struct dentry * dentry, struct sysfs_buffer * buffer, size_t count)
+static int flush_write_buffer(struct dentry *dentry,
+ struct sysfs_buffer *buffer, size_t count_in)
{
struct attribute * attr = to_attr(dentry);
struct kobject * kobj = to_kobj(dentry->d_parent);
struct sysfs_ops * ops = buffer->ops;
char *x;
+ size_t count = count_in;

/* locate trailing white space */
while ((count > 0) && isspace(buffer->page[count - 1]))
@@ -224,7 +225,8 @@ flush_write_buffer(struct dentry * dentr
/* terminate the string */
x[count] = '\0';

- return ops->store(kobj, attr, x, count);
+ ops->store(kobj, attr, x, count);
+ return count_in;
}