CC-ing author since I'm unsure about domain responsibility. The commit
"[PATCH] initcall failure reporting" AKA
c1cda48af8b330a23206eceef3bd030b53c979cd immediately triggered:
--- dmesg-cd02b966bfcad12d1b2e265dc8dbc331d4c184c4 2006-03-30 08:41:30.000000000 +0200
+++ dmesg-c1cda48af8b330a23206eceef3bd030b53c979cd 2006-03-30 09:12:31.000000000 +0200
[...]
@@ -83,10 +83,12 @@
SCSI subsystem initialized
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
+initcall at 0xffffffff804615d1: returned with error code -1
pnp: 00:06: ioport range 0x600-0x60f has been reserved
pnp: 00:06: ioport range 0x1c0-0x1cf has been reserved
pnp: 00:06: ioport range 0x4d0-0x4d1 has been reserved
pnp: 00:06: ioport range 0xfe10-0xfe11 could not be reserved
+initcall at 0xffffffff804704fc: returned with error code 2
PCI: Failed to allocate mem resource #6:20000@f0000000 for 0000:01:00.0
PCI: Bridge: 0000:00:01.0
IO window: disabled.
Since then (now at 2.6.16-git18) the last/lower one has vanished, but the
first one remains. The patch says that the initcall function should be
printed, but it seems to need some debugging option set. Please advice if
this is of interest (the addresses do not stay constant).
Mvh
Mats Johannesson
--
Voluspa <[email protected]> wrote:
>
>
> CC-ing author since I'm unsure about domain responsibility. The commit
> "[PATCH] initcall failure reporting" AKA
> c1cda48af8b330a23206eceef3bd030b53c979cd immediately triggered:
>
> --- dmesg-cd02b966bfcad12d1b2e265dc8dbc331d4c184c4 2006-03-30 08:41:30.000000000 +0200
> +++ dmesg-c1cda48af8b330a23206eceef3bd030b53c979cd 2006-03-30 09:12:31.000000000 +0200
> [...]
> @@ -83,10 +83,12 @@
> SCSI subsystem initialized
> PCI: Using ACPI for IRQ routing
> PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
> +initcall at 0xffffffff804615d1: returned with error code -1
> pnp: 00:06: ioport range 0x600-0x60f has been reserved
> pnp: 00:06: ioport range 0x1c0-0x1cf has been reserved
> pnp: 00:06: ioport range 0x4d0-0x4d1 has been reserved
> pnp: 00:06: ioport range 0xfe10-0xfe11 could not be reserved
> +initcall at 0xffffffff804704fc: returned with error code 2
> PCI: Failed to allocate mem resource #6:20000@f0000000 for 0000:01:00.0
> PCI: Bridge: 0000:00:01.0
> IO window: disabled.
>
> Since then (now at 2.6.16-git18) the last/lower one has vanished, but the
> first one remains. The patch says that the initcall function should be
> printed, but it seems to need some debugging option set. Please advice if
> this is of interest (the addresses do not stay constant).
>
If you have CONFIG_KALLSYMS enabled then the kernel should print the name
of the function at that address. It's pretty hard to turn off
CONFIG_KALLSYMS, actually.
If you _do_ have CONFIG_KALLSYMS enabled then something bad has happened -
you can look up those addresses with `nm -n vmlinux > foo' then searching
through foo. (Or use addr2line, or gdb, or other things...)
On Thu, 30 Mar 2006 03:19:49 -0800 Andrew Morton wrote:
> Voluspa wrote:
[..]
> >
> > Since then (now at 2.6.16-git18) the last/lower one has vanished, but the
> > first one remains. The patch says that the initcall function should be
> > printed, but it seems to need some debugging option set. Please advice if
> > this is of interest (the addresses do not stay constant).
> >
>
> If you have CONFIG_KALLSYMS enabled then the kernel should print the name
> of the function at that address. It's pretty hard to turn off
> CONFIG_KALLSYMS, actually.
Ah ok, kallsyms... I've been pampered by good quality kernels and turned it
off a long time ago.
initcall at 0xffffffff8049a5b0: late_hpet_init+0x0/0xb0(): returned with error code -1
loke@sleipner:/home/git$ grep -i hpet 2.6.16-git-kallsyms-.config
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
CONFIG_HPET_MMAP=y
Those options are just wish-thinking since the machine doesn't have that kind of timer.
So the warning should go away when I turn them off. Sorry about the noise.
Mvh
Mats Johannesson
--
Voluspa <[email protected]> writes:
>
> Those options are just wish-thinking since the machine doesn't have that kind of timer.
> So the warning should go away when I turn them off. Sorry about the noise.
I fixed it here
-Andi