On 3/3/06, Andrew Morton <[email protected]> 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 <[email protected]>
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
"Jesper Juhl" <[email protected]> wrote:
>
> On 3/3/06, Andrew Morton <[email protected]> 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".
On 3/6/06, Andrew Morton <[email protected]> wrote:
> "Jesper Juhl" <[email protected]> wrote:
> >
> > On 3/3/06, Andrew Morton <[email protected]> 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 <[email protected]>
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
On Mon, 6 Mar 2006 22:59:56 +0100 Jesper Juhl wrote:
> On 3/3/06, Andrew Morton <[email protected]> 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
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 <[email protected]> 1.925.600.0401
>>>>> "Paul" == Paul Jackson <[email protected]> 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
On Tuesday 07 March 2006 06:10, Jes Sorensen wrote:
> >>>>> "Paul" == Paul Jackson <[email protected]> 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
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