Hello!
I gathered the information you asked for with the
sysrq-t as an attachment.
Thank you
Alfred Isele

----------------------------------------------------------------
cat /proc/mdstat
----------------------------------------------------------------
Personalities : [raid1] 
read_ahead 1024 sectors
md0 : active raid1 sdb1[1] sda1[0]
      80256 blocks [2/2] [UU]
      
md1 : active raid1 sdb2[1] sda2[0]
      722816 blocks [2/2] [UU]
      
md2 : active raid1 sdb3[1]
      2409664 blocks [2/1] [_U]
      
md3 : active raid1 sdb4[1]
      1044160 blocks [2/1] [_U]
      
md4 : active raid1 sdd2[1] sdd1[0]
      80256 blocks [2/2] [UU]
      
unused devices: <none>
----------------------------------------------------------------


----------------------------------------------------------------
top
----------------------------------------------------------------
128 processes: 122 sleeping, 6 running, 0 zombie, 0 stopped
CPU0 states:  1.1% user,  1.1% system,  0.0% nice, 97.1% idle
CPU1 states:  0.0% user, 100.0% system,  0.0% nice,  0.0% idle
Mem:  1162020K av,  703760K used,  458260K free,       0K shrd,   85888K buff
Swap:  722808K av,       0K used,  722808K free                  471184K
cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
   20 root      19   0     0    0     0 RW   99.9  0.0  15:56 raid1d
 3140 isele     15   0  1112 1112   764 R     2.5  0.0   2:31 top
 1357 solid     15   0  3176 3176  1824 S     0.1  0.2   0:02 RtpSolidD
    1 root      15   0   236  236   204 S     0.0  0.0   0:03 init
    2 root      0K   0     0    0     0 SW    0.0  0.0   0:00 migration_CPU0
    3 root      0K   0     0    0     0 SW    0.0  0.0   0:00 migration_CPU1
    4 root      15   0     0    0     0 SW    0.0  0.0   0:00 keventd
    5 root      34  19     0    0     0 SWN   0.0  0.0   0:00 ksoftirqd_CPU0
---------------------------------------------------------------

---------------------------------------------------------------
sysrq-t output as attachment Z:\aries_stack_trace;
---------------------------------------------------------------

---------------------------------------------------------------
mdadm -D /dev/md2
---------------------------------------------------------------
/dev/md2:
        Version : 00.90.00
  Creation Time : Fri Feb 28 11:03:30 2003
     Raid Level : raid1
     Array Size : 2409664 (2.30 GiB 2.51 GB)
    Device Size : 2409664 (2.30 GiB 2.51 GB)
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 2
    Persistence : Superblock is persistent

    Update Time : Fri Apr 11 12:04:47 2003
          State : dirty, no-errors
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 1


    Number   Major   Minor   RaidDevice State
       0       0        0        0      faulty removed
       1       8       19        1      active sync   /dev/sdb3
           UUID : a8a7ae0d:4b8ec9c8:7085515a:6a79bba9


---------------------------------------------------------------
 mdadm -D /dev/md3
---------------------------------------------------------------
/dev/md3:
        Version : 00.90.00
  Creation Time : Fri Feb 28 11:03:38 2003
     Raid Level : raid1
     Array Size : 1044160 (1019.69 MiB 1069.22 MB)
    Device Size : 1044160 (1019.69 MiB 1069.22 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 3
    Persistence : Superblock is persistent

    Update Time : Fri Apr 11 12:04:48 2003
          State : dirty, no-errors
 Active Devices : 1
Working Devices : 1
 Failed Devices : 1
  Spare Devices : 1


    Number   Major   Minor   RaidDevice State
       0       0        0        0      faulty removed
       1       8       20        1      active sync   /dev/sdb4
           UUID : fcf84cfb:a2f9f586:fd748cdd:79ef7c22
---------------------------------------------------------------


At 11:13 11.04.03 +0200, Lars Marowsky-Bree wrote:

On 2003-04-11T10:20:33,
  Alfred Isele [off-list ref] said:

quoted

After rebooting the resynch really starts.
Moreover sometimes after detaching (... -f ... -r ...)
I have either raid1d or mdrecoveryd 
obviously looping uninterruptible on a CPU. 

Hrm. I've not had that happen to me, but it would be nice if you could

provide

sysrq-t output would be helpful.

What happens if you mdadm -S the array? What is the mdadm --detail status?


Sincerely,
   Lars Marowsky-Brée [off-list ref]

-- 
SuSE Labs - Research & Development, SuSE Linux AG
 
"If anything can go wrong, it will." "Chance favors the prepared (mind)."
 -- Capt. Edward A. Murphy            -- Louis Pasteur