initcall at ... returned with error code -19 (Was: Re: 2.6.16-rc5-mm2)

initcall at ... returned with error code -19 (Was: Re: 2.6.16-rc5-mm2)

[Jesper Juhl]

On 3/3/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc5/2.6.16-rc5-mm2/
>

With this kernel I sometimes get :
  initcall at 0xc0432790: rng_init+0x0/0xa0(): returned with error code -19
and sometimes :
  initcall at 0xc0428240: init_hpet_clocksource+0x0/0x90(): returned
with error code -19

I haven't paid enough attention to be able to say if some boots had
other variations, but at least the two above have been observed.

2.6.16-rc5-git8 is fine.

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: initcall at ... returned with error code -19 (Was: Re: 2.6.16-rc5-mm2)

[Andrew Morton]

"Jesper Juhl" <jesper.juhl@gmail.com> wrote:
>
> On 3/3/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc5/2.6.16-rc5-mm2/
> >
> 
> With this kernel I sometimes get :
>   initcall at 0xc0432790: rng_init+0x0/0xa0(): returned with error code -19
> and sometimes :
>   initcall at 0xc0428240: init_hpet_clocksource+0x0/0x90(): returned
> with error code -19
> 
> I haven't paid enough attention to be able to say if some boots had
> other variations, but at least the two above have been observed.
> 

That's OK - it's -ENODEV.  It's saying "hey, you linked this driver into
vmlinux but it didn't find any hardware to drive".

Re: initcall at ... returned with error code -19 (Was: Re: 2.6.16-rc5-mm2)

[Jesper Juhl]

On 3/6/06, Andrew Morton <akpm@osdl.org> wrote:
> "Jesper Juhl" <jesper.juhl@gmail.com> wrote:
> >
> > On 3/3/06, Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc5/2.6.16-rc5-mm2/
> > >
> >
> > With this kernel I sometimes get :
> >   initcall at 0xc0432790: rng_init+0x0/0xa0(): returned with error code -19
> > and sometimes :
> >   initcall at 0xc0428240: init_hpet_clocksource+0x0/0x90(): returned
> > with error code -19
> >
> > I haven't paid enough attention to be able to say if some boots had
> > other variations, but at least the two above have been observed.
> >
>
> That's OK - it's -ENODEV.  It's saying "hey, you linked this driver into
> vmlinux but it didn't find any hardware to drive".
>

Hmm, then perhaps we should make the warnings print some slightly less
"bad things happening" looking string...
As it is it looks very much like something bad is going on, so I
predict it will generate a lot of bug reports in the future if left in
its current form.

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: initcall at ... returned with error code -19 (Was: Re: 2.6.16-rc5-mm2)

[Randy.Dunlap]

On Mon, 6 Mar 2006 22:59:56 +0100 Jesper Juhl wrote:

> On 3/3/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc5/2.6.16-rc5-mm2/
> >
> 
> With this kernel I sometimes get :
>   initcall at 0xc0432790: rng_init+0x0/0xa0(): returned with error code -19
> and sometimes :
>   initcall at 0xc0428240: init_hpet_clocksource+0x0/0x90(): returned
> with error code -19
> 
> I haven't paid enough attention to be able to say if some boots had
> other variations, but at least the two above have been observed.
> 
> 2.6.16-rc5-git8 is fine.

Andrew added some initcall error detection messages.
-19 is just -ENODEV.  No big deal except maybe the messages themselves. :)
You don't have a RNG or HPET device...

---
~Randy

Re: initcall at ... returned with error code -19 (Was: Re: 2.6.16-rc5-mm2)

[Paul Jackson]

Andrew wrote:
> That's OK - it's -ENODEV. 

I can't help but wonder if the particular case of -ENODEV should
be kept quiet, as in the following totally untested patch:

diff -Naurp 2.6.16-rc5-mm2.orig/init/main.c 2.6.16-rc5-mm2/init/main.c
--- 2.6.16-rc5-mm2.orig/init/main.c	2006-03-06 17:02:46.491860190 -0800
+++ 2.6.16-rc5-mm2/init/main.c	2006-03-06 17:07:29.754830844 -0800
@@ -608,7 +608,8 @@ static void __init do_initcalls(void)
 
 		result = (*call)();
 
-		if (result) {
+		/* don't mind -ENODEV - just a driver w/o hardware */
+		if (result && result != -ENODEV) {
 			sprintf(msgbuf, "error code %d", result);
 			msg = msgbuf;
 		}

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: initcall at ... returned with error code -19 (Was: Re: 2.6.16-rc5-mm2)

[Jes Sorensen]

>>>>> "Paul" == Paul Jackson <pj@sgi.com> writes:

Paul> Andrew wrote:
>> That's OK - it's -ENODEV.

Paul> I can't help but wonder if the particular case of -ENODEV should
Paul> be kept quiet, as in the following totally untested patch:

I'd subscribe to that. It seems a bit wrong to return 0 in a
loadable module if nothing is found, and some of the ones people have
posted patches for converting can be either modules or static.

Cheers,
Jes

Re: initcall at ... returned with error code -19 (Was: Re: 2.6.16-rc5-mm2)

[Jes Sorensen]

Bjorn Helgaas wrote:
> On Tuesday 07 March 2006 06:10, Jes Sorensen wrote:
>> I'd subscribe to that. It seems a bit wrong to return 0 in a
>> loadable module if nothing is found, and some of the ones people have
>> posted patches for converting can be either modules or static.
> 
> Yeah, maybe.  But it feels a little like the question of whether
> {pci,pnp,acpi_bus}_register_driver() should return the number of
> devices found.  The consensus is that these functions should return
> only a negative error, or zero for success, leaving any counting of
> devices to the driver's .probe() or .add() method.
> 
> I think a loadable driver's init function *should* return success
> even if no device is yet present.  Maybe you want to load the driver
> before hot-adding the device.

I don't really like this ;-( If a driver is loaded for a specific PCI
device and that isn't present, then IMHO it is better to have it
return -ENODEV and unload it again.

Cheers,
Jes

Re: initcall at ... returned with error code -19 (Was: Re: 2.6.16-rc5-mm2)

[Bjorn Helgaas]

On Tuesday 07 March 2006 06:10, Jes Sorensen wrote:
> >>>>> "Paul" == Paul Jackson <pj@sgi.com> writes:
> Paul> Andrew wrote:
> >> That's OK - it's -ENODEV.
> 
> Paul> I can't help but wonder if the particular case of -ENODEV should
> Paul> be kept quiet, as in the following totally untested patch:
> 
> I'd subscribe to that. It seems a bit wrong to return 0 in a
> loadable module if nothing is found, and some of the ones people have
> posted patches for converting can be either modules or static.

Yeah, maybe.  But it feels a little like the question of whether
{pci,pnp,acpi_bus}_register_driver() should return the number of
devices found.  The consensus is that these functions should return
only a negative error, or zero for success, leaving any counting of
devices to the driver's .probe() or .add() method.

I think a loadable driver's init function *should* return success
even if no device is yet present.  Maybe you want to load the driver
before hot-adding the device.

The common idiom of, e.g.,

    static int __init serial8250_pci_init(void)
    {
        return pci_register_driver(&serial_pci_driver);
    }

should remain acceptable, though it returns 0 even if no devices
are found.

Bjorn