Bug 127752 - Thinkpad X24 laptop HD grinds until unresponsive
Summary: Thinkpad X24 laptop HD grinds until unresponsive
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 2
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-07-13 13:31 UTC by Alex Deucher
Modified: 2015-01-04 22:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-05-04 13:27:44 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Alex Deucher 2004-07-13 13:31:48 UTC
Description of problem:

Everything seems to work great on the laptop, but after an hour or
two, the harddrive starts to grind and grind and grind and eventually
the machine become completely unresponsive.  This problem persists
with both acpi and acpi=off.  There doesn't seem to be any process
eating the CPU.  the laptop has 256 MB of ram and 800 MB of swap. 
What is odd is that while there is still plenty of physical memory
free, huge amounts of swap are in use.  Usually the only thing I am
running is the the GNOME desktop and a web browser.  I'm not sure if
it's kernel related or not.  I suspected ACPI, but that doesn't seem
to matter as it acts the same with acpi on or off.  The system worked
flawlessly with redhat 9.  I did a fresh install of fedora core 2, not
an upgrade.


Version-Release number of selected component (if applicable):
2.6.5-1.358

How reproducible:
everytime I boot.

Steps to Reproduce:
1. boot the laptop
2. work for a while
3. harddrive starts grinding
4. system becomes less and less responsive
5. eventually you have to force it off
  
Actual results:
system grinds to a halt

Expected results:
system continue to work for more than an hour or so.

Additional info:
dmesg:
http://www.botchco.com/alex/x24/dmesg.txt
lsmod:
http://www.botchco.com/alex/x24/lsmod.txt
/proc/acpi:
http://www.botchco.com/alex/x24/proc-acpi.txt

Comment 1 Barry K. Nathan 2004-07-15 04:59:51 UTC
Keep a terminal window open and running "top". Then when it starts
grinding, keep the window in view. By the time it's unresponsive, note
down what the top several processes are. (I have several specific
ideas about what might be causing this, but knowing the output of
"top" would seriously help me narrow this down.)

Also, you may want to try booting with "elevator=as" and see if that
helps responsiveness. (It could also make the situation worse not
better, but it's worth trying.)

Comment 2 Alex Deucher 2004-07-15 12:55:25 UTC
Last time this happened I sshed in and ran top, as I recall the big 3
were rpmq (?), X, and top.  I can check again tonight to be sure. 
I'll also try the elevator=as option.

Comment 3 Alex Deucher 2004-07-16 04:07:58 UTC
it's definitely rpmq:

top - 00:05:18 up  1:13,  2 users,  load average: 11.40, 6.52, 2.85
Tasks:  80 total,   2 running,  78 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.3% us,  3.3% sy,  0.7% ni,  0.0% id, 95.3% wa,  0.3% hi, 
0.0% si
Mem:    256600k total,   253988k used,     2612k free,      160k buffers
Swap:   718192k total,   299812k used,   418380k free,     7976k cached
                                                                     
          
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3724 root      34  19  445m 192m 7168 D  3.3 77.0   0:20.27 rpmq
    9 root      15   0     0    0    0 D  1.0  0.0   0:01.18 kswapd0
 2913 alex      17   0 20252 2424  17m S  0.3  0.9   0:05.72
battstat-applet
    1 root      16   0  2800   68 1316 S  0.0  0.0   0:05.10 init
    2 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0
    3 root       5 -10     0    0    0 S  0.0  0.0   0:00.09 events/0
    4 root       5 -10     0    0    0 S  0.0  0.0   0:00.00 kblockd/0
    6 root       5 -10     0    0    0 S  0.0  0.0   0:00.01 khelper
    5 root      15   0     0    0    0 S  0.0  0.0   0:00.00 khubd
   10 root      11 -10     0    0    0 S  0.0  0.0   0:00.00 aio/0
  114 root      19   0     0    0    0 S  0.0  0.0   0:00.00 kseriod
  153 root      15   0     0    0    0 S  0.0  0.0   0:00.09 kjournald
 1115 root      15   0     0    0    0 S  0.0  0.0   0:00.03 kjournald
 1377 root      15   0  2688  168 1232 S  0.0  0.1   0:00.00 cpuspeed
 1576 root      16   0  2920    4 1236 S  0.0  0.0   0:00.00 netplugd
 1586 root      15   0  2064   72 1296 S  0.0  0.0   0:00.02 syslogd
 1590 root      16   0  1872    4 1244 S  0.0  0.0   0:00.00 klogd

it stay consistently at the top and occasionally spikes to 20-30% CPU.

 3724 root      34  19  497m 193m 7168 D  2.3 77.3   0:26.14 rpmq
    9 root      15   0     0    0    0 D  0.7  0.0   0:01.68 kswapd0
 3745 alex      16   0  8800  284 6836 R  0.3  0.1   0:00.13 sshd
 3777 alex      16   0  2756  820 1620 R  0.3  0.3   0:00.67 top


 3724 root      35  19  477m 122m 7168 R 53.2 48.8   0:27.75 rpmq
 3777 alex      16   0  2756  820 1620 R  0.3  0.3   0:00.68 top
    1 root      16   0  2800   68 1316 S  0.0  0.0   0:05.10 init
    2 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0


 3724 root      35  19  477m 193m 7168 D  3.0 77.1   0:28.34 rpmq
 2913 alex      16   0 20252 2484  17m S  0.7  1.0   0:05.93
battstat-applet
 3777 alex      16   0  2756  820 1620 R  0.7  0.3   0:00.74 top
    3 root       5 -10     0    0    0 S  0.3  0.0   0:00.10 events/0


etc.

I haven't gotten a chance to try the elevator=as option.

What is rpmq?

Comment 4 Alex Deucher 2004-07-16 20:07:18 UTC
"kill -9"ing the rpmq process (plain kill doesn't work) returns the
computer to a useable state.  What is rpmq and why does it go nuts on
my computer? 

Comment 5 Barry K. Nathan 2004-07-17 03:00:22 UTC
(Sorry I didn't respond earlier, I've been busy)

rpmq is what performs rpm queries (e.g. when you run "rpm -q
name-of-package" or "rpm -qa" or whatever)

There's a cron script at /etc/cron.daily/rpm that, once a day, lists
all of the packages installed on your computer, sorts the list, and
writes it to a log file. (BTW, after you kill -9 it, it would be a
good idea to reboot in case the RPM locks are left in a bad state. If
you don't, rpm or anything that updates/installs/removes/queries
packages could freeze up later.)

You could try "chmod a-x /etc/cron.daily/rpm" to disable the script.
I'm not sure that's really a fix per se, but at least your computer
will be usable for now.

Comment 6 Alex Deucher 2004-07-17 13:41:01 UTC
re-assigning to rpm component.

Comment 7 Matthew Miller 2005-04-26 16:10:18 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 8 John Thacker 2006-05-04 13:27:44 UTC
Closing per previous comment.


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