Bug 126433 - basp_worker and esm_wd_thread causing load = 2 in a idle system
Summary: basp_worker and esm_wd_thread causing load = 2 in a idle system
Status: CLOSED DUPLICATE of bug 78616
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-06-21 16:30 UTC by Antonio Cruz
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 19:04:11 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Antonio Cruz 2004-06-21 16:30:45 UTC
Description of problem:

These two daemons are permanently in DW state at tops output, even 
with the system otherwise idle.

Version-Release number of selected component (if applicable):
kernel-smp-2.4.21-15.EL

How reproducible:
Every time

Steps to Reproduce:
1. Just to reboot the system and watch the load steadly approaching 2.
  
Actual results:
The load steadly reaches 2, even with no other applications running.

Expected results:
The load should be around 0 with the system idle

Additional info:
From time to time in a aparently random manner, the load jumps 1 ou 2 
units, and steadly decays to 2 after some dozen seconds.

Comment 1 Arjan van de Ven 2004-06-21 16:31:52 UTC
these 2 threads are part of binary only kernel modules, which we
cannot fix. It's usually a quite simple fix to fix this type of
bug.... if we have/ship the source, which we don't.

*** This bug has been marked as a duplicate of 78616 ***

Comment 2 Antonio Cruz 2004-06-21 16:37:34 UTC
That's the output of top i, showing the two processes, in permanent 
DW state.

 13:32:11  up 18 days, 19:14,  8 users,  load average: 2.19, 2.13, 
2.04
202 processes: 201 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    
idle
           total    0.4%    0.1%    0.5%   0.0%     0.0%    0.1%   
98.5%
           cpu00    0.6%    0.0%    0.2%   0.0%     0.0%    0.2%   
98.8%
           cpu01    0.2%    1.3%    0.4%   0.2%     0.4%    0.0%   
97.2%
           cpu02    0.0%    0.0%    2.2%   0.0%     0.0%    0.4%   
97.2%
           cpu03    0.2%    0.0%    0.0%   0.0%     0.0%    0.2%   
99.5%
           cpu04    2.7%    0.0%    1.3%   0.0%     0.0%    0.4%   
95.4%
           cpu05    0.0%    0.0%    0.0%   0.0%     0.0%    0.0%  
100.0%
           cpu06    0.0%    0.0%    0.0%   0.0%     0.0%    0.2%   
99.7%
           cpu07    0.0%    0.0%    0.0%   0.0%     0.0%    0.0%  
100.0%
Mem:  7998320k av, 3818464k used, 4179856k free,       0k shrd,  
330768k buff
                   2866744k actv,  597796k in_d,    1576k in_c
Swap: 8385760k av,   50220k used, 8335540k free                 
3008136k cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU 
COMMAND
  727 root      15   0     0    0     0 DW    0.0  0.0   2:00   2 
basp_worker
 1897 root      15   0     0    0     0 DW    0.0  0.0   0:09   5 
esm_wd_thread
28647 root      16   0  1364 1364   916 R     0.0  0.0   0:00   0 top

I will supply any info or data needed to solve this.

Thank you.

Antonio


Comment 3 Red Hat Bugzilla 2006-02-21 19:04:11 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.


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