Bug 4707 - memory leak somewhere in toshiba_acpi
Summary: memory leak somewhere in toshiba_acpi
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Platform (show other bugs)
Hardware: i386 Linux
: P2 high
Assignee: John Belmonte
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-04 04:56 UTC by Michal Cihar
Modified: 2010-10-08 18:16 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.11.10
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
acpidmp output (111.96 KB, text/plain)
2005-06-07 23:26 UTC, Michal Cihar
Details
acpidmp output (111.96 KB, text/plain)
2005-07-22 13:58 UTC, Michal Cihar
Details

Description Michal Cihar 2005-06-04 04:56:30 UTC
Distribution: Debian
Hardware Environment: Toshiba Stalellite Pro M30
Software Environment:
Problem Description:

While reading entries from /proc/acpi/toshiba, kernel still allocates memory and
doesn't free it until kernel kills everything because of no free memory.

Steps to reproduce:

This script shows allocations:

grep size-64\  /proc/slabinfo
sleep 10
grep size-64\  /proc/slabinfo
for x in `seq 1 100` ; do
    cat /proc/acpi/toshiba/fan > /dev/null
done
grep size-64\  /proc/slabinfo
sleep 10
grep size-64\  /proc/slabinfo

Output looks like:

size-64           201360 201361     64   61    1 : tunables  120   60    0 :
slabdata   3301   3301      0
size-64           201360 201361     64   61    1 : tunables  120   60    0 :
slabdata   3301   3301      0
size-64           201604 201605     64   61    1 : tunables  120   60    0 :
slabdata   3305   3305      0
size-64           201604 201605     64   61    1 : tunables  120   60    0 :
slabdata   3305   3305      0

It has been happening also in several older kernel versions.
Comment 1 Shaohua 2005-06-05 19:19:32 UTC
Does reading other entry under acpi/toshiba have the same memory leak behavior?
Could you please post your acpidmp output? A quick look at the toshiba driver 
shows there isn't memory leak there, so maybe it's ACPICA's issue.
Comment 2 Michal Cihar 2005-06-06 01:09:54 UTC
Other entries in /proc/acpi/toshiba has this behaviour, I wasn't able to
reproduce it using another files in /proc/acpi.

I will post acpidmp output later, I don't have that computer right here.
Comment 3 Michal Cihar 2005-06-07 23:26:00 UTC
Created attachment 5136 [details]
acpidmp output

Here it comes.
Comment 4 Adrian Bunk 2005-07-22 10:43:57 UTC
Is this problem still present in kernel 2.6.13-rc3?
Comment 5 Michal Cihar 2005-07-22 13:46:21 UTC
Yes, still present.
Comment 6 Michal Cihar 2005-07-22 13:58:19 UTC
Created attachment 5363 [details]
acpidmp output

I also updated BIOS meanwhile, so it's probably that ACPI tables changed. Here
is current version.
Comment 7 Michal Cihar 2005-11-15 05:47:19 UTC
This problem seems to be gone in 2.6.14.

Note You need to log in before you can comment on or make changes to this bug.