mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Horms <horms@debian.org>
To: Frans Pop <aragorn@tiscali.nl>, 320379@bugs.debian.org
Cc: rgooch@atnf.csiro.au,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Bug#320379: Errors during initrd loading when / is on LVM over RAID
Date: Wed, 3 Aug 2005 20:54:37 +0900	[thread overview]
Message-ID: <20050803115432.GT23916@verge.net.au> (raw)
In-Reply-To: <200507290041.49606.aragorn@tiscali.nl>

On Fri, Jul 29, 2005 at 12:41:38AM +0200, Frans Pop wrote:
> Package: kernel
> Tags: patch
> 
> After switching from a 2.4.27 to 2.6.8 kernel for an old desktop Iuse as
> a server, I noticed the following messages on console and kern.log.
> Note: the errors are not harmful, just ugly; the system boots normally.
> 
> kernel: Inspecting /boot/System.map-2.6.8-2-686
> kernel: Loaded 27390 symbols from /boot/System.map-2.6.8-2-686.
> kernel: Symbols match kernel version 2.6.8.
> kernel: No module symbols loaded - kernel modules not enabled.
> kernel: ould not append to parent for /disc
> kernel: devfs_mk_dir: invalid argument.<4>devfs_mk_dev: could not append to parent for /disc
> last message repeated 151 times
> 
> 
> Cleaned for a missing \n in a printk and with added debug printk's in
> fs/devfs/base.c, this looks like:
> kernel: devfs_mk_dir: invalid argument, buf: .
> kernel: _devfs_append_entry: -EEXIST for :disc
> kernel: devfs_mk_dev: could not append to parent for /disc
> (repeated)
> 
> The last error is a consequence of the error in devfs_mk_dir, so can
> be ignored. The basic problem is that buf is empty.
> 
> Tracing back I ended up in fs/partitions/check.c, which has the following code
> in function register_disk:
> 
> 	/* No minors to use for partitions */
> 	if (disk->minors == 1) {
> 		if (disk->devfs_name[0] != '\0')
> 			devfs_add_disk(disk);
> 		return;
> 	}
> 
> 	/* always add handle for the whole disk */
> 	devfs_add_partitioned(disk);
> 
> This looks unlogical: why does the first statement check for empty
> disk->devfs_name and is the second one called blindly?
> 
> Changing the last statement to:
> 	if (disk->devfs_name[0] != '\0')
> 		devfs_add_partitioned(disk);
> 	else
> 		printk(KERN_WARNING "%s: No devfs_name for %s.\n", __FUNCTION__, disk->disk_name);
> resulted in the errors disappearing and the following log output:
> 
> kernel: register_disk: No devfs_name for md_d0.
> kernel: register_disk: No devfs_name for md_d64.
> kernel: register_disk: No devfs_name for md_d128.
> kernel: register_disk: No devfs_name for md_d192.
> kernel: register_disk: No devfs_name for md_d4.
> kernel: register_disk: No devfs_name for md_d68.
> kernel: register_disk: No devfs_name for md_d132.
> kernel: register_disk: No devfs_name for md_d196.
> (repeated to md_d255)
> 
> I've debugged using kernel version 2.6.8, but a check showed this code is
> unchanged in 2.6.11 and 2.6.12.
> 
> Please review my reasoning. If I'm correct, the attached patch may fix
> the errors (and fix the missing \n). If you think the patch is correct,
> I would appreciate advice how best to get it upstream.
> The other option would of course be that something is more fundamentally
> broken and that disk->devfs_name should be filled in these cases, but
> I doubt that.

Hi Frans,

The null devfs_name check seems fine to me,
I've CCed Richard Gooch for comment, hopefully
he can offer one despite devfs being debricated
upstream.

The \n fix is obviously ok, but again its going away upstream,
so I doubt they care, and I'm not excited about this kind
of fix for Sarge.

> 
> Cheers,
> FJP
> 

> --- fs/partitions/check.c.orig	2005-05-19 12:52:23.000000000 +0200
> +++ fs/partitions/check.c	2005-07-29 00:36:04.523385998 +0200
> @@ -348,7 +348,8 @@
>  	}
>  
>  	/* always add handle for the whole disk */
> -	devfs_add_partitioned(disk);
> +	if (disk->devfs_name[0] != '\0')
> +		devfs_add_partitioned(disk);
>  
>  	/* No such device (e.g., media were just removed) */
>  	if (!get_capacity(disk))
> --- fs/devfs/base.c.orig	2005-07-29 00:32:03.329992027 +0200
> +++ fs/devfs/base.c	2005-07-29 00:32:52.000008934 +0200
> @@ -1644,7 +1644,7 @@
>  	va_start(args, fmt);
>  	n = vsnprintf(buf, 64, fmt, args);
>  	if (n >= 64 || !buf[0]) {
> -		printk(KERN_WARNING "%s: invalid argument.", __FUNCTION__);
> +		printk(KERN_WARNING "%s: invalid argument.\n", __FUNCTION__);
>  		return -EINVAL;
>  	}
>  




-- 
Horms

       reply	other threads:[~2005-08-03 12:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200507290041.49606.aragorn@tiscali.nl>
2005-08-03 11:54 ` Horms [this message]
2005-08-03 14:12   ` Adrian Bunk

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=20050803115432.GT23916@verge.net.au \
    --to=horms@debian.org \
    --cc=320379@bugs.debian.org \
    --cc=aragorn@tiscali.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rgooch@atnf.csiro.au \
    /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®