Re: physmap and "request_module: runaway loop modprobe net-pf-1"

["Gordon Farquharson" <gordonfarquharson@gmail.com>]

Hi David

On Tue, Apr 22, 2008 at 6:37 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Tue, 2008-03-11 at 22:59 -0700, Andrew Morton wrote:
>
> > Now, af_unix_init() uses module_init(), which is really __initcall(), which
>  > is really device_initcall() (ug, don't ask).
>
>  ... which is really __define_initcall("6", ...);.
>
>
>  > So you can do what you're sugesting here by locating the caller/callers of
>  > parse_mtd_partitions() and marking them late_initcall().
>
>  Better still, just initialise af_unix earlier so that it's there before
>  any normal drivers which happen to call request_module(). Since core
>  network stuff is initialised with subsys_initcall() which is really
>  __define_initcall("4", ...), we can initialise af_unix with
>  fs_initcall() which is really __define_initcall("5", ...).

I tested the patch you sent. It fixes the runaway modprobe messages,
but I get a modprobe error (see below) with the Debian kernel I used
to test the patch because modules.dep does not exist in the initramfs
(should it?). In my kernel config, I did not enable
CONFIG_MTD_CMDLINE_PARTS and I set CONFIG_MTD_REDBOOT_PARTS=m but the
redboot module was not included in the initramfs so it could not be
loaded, hence the messages saying that the parsing schemes are not
available.

[    4.790000] physmap platform flash device: 00080000 at f0000000
[    4.800000] Found: ST M29W400DB
[    4.800000] physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
[    4.810000] number of JEDEC chips: 1
[    4.810000] cfi_cmdset_0002: Disabling erase-suspend-program due to
code brokenness.
modprobe: FATAL: Could not load
/lib/modules/2.6.25-trunk-iop32x/modules.dep: No such file or
directory

[    4.900000] cmdlinepart partition parsing not available
modprobe: FATAL: Could not load
/lib/modules/2.6.25-trunk-iop32x/modules.dep: No such file or
directory

[    4.970000] RedBoot partition parsing not available

I guess the question is which patch (if either) is more appealing.

Gordon

-- 
Gordon Farquharson
GnuPG Key ID: 32D6D676