* Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit?
@ 2006-09-15 12:19 Roger Lucas
2006-09-15 14:34 ` Roger Lucas
0 siblings, 1 reply; 13+ messages in thread
From: Roger Lucas @ 2006-09-15 12:19 UTC (permalink / raw)
To: linux-acpi
Hi,
I am running Linux kernel 2.6.16.20 with ACPI active on a Abit LG-81
motherboard. Over time, the system slowly runs out of memory. Checking
with "top" suggests that none of the processes are to blame since there
aren't that many running...
top - 13:14:52 up 14 days, 20:45, 2 users, load average: 0.23, 0.18, 0.17
Tasks: 70 total, 1 running, 69 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.7% us, 0.6% sy, 0.0% ni, 97.9% id, 0.7% wa, 0.0% hi, 0.0% si
Mem: 508780k total, 496700k used, 12080k free, 2432k buffers
Swap: 0k total, 0k used, 0k free, 10700k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 16 0 1588 124 56 S 0.0 0.0 0:01.27 init
2 root 34 19 0 0 0 S 0.0 0.0 0:00.85 ksoftirqd/0
3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
4 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/0
5 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
6 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread
8 root 10 -5 0 0 0 S 0.0 0.0 0:01.78 kblockd/0
9 root 10 -5 0 0 0 S 0.0 0.0 62:14.03 kacpid
140 root 15 0 0 0 0 S 0.0 0.0 0:34.30 pdflush
141 root 15 0 0 0 0 S 0.0 0.0 0:20.82 pdflush
143 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0
142 root 15 0 0 0 0 S 0.0 0.0 0:36.16 kswapd0
733 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod
1131 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khubd
1438 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kpsmoused
1637 root 10 -5 0 0 0 S 0.0 0.0 0:10.21 ata/0
1713 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_0
1714 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_1
4033 root 10 -5 0 0 0 S 0.0 0.0 1:11.54 md0_raid1
4230 root 12 -4 2212 276 96 S 0.0 0.1 0:00.26 udevd
5945 root 15 0 0 0 0 S 0.0 0.0 0:00.00 kjournald
5949 root 10 -5 0 0 0 S 0.0 0.0 1:01.63 reiserfs/0
6280 daemon 15 0 1688 80 0 S 0.0 0.0 0:00.00 portmap
6480 root 16 0 2332 360 228 S 0.0 0.1 0:27.96 syslogd
6483 root 15 0 2340 892 40 S 0.0 0.2 0:00.08 klogd
6488 root 16 0 19784 528 288 S 0.0 0.1 2:13.92 apcupsd
6496 root 15 0 3332 1668 1064 S 0.0 0.3 0:24.06 openvpn
6557 root 21 0 2316 76 0 S 0.0 0.0 0:00.00 inetd
6658 www-data 21 0 1756 76 0 S 0.0 0.0 0:00.00 daemon-helper
6661 root 22 0 1756 76 0 S 0.0 0.0 0:00.00 daemon-helper
6767 root 16 0 3744 336 144 S 0.0 0.1 0:00.06 master
6769 postfix 17 0 3080 472 280 S 0.0 0.1 0:00.13 qmgr
6775 root 16 0 5620 900 432 S 0.0 0.2 0:01.68 nmbd
6777 root 15 0 8256 900 280 S 0.0 0.2 0:00.19 smbd
6786 root 18 0 8256 608 4 S 0.0 0.1 0:00.00 smbd
6788 root 16 0 3548 404 160 S 0.0 0.1 0:00.01 sshd
6810 root 18 0 2452 96 0 S 0.0 0.0 0:00.00 rpc.statd
6819 root 16 0 1900 452 128 S 0.0 0.1 0:00.82 mdadm
6850 root 10 -5 0 0 0 S 0.0 0.0 1:10.77 kcryptd/0
6873 root 16 0 1956 480 304 S 0.0 0.1 0:00.79 chronyd
6876 root 16 0 1820 264 124 S 0.0 0.1 0:01.13 cron
6884 root 16 0 1868 196 88 S 0.0 0.0 0:00.00 egor
6932 root 16 0 1584 68 0 S 0.0 0.0 0:00.00 getty
6933 root 16 0 1580 64 0 S 0.0 0.0 0:00.00 getty
6934 root 16 0 1584 68 0 S 0.0 0.0 0:00.00 getty
6935 root 16 0 1580 64 0 S 0.0 0.0 0:00.00 getty
6936 root 16 0 1580 64 0 S 0.0 0.0 0:00.00 getty
6937 root 16 0 1580 64 0 S 0.0 0.0 0:00.00 getty
22615 root 16 0 12096 1400 56 S 0.0 0.3 0:00.03 apache2
22621 www-data 21 0 12096 1356 0 S 0.0 0.3 0:00.00 apache2
22622 www-data 21 0 12096 1356 0 S 0.0 0.3 0:00.00 apache2
22623 www-data 21 0 12096 1356 0 S 0.0 0.3 0:00.00 apache2
22624 www-data 21 0 12096 1356 0 S 0.0 0.3 0:00.00 apache2
22625 www-data 21 0 12096 1356 0 S 0.0 0.3 0:00.00 apache2
23215 lp 19 0 2532 116 0 S 0.0 0.0 0:00.00 lpd
11442 root 16 0 8964 2912 1812 S 0.0 0.6 0:04.24 smbd
11784 root 16 0 8696 1500 736 S 0.0 0.3 0:00.66 smbd
11816 root 16 0 8852 1812 880 S 0.0 0.4 0:02.18 smbd
11831 root 16 0 8816 1864 928 S 0.0 0.4 0:00.95 smbd
11890 root 16 0 8852 2752 1748 S 0.0 0.5 0:02.16 smbd
12005 root 16 0 8696 1692 944 S 0.0 0.3 0:01.16 smbd
12049 root 16 0 8848 2728 1772 S 0.0 0.5 0:02.74 smbd
12066 root 16 0 9004 1944 940 S 0.0 0.4 0:03.46 smbd
14385 root 15 0 14688 1152 760 S 0.0 0.2 0:00.12 sshd
14388 root 15 0 3064 1348 920 S 0.0 0.3 0:00.04 bash
14698 root 25 0 1584 472 388 S 0.0 0.1 0:00.00 acpid
15650 postfix 16 0 3052 1132 960 S 0.0 0.2 0:00.00 pickup
15847 root 15 0 14688 1832 1440 S 0.0 0.4 0:00.01 sshd
15850 root 15 0 3084 1668 1224 S 0.0 0.3 0:00.01 bash
16070 root 15 0 2128 948 736 R 0.0 0.2 0:00.00 top
When I looked into the kernel slabinfo, however, I saw that acpi had
allocated over 10 million acpi_operand blocks of 40 bytes each! I suspect
that this is the culprit.
slabinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab>
<pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata
<active_slabs> <num_slabs> <sharedavail>
dm-snapshot-in 128 134 56 67 1 : tunables 120 60 0 :
slabdata 2 2 0
dm-snapshot-ex 0 0 24 145 1 : tunables 120 60 0 :
slabdata 0 0 0
dm-crypt_io 256 616 68 56 1 : tunables 120 60 0 :
slabdata 11 11 0
fib6_nodes 5 113 32 113 1 : tunables 120 60 0 :
slabdata 1 1 0
ip6_dst_cache 4 15 256 15 1 : tunables 120 60 0 :
slabdata 1 1 0
ndisc_cache 1 15 256 15 1 : tunables 120 60 0 :
slabdata 1 1 0
RAWv6 4 6 640 6 1 : tunables 54 27 0 :
slabdata 1 1 0
UDPv6 0 0 640 6 1 : tunables 54 27 0 :
slabdata 0 0 0
tw_sock_TCPv6 0 0 128 30 1 : tunables 120 60 0 :
slabdata 0 0 0
request_sock_TCPv6 0 0 128 30 1 : tunables 120 60 0
: slabdata 0 0 0
TCPv6 4 7 1152 7 2 : tunables 24 12 0 :
slabdata 1 1 0
ip_fib_alias 12 113 32 113 1 : tunables 120 60 0 :
slabdata 1 1 0
ip_fib_hash 12 113 32 113 1 : tunables 120 60 0 :
slabdata 1 1 0
dm_tio 1037 2030 16 203 1 : tunables 120 60 0 :
slabdata 10 10 0
dm_io 1037 2028 20 169 1 : tunables 120 60 0 :
slabdata 12 12 0
scsi_cmd_cache 10 10 384 10 1 : tunables 54 27 0 :
slabdata 1 1 0
sgpool-128 32 32 2048 2 1 : tunables 24 12 0 :
slabdata 16 16 0
sgpool-64 32 32 1024 4 1 : tunables 54 27 0 :
slabdata 8 8 0
sgpool-32 34 40 512 8 1 : tunables 54 27 0 :
slabdata 5 5 0
sgpool-16 33 45 256 15 1 : tunables 120 60 0 :
slabdata 3 3 0
sgpool-8 36 60 128 30 1 : tunables 120 60 0 :
slabdata 2 2 0
scsi_io_context 0 0 104 37 1 : tunables 120 60 0 :
slabdata 0 0 0
uhci_urb_priv 37 92 40 92 1 : tunables 120 60 0 :
slabdata 1 1 0
reiser_inode_cache 38 216 420 9 1 : tunables 54 27 0
: slabdata 24 24 0
ext3_inode_cache 3 8 492 8 1 : tunables 54 27 0 :
slabdata 1 1 0
ext3_xattr 0 0 48 78 1 : tunables 120 60 0 :
slabdata 0 0 0
journal_handle 0 0 20 169 1 : tunables 120 60 0 :
slabdata 0 0 0
journal_head 1 72 52 72 1 : tunables 120 60 0 :
slabdata 1 1 0
revoke_table 2 254 12 254 1 : tunables 120 60 0 :
slabdata 1 1 0
revoke_record 0 0 16 203 1 : tunables 120 60 0 :
slabdata 0 0 0
ext2_inode_cache 4997 5064 472 8 1 : tunables 54 27 0 :
slabdata 628 633 0
ext2_xattr 0 0 48 78 1 : tunables 120 60 0 :
slabdata 0 0 0
isofs_inode_cache 0 0 372 10 1 : tunables 54 27 0 :
slabdata 0 0 0
UNIX 87 100 384 10 1 : tunables 54 27 0 :
slabdata 10 10 0
ip_mrt_cache 0 0 128 30 1 : tunables 120 60 0 :
slabdata 0 0 0
tcp_bind_bucket 9 203 16 203 1 : tunables 120 60 0 :
slabdata 1 1 0
inet_peer_cache 0 0 64 59 1 : tunables 120 60 0 :
slabdata 0 0 0
secpath_cache 0 0 128 30 1 : tunables 120 60 0 :
slabdata 0 0 0
xfrm_dst_cache 0 0 384 10 1 : tunables 54 27 0 :
slabdata 0 0 0
ip_dst_cache 24 60 256 15 1 : tunables 120 60 0 :
slabdata 4 4 0
arp_cache 12 30 128 30 1 : tunables 120 60 0 :
slabdata 1 1 0
RAW 2 7 512 7 1 : tunables 54 27 0 :
slabdata 1 1 0
UDP 11 14 512 7 1 : tunables 54 27 0 :
slabdata 2 2 0
tw_sock_TCP 0 0 128 30 1 : tunables 120 60 0 :
slabdata 0 0 0
request_sock_TCP 0 0 64 59 1 : tunables 120 60 0 :
slabdata 0 0 0
TCP 15 16 1024 4 1 : tunables 54 27 0 :
slabdata 4 4 0
flow_cache 0 0 128 30 1 : tunables 120 60 0 :
slabdata 0 0 0
msi_cache 1 1 3840 1 1 : tunables 24 12 0 :
slabdata 1 1 0
cfq_ioc_pool 0 0 48 78 1 : tunables 120 60 0 :
slabdata 0 0 0
cfq_pool 0 0 96 40 1 : tunables 120 60 0 :
slabdata 0 0 0
crq_pool 0 0 48 78 1 : tunables 120 60 0 :
slabdata 0 0 0
deadline_drq 0 0 52 72 1 : tunables 120 60 0 :
slabdata 0 0 0
as_arq 40 118 64 59 1 : tunables 120 60 0 :
slabdata 2 2 0
configfs_dir_cache 0 0 48 78 1 : tunables 120 60 0
: slabdata 0 0 0
romfs_inode_cache 0 0 352 11 1 : tunables 54 27 0 :
slabdata 0 0 0
dnotify_cache 4 169 20 169 1 : tunables 120 60 0 :
slabdata 1 1 0
dquot 0 0 128 30 1 : tunables 120 60 0 :
slabdata 0 0 0
eventpoll_pwq 0 0 36 101 1 : tunables 120 60 0 :
slabdata 0 0 0
eventpoll_epi 0 0 128 30 1 : tunables 120 60 0 :
slabdata 0 0 0
inotify_event_cache 0 0 28 127 1 : tunables 120 60 0
: slabdata 0 0 0
inotify_watch_cache 1 101 36 101 1 : tunables 120 60 0
: slabdata 1 1 0
kioctx 0 0 256 15 1 : tunables 120 60 0 :
slabdata 0 0 0
kiocb 0 0 128 30 1 : tunables 120 60 0 :
slabdata 0 0 0
fasync_cache 6 203 16 203 1 : tunables 120 60 0 :
slabdata 1 1 0
shmem_inode_cache 767 1098 436 9 1 : tunables 54 27 0 :
slabdata 122 122 0
posix_timers_cache 0 0 96 40 1 : tunables 120 60 0
: slabdata 0 0 0
uid_cache 4 59 64 59 1 : tunables 120 60 0 :
slabdata 1 1 0
blkdev_ioc 44 127 28 127 1 : tunables 120 60 0 :
slabdata 1 1 0
blkdev_queue 32 32 928 4 1 : tunables 54 27 0 :
slabdata 8 8 0
blkdev_requests 25 110 176 22 1 : tunables 120 60 0 :
slabdata 5 5 0
biovec-(256) 260 260 3072 2 2 : tunables 24 12 0 :
slabdata 130 130 0
biovec-128 264 265 1536 5 2 : tunables 24 12 0 :
slabdata 53 53 0
biovec-64 290 290 768 5 1 : tunables 54 27 0 :
slabdata 58 58 0
biovec-16 275 285 256 15 1 : tunables 120 60 0 :
slabdata 19 19 0
biovec-4 306 354 64 59 1 : tunables 120 60 0 :
slabdata 6 6 0
biovec-1 285 1624 16 203 1 : tunables 120 60 0 :
slabdata 8 8 0
bio 285 1200 128 30 1 : tunables 120 60 0 :
slabdata 40 40 0
sock_inode_cache 136 140 384 10 1 : tunables 54 27 0 :
slabdata 14 14 0
skbuff_fclone_cache 10 10 384 10 1 : tunables 54 27 0
: slabdata 1 1 0
skbuff_head_cache 240 240 256 15 1 : tunables 120 60 0 :
slabdata 16 16 0
file_lock_cache 66 88 88 44 1 : tunables 120 60 0 :
slabdata 2 2 0
acpi_operand 10366560 10366560 40 92 1 : tunables 120 60
0 : slabdata 112680 112680 0
acpi_parse_ext 61 84 44 84 1 : tunables 120 60 0 :
slabdata 1 1 0
acpi_parse 63 127 28 127 1 : tunables 120 60 0 :
slabdata 1 1 0
acpi_state 63 78 48 78 1 : tunables 120 60 0 :
slabdata 1 1 0
proc_inode_cache 79 220 360 11 1 : tunables 54 27 0 :
slabdata 20 20 0
sigqueue 0 0 144 27 1 : tunables 120 60 0 :
slabdata 0 0 0
radix_tree_node 1401 1792 276 14 1 : tunables 54 27 0 :
slabdata 128 128 0
bdev_cache 27 27 448 9 1 : tunables 54 27 0 :
slabdata 3 3 0
sysfs_dir_cache 4800 4876 40 92 1 : tunables 120 60 0 :
slabdata 53 53 0
mnt_cache 23 30 128 30 1 : tunables 120 60 0 :
slabdata 1 1 0
inode_cache 1197 1353 344 11 1 : tunables 54 27 0 :
slabdata 123 123 0
dentry_cache 6059 7409 124 31 1 : tunables 120 60 0 :
slabdata 239 239 0
filp 792 960 192 20 1 : tunables 120 60 0 :
slabdata 48 48 0
names_cache 1 1 4096 1 1 : tunables 24 12 0 :
slabdata 1 1 0
idr_layer_cache 139 145 136 29 1 : tunables 120 60 0 :
slabdata 5 5 0
buffer_head 598 1368 52 72 1 : tunables 120 60 0 :
slabdata 19 19 0
mm_struct 54 54 448 9 1 : tunables 54 27 0 :
slabdata 6 6 0
vm_area_struct 2369 2464 88 44 1 : tunables 120 60 0 :
slabdata 55 56 0
fs_cache 49 113 32 113 1 : tunables 120 60 0 :
slabdata 1 1 0
files_cache 49 63 448 9 1 : tunables 54 27 0 :
slabdata 7 7 0
signal_cache 80 80 384 10 1 : tunables 54 27 0 :
slabdata 8 8 0
sighand_cache 72 72 1344 3 1 : tunables 24 12 0 :
slabdata 24 24 0
task_struct 71 84 1312 3 1 : tunables 24 12 0 :
slabdata 28 28 0
anon_vma 533 1017 8 339 1 : tunables 120 60 0 :
slabdata 3 3 0
pgd 50 50 4096 1 1 : tunables 24 12 0 :
slabdata 50 50 0
size-131072(DMA) 0 0 131072 1 32 : tunables 8 4 0 :
slabdata 0 0 0
size-131072 0 0 131072 1 32 : tunables 8 4 0 :
slabdata 0 0 0
size-65536(DMA) 0 0 65536 1 16 : tunables 8 4 0 :
slabdata 0 0 0
size-65536 0 0 65536 1 16 : tunables 8 4 0 :
slabdata 0 0 0
size-32768(DMA) 0 0 32768 1 8 : tunables 8 4 0 :
slabdata 0 0 0
size-32768 0 0 32768 1 8 : tunables 8 4 0 :
slabdata 0 0 0
size-16384(DMA) 0 0 16384 1 4 : tunables 8 4 0 :
slabdata 0 0 0
size-16384 0 0 16384 1 4 : tunables 8 4 0 :
slabdata 0 0 0
size-8192(DMA) 0 0 8192 1 2 : tunables 8 4 0 :
slabdata 0 0 0
size-8192 76 76 8192 1 2 : tunables 8 4 0 :
slabdata 76 76 0
size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 0 :
slabdata 0 0 0
size-4096 231 231 4096 1 1 : tunables 24 12 0 :
slabdata 231 231 0
size-2048(DMA) 0 0 2048 2 1 : tunables 24 12 0 :
slabdata 0 0 0
size-2048 271 280 2048 2 1 : tunables 24 12 0 :
slabdata 140 140 0
size-1024(DMA) 0 0 1024 4 1 : tunables 54 27 0 :
slabdata 0 0 0
size-1024 188 188 1024 4 1 : tunables 54 27 0 :
slabdata 47 47 0
size-512(DMA) 0 0 512 8 1 : tunables 54 27 0 :
slabdata 0 0 0
size-512 277 288 512 8 1 : tunables 54 27 0 :
slabdata 36 36 0
size-256(DMA) 0 0 256 15 1 : tunables 120 60 0 :
slabdata 0 0 0
size-256 795 795 256 15 1 : tunables 120 60 0 :
slabdata 53 53 0
size-128(DMA) 0 0 128 30 1 : tunables 120 60 0 :
slabdata 0 0 0
size-128 1097 1170 128 30 1 : tunables 120 60 0 :
slabdata 39 39 0
size-64(DMA) 0 0 64 59 1 : tunables 120 60 0 :
slabdata 0 0 0
size-32(DMA) 0 0 32 113 1 : tunables 120 60 0 :
slabdata 0 0 0
size-64 1775 3599 64 59 1 : tunables 120 60 0 :
slabdata 61 61 0
size-32 3494 5650 32 113 1 : tunables 120 60 0 :
slabdata 50 50 0
kmem_cache 150 150 128 30 1 : tunables 120 60 0 :
slabdata 5 5 0
Can anyone explain what is going on and how I can stop it?
I appreciate that I could run the box without ACPI, but that kind of defeats
its while purpose. Is it possible to tell if this is a BIOS issue, a kernel
issue or an ACPI module issue from the above information?
All assistance greatly appreciated.
Best regards,
Roger
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit?
2006-09-15 12:19 Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit? Roger Lucas
@ 2006-09-15 14:34 ` Roger Lucas
2006-09-15 14:40 ` Alexey Starikovskiy
0 siblings, 1 reply; 13+ messages in thread
From: Roger Lucas @ 2006-09-15 14:34 UTC (permalink / raw)
To: linux-acpi
Some more information...
It seems that there are bugs in the DSDT information. I followed the
instructions on this link to analyse the DSDT table.
http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
When I recompiled it, the following errors occurred. I have no idea what
these mean or if they are important, but I suspect that they are not good.
The BIOS ASL was originally compiled with the Microsoft compiler.
root@hydra:~# iasl -tc dsdt.dsl
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20051216 [Jan 9 2006]
Copyright (C) 2000 - 2005 Intel Corporation
Supports ACPI Specification Revision 3.0
dsdt.dsl 361: Method (\_WAK, 1, NotSerialized)
Warning 2078 - ^ Reserved method must return a value (_WAK)
dsdt.dsl 394: Store (Local0, Local0)
Error 1048 - ^ Method local variable is not
initialized (Local0)
dsdt.dsl 399: Store (Local0, Local0)
Error 1048 - ^ Method local variable is not
initialized (Local0)
dsdt.dsl 5349: If (Or (PLCY, PLCY, Local7))
Warning 2097 - ^ Statement is unreachable
ASL Input: dsdt.dsl - 5433 lines, 178284 bytes, 2002 keywords
Compilation complete. 2 Errors, 2 Warnings, 0 Remarks, 537 Optimizations
root@hydra:~#
All help to resolve this is greatly appreciated.
- Roger
> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Roger Lucas
> Sent: 15 September 2006 13:19
> To: linux-acpi@vger.kernel.org
> Subject: Kernel eats memory with LG-81 motherboard , acpi_operand possible
> culprit?
>
> Hi,
>
> I am running Linux kernel 2.6.16.20 with ACPI active on a Abit LG-81
> motherboard. Over time, the system slowly runs out of memory. Checking
> with "top" suggests that none of the processes are to blame since there
> aren't that many running...
>
> top - 13:14:52 up 14 days, 20:45, 2 users, load average: 0.23, 0.18,
> 0.17
> Tasks: 70 total, 1 running, 69 sleeping, 0 stopped, 0 zombie
> Cpu(s): 0.7% us, 0.6% sy, 0.0% ni, 97.9% id, 0.7% wa, 0.0% hi, 0.0%
> si
> Mem: 508780k total, 496700k used, 12080k free, 2432k buffers
> Swap: 0k total, 0k used, 0k free, 10700k cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 1 root 16 0 1588 124 56 S 0.0 0.0 0:01.27 init
> 2 root 34 19 0 0 0 S 0.0 0.0 0:00.85 ksoftirqd/0
> 3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
> 4 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/0
> 5 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
> 6 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread
> 8 root 10 -5 0 0 0 S 0.0 0.0 0:01.78 kblockd/0
> 9 root 10 -5 0 0 0 S 0.0 0.0 62:14.03 kacpid
> 140 root 15 0 0 0 0 S 0.0 0.0 0:34.30 pdflush
> 141 root 15 0 0 0 0 S 0.0 0.0 0:20.82 pdflush
> 143 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0
> 142 root 15 0 0 0 0 S 0.0 0.0 0:36.16 kswapd0
> 733 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod
> 1131 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khubd
> 1438 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kpsmoused
> 1637 root 10 -5 0 0 0 S 0.0 0.0 0:10.21 ata/0
> 1713 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_0
> 1714 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_1
> 4033 root 10 -5 0 0 0 S 0.0 0.0 1:11.54 md0_raid1
> 4230 root 12 -4 2212 276 96 S 0.0 0.1 0:00.26 udevd
> 5945 root 15 0 0 0 0 S 0.0 0.0 0:00.00 kjournald
> 5949 root 10 -5 0 0 0 S 0.0 0.0 1:01.63 reiserfs/0
> 6280 daemon 15 0 1688 80 0 S 0.0 0.0 0:00.00 portmap
> 6480 root 16 0 2332 360 228 S 0.0 0.1 0:27.96 syslogd
> 6483 root 15 0 2340 892 40 S 0.0 0.2 0:00.08 klogd
> 6488 root 16 0 19784 528 288 S 0.0 0.1 2:13.92 apcupsd
> 6496 root 15 0 3332 1668 1064 S 0.0 0.3 0:24.06 openvpn
> 6557 root 21 0 2316 76 0 S 0.0 0.0 0:00.00 inetd
> 6658 www-data 21 0 1756 76 0 S 0.0 0.0 0:00.00 daemon-helper
> 6661 root 22 0 1756 76 0 S 0.0 0.0 0:00.00 daemon-helper
> 6767 root 16 0 3744 336 144 S 0.0 0.1 0:00.06 master
> 6769 postfix 17 0 3080 472 280 S 0.0 0.1 0:00.13 qmgr
> 6775 root 16 0 5620 900 432 S 0.0 0.2 0:01.68 nmbd
> 6777 root 15 0 8256 900 280 S 0.0 0.2 0:00.19 smbd
> 6786 root 18 0 8256 608 4 S 0.0 0.1 0:00.00 smbd
> 6788 root 16 0 3548 404 160 S 0.0 0.1 0:00.01 sshd
> 6810 root 18 0 2452 96 0 S 0.0 0.0 0:00.00 rpc.statd
> 6819 root 16 0 1900 452 128 S 0.0 0.1 0:00.82 mdadm
> 6850 root 10 -5 0 0 0 S 0.0 0.0 1:10.77 kcryptd/0
> 6873 root 16 0 1956 480 304 S 0.0 0.1 0:00.79 chronyd
> 6876 root 16 0 1820 264 124 S 0.0 0.1 0:01.13 cron
> 6884 root 16 0 1868 196 88 S 0.0 0.0 0:00.00 egor
> 6932 root 16 0 1584 68 0 S 0.0 0.0 0:00.00 getty
> 6933 root 16 0 1580 64 0 S 0.0 0.0 0:00.00 getty
> 6934 root 16 0 1584 68 0 S 0.0 0.0 0:00.00 getty
> 6935 root 16 0 1580 64 0 S 0.0 0.0 0:00.00 getty
> 6936 root 16 0 1580 64 0 S 0.0 0.0 0:00.00 getty
> 6937 root 16 0 1580 64 0 S 0.0 0.0 0:00.00 getty
> 22615 root 16 0 12096 1400 56 S 0.0 0.3 0:00.03 apache2
> 22621 www-data 21 0 12096 1356 0 S 0.0 0.3 0:00.00 apache2
> 22622 www-data 21 0 12096 1356 0 S 0.0 0.3 0:00.00 apache2
> 22623 www-data 21 0 12096 1356 0 S 0.0 0.3 0:00.00 apache2
> 22624 www-data 21 0 12096 1356 0 S 0.0 0.3 0:00.00 apache2
> 22625 www-data 21 0 12096 1356 0 S 0.0 0.3 0:00.00 apache2
> 23215 lp 19 0 2532 116 0 S 0.0 0.0 0:00.00 lpd
> 11442 root 16 0 8964 2912 1812 S 0.0 0.6 0:04.24 smbd
> 11784 root 16 0 8696 1500 736 S 0.0 0.3 0:00.66 smbd
> 11816 root 16 0 8852 1812 880 S 0.0 0.4 0:02.18 smbd
> 11831 root 16 0 8816 1864 928 S 0.0 0.4 0:00.95 smbd
> 11890 root 16 0 8852 2752 1748 S 0.0 0.5 0:02.16 smbd
> 12005 root 16 0 8696 1692 944 S 0.0 0.3 0:01.16 smbd
> 12049 root 16 0 8848 2728 1772 S 0.0 0.5 0:02.74 smbd
> 12066 root 16 0 9004 1944 940 S 0.0 0.4 0:03.46 smbd
> 14385 root 15 0 14688 1152 760 S 0.0 0.2 0:00.12 sshd
> 14388 root 15 0 3064 1348 920 S 0.0 0.3 0:00.04 bash
> 14698 root 25 0 1584 472 388 S 0.0 0.1 0:00.00 acpid
> 15650 postfix 16 0 3052 1132 960 S 0.0 0.2 0:00.00 pickup
> 15847 root 15 0 14688 1832 1440 S 0.0 0.4 0:00.01 sshd
> 15850 root 15 0 3084 1668 1224 S 0.0 0.3 0:00.01 bash
> 16070 root 15 0 2128 948 736 R 0.0 0.2 0:00.00 top
>
>
> When I looked into the kernel slabinfo, however, I saw that acpi had
> allocated over 10 million acpi_operand blocks of 40 bytes each! I suspect
> that this is the culprit.
>
> slabinfo - version: 2.1
> # name <active_objs> <num_objs> <objsize> <objperslab>
> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata
> <active_slabs> <num_slabs> <sharedavail>
> dm-snapshot-in 128 134 56 67 1 : tunables 120 60 0
> :
> slabdata 2 2 0
> dm-snapshot-ex 0 0 24 145 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> dm-crypt_io 256 616 68 56 1 : tunables 120 60 0
> :
> slabdata 11 11 0
> fib6_nodes 5 113 32 113 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> ip6_dst_cache 4 15 256 15 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> ndisc_cache 1 15 256 15 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> RAWv6 4 6 640 6 1 : tunables 54 27 0
> :
> slabdata 1 1 0
> UDPv6 0 0 640 6 1 : tunables 54 27 0
> :
> slabdata 0 0 0
> tw_sock_TCPv6 0 0 128 30 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> request_sock_TCPv6 0 0 128 30 1 : tunables 120 60
> 0
> : slabdata 0 0 0
> TCPv6 4 7 1152 7 2 : tunables 24 12 0
> :
> slabdata 1 1 0
> ip_fib_alias 12 113 32 113 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> ip_fib_hash 12 113 32 113 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> dm_tio 1037 2030 16 203 1 : tunables 120 60 0
> :
> slabdata 10 10 0
> dm_io 1037 2028 20 169 1 : tunables 120 60 0
> :
> slabdata 12 12 0
> scsi_cmd_cache 10 10 384 10 1 : tunables 54 27 0
> :
> slabdata 1 1 0
> sgpool-128 32 32 2048 2 1 : tunables 24 12 0
> :
> slabdata 16 16 0
> sgpool-64 32 32 1024 4 1 : tunables 54 27 0
> :
> slabdata 8 8 0
> sgpool-32 34 40 512 8 1 : tunables 54 27 0
> :
> slabdata 5 5 0
> sgpool-16 33 45 256 15 1 : tunables 120 60 0
> :
> slabdata 3 3 0
> sgpool-8 36 60 128 30 1 : tunables 120 60 0
> :
> slabdata 2 2 0
> scsi_io_context 0 0 104 37 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> uhci_urb_priv 37 92 40 92 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> reiser_inode_cache 38 216 420 9 1 : tunables 54 27
> 0
> : slabdata 24 24 0
> ext3_inode_cache 3 8 492 8 1 : tunables 54 27 0
> :
> slabdata 1 1 0
> ext3_xattr 0 0 48 78 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> journal_handle 0 0 20 169 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> journal_head 1 72 52 72 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> revoke_table 2 254 12 254 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> revoke_record 0 0 16 203 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> ext2_inode_cache 4997 5064 472 8 1 : tunables 54 27 0
> :
> slabdata 628 633 0
> ext2_xattr 0 0 48 78 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> isofs_inode_cache 0 0 372 10 1 : tunables 54 27 0
> :
> slabdata 0 0 0
> UNIX 87 100 384 10 1 : tunables 54 27 0
> :
> slabdata 10 10 0
> ip_mrt_cache 0 0 128 30 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> tcp_bind_bucket 9 203 16 203 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> inet_peer_cache 0 0 64 59 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> secpath_cache 0 0 128 30 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> xfrm_dst_cache 0 0 384 10 1 : tunables 54 27 0
> :
> slabdata 0 0 0
> ip_dst_cache 24 60 256 15 1 : tunables 120 60 0
> :
> slabdata 4 4 0
> arp_cache 12 30 128 30 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> RAW 2 7 512 7 1 : tunables 54 27 0
> :
> slabdata 1 1 0
> UDP 11 14 512 7 1 : tunables 54 27 0
> :
> slabdata 2 2 0
> tw_sock_TCP 0 0 128 30 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> request_sock_TCP 0 0 64 59 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> TCP 15 16 1024 4 1 : tunables 54 27 0
> :
> slabdata 4 4 0
> flow_cache 0 0 128 30 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> msi_cache 1 1 3840 1 1 : tunables 24 12 0
> :
> slabdata 1 1 0
> cfq_ioc_pool 0 0 48 78 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> cfq_pool 0 0 96 40 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> crq_pool 0 0 48 78 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> deadline_drq 0 0 52 72 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> as_arq 40 118 64 59 1 : tunables 120 60 0
> :
> slabdata 2 2 0
> configfs_dir_cache 0 0 48 78 1 : tunables 120 60
> 0
> : slabdata 0 0 0
> romfs_inode_cache 0 0 352 11 1 : tunables 54 27 0
> :
> slabdata 0 0 0
> dnotify_cache 4 169 20 169 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> dquot 0 0 128 30 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> eventpoll_pwq 0 0 36 101 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> eventpoll_epi 0 0 128 30 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> inotify_event_cache 0 0 28 127 1 : tunables 120 60
> 0
> : slabdata 0 0 0
> inotify_watch_cache 1 101 36 101 1 : tunables 120 60
> 0
> : slabdata 1 1 0
> kioctx 0 0 256 15 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> kiocb 0 0 128 30 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> fasync_cache 6 203 16 203 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> shmem_inode_cache 767 1098 436 9 1 : tunables 54 27 0
> :
> slabdata 122 122 0
> posix_timers_cache 0 0 96 40 1 : tunables 120 60
> 0
> : slabdata 0 0 0
> uid_cache 4 59 64 59 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> blkdev_ioc 44 127 28 127 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> blkdev_queue 32 32 928 4 1 : tunables 54 27 0
> :
> slabdata 8 8 0
> blkdev_requests 25 110 176 22 1 : tunables 120 60 0
> :
> slabdata 5 5 0
> biovec-(256) 260 260 3072 2 2 : tunables 24 12 0
> :
> slabdata 130 130 0
> biovec-128 264 265 1536 5 2 : tunables 24 12 0
> :
> slabdata 53 53 0
> biovec-64 290 290 768 5 1 : tunables 54 27 0
> :
> slabdata 58 58 0
> biovec-16 275 285 256 15 1 : tunables 120 60 0
> :
> slabdata 19 19 0
> biovec-4 306 354 64 59 1 : tunables 120 60 0
> :
> slabdata 6 6 0
> biovec-1 285 1624 16 203 1 : tunables 120 60 0
> :
> slabdata 8 8 0
> bio 285 1200 128 30 1 : tunables 120 60 0
> :
> slabdata 40 40 0
> sock_inode_cache 136 140 384 10 1 : tunables 54 27 0
> :
> slabdata 14 14 0
> skbuff_fclone_cache 10 10 384 10 1 : tunables 54 27
> 0
> : slabdata 1 1 0
> skbuff_head_cache 240 240 256 15 1 : tunables 120 60 0
> :
> slabdata 16 16 0
> file_lock_cache 66 88 88 44 1 : tunables 120 60 0
> :
> slabdata 2 2 0
> acpi_operand 10366560 10366560 40 92 1 : tunables 120 60
> 0 : slabdata 112680 112680 0
> acpi_parse_ext 61 84 44 84 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> acpi_parse 63 127 28 127 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> acpi_state 63 78 48 78 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> proc_inode_cache 79 220 360 11 1 : tunables 54 27 0
> :
> slabdata 20 20 0
> sigqueue 0 0 144 27 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> radix_tree_node 1401 1792 276 14 1 : tunables 54 27 0
> :
> slabdata 128 128 0
> bdev_cache 27 27 448 9 1 : tunables 54 27 0
> :
> slabdata 3 3 0
> sysfs_dir_cache 4800 4876 40 92 1 : tunables 120 60 0
> :
> slabdata 53 53 0
> mnt_cache 23 30 128 30 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> inode_cache 1197 1353 344 11 1 : tunables 54 27 0
> :
> slabdata 123 123 0
> dentry_cache 6059 7409 124 31 1 : tunables 120 60 0
> :
> slabdata 239 239 0
> filp 792 960 192 20 1 : tunables 120 60 0
> :
> slabdata 48 48 0
> names_cache 1 1 4096 1 1 : tunables 24 12 0
> :
> slabdata 1 1 0
> idr_layer_cache 139 145 136 29 1 : tunables 120 60 0
> :
> slabdata 5 5 0
> buffer_head 598 1368 52 72 1 : tunables 120 60 0
> :
> slabdata 19 19 0
> mm_struct 54 54 448 9 1 : tunables 54 27 0
> :
> slabdata 6 6 0
> vm_area_struct 2369 2464 88 44 1 : tunables 120 60 0
> :
> slabdata 55 56 0
> fs_cache 49 113 32 113 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> files_cache 49 63 448 9 1 : tunables 54 27 0
> :
> slabdata 7 7 0
> signal_cache 80 80 384 10 1 : tunables 54 27 0
> :
> slabdata 8 8 0
> sighand_cache 72 72 1344 3 1 : tunables 24 12 0
> :
> slabdata 24 24 0
> task_struct 71 84 1312 3 1 : tunables 24 12 0
> :
> slabdata 28 28 0
> anon_vma 533 1017 8 339 1 : tunables 120 60 0
> :
> slabdata 3 3 0
> pgd 50 50 4096 1 1 : tunables 24 12 0
> :
> slabdata 50 50 0
> size-131072(DMA) 0 0 131072 1 32 : tunables 8 4 0
> :
> slabdata 0 0 0
> size-131072 0 0 131072 1 32 : tunables 8 4 0
> :
> slabdata 0 0 0
> size-65536(DMA) 0 0 65536 1 16 : tunables 8 4 0
> :
> slabdata 0 0 0
> size-65536 0 0 65536 1 16 : tunables 8 4 0
> :
> slabdata 0 0 0
> size-32768(DMA) 0 0 32768 1 8 : tunables 8 4 0
> :
> slabdata 0 0 0
> size-32768 0 0 32768 1 8 : tunables 8 4 0
> :
> slabdata 0 0 0
> size-16384(DMA) 0 0 16384 1 4 : tunables 8 4 0
> :
> slabdata 0 0 0
> size-16384 0 0 16384 1 4 : tunables 8 4 0
> :
> slabdata 0 0 0
> size-8192(DMA) 0 0 8192 1 2 : tunables 8 4 0
> :
> slabdata 0 0 0
> size-8192 76 76 8192 1 2 : tunables 8 4 0
> :
> slabdata 76 76 0
> size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 0
> :
> slabdata 0 0 0
> size-4096 231 231 4096 1 1 : tunables 24 12 0
> :
> slabdata 231 231 0
> size-2048(DMA) 0 0 2048 2 1 : tunables 24 12 0
> :
> slabdata 0 0 0
> size-2048 271 280 2048 2 1 : tunables 24 12 0
> :
> slabdata 140 140 0
> size-1024(DMA) 0 0 1024 4 1 : tunables 54 27 0
> :
> slabdata 0 0 0
> size-1024 188 188 1024 4 1 : tunables 54 27 0
> :
> slabdata 47 47 0
> size-512(DMA) 0 0 512 8 1 : tunables 54 27 0
> :
> slabdata 0 0 0
> size-512 277 288 512 8 1 : tunables 54 27 0
> :
> slabdata 36 36 0
> size-256(DMA) 0 0 256 15 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> size-256 795 795 256 15 1 : tunables 120 60 0
> :
> slabdata 53 53 0
> size-128(DMA) 0 0 128 30 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> size-128 1097 1170 128 30 1 : tunables 120 60 0
> :
> slabdata 39 39 0
> size-64(DMA) 0 0 64 59 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> size-32(DMA) 0 0 32 113 1 : tunables 120 60 0
> :
> slabdata 0 0 0
> size-64 1775 3599 64 59 1 : tunables 120 60 0
> :
> slabdata 61 61 0
> size-32 3494 5650 32 113 1 : tunables 120 60 0
> :
> slabdata 50 50 0
> kmem_cache 150 150 128 30 1 : tunables 120 60 0
> :
> slabdata 5 5 0
>
> Can anyone explain what is going on and how I can stop it?
>
> I appreciate that I could run the box without ACPI, but that kind of
> defeats
> its while purpose. Is it possible to tell if this is a BIOS issue, a
> kernel
> issue or an ACPI module issue from the above information?
>
> All assistance greatly appreciated.
>
> Best regards,
>
> Roger
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit?
2006-09-15 14:34 ` Roger Lucas
@ 2006-09-15 14:40 ` Alexey Starikovskiy
2006-09-16 13:25 ` Roger Lucas
0 siblings, 1 reply; 13+ messages in thread
From: Alexey Starikovskiy @ 2006-09-15 14:40 UTC (permalink / raw)
To: Roger Lucas; +Cc: linux-acpi
Roger,
Please try to change Store(Local0, Local0) to Store(Zero, Local0) and check if you still have a leak...
Thanks,
Alex.
Roger Lucas wrote:
> Some more information...
>
> It seems that there are bugs in the DSDT information. I followed the
> instructions on this link to analyse the DSDT table.
>
> http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
>
> When I recompiled it, the following errors occurred. I have no idea what
> these mean or if they are important, but I suspect that they are not good.
> The BIOS ASL was originally compiled with the Microsoft compiler.
>
> root@hydra:~# iasl -tc dsdt.dsl
>
> Intel ACPI Component Architecture
> ASL Optimizing Compiler version 20051216 [Jan 9 2006]
> Copyright (C) 2000 - 2005 Intel Corporation
> Supports ACPI Specification Revision 3.0
>
> dsdt.dsl 361: Method (\_WAK, 1, NotSerialized)
> Warning 2078 - ^ Reserved method must return a value (_WAK)
>
> dsdt.dsl 394: Store (Local0, Local0)
> Error 1048 - ^ Method local variable is not
> initialized (Local0)
>
> dsdt.dsl 399: Store (Local0, Local0)
> Error 1048 - ^ Method local variable is not
> initialized (Local0)
>
> dsdt.dsl 5349: If (Or (PLCY, PLCY, Local7))
> Warning 2097 - ^ Statement is unreachable
>
> ASL Input: dsdt.dsl - 5433 lines, 178284 bytes, 2002 keywords
> Compilation complete. 2 Errors, 2 Warnings, 0 Remarks, 537 Optimizations
> root@hydra:~#
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit?
@ 2006-09-15 15:18 Suietov, Fiodor F
2006-09-15 15:52 ` Alexey Starikovskiy
0 siblings, 1 reply; 13+ messages in thread
From: Suietov, Fiodor F @ 2006-09-15 15:18 UTC (permalink / raw)
To: Roger Lucas; +Cc: linux-acpi
Perhaps, it is related to #6514:
http://bugzilla.kernel.org/show_bug.cgi?id=6514
Thanks,
Fiodor
> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Alexey Starikovskiy
> Sent: Friday, September 15, 2006 6:41 PM
> To: Roger Lucas
> Cc: linux-acpi@vger.kernel.org
> Subject: Re: Kernel eats memory with LG-81 motherboard , acpi_operand
> possible culprit?
>
> Roger,
>
> Please try to change Store(Local0, Local0) to Store(Zero, Local0) and
> check if you still have a leak...
>
> Thanks,
> Alex.
>
> Roger Lucas wrote:
> > Some more information...
> >
> > It seems that there are bugs in the DSDT information. I followed
the
> > instructions on this link to analyse the DSDT table.
> >
> > http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
> >
> > When I recompiled it, the following errors occurred. I have no idea
> what
> > these mean or if they are important, but I suspect that they are not
> good.
> > The BIOS ASL was originally compiled with the Microsoft compiler.
> >
> > root@hydra:~# iasl -tc dsdt.dsl
> >
> > Intel ACPI Component Architecture
> > ASL Optimizing Compiler version 20051216 [Jan 9 2006]
> > Copyright (C) 2000 - 2005 Intel Corporation
> > Supports ACPI Specification Revision 3.0
> >
> > dsdt.dsl 361: Method (\_WAK, 1, NotSerialized)
> > Warning 2078 - ^ Reserved method must return a
value
> (_WAK)
> >
> > dsdt.dsl 394: Store (Local0, Local0)
> > Error 1048 - ^ Method local variable is
not
> > initialized (Local0)
> >
> > dsdt.dsl 399: Store (Local0, Local0)
> > Error 1048 - ^ Method local variable is
not
> > initialized (Local0)
> >
> > dsdt.dsl 5349: If (Or (PLCY, PLCY, Local7))
> > Warning 2097 - ^ Statement is unreachable
> >
> > ASL Input: dsdt.dsl - 5433 lines, 178284 bytes, 2002 keywords
> > Compilation complete. 2 Errors, 2 Warnings, 0 Remarks, 537
Optimizations
> > root@hydra:~#
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit?
2006-09-15 15:18 Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit? Suietov, Fiodor F
@ 2006-09-15 15:52 ` Alexey Starikovskiy
2006-09-15 16:41 ` Roger Lucas
0 siblings, 1 reply; 13+ messages in thread
From: Alexey Starikovskiy @ 2006-09-15 15:52 UTC (permalink / raw)
To: Suietov, Fiodor F; +Cc: Roger Lucas, linux-acpi
Roger,
Please try to upgrade to 2.6.17.x, as it probably contains a fix to your memory leak.
Regards,
Alex.
Suietov, Fiodor F wrote:
> Perhaps, it is related to #6514:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6514
>
> Thanks,
> Fiodor
>
>> -----Original Message-----
>> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
>> owner@vger.kernel.org] On Behalf Of Alexey Starikovskiy
>> Sent: Friday, September 15, 2006 6:41 PM
>> To: Roger Lucas
>> Cc: linux-acpi@vger.kernel.org
>> Subject: Re: Kernel eats memory with LG-81 motherboard , acpi_operand
>> possible culprit?
>>
>> Roger,
>>
>> Please try to change Store(Local0, Local0) to Store(Zero, Local0) and
>> check if you still have a leak...
>>
>> Thanks,
>> Alex.
>>
>> Roger Lucas wrote:
>>> Some more information...
>>>
>>> It seems that there are bugs in the DSDT information. I followed
> the
>>> instructions on this link to analyse the DSDT table.
>>>
>>> http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
>>>
>>> When I recompiled it, the following errors occurred. I have no idea
>> what
>>> these mean or if they are important, but I suspect that they are not
>> good.
>>> The BIOS ASL was originally compiled with the Microsoft compiler.
>>>
>>> root@hydra:~# iasl -tc dsdt.dsl
>>>
>>> Intel ACPI Component Architecture
>>> ASL Optimizing Compiler version 20051216 [Jan 9 2006]
>>> Copyright (C) 2000 - 2005 Intel Corporation
>>> Supports ACPI Specification Revision 3.0
>>>
>>> dsdt.dsl 361: Method (\_WAK, 1, NotSerialized)
>>> Warning 2078 - ^ Reserved method must return a
> value
>> (_WAK)
>>> dsdt.dsl 394: Store (Local0, Local0)
>>> Error 1048 - ^ Method local variable is
> not
>>> initialized (Local0)
>>>
>>> dsdt.dsl 399: Store (Local0, Local0)
>>> Error 1048 - ^ Method local variable is
> not
>>> initialized (Local0)
>>>
>>> dsdt.dsl 5349: If (Or (PLCY, PLCY, Local7))
>>> Warning 2097 - ^ Statement is unreachable
>>>
>>> ASL Input: dsdt.dsl - 5433 lines, 178284 bytes, 2002 keywords
>>> Compilation complete. 2 Errors, 2 Warnings, 0 Remarks, 537
> Optimizations
>>> root@hydra:~#
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit?
2006-09-15 15:52 ` Alexey Starikovskiy
@ 2006-09-15 16:41 ` Roger Lucas
2006-09-15 18:41 ` Alexey Starikovskiy
0 siblings, 1 reply; 13+ messages in thread
From: Roger Lucas @ 2006-09-15 16:41 UTC (permalink / raw)
To: 'Alexey Starikovskiy'; +Cc: linux-acpi, 'Suietov, Fiodor F'
Hi Alexey,
Thanks for the quick responses - it looks like I either need to
path+recompile the 2.6.16.20 kernel to allow a replacement DSDT file or use
the 2.6.17.13 kernel.
Can you clarify exactly what memory leak you think is the problem? I don't
mind trying the 2.6.17.x kernel, but I would like to know exactly what the
problem being resolved is.
Thanks,
Roger
> -----Original Message-----
> From: Alexey Starikovskiy [mailto:alexey_y_starikovskiy@linux.intel.com]
> Sent: 15 September 2006 16:52
> To: Suietov, Fiodor F
> Cc: Roger Lucas; linux-acpi@vger.kernel.org
> Subject: Re: Kernel eats memory with LG-81 motherboard , acpi_operand
> possible culprit?
>
> Roger,
> Please try to upgrade to 2.6.17.x, as it probably contains a fix to your
> memory leak.
>
> Regards,
> Alex.
>
> Suietov, Fiodor F wrote:
> > Perhaps, it is related to #6514:
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=6514
> >
> > Thanks,
> > Fiodor
> >
> >> -----Original Message-----
> >> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> >> owner@vger.kernel.org] On Behalf Of Alexey Starikovskiy
> >> Sent: Friday, September 15, 2006 6:41 PM
> >> To: Roger Lucas
> >> Cc: linux-acpi@vger.kernel.org
> >> Subject: Re: Kernel eats memory with LG-81 motherboard , acpi_operand
> >> possible culprit?
> >>
> >> Roger,
> >>
> >> Please try to change Store(Local0, Local0) to Store(Zero, Local0) and
> >> check if you still have a leak...
> >>
> >> Thanks,
> >> Alex.
> >>
> >> Roger Lucas wrote:
> >>> Some more information...
> >>>
> >>> It seems that there are bugs in the DSDT information. I followed
> > the
> >>> instructions on this link to analyse the DSDT table.
> >>>
> >>> http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
> >>>
> >>> When I recompiled it, the following errors occurred. I have no idea
> >> what
> >>> these mean or if they are important, but I suspect that they are not
> >> good.
> >>> The BIOS ASL was originally compiled with the Microsoft compiler.
> >>>
> >>> root@hydra:~# iasl -tc dsdt.dsl
> >>>
> >>> Intel ACPI Component Architecture
> >>> ASL Optimizing Compiler version 20051216 [Jan 9 2006]
> >>> Copyright (C) 2000 - 2005 Intel Corporation
> >>> Supports ACPI Specification Revision 3.0
> >>>
> >>> dsdt.dsl 361: Method (\_WAK, 1, NotSerialized)
> >>> Warning 2078 - ^ Reserved method must return a
> > value
> >> (_WAK)
> >>> dsdt.dsl 394: Store (Local0, Local0)
> >>> Error 1048 - ^ Method local variable is
> > not
> >>> initialized (Local0)
> >>>
> >>> dsdt.dsl 399: Store (Local0, Local0)
> >>> Error 1048 - ^ Method local variable is
> > not
> >>> initialized (Local0)
> >>>
> >>> dsdt.dsl 5349: If (Or (PLCY, PLCY, Local7))
> >>> Warning 2097 - ^ Statement is unreachable
> >>>
> >>> ASL Input: dsdt.dsl - 5433 lines, 178284 bytes, 2002 keywords
> >>> Compilation complete. 2 Errors, 2 Warnings, 0 Remarks, 537
> > Optimizations
> >>> root@hydra:~#
> >> -
> >> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> > in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit?
2006-09-15 16:41 ` Roger Lucas
@ 2006-09-15 18:41 ` Alexey Starikovskiy
2006-09-15 19:57 ` Roger Lucas
0 siblings, 1 reply; 13+ messages in thread
From: Alexey Starikovskiy @ 2006-09-15 18:41 UTC (permalink / raw)
To: Roger Lucas; +Cc: linux-acpi, 'Suietov, Fiodor F'
It is a leak mentioned by Fiodor -- bug #6514.
Roger Lucas wrote:
> Hi Alexey,
>
> Thanks for the quick responses - it looks like I either need to
> path+recompile the 2.6.16.20 kernel to allow a replacement DSDT file or use
> the 2.6.17.13 kernel.
>
> Can you clarify exactly what memory leak you think is the problem? I don't
> mind trying the 2.6.17.x kernel, but I would like to know exactly what the
> problem being resolved is.
>
> Thanks,
>
> Roger
>
>> -----Original Message-----
>> From: Alexey Starikovskiy [mailto:alexey_y_starikovskiy@linux.intel.com]
>> Sent: 15 September 2006 16:52
>> To: Suietov, Fiodor F
>> Cc: Roger Lucas; linux-acpi@vger.kernel.org
>> Subject: Re: Kernel eats memory with LG-81 motherboard , acpi_operand
>> possible culprit?
>>
>> Roger,
>> Please try to upgrade to 2.6.17.x, as it probably contains a fix to your
>> memory leak.
>>
>> Regards,
>> Alex.
>>
>> Suietov, Fiodor F wrote:
>>> Perhaps, it is related to #6514:
>>>
>>> http://bugzilla.kernel.org/show_bug.cgi?id=6514
>>>
>>> Thanks,
>>> Fiodor
>>>
>>>> -----Original Message-----
>>>> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
>>>> owner@vger.kernel.org] On Behalf Of Alexey Starikovskiy
>>>> Sent: Friday, September 15, 2006 6:41 PM
>>>> To: Roger Lucas
>>>> Cc: linux-acpi@vger.kernel.org
>>>> Subject: Re: Kernel eats memory with LG-81 motherboard , acpi_operand
>>>> possible culprit?
>>>>
>>>> Roger,
>>>>
>>>> Please try to change Store(Local0, Local0) to Store(Zero, Local0) and
>>>> check if you still have a leak...
>>>>
>>>> Thanks,
>>>> Alex.
>>>>
>>>> Roger Lucas wrote:
>>>>> Some more information...
>>>>>
>>>>> It seems that there are bugs in the DSDT information. I followed
>>> the
>>>>> instructions on this link to analyse the DSDT table.
>>>>>
>>>>> http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
>>>>>
>>>>> When I recompiled it, the following errors occurred. I have no idea
>>>> what
>>>>> these mean or if they are important, but I suspect that they are not
>>>> good.
>>>>> The BIOS ASL was originally compiled with the Microsoft compiler.
>>>>>
>>>>> root@hydra:~# iasl -tc dsdt.dsl
>>>>>
>>>>> Intel ACPI Component Architecture
>>>>> ASL Optimizing Compiler version 20051216 [Jan 9 2006]
>>>>> Copyright (C) 2000 - 2005 Intel Corporation
>>>>> Supports ACPI Specification Revision 3.0
>>>>>
>>>>> dsdt.dsl 361: Method (\_WAK, 1, NotSerialized)
>>>>> Warning 2078 - ^ Reserved method must return a
>>> value
>>>> (_WAK)
>>>>> dsdt.dsl 394: Store (Local0, Local0)
>>>>> Error 1048 - ^ Method local variable is
>>> not
>>>>> initialized (Local0)
>>>>>
>>>>> dsdt.dsl 399: Store (Local0, Local0)
>>>>> Error 1048 - ^ Method local variable is
>>> not
>>>>> initialized (Local0)
>>>>>
>>>>> dsdt.dsl 5349: If (Or (PLCY, PLCY, Local7))
>>>>> Warning 2097 - ^ Statement is unreachable
>>>>>
>>>>> ASL Input: dsdt.dsl - 5433 lines, 178284 bytes, 2002 keywords
>>>>> Compilation complete. 2 Errors, 2 Warnings, 0 Remarks, 537
>>> Optimizations
>>>>> root@hydra:~#
>>>> -
>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
>>> in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> -
>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit?
2006-09-15 18:41 ` Alexey Starikovskiy
@ 2006-09-15 19:57 ` Roger Lucas
2006-09-15 21:08 ` Alexey Starikovskiy
0 siblings, 1 reply; 13+ messages in thread
From: Roger Lucas @ 2006-09-15 19:57 UTC (permalink / raw)
To: 'Alexey Starikovskiy'; +Cc: linux-acpi, 'Suietov, Fiodor F'
Hi Alexey,
I've installed the latest 2.6.17.13 kernel (compiled from kernel.org source
that I downloaded earlier today) and the "acpi_operand" field in
"/proc/slabinfo" is still steadily rising. After just 5 mins uptime, the
acpi_operand field has ~4200 objects of 40 bytes each. After 8 mins, this
had rised on 4876 objects.
I am now going to try to patch the DSDT file into the kernel and see if that
cures it.
Regards,
Roger
> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Alexey Starikovskiy
> Sent: 15 September 2006 19:42
> To: Roger Lucas
> Cc: linux-acpi@vger.kernel.org; 'Suietov, Fiodor F'
> Subject: Re: Kernel eats memory with LG-81 motherboard , acpi_operand
> possible culprit?
>
> It is a leak mentioned by Fiodor -- bug #6514.
> Roger Lucas wrote:
> > Hi Alexey,
> >
> > Thanks for the quick responses - it looks like I either need to
> > path+recompile the 2.6.16.20 kernel to allow a replacement DSDT file or
> use
> > the 2.6.17.13 kernel.
> >
> > Can you clarify exactly what memory leak you think is the problem? I
> don't
> > mind trying the 2.6.17.x kernel, but I would like to know exactly what
> the
> > problem being resolved is.
> >
> > Thanks,
> >
> > Roger
> >
> >> -----Original Message-----
> >> From: Alexey Starikovskiy
> [mailto:alexey_y_starikovskiy@linux.intel.com]
> >> Sent: 15 September 2006 16:52
> >> To: Suietov, Fiodor F
> >> Cc: Roger Lucas; linux-acpi@vger.kernel.org
> >> Subject: Re: Kernel eats memory with LG-81 motherboard , acpi_operand
> >> possible culprit?
> >>
> >> Roger,
> >> Please try to upgrade to 2.6.17.x, as it probably contains a fix to
> your
> >> memory leak.
> >>
> >> Regards,
> >> Alex.
> >>
> >> Suietov, Fiodor F wrote:
> >>> Perhaps, it is related to #6514:
> >>>
> >>> http://bugzilla.kernel.org/show_bug.cgi?id=6514
> >>>
> >>> Thanks,
> >>> Fiodor
> >>>
> >>>> -----Original Message-----
> >>>> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> >>>> owner@vger.kernel.org] On Behalf Of Alexey Starikovskiy
> >>>> Sent: Friday, September 15, 2006 6:41 PM
> >>>> To: Roger Lucas
> >>>> Cc: linux-acpi@vger.kernel.org
> >>>> Subject: Re: Kernel eats memory with LG-81 motherboard , acpi_operand
> >>>> possible culprit?
> >>>>
> >>>> Roger,
> >>>>
> >>>> Please try to change Store(Local0, Local0) to Store(Zero, Local0) and
> >>>> check if you still have a leak...
> >>>>
> >>>> Thanks,
> >>>> Alex.
> >>>>
> >>>> Roger Lucas wrote:
> >>>>> Some more information...
> >>>>>
> >>>>> It seems that there are bugs in the DSDT information. I followed
> >>> the
> >>>>> instructions on this link to analyse the DSDT table.
> >>>>>
> >>>>> http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
> >>>>>
> >>>>> When I recompiled it, the following errors occurred. I have no idea
> >>>> what
> >>>>> these mean or if they are important, but I suspect that they are not
> >>>> good.
> >>>>> The BIOS ASL was originally compiled with the Microsoft compiler.
> >>>>>
> >>>>> root@hydra:~# iasl -tc dsdt.dsl
> >>>>>
> >>>>> Intel ACPI Component Architecture
> >>>>> ASL Optimizing Compiler version 20051216 [Jan 9 2006]
> >>>>> Copyright (C) 2000 - 2005 Intel Corporation
> >>>>> Supports ACPI Specification Revision 3.0
> >>>>>
> >>>>> dsdt.dsl 361: Method (\_WAK, 1, NotSerialized)
> >>>>> Warning 2078 - ^ Reserved method must return a
> >>> value
> >>>> (_WAK)
> >>>>> dsdt.dsl 394: Store (Local0, Local0)
> >>>>> Error 1048 - ^ Method local variable is
> >>> not
> >>>>> initialized (Local0)
> >>>>>
> >>>>> dsdt.dsl 399: Store (Local0, Local0)
> >>>>> Error 1048 - ^ Method local variable is
> >>> not
> >>>>> initialized (Local0)
> >>>>>
> >>>>> dsdt.dsl 5349: If (Or (PLCY, PLCY, Local7))
> >>>>> Warning 2097 - ^ Statement is unreachable
> >>>>>
> >>>>> ASL Input: dsdt.dsl - 5433 lines, 178284 bytes, 2002 keywords
> >>>>> Compilation complete. 2 Errors, 2 Warnings, 0 Remarks, 537
> >>> Optimizations
> >>>>> root@hydra:~#
> >>>> -
> >>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> >>> in
> >>>> the body of a message to majordomo@vger.kernel.org
> >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>> -
> >>> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> in
> >>> the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit?
2006-09-15 19:57 ` Roger Lucas
@ 2006-09-15 21:08 ` Alexey Starikovskiy
2006-09-16 12:19 ` Roger Lucas
0 siblings, 1 reply; 13+ messages in thread
From: Alexey Starikovskiy @ 2006-09-15 21:08 UTC (permalink / raw)
To: Roger Lucas; +Cc: linux-acpi, 'Suietov, Fiodor F'
Please open bug against AML interpreter (same category as 6514) and put
your original DSDT and dmesg there.
Thanks,
Alex.
Roger Lucas wrote:
> Hi Alexey,
>
> I've installed the latest 2.6.17.13 kernel (compiled from kernel.org source
> that I downloaded earlier today) and the "acpi_operand" field in
> "/proc/slabinfo" is still steadily rising. After just 5 mins uptime, the
> acpi_operand field has ~4200 objects of 40 bytes each. After 8 mins, this
> had rised on 4876 objects.
>
> I am now going to try to patch the DSDT file into the kernel and see if that
> cures it.
>
> Regards,
>
> Roger
>
>> -----Original Message-----
>> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
>> owner@vger.kernel.org] On Behalf Of Alexey Starikovskiy
>> Sent: 15 September 2006 19:42
>> To: Roger Lucas
>> Cc: linux-acpi@vger.kernel.org; 'Suietov, Fiodor F'
>> Subject: Re: Kernel eats memory with LG-81 motherboard , acpi_operand
>> possible culprit?
>>
>> It is a leak mentioned by Fiodor -- bug #6514.
>> Roger Lucas wrote:
>>> Hi Alexey,
>>>
>>> Thanks for the quick responses - it looks like I either need to
>>> path+recompile the 2.6.16.20 kernel to allow a replacement DSDT file or
>> use
>>> the 2.6.17.13 kernel.
>>>
>>> Can you clarify exactly what memory leak you think is the problem? I
>> don't
>>> mind trying the 2.6.17.x kernel, but I would like to know exactly what
>> the
>>> problem being resolved is.
>>>
>>> Thanks,
>>>
>>> Roger
>>>
>>>> -----Original Message-----
>>>> From: Alexey Starikovskiy
>> [mailto:alexey_y_starikovskiy@linux.intel.com]
>>>> Sent: 15 September 2006 16:52
>>>> To: Suietov, Fiodor F
>>>> Cc: Roger Lucas; linux-acpi@vger.kernel.org
>>>> Subject: Re: Kernel eats memory with LG-81 motherboard , acpi_operand
>>>> possible culprit?
>>>>
>>>> Roger,
>>>> Please try to upgrade to 2.6.17.x, as it probably contains a fix to
>> your
>>>> memory leak.
>>>>
>>>> Regards,
>>>> Alex.
>>>>
>>>> Suietov, Fiodor F wrote:
>>>>> Perhaps, it is related to #6514:
>>>>>
>>>>> http://bugzilla.kernel.org/show_bug.cgi?id=6514
>>>>>
>>>>> Thanks,
>>>>> Fiodor
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
>>>>>> owner@vger.kernel.org] On Behalf Of Alexey Starikovskiy
>>>>>> Sent: Friday, September 15, 2006 6:41 PM
>>>>>> To: Roger Lucas
>>>>>> Cc: linux-acpi@vger.kernel.org
>>>>>> Subject: Re: Kernel eats memory with LG-81 motherboard , acpi_operand
>>>>>> possible culprit?
>>>>>>
>>>>>> Roger,
>>>>>>
>>>>>> Please try to change Store(Local0, Local0) to Store(Zero, Local0) and
>>>>>> check if you still have a leak...
>>>>>>
>>>>>> Thanks,
>>>>>> Alex.
>>>>>>
>>>>>> Roger Lucas wrote:
>>>>>>> Some more information...
>>>>>>>
>>>>>>> It seems that there are bugs in the DSDT information. I followed
>>>>> the
>>>>>>> instructions on this link to analyse the DSDT table.
>>>>>>>
>>>>>>> http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
>>>>>>>
>>>>>>> When I recompiled it, the following errors occurred. I have no idea
>>>>>> what
>>>>>>> these mean or if they are important, but I suspect that they are not
>>>>>> good.
>>>>>>> The BIOS ASL was originally compiled with the Microsoft compiler.
>>>>>>>
>>>>>>> root@hydra:~# iasl -tc dsdt.dsl
>>>>>>>
>>>>>>> Intel ACPI Component Architecture
>>>>>>> ASL Optimizing Compiler version 20051216 [Jan 9 2006]
>>>>>>> Copyright (C) 2000 - 2005 Intel Corporation
>>>>>>> Supports ACPI Specification Revision 3.0
>>>>>>>
>>>>>>> dsdt.dsl 361: Method (\_WAK, 1, NotSerialized)
>>>>>>> Warning 2078 - ^ Reserved method must return a
>>>>> value
>>>>>> (_WAK)
>>>>>>> dsdt.dsl 394: Store (Local0, Local0)
>>>>>>> Error 1048 - ^ Method local variable is
>>>>> not
>>>>>>> initialized (Local0)
>>>>>>>
>>>>>>> dsdt.dsl 399: Store (Local0, Local0)
>>>>>>> Error 1048 - ^ Method local variable is
>>>>> not
>>>>>>> initialized (Local0)
>>>>>>>
>>>>>>> dsdt.dsl 5349: If (Or (PLCY, PLCY, Local7))
>>>>>>> Warning 2097 - ^ Statement is unreachable
>>>>>>>
>>>>>>> ASL Input: dsdt.dsl - 5433 lines, 178284 bytes, 2002 keywords
>>>>>>> Compilation complete. 2 Errors, 2 Warnings, 0 Remarks, 537
>>>>> Optimizations
>>>>>>> root@hydra:~#
>>>>>> -
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
>>>>> in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>> -
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
>> in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>> -
>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit?
2006-09-15 21:08 ` Alexey Starikovskiy
@ 2006-09-16 12:19 ` Roger Lucas
0 siblings, 0 replies; 13+ messages in thread
From: Roger Lucas @ 2006-09-16 12:19 UTC (permalink / raw)
To: 'Alexey Starikovskiy'; +Cc: linux-acpi, 'Suietov, Fiodor F'
Hi Alexey,
Thank you for your help. I have raised the bug #7163 with the DSDT capture
from the /proc subsystem. I will keep digging to see if I can find a
workaround. So far, all I can do is disable ACPI to stop the memory leak.
:-(
Best regards,
Roger
> -----Original Message-----
> From: Alexey Starikovskiy [mailto:alexey_y_starikovskiy@linux.intel.com]
> Sent: 15 September 2006 22:08
> To: Roger Lucas
> Cc: linux-acpi@vger.kernel.org; 'Suietov, Fiodor F'
> Subject: Re: Kernel eats memory with LG-81 motherboard , acpi_operand
> possible culprit?
>
> Please open bug against AML interpreter (same category as 6514) and put
> your original DSDT and dmesg there.
>
> Thanks,
> Alex.
>
> Roger Lucas wrote:
> > Hi Alexey,
> >
> > I've installed the latest 2.6.17.13 kernel (compiled from kernel.org
> source
> > that I downloaded earlier today) and the "acpi_operand" field in
> > "/proc/slabinfo" is still steadily rising. After just 5 mins uptime,
> the
> > acpi_operand field has ~4200 objects of 40 bytes each. After 8 mins,
> this
> > had rised on 4876 objects.
> >
> > I am now going to try to patch the DSDT file into the kernel and see if
> that
> > cures it.
> >
> > Regards,
> >
> > Roger
> >
> >> -----Original Message-----
> >> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> >> owner@vger.kernel.org] On Behalf Of Alexey Starikovskiy
> >> Sent: 15 September 2006 19:42
> >> To: Roger Lucas
> >> Cc: linux-acpi@vger.kernel.org; 'Suietov, Fiodor F'
> >> Subject: Re: Kernel eats memory with LG-81 motherboard , acpi_operand
> >> possible culprit?
> >>
> >> It is a leak mentioned by Fiodor -- bug #6514.
> >> Roger Lucas wrote:
> >>> Hi Alexey,
> >>>
> >>> Thanks for the quick responses - it looks like I either need to
> >>> path+recompile the 2.6.16.20 kernel to allow a replacement DSDT file
> or
> >> use
> >>> the 2.6.17.13 kernel.
> >>>
> >>> Can you clarify exactly what memory leak you think is the problem? I
> >> don't
> >>> mind trying the 2.6.17.x kernel, but I would like to know exactly what
> >> the
> >>> problem being resolved is.
> >>>
> >>> Thanks,
> >>>
> >>> Roger
> >>>
> >>>> -----Original Message-----
> >>>> From: Alexey Starikovskiy
> >> [mailto:alexey_y_starikovskiy@linux.intel.com]
> >>>> Sent: 15 September 2006 16:52
> >>>> To: Suietov, Fiodor F
> >>>> Cc: Roger Lucas; linux-acpi@vger.kernel.org
> >>>> Subject: Re: Kernel eats memory with LG-81 motherboard , acpi_operand
> >>>> possible culprit?
> >>>>
> >>>> Roger,
> >>>> Please try to upgrade to 2.6.17.x, as it probably contains a fix to
> >> your
> >>>> memory leak.
> >>>>
> >>>> Regards,
> >>>> Alex.
> >>>>
> >>>> Suietov, Fiodor F wrote:
> >>>>> Perhaps, it is related to #6514:
> >>>>>
> >>>>> http://bugzilla.kernel.org/show_bug.cgi?id=6514
> >>>>>
> >>>>> Thanks,
> >>>>> Fiodor
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> >>>>>> owner@vger.kernel.org] On Behalf Of Alexey Starikovskiy
> >>>>>> Sent: Friday, September 15, 2006 6:41 PM
> >>>>>> To: Roger Lucas
> >>>>>> Cc: linux-acpi@vger.kernel.org
> >>>>>> Subject: Re: Kernel eats memory with LG-81 motherboard ,
> acpi_operand
> >>>>>> possible culprit?
> >>>>>>
> >>>>>> Roger,
> >>>>>>
> >>>>>> Please try to change Store(Local0, Local0) to Store(Zero, Local0)
> and
> >>>>>> check if you still have a leak...
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Alex.
> >>>>>>
> >>>>>> Roger Lucas wrote:
> >>>>>>> Some more information...
> >>>>>>>
> >>>>>>> It seems that there are bugs in the DSDT information. I followed
> >>>>> the
> >>>>>>> instructions on this link to analyse the DSDT table.
> >>>>>>>
> >>>>>>> http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
> >>>>>>>
> >>>>>>> When I recompiled it, the following errors occurred. I have no
> idea
> >>>>>> what
> >>>>>>> these mean or if they are important, but I suspect that they are
> not
> >>>>>> good.
> >>>>>>> The BIOS ASL was originally compiled with the Microsoft compiler.
> >>>>>>>
> >>>>>>> root@hydra:~# iasl -tc dsdt.dsl
> >>>>>>>
> >>>>>>> Intel ACPI Component Architecture
> >>>>>>> ASL Optimizing Compiler version 20051216 [Jan 9 2006]
> >>>>>>> Copyright (C) 2000 - 2005 Intel Corporation
> >>>>>>> Supports ACPI Specification Revision 3.0
> >>>>>>>
> >>>>>>> dsdt.dsl 361: Method (\_WAK, 1, NotSerialized)
> >>>>>>> Warning 2078 - ^ Reserved method must return a
> >>>>> value
> >>>>>> (_WAK)
> >>>>>>> dsdt.dsl 394: Store (Local0, Local0)
> >>>>>>> Error 1048 - ^ Method local variable is
> >>>>> not
> >>>>>>> initialized (Local0)
> >>>>>>>
> >>>>>>> dsdt.dsl 399: Store (Local0, Local0)
> >>>>>>> Error 1048 - ^ Method local variable is
> >>>>> not
> >>>>>>> initialized (Local0)
> >>>>>>>
> >>>>>>> dsdt.dsl 5349: If (Or (PLCY, PLCY, Local7))
> >>>>>>> Warning 2097 - ^ Statement is unreachable
> >>>>>>>
> >>>>>>> ASL Input: dsdt.dsl - 5433 lines, 178284 bytes, 2002 keywords
> >>>>>>> Compilation complete. 2 Errors, 2 Warnings, 0 Remarks, 537
> >>>>> Optimizations
> >>>>>>> root@hydra:~#
> >>>>>> -
> >>>>>> To unsubscribe from this list: send the line "unsubscribe linux-
> acpi"
> >>>>> in
> >>>>>> the body of a message to majordomo@vger.kernel.org
> >>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>>> -
> >>>>> To unsubscribe from this list: send the line "unsubscribe linux-
> acpi"
> >> in
> >>>>> the body of a message to majordomo@vger.kernel.org
> >>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>>>
> >>> -
> >>> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> in
> >>> the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>
> >> -
> >> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit?
2006-09-15 14:40 ` Alexey Starikovskiy
@ 2006-09-16 13:25 ` Roger Lucas
2006-09-16 16:44 ` Roger Lucas
0 siblings, 1 reply; 13+ messages in thread
From: Roger Lucas @ 2006-09-16 13:25 UTC (permalink / raw)
To: 'Alexey Starikovskiy'; +Cc: linux-acpi
Hi Alexey,
I have made the changes that you recommend and am also using the latest
2.6.17.13 kernel. The output from IASL is now:
# iasl -tc ../dsdt.dsl
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20051216 [Jan 9 2006]
Copyright (C) 2000 - 2005 Intel Corporation
Supports ACPI Specification Revision 3.0
../dsdt.dsl 5350: If (Or (PLCY, PLCY, Local7))
Warning 2097 - ^ Statement is unreachable
ASL Input: ../dsdt.dsl - 5434 lines, 178315 bytes, 2003 keywords
AML Output: DSDT.aml - 17187 bytes 642 named objects 1361 executable opcodes
Compilation complete. 0 Errors, 1 Warnings, 0 Remarks, 534 Optimizations
#
I patched the kernel to allow a DSDT table to come from the initrd image as
per:
http://gaugusch.at/kernel.shtml
This worked fine and I now see the corrected DSDT table being loaded.
# dmesg
Linux version 2.6.17.13.rwl2 (root@deb1) (gcc version 3.3.5 (Debian
1:3.3.5-13)) #1 Fri Sep 15 21:18:15 BST 2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001f7f0000 (usable)
BIOS-e820: 000000001f7f0000 - 000000001f7f3000 (ACPI NVS)
BIOS-e820: 000000001f7f3000 - 000000001f800000 (ACPI data)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
0MB HIGHMEM available.
503MB LOWMEM available.
found SMP MP-table at 000f5400
On node 0 totalpages: 129008
DMA zone: 4096 pages, LIFO batch:0
Normal zone: 124912 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP (v000 IntelR ) @ 0x000f9540
ACPI: RSDT (v001 IntelR AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1f7f3040
ACPI: FADT (v001 IntelR AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1f7f30c0
ACPI: BOOT (v001 IntelR AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1f7f79c0
ACPI: MCFG (v001 IntelR AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1f7f7b40
ACPI: MADT (v001 IntelR AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1f7f7a40
ACPI: DSDT (v001 INTELR AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x00000000
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 4, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode: Flat. Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
<snip>
Freeing initrd memory: 4600k freed
ACPI: Looking for DSDT in initramfs... successfully read 17187 bytes from
/DSDT.aml.
ACPI (tbget-0290): Table [DSDT] replaced by host OS [20060127]
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
NET: Registered protocol family 16
EISA bus registered
ACPI: bus type pci registered
PCI: Using MMCONFIG
Setting up standard PCI resources
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
Boot video device is 0000:00:02.0
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 *10 11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs *3 4 5 7 10 11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 10 *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 7 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 *5 7 10 11)
Linux Plug and Play Support v0.97 (c) Adam Belay
<snip>
Unfortunately, the "acpi_operand" field is still leaking.
# cat /proc/slabinfo | grep acpi
acpi_operand 11652 11684 40 92 1 : tunables 120 60 0 :
slabdata 127 127 0
acpi_parse_ext 3 84 44 84 1 : tunables 120 60 0 :
slabdata 1 1 0
acpi_parse 16 127 28 127 1 : tunables 120 60 0 :
slabdata 1 1 0
acpi_state 26 78 48 78 1 : tunables 120 60 0 :
slabdata 1 1 0
#
I'm a bit stuck as to what the problem is now. I have brought everything
upt to the latest stable kernel and make the ACPI DSDT changes to allow it
to compile without errors.
Any ideas?
Thanks,
Roger
> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Alexey Starikovskiy
> Sent: 15 September 2006 15:41
> To: Roger Lucas
> Cc: linux-acpi@vger.kernel.org
> Subject: Re: Kernel eats memory with LG-81 motherboard , acpi_operand
> possible culprit?
>
> Roger,
>
> Please try to change Store(Local0, Local0) to Store(Zero, Local0) and
> check if you still have a leak...
>
> Thanks,
> Alex.
>
> Roger Lucas wrote:
> > Some more information...
> >
> > It seems that there are bugs in the DSDT information. I followed the
> > instructions on this link to analyse the DSDT table.
> >
> > http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
> >
> > When I recompiled it, the following errors occurred. I have no idea
> what
> > these mean or if they are important, but I suspect that they are not
> good.
> > The BIOS ASL was originally compiled with the Microsoft compiler.
> >
> > root@hydra:~# iasl -tc dsdt.dsl
> >
> > Intel ACPI Component Architecture
> > ASL Optimizing Compiler version 20051216 [Jan 9 2006]
> > Copyright (C) 2000 - 2005 Intel Corporation
> > Supports ACPI Specification Revision 3.0
> >
> > dsdt.dsl 361: Method (\_WAK, 1, NotSerialized)
> > Warning 2078 - ^ Reserved method must return a value
> (_WAK)
> >
> > dsdt.dsl 394: Store (Local0, Local0)
> > Error 1048 - ^ Method local variable is not
> > initialized (Local0)
> >
> > dsdt.dsl 399: Store (Local0, Local0)
> > Error 1048 - ^ Method local variable is not
> > initialized (Local0)
> >
> > dsdt.dsl 5349: If (Or (PLCY, PLCY, Local7))
> > Warning 2097 - ^ Statement is unreachable
> >
> > ASL Input: dsdt.dsl - 5433 lines, 178284 bytes, 2002 keywords
> > Compilation complete. 2 Errors, 2 Warnings, 0 Remarks, 537 Optimizations
> > root@hydra:~#
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit?
2006-09-16 13:25 ` Roger Lucas
@ 2006-09-16 16:44 ` Roger Lucas
2006-09-18 11:11 ` Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit? RESOLVED Roger Lucas
0 siblings, 1 reply; 13+ messages in thread
From: Roger Lucas @ 2006-09-16 16:44 UTC (permalink / raw)
To: 'Alexey Starikovskiy'; +Cc: linux-acpi
Hi Alexey,
I'm still trying to get to the bottom of this. I am really not familiar
with ACPI, but I am slowly finding out a bit more about the problem. I
restored the latest BIOS v15 for the motherboard and removed the new
DSDT.aml file from initrd so that I have an "as original" configuration.
On my generic 2.6.17.13 kernel, I have the following ACPI modules:
ac
battery
button
fan
processor
thermal
video
I can install all of them apart from "thermal" without a problem. As soon
as I install the "thermal" module, the memory leak starts. If I remove the
"thermal" module, the memory leak stops.
I've repeated the same test on the 2.6.16.20 kernel (again, generic from
Kernel.org) and it has the same sensitivity. The leak is only present if
the "thermal" module is loaded.
On the 2.6.16.20 kernel, the following is present in the "/proc" filesystem
for the processor and thermal.
mouse:~# cat /proc/acpi/processor/CPU0/info
processor id: 0
acpi id: 0
bus mastering control: no
power management: no
throttling control: no
limit interface: no
mouse:~# cat /proc/acpi/processor/CPU0/limit
<not supported>
mouse:~# cat /proc/acpi/processor/CPU0/power
active state: C1
max_cstate: C8
bus master activity: 00000000
states:
*C1: type[C1] promotion[--] demotion[--] latency[000]
usage[00000000]
mouse:~# cat /proc/acpi/processor/CPU0/throttling
<not supported>
mouse:~# cat /proc/acpi/thermal_zone/THRM/
cooling_mode polling_frequency state temperature
trip_points
mouse:~# cat /proc/acpi/thermal_zone/THRM/cooling_mode
cooling mode: active
mouse:~# cat /proc/acpi/thermal_zone/THRM/polling_frequency
<polling disabled>
mouse:~# cat /proc/acpi/thermal_zone/THRM/state
state: ok
mouse:~# cat /proc/acpi/thermal_zone/THRM/temperature
temperature: 32 C
mouse:~# cat /proc/acpi/thermal_zone/THRM/trip_points
critical (S5): 90 C
passive: 90 C: tc1=4 tc2=3 tsp=60 devices=0xdf7eefc0
active[0]: 85 C: devices=0xc1461640
mouse:~#
I don't know exactly what it is in the "thermal" module that is triggering
the leak, but hopefully this will help narrow down the search. According to
the above information, it shouldn't even be polling and is a long way from
any of the trip points.
Best regards,
Roger
> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Roger Lucas
> Sent: 16 September 2006 14:26
> To: 'Alexey Starikovskiy'
> Cc: linux-acpi@vger.kernel.org
> Subject: RE: Kernel eats memory with LG-81 motherboard , acpi_operand
> possible culprit?
>
> Hi Alexey,
>
> I have made the changes that you recommend and am also using the latest
> 2.6.17.13 kernel. The output from IASL is now:
>
> # iasl -tc ../dsdt.dsl
>
> Intel ACPI Component Architecture
> ASL Optimizing Compiler version 20051216 [Jan 9 2006]
> Copyright (C) 2000 - 2005 Intel Corporation
> Supports ACPI Specification Revision 3.0
>
> ../dsdt.dsl 5350: If (Or (PLCY, PLCY, Local7))
> Warning 2097 - ^ Statement is unreachable
>
> ASL Input: ../dsdt.dsl - 5434 lines, 178315 bytes, 2003 keywords
> AML Output: DSDT.aml - 17187 bytes 642 named objects 1361 executable
> opcodes
>
> Compilation complete. 0 Errors, 1 Warnings, 0 Remarks, 534 Optimizations
> #
>
> I patched the kernel to allow a DSDT table to come from the initrd image
> as
> per:
> http://gaugusch.at/kernel.shtml
>
> This worked fine and I now see the corrected DSDT table being loaded.
>
> # dmesg
> Linux version 2.6.17.13.rwl2 (root@deb1) (gcc version 3.3.5 (Debian
> 1:3.3.5-13)) #1 Fri Sep 15 21:18:15 BST 2006
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
> BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000001f7f0000 (usable)
> BIOS-e820: 000000001f7f0000 - 000000001f7f3000 (ACPI NVS)
> BIOS-e820: 000000001f7f3000 - 000000001f800000 (ACPI data)
> BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
> BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
> 0MB HIGHMEM available.
> 503MB LOWMEM available.
> found SMP MP-table at 000f5400
> On node 0 totalpages: 129008
> DMA zone: 4096 pages, LIFO batch:0
> Normal zone: 124912 pages, LIFO batch:31
> DMI 2.3 present.
> ACPI: RSDP (v000 IntelR ) @ 0x000f9540
> ACPI: RSDT (v001 IntelR AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1f7f3040
> ACPI: FADT (v001 IntelR AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1f7f30c0
> ACPI: BOOT (v001 IntelR AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1f7f79c0
> ACPI: MCFG (v001 IntelR AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1f7f7b40
> ACPI: MADT (v001 IntelR AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1f7f7a40
> ACPI: DSDT (v001 INTELR AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x00000000
> ACPI: PM-Timer IO Port: 0x408
> ACPI: Local APIC address 0xfee00000
> ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
> Processor #0 15:4 APIC version 20
> ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
> ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
> ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
> ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
> ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
> ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
> ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
> ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
> IOAPIC[0]: apic_id 4, version 32, address 0xfec00000, GSI 0-23
> ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> ACPI: IRQ0 used by override.
> ACPI: IRQ2 used by override.
> ACPI: IRQ9 used by override.
> Enabling APIC mode: Flat. Using 1 I/O APICs
> Using ACPI (MADT) for SMP configuration information
>
> <snip>
>
> Freeing initrd memory: 4600k freed
> ACPI: Looking for DSDT in initramfs... successfully read 17187 bytes from
> /DSDT.aml.
> ACPI (tbget-0290): Table [DSDT] replaced by host OS [20060127]
> ENABLING IO-APIC IRQs
> ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
> NET: Registered protocol family 16
> EISA bus registered
> ACPI: bus type pci registered
> PCI: Using MMCONFIG
> Setting up standard PCI resources
> ACPI: Subsystem revision 20060127
> ACPI: Interpreter enabled
> ACPI: Using IOAPIC for interrupt routing
> ACPI: PCI Root Bridge [PCI0] (0000:00)
> PCI: Probing PCI hardware (bus 00)
> Boot video device is 0000:00:02.0
> PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
> PCI: Transparent bridge - 0000:00:1e.0
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
> ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 *10 11)
> ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 10 11) *0, disabled.
> ACPI: PCI Interrupt Link [LNKC] (IRQs *3 4 5 7 10 11)
> ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 10 *11)
> ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 10 11) *0, disabled.
> ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 10 11) *0, disabled.
> ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 7 10 11) *0, disabled.
> ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 *5 7 10 11)
> Linux Plug and Play Support v0.97 (c) Adam Belay
>
> <snip>
>
> Unfortunately, the "acpi_operand" field is still leaking.
>
> # cat /proc/slabinfo | grep acpi
> acpi_operand 11652 11684 40 92 1 : tunables 120 60 0
> :
> slabdata 127 127 0
> acpi_parse_ext 3 84 44 84 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> acpi_parse 16 127 28 127 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> acpi_state 26 78 48 78 1 : tunables 120 60 0
> :
> slabdata 1 1 0
> #
>
> I'm a bit stuck as to what the problem is now. I have brought everything
> upt to the latest stable kernel and make the ACPI DSDT changes to allow it
> to compile without errors.
>
> Any ideas?
>
> Thanks,
>
> Roger
>
>
> > -----Original Message-----
> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> > owner@vger.kernel.org] On Behalf Of Alexey Starikovskiy
> > Sent: 15 September 2006 15:41
> > To: Roger Lucas
> > Cc: linux-acpi@vger.kernel.org
> > Subject: Re: Kernel eats memory with LG-81 motherboard , acpi_operand
> > possible culprit?
> >
> > Roger,
> >
> > Please try to change Store(Local0, Local0) to Store(Zero, Local0) and
> > check if you still have a leak...
> >
> > Thanks,
> > Alex.
> >
> > Roger Lucas wrote:
> > > Some more information...
> > >
> > > It seems that there are bugs in the DSDT information. I followed the
> > > instructions on this link to analyse the DSDT table.
> > >
> > > http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
> > >
> > > When I recompiled it, the following errors occurred. I have no idea
> > what
> > > these mean or if they are important, but I suspect that they are not
> > good.
> > > The BIOS ASL was originally compiled with the Microsoft compiler.
> > >
> > > root@hydra:~# iasl -tc dsdt.dsl
> > >
> > > Intel ACPI Component Architecture
> > > ASL Optimizing Compiler version 20051216 [Jan 9 2006]
> > > Copyright (C) 2000 - 2005 Intel Corporation
> > > Supports ACPI Specification Revision 3.0
> > >
> > > dsdt.dsl 361: Method (\_WAK, 1, NotSerialized)
> > > Warning 2078 - ^ Reserved method must return a value
> > (_WAK)
> > >
> > > dsdt.dsl 394: Store (Local0, Local0)
> > > Error 1048 - ^ Method local variable is not
> > > initialized (Local0)
> > >
> > > dsdt.dsl 399: Store (Local0, Local0)
> > > Error 1048 - ^ Method local variable is not
> > > initialized (Local0)
> > >
> > > dsdt.dsl 5349: If (Or (PLCY, PLCY, Local7))
> > > Warning 2097 - ^ Statement is unreachable
> > >
> > > ASL Input: dsdt.dsl - 5433 lines, 178284 bytes, 2002 keywords
> > > Compilation complete. 2 Errors, 2 Warnings, 0 Remarks, 537
> Optimizations
> > > root@hydra:~#
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit? RESOLVED
2006-09-16 16:44 ` Roger Lucas
@ 2006-09-18 11:11 ` Roger Lucas
0 siblings, 0 replies; 13+ messages in thread
From: Roger Lucas @ 2006-09-18 11:11 UTC (permalink / raw)
To: linux-acpi
RESOLVED - http://bugzilla.kernel.org/show_bug.cgi?id=7163
There was a code construct in the DSDT BIOS code that exposed a memory leak
in the ACPI kernel module. The leak is patched in 2.6.18.rc1 onwards and it
was possible to rewrite the DSDT code such that the memory leak condition
was avoided on the unpatched 2.6.16 and 2.6.17 kernels.
"Thank You" to Fiodor and Alexey for helping resolve this so quickly.
- Roger
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2006-09-18 11:11 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-15 12:19 Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit? Roger Lucas
2006-09-15 14:34 ` Roger Lucas
2006-09-15 14:40 ` Alexey Starikovskiy
2006-09-16 13:25 ` Roger Lucas
2006-09-16 16:44 ` Roger Lucas
2006-09-18 11:11 ` Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit? RESOLVED Roger Lucas
-- strict thread matches above, loose matches on Subject: below --
2006-09-15 15:18 Kernel eats memory with LG-81 motherboard , acpi_operand possible culprit? Suietov, Fiodor F
2006-09-15 15:52 ` Alexey Starikovskiy
2006-09-15 16:41 ` Roger Lucas
2006-09-15 18:41 ` Alexey Starikovskiy
2006-09-15 19:57 ` Roger Lucas
2006-09-15 21:08 ` Alexey Starikovskiy
2006-09-16 12:19 ` Roger Lucas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox