* Messages "ACPI attempting to access kernel owned memory"?
@ 2001-08-30 20:54 Andreas Franck
2001-08-30 21:10 ` Alan Cox
0 siblings, 1 reply; 6+ messages in thread
From: Andreas Franck @ 2001-08-30 20:54 UTC (permalink / raw)
To: linux-kernel
Hello people,
since a few releases of 2.4.x-ac? I get the following error message before
ACPI is initialized:
ACPI attempting to access kernel owned memory at 040FDC09.
ACPI attempting to access kernel owned memory at 040FDC09.
ACPI attempting to access kernel owned memory at 040FF78C.
ACPI attempting to access kernel owned memory at 040FF78C.
ACPI attempting to access kernel owned memory at 040FFBC0.
ACPI attempting to access kernel owned memory at 040FDC31.
ACPI attempting to access kernel owned memory at 040FDC31.
ACPI: Core Subsystem version [20010615]
ACPI: Subsystem enabled
ACPI: System firmware supports S0 S1 S5
Processor[0]: C0 C1 C2
Power Button: found
My mainboard is an Intel AL440LX with (440LX Chipset), a bit old, but ACPI
works (at least, it cleanly shutd down my computer when I push the power
button, which seems the only thing it really does, so far).
Apart from this messages showing up at boot time, everything works normal.
What puzzles me is that the memory adresses should not be owned by the
kernel, the ranges are reserved for ACPI in the BIOS-e820 printout:
Linux version 2.4.9-ac3 (root@dg1kfa) (gcc version 2.95.2 19991024
(release)) #1 Wed Aug 29 23:09:32 CEST 2001
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e7400 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000040fdc00 (usable)
BIOS-e820: 00000000040fdc00 - 00000000040ff800 (ACPI data)
BIOS-e820: 00000000040ff800 - 00000000040ffc00 (ACPI NVS)
BIOS-e820: 00000000040ffc00 - 0000000020000000 (usable)
BIOS-e820: 00000000fffe7400 - 0000000100000000 (reserved)
On node 0 totalpages: 131072
zone(0): 4096 pages.
zone(1): 126976 pages.
zone(2): 0 pages.
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Kernel command line: root=/dev/hdc2 apm=off video=matrox:vesa:280,fv:76
hdb=ide-scsi mem=524288K
In the .config, I have enabled the following options for kernel debugging (to
help you all to fix my problems :-):
#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_IOVIRT=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_BUGVERBOSE=y
The PM/ACPI configuration looks as following:
CONFIG_PM=y
CONFIG_ACPI=y
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_BUSMGR=y
CONFIG_ACPI_SYS=y
CONFIG_ACPI_CPU=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_CMBATT=y
CONFIG_ACPI_THERMAL=y
# CONFIG_APM is not set
I hope this report was useful, I'm willing to test any suggestions or patches
here.
Greetings,
Andreas
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Messages "ACPI attempting to access kernel owned memory"?
2001-08-30 20:54 Messages "ACPI attempting to access kernel owned memory"? Andreas Franck
@ 2001-08-30 21:10 ` Alan Cox
2001-08-31 1:56 ` Andreas Franck
0 siblings, 1 reply; 6+ messages in thread
From: Alan Cox @ 2001-08-30 21:10 UTC (permalink / raw)
To: Andreas Franck; +Cc: linux-kernel
> since a few releases of 2.4.x-ac? I get the following error message before
> ACPI is initialized:
>
> ACPI attempting to access kernel owned memory at 040FDC09.
> ACPI attempting to access kernel owned memory at 040FDC09.
> ACPI attempting to access kernel owned memory at 040FF78C.
> ACPI attempting to access kernel owned memory at 040FF78C.
> ACPI attempting to access kernel owned memory at 040FFBC0.
> ACPI attempting to access kernel owned memory at 040FDC31.
> ACPI attempting to access kernel owned memory at 040FDC31.
> ACPI: Core Subsystem version [20010615]
> ACPI: Subsystem enabled
> ACPI: System firmware supports S0 S1 S5
> Processor[0]: C0 C1 C2
> Power Button: found
>
> My mainboard is an Intel AL440LX with (440LX Chipset), a bit old, but ACPI
> works (at least, it cleanly shutd down my computer when I push the power
> button, which seems the only thing it really does, so far).
Thanks for the traces.
> BIOS-e820: 00000000040fdc00 - 00000000040ff800 (ACPI data)
> BIOS-e820: 00000000040ff800 - 00000000040ffc00 (ACPI NVS)
Ok the code I use for debug checks assumes that the memory in question is
has been marked as reserved. I need to review the code since that seems
not to have happened in this case.
I'll investigate - seems the trap is buggy 8)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Messages "ACPI attempting to access kernel owned memory"?
2001-08-30 21:10 ` Alan Cox
@ 2001-08-31 1:56 ` Andreas Franck
2001-08-31 2:31 ` Jan Niehusmann
2001-08-31 13:53 ` Alan Cox
0 siblings, 2 replies; 6+ messages in thread
From: Andreas Franck @ 2001-08-31 1:56 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
Hello Alan and linux-kernel audience,
> Thanks for the traces.
>
> > BIOS-e820: 00000000040fdc00 - 00000000040ff800 (ACPI data)
> > BIOS-e820: 00000000040ff800 - 00000000040ffc00 (ACPI NVS)
>
> Ok the code I use for debug checks assumes that the memory in question is
> has been marked as reserved. I need to review the code since that seems
> not to have happened in this case.
> I'll investigate - seems the trap is buggy 8)
No, your code is all right, I have found the cause of this behaviour: it's
because I boot with GRUB and not with LILO. So, you might say "What the hell
does the bootloader matter", and this is what I also thought in the first
hours, until I noticed that GRUB was adding a "mem=524288K" entry to my
kernel commandline, why ever (it's right, I have 512MB of RAM, but the kernel
could find that by itself, without being told by GRUB...)
The consequences of this mem=... are quite extreme, which is what I have
found out now (and should be fixed, or at least documented, IMHO!):
>From arch/i386/kernel/setup.c (parse_mem_cmdline):
[...]
for (;;) {
/*
* "mem=nopentium" disables the 4MB page tables.
* "mem=XXX[kKmM]" defines a memory region from HIGH_MEM
* to <mem>, overriding the bios size.
* "mem=XXX[KkmM]@XXX[KkmM]" defines a memory region from
* <start> to <start>+<mem>, overriding the bios size.
*/
if (c == ' ' && !memcmp(from, "memx=", 4)) {
[...]
} else {
/* If the user specifies memory size, we
* blow away any automatically generated
* size
*/
unsigned long long start_at, mem_size;
if (usermem == 0) {
/* first time in: zap the whitelist
* and reinitialize it with the
* standard low-memory region.
*/
e820.nr_map = 0;
^^^^^^^^^^^^^^^^^ <- Here the complete E820 map is
cleaned without any further notice!!!
usermem = 1;
[...]
So when specifying a mem=... on the command line, all the information from
the E820 tables is lost, and the ACPI memory ranges are not allocated as
iomem resources. With a mem=... option, they do not show up in /proc/iomem,
without it they do nicely, and your check keeps quiet:
from /proc/iomem (without mem=... on the commandline)
00000000-0009f7ff : System RAM
0009f800-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-040fdbff : System RAM
00100000-0025ea7b : Kernel code
0025ea7c-002ecb4b : Kernel data
040fdc00-040ff7ff : ACPI Tables
040ff800-040ffbff : ACPI Non-volatile Storage
040ffc00-1fffffff : System RAM
f4000000-f48fffff : PCI Bus #01
[...]
from dmesg, without mem=...:
[...]
allocated 32 pages and 32 bhs reserved for the highmem bounces
VFS: Diskquotas version dquot_6.5.0 initialized
devfs: v0.107 (20010709) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
ACPI: Core Subsystem version [20010615]
ACPI: Subsystem enabled
ACPI: System firmware supports S0 S1 S5
Processor[0]: C0 C1 C2
Power Button: found
PCI: Found IRQ 10 for device 01:00.0
matroxfb: Matrox Millennium G400 MAX (AGP) detected
[...]
So the solution was not to use a mem commandline. I have not found a way to
tell GRUB it should not pass this option, so this should be fixed in GRUB.
Futhermore, one should discuss if the current kernel behaviour is right
(clearing the E820 table completely when specifying mem=...) -- I think the
"reserved" and ACPI ranges should be kept and merged into the faked tables,
so we do not get in risk of overwriting this memory by accident.
Greetings,
Andreas
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Messages "ACPI attempting to access kernel owned memory"?
2001-08-31 1:56 ` Andreas Franck
@ 2001-08-31 2:31 ` Jan Niehusmann
2001-08-31 13:53 ` Alan Cox
1 sibling, 0 replies; 6+ messages in thread
From: Jan Niehusmann @ 2001-08-31 2:31 UTC (permalink / raw)
To: Andreas Franck; +Cc: Alan Cox, linux-kernel
On Fri, Aug 31, 2001 at 03:56:00AM +0200, Andreas Franck wrote:
> So the solution was not to use a mem commandline. I have not found a way to
> tell GRUB it should not pass this option, so this should be fixed in GRUB.
the option you are looking for is --no-mem-option in grubs menu.lst.
For example:
kernel --no-mem-option (hd0,2)/boot/latest-kernel root=/dev/hda3
Jan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Messages "ACPI attempting to access kernel owned memory"?
2001-08-31 1:56 ` Andreas Franck
2001-08-31 2:31 ` Jan Niehusmann
@ 2001-08-31 13:53 ` Alan Cox
2001-08-31 16:49 ` Andreas Franck
1 sibling, 1 reply; 6+ messages in thread
From: Alan Cox @ 2001-08-31 13:53 UTC (permalink / raw)
To: Andreas Franck; +Cc: Alan Cox, linux-kernel
> No, your code is all right, I have found the cause of this behaviour: it's
> because I boot with GRUB and not with LILO. So, you might say "What the hell
> does the bootloader matter", and this is what I also thought in the first
> hours, until I noticed that GRUB was adding a "mem=524288K" entry to my
This is a known problem with old versions of GRUB. Up to date versions of
grub shouldnt be passing mem= lines.
Alan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Messages "ACPI attempting to access kernel owned memory"?
2001-08-31 13:53 ` Alan Cox
@ 2001-08-31 16:49 ` Andreas Franck
0 siblings, 0 replies; 6+ messages in thread
From: Andreas Franck @ 2001-08-31 16:49 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
Hello Alan, hello linux-kernel,
> > No, your code is all right, I have found the cause of this behaviour:
> > it's because I boot with GRUB and not with LILO. So, you might say "What
> > the hell does the bootloader matter", and this is what I also thought in
> > the first hours, until I noticed that GRUB was adding a "mem=524288K"
> > entry to my
>
> This is a known problem with old versions of GRUB. Up to date versions of
> grub shouldnt be passing mem= lines.
So I'll try to get a newer GRUB, the --no-mem-option suggestion from Jan
Niehusmann didn't work for me (using GRUB version 0.5.96.1). But,
nevertheless, shouldn't this be fixed (not reserving ACPI memory when a mem=
commandline is passed)? Or, at least documented somewhere?
Greetings,
Andreas
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-08-31 16:49 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-30 20:54 Messages "ACPI attempting to access kernel owned memory"? Andreas Franck
2001-08-30 21:10 ` Alan Cox
2001-08-31 1:56 ` Andreas Franck
2001-08-31 2:31 ` Jan Niehusmann
2001-08-31 13:53 ` Alan Cox
2001-08-31 16:49 ` Andreas Franck
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).