Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

New Array 12hours-80% to Go

Featured Replies

Hi

 

I started a new array with new drives { 500g Sata(Parity) 500gSata (Data) 300gPATA (Data)}, 11 hours ago and it is only 20% done with a 2,448KB/Sec Rate. It is working, because I see increases in the KBs every time I refresh. I assume it is preparing the file system.

 

Is this normal? I hope this is not a reflection of how long it takes to rip music and video data to these.

 

Again, Thanks to Everyone for their input on my last couple of questions

  • Author

That was a little confusing. It is closer to 12hours not 11.

 

Sorry.

That does sound slow, although your motherboard may not have the right settings (see here and here...)

 

http://lime-technology.com/forum/index.php?topic=109.0

http://lime-technology.com/forum/index.php?topic=430.15

 

For comparison, I recently set up a unRAID server with four drives (one parity, three data), all 500GB Seagate 7200rpm SATA units.  While I don't know exactly how long it took (I went to bed), it was done the next morning.

  • Author

Thank you for the information.

 

Although all the drives were making progress, I stopped it and took the Pata drive out and it created the array on the two 500g satas in 1.5 hours.

 

I then tried adding the pata back in, unraid saw it, started clearing and the whole system became extreeeeeeemely slow and did not show any progress on the PATA. I rebooted several times, same result.

 

I'm using flat new ASUS HDD ribbon, which i remounted in all possible positions. I tried changing the Bios IDE config, from Enhanced Sata to enhanced PATA plus SATA- Mistake- it caused unraid to redo the completed SATA drives.

 

The is a MB P5LD2-VM R2.0, any suggestions on Bios settings or experiences. I have searched many posts and have seen similar problems, but I could not find the solution.

 

 

 

 

That board uses Intel ICH7 southbridge chip, which doesn't have proper IDE (aka, PATA) support in the linux kernel that unRAID 3.0 is using (supports ICH6 and below).  The result is that the IDE driver will not use DMA which is why you're seeing the slow rate.

 

However... we recently added this support & are testing it.  In meantime, you can avoid the IDE controller on the MB (use a Promise card instead).

I'm doing a clean rebuild with a new MB, the Asus P5PE-VM.  I used all of the BIOS settings recommended in the motherboard forum.

 

But, I'm having a similar problem with parity building taking forever.  Originally it ran for several hours, was at 5% and said that there were 3000 minutes left to build parity.  So I moved all of the drives onto the promise controllers (there are 8 IDE drives of different sizes).  It is taking even longer this time.    Now it's 8000 minutes!!!

 

I'm going to leave it running overnight and see what happens, but it doesn't look right.

After 12 hours, it is 22.9% done.  Uggh.    I'm not sure what to do now.  Any suggestions?

Here is my syslog if it helps.  Lots of errors, not really sure what they mean though.  I'm going to guess that its a DMA issue that needs to be fixed in my BIOS and I'll try to start working on that until someone tells me otherwise.

 

 

Feb  4 01:49:52 Tower kernel: md: using function: pIII_sse (5236.800 MB/sec)

Feb  4 01:49:52 Tower kernel: md: superblock -> /boot/config/super.dat

Feb  4 01:49:52 Tower kernel: md: slot 0 device -> hdl [57,64]

Feb  4 01:49:52 Tower kernel: md: slot 1 device -> hdk [57,0]

Feb  4 01:49:52 Tower kernel: md: slot 2 device -> hdj [56,64]

Feb  4 01:49:52 Tower kernel: md: slot 3 device -> hdi [56,0]

Feb  4 01:49:52 Tower kernel: md: slot 4 device -> hdh [34,64]

Feb  4 01:49:52 Tower kernel: md: slot 5 device -> hdg [34,0]

Feb  4 01:49:52 Tower kernel: md: slot 6 device -> hdf [33,64]

Feb  4 01:49:52 Tower kernel: md: slot 7 device -> hde [33,0]

Feb  4 01:49:52 Tower kernel: md: slot 8 device -> ? [0,0]

Feb  4 01:49:52 Tower kernel: md: slot 9 device -> ? [0,0]

Feb  4 01:49:52 Tower kernel: md: slot 10 device -> ? [0,0]

Feb  4 01:49:52 Tower kernel: md: slot 11 device -> ? [0,0]

Feb  4 01:49:52 Tower ifplugd(eth0)[736]: Executing '/etc/ifplugd/ifplugd.action

eth0 up'.

Feb  4 01:49:52 Tower kernel: md: reading superblock from /boot/config/super.dat

Feb  4 01:49:52 Tower kernel: md: superblock events: 7

Feb  4 01:49:52 Tower kernel: md: import hdl Maxtor 6Y160P0 Y60BS0KE offset: 63

size: 160086496

Feb  4 01:49:52 Tower kernel: md0: wrong

Feb  4 01:49:52 Tower kernel: md: import hdk HDS722525VLAT80 VNR93EC6CKMY0M offs

et: 63 size: 244198552

Feb  4 01:49:52 Tower kernel: md1: wrong

Feb  4 01:49:52 Tower kernel: md: import hdj WDC WD2500JB-00EVA0 WD-WMAEH2130986

offset: 63 size: 244198552

Feb  4 01:49:52 Tower kernel: md2: wrong

Feb  4 01:49:52 Tower kernel: md: import hdi HDS722525VLAT80 VNR93EC6CGRWHM offs

et: 63 size: 244198552

Feb  4 01:49:52 Tower kernel: md3: wrong

Feb  4 01:49:52 Tower kernel: md: import hdh ST3300620A 5QF0FZSK offset: 63 size

: 293036152

Feb  4 01:49:52 Tower kernel: md4: wrong

Feb  4 01:49:52 Tower kernel: md: import hdg ST3400633A 5NF205WY offset: 63 size

: 390711352

Feb  4 01:49:52 Tower kernel: md5: wrong

Feb  4 01:49:52 Tower kernel: md: import hdf ST3400633A 5NF1XLRH offset: 63 size

: 390711352

Feb  4 01:49:52 Tower kernel: md6: wrong

Feb  4 01:49:52 Tower kernel: md: import hde ST3400633A 5NF1XAGJ offset: 63 size

: 390711352

Feb  4 01:49:52 Tower kernel: md7: wrong

Feb  4 01:49:52 Tower emhttp[728]: Device inventory:

Feb  4 01:49:52 Tower emhttp[728]: /dev/hdl (hdl1) PATA:Maxtor 6Y160P0/Y60BS0KE

Feb  4 01:49:52 Tower emhttp[728]: /dev/hdk (hdk1) PATA:HDS722525VLAT80/VNR93EC6

CKMY0M

Feb  4 01:49:52 Tower emhttp[728]: /dev/hdj (hdj1) PATA:WDC WD2500JB-00EVA0/WD-W

MAEH2130986

Feb  4 01:49:52 Tower emhttp[728]: /dev/hdi (hdi1) PATA:HDS722525VLAT80/VNR93EC6

CGRWHM

Feb  4 01:49:52 Tower emhttp[728]: /dev/hdh (hdh1) PATA:ST3300620A/5QF0FZSK

Feb  4 01:49:52 Tower emhttp[728]: /dev/hdg (hdg1) PATA:ST3400633A/5NF205WY

Feb  4 01:49:52 Tower emhttp[728]: /dev/hdf (hdf1) PATA:ST3400633A/5NF1XLRH

Feb  4 01:49:52 Tower emhttp[728]: /dev/hde (hde1) PATA:ST3400633A/5NF1XAGJ

Feb  4 01:49:52 Tower emhttp[728]: shcmd (3): rmmod md-mod >>/var/log/go 2>&1

Feb  4 01:49:52 Tower kernel: md: unraid driver removed.

Feb  4 01:49:52 Tower emhttp[728]: shcmd (4): modprobe md-mod super=/boot/config

/super.dat slots=33,0,33,64,34,0,34,64,56,0,56,64,57,0,57,64,0,0,0,0,0,0,0,0 >>/

var/log/go 2>&1

Feb  4 01:49:52 Tower ifplugd(eth0)[736]: Program executed successfully.

Feb  4 01:49:52 Tower kernel: md: unraid driver 0.91.0

Feb  4 01:49:52 Tower kernel: md: sizeof(mdp_super_t) = 4096

Feb  4 01:49:52 Tower kernel: md: measuring xor speed

Feb  4 01:49:52 Tower kernel:    8regs    :  3402.000 MB/sec

Feb  4 01:49:52 Tower kernel:    32regs    :  2206.800 MB/sec

Feb  4 01:49:52 Tower kernel:    pIII_sse  :  5236.800 MB/sec

Feb  4 01:49:52 Tower kernel:    pII_mmx  :  3231.600 MB/sec

Feb  4 01:49:52 Tower kernel:    p5_mmx    :  3252.400 MB/sec

Feb  4 01:49:52 Tower kernel: md: using function: pIII_sse (5236.800 MB/sec)

Feb  4 01:49:52 Tower kernel: md: superblock -> /boot/config/super.dat

Feb  4 01:49:52 Tower kernel: md: slot 0 device -> hde [33,0]

Feb  4 01:49:52 Tower kernel: md: slot 1 device -> hdf [33,64]

Feb  4 01:49:52 Tower kernel: md: slot 2 device -> hdg [34,0]

Feb  4 01:49:52 Tower kernel: md: slot 3 device -> hdh [34,64]

Feb  4 01:49:52 Tower kernel: md: slot 4 device -> hdi [56,0]

Feb  4 01:49:52 Tower kernel: md: slot 5 device -> hdj [56,64]

Feb  4 01:49:52 Tower kernel: md: slot 6 device -> hdk [57,0]

Feb  4 01:49:52 Tower kernel: md: slot 7 device -> hdl [57,64]

Feb  4 01:49:52 Tower kernel: md: slot 8 device -> ? [0,0]

Feb  4 01:49:52 Tower kernel: md: slot 9 device -> ? [0,0]

Feb  4 01:49:52 Tower kernel: md: slot 10 device -> ? [0,0]

Feb  4 01:49:52 Tower kernel: md: slot 11 device -> ? [0,0]

Feb  4 01:49:52 Tower kernel: md: reading superblock from /boot/config/super.dat

Feb  4 01:49:52 Tower kernel: md: superblock events: 7

Feb  4 01:49:52 Tower kernel: md: import hde ST3400633A 5NF1XAGJ offset: 63 size

: 390711352

Feb  4 01:49:52 Tower kernel: md: import hdf ST3400633A 5NF1XLRH offset: 63 size

: 390711352

Feb  4 01:49:52 Tower kernel: md: import hdg ST3400633A 5NF205WY offset: 63 size

: 390711352

Feb  4 01:49:52 Tower kernel: md: import hdh ST3300620A 5QF0FZSK offset: 63 size

: 293036152

Feb  4 01:49:52 Tower kernel: md: import hdi HDS722525VLAT80 VNR93EC6CGRWHM offs

et: 63 size: 244198552

Feb  4 01:49:52 Tower kernel: md: import hdj WDC WD2500JB-00EVA0 WD-WMAEH2130986

offset: 63 size: 244198552

Feb  4 01:49:52 Tower kernel: md: import hdk HDS722525VLAT80 VNR93EC6CKMY0M offs

et: 63 size: 244198552

Feb  4 01:49:52 Tower kernel: md: import hdl Maxtor 6Y160P0 Y60BS0KE offset: 63

size: 160086496

Feb  4 01:49:52 Tower emhttp[728]: shcmd (5): killall -w smbd nmbd

Feb  4 01:49:52 Tower nmbd[722]: [2007/02/04 01:49:52, 0] nmbd/nmbd.c:terminate(

56)

Feb  4 01:49:52 Tower nmbd[722]:  Got SIGTERM: going down...

Feb  4 01:49:54 Tower emhttp[728]: shcmd (6): /usr/sbin/nmbd -D

Feb  4 01:49:54 Tower emhttp[728]: shcmd (7): /usr/sbin/smbd -D

Feb  4 01:49:54 Tower emhttp[786]: driver cmd: start STOPPED

Feb  4 01:49:54 Tower kernel: mdcmd (2): start

Feb  4 01:49:54 Tower kernel: md: reading superblock from /boot/config/super.dat

Feb  4 01:49:54 Tower kernel: md: superblock events: 7

Feb  4 01:49:54 Tower kernel: md: import hde ST3400633A 5NF1XAGJ offset: 63 size

: 390711352

Feb  4 01:49:54 Tower kernel: md: import hdf ST3400633A 5NF1XLRH offset: 63 size

: 390711352

Feb  4 01:49:54 Tower kernel: md: import hdg ST3400633A 5NF205WY offset: 63 size

: 390711352

Feb  4 01:49:54 Tower kernel: md: import hdh ST3300620A 5QF0FZSK offset: 63 size

: 293036152

Feb  4 01:49:54 Tower kernel: md: import hdi HDS722525VLAT80 VNR93EC6CGRWHM offs

et: 63 size: 244198552

Feb  4 01:49:54 Tower kernel: md: import hdj WDC WD2500JB-00EVA0 WD-WMAEH2130986

offset: 63 size: 244198552

Feb  4 01:49:54 Tower kernel: md: import hdk HDS722525VLAT80 VNR93EC6CKMY0M offs

et: 63 size: 244198552

Feb  4 01:49:54 Tower kernel: md: import hdl Maxtor 6Y160P0 Y60BS0KE offset: 63

size: 160086496

Feb  4 01:49:54 Tower kernel: unraid: allocated 8462kB for md0

Feb  4 01:49:54 Tower kernel: md1: running, size: 390711352 blocks

Feb  4 01:49:54 Tower kernel: md2: running, size: 390711352 blocks

Feb  4 01:49:54 Tower kernel: md3: running, size: 293036152 blocks

Feb  4 01:49:54 Tower kernel: md4: running, size: 244198552 blocks

Feb  4 01:49:54 Tower kernel: md5: running, size: 244198552 blocks

Feb  4 01:49:54 Tower kernel: md6: running, size: 244198552 blocks

Feb  4 01:49:54 Tower kernel: md7: running, size: 160086496 blocks

Feb  4 01:49:55 Tower emhttp[786]: driver cmd: check

Feb  4 01:49:55 Tower kernel: mdcmd (4): check

Feb  4 01:49:55 Tower kernel: md: recovery thread got woken up ...

Feb  4 01:49:55 Tower kernel: md: recovery thread syncing parity disk...

Feb  4 01:49:55 Tower kernel: md: writing superblock to /boot/config/super.dat

Feb  4 01:49:55 Tower emhttp[797]: shcmd (8): mount -t reiserfs -o noatime,nodir

atime /dev/md1 /mnt/disk1

Feb  4 01:49:55 Tower emhttp[798]: shcmd (8): mount -t reiserfs -o noatime,nodir

atime /dev/md2 /mnt/disk2

Feb  4 01:49:55 Tower emhttp[799]: shcmd (8): mount -t reiserfs -o noatime,nodir

atime /dev/md3 /mnt/disk3

Feb  4 01:49:55 Tower emhttp[800]: shcmd (8): mount -t reiserfs -o noatime,nodir

atime /dev/md4 /mnt/disk4

Feb  4 01:49:55 Tower emhttp[801]: shcmd (8): mount -t reiserfs -o noatime,nodir

atime /dev/md5 /mnt/disk5

Feb  4 01:49:55 Tower emhttp[807]: shcmd (8): mount -t reiserfs -o noatime,nodir

atime /dev/md6 /mnt/disk6

Feb  4 01:49:55 Tower emhttp[808]: shcmd (8): mount -t reiserfs -o noatime,nodir

atime /dev/md7 /mnt/disk7

Feb  4 01:49:55 Tower kernel: reiserfs: found format "3.6" with standard journal

Feb  4 01:49:55 Tower last message repeated 5 times

Feb  4 01:49:55 Tower kernel: md: using 256k window, over a total of 390711352 b

locks.

Feb  4 01:49:55 Tower kernel: reiserfs: found format "3.6" with standard journal

Feb  4 01:50:19 Tower kernel: hde: dma_timer_expiry: dma status == 0x60

Feb  4 01:50:19 Tower kernel: hde: timeout waiting for DMA

Feb  4 01:50:19 Tower kernel: PDC202XX: Primary channel reset.

Feb  4 01:50:19 Tower kernel: hde: timeout waiting for DMA

Feb  4 01:50:19 Tower kernel: hde: (__ide_dma_test_irq) called while not waiting

Feb  4 01:50:20 Tower kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComple

te Error }

Feb  4 01:50:20 Tower kernel: hdf: dma_intr: error=0x84 { DriveStatusError BadCR

C }

Feb  4 01:50:20 Tower kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComple

te Error }

Feb  4 01:50:20 Tower kernel: hdf: dma_intr: error=0x84 { DriveStatusError BadCR

C }

Feb  4 01:50:21 Tower kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComple

te Error }

Feb  4 01:50:21 Tower kernel: hdf: dma_intr: error=0x84 { DriveStatusError BadCR

C }

Feb  4 01:50:21 Tower kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComple

te Error }

Feb  4 01:50:21 Tower kernel: hdf: dma_intr: error=0x84 { DriveStatusError BadCR

C }

Feb  4 01:50:21 Tower kernel: PDC202XX: Primary channel reset.

Feb  4 01:50:22 Tower kernel: ide2: reset: success

Feb  4 01:50:24 Tower kernel: spurious 8259A interrupt: IRQ7.

Feb  4 01:50:47 Tower kernel: hde: dma_timer_expiry: dma status == 0x60

Feb  4 01:50:47 Tower kernel: hde: timeout waiting for DMA

Feb  4 01:50:47 Tower kernel: PDC202XX: Primary channel reset.

Feb  4 01:50:47 Tower kernel: hde: timeout waiting for DMA

Feb  4 01:50:47 Tower kernel: hde: (__ide_dma_test_irq) called while not waiting

Feb  4 01:50:47 Tower kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComple

te Error }

Feb  4 01:50:47 Tower kernel: hdf: dma_intr: error=0x84 { DriveStatusError BadCR

C }

Feb  4 01:50:48 Tower kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComple

te Error }

Feb  4 01:50:48 Tower kernel: hdf: dma_intr: error=0x84 { DriveStatusError BadCR

C }

Feb  4 01:50:48 Tower kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComple

te Error }

Feb  4 01:50:48 Tower kernel: hdf: dma_intr: error=0x84 { DriveStatusError BadCR

C }

Feb  4 01:50:48 Tower kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComple

te Error }

Feb  4 01:50:48 Tower kernel: hdf: dma_intr: error=0x84 { DriveStatusError BadCR

C }

Feb  4 01:50:48 Tower kernel: PDC202XX: Primary channel reset.

Feb  4 01:50:49 Tower kernel: ide2: reset: success

Feb  4 01:50:52 Tower kernel: reiserfs: checking transaction log (device md(9,5)

) ...

Feb  4 01:50:52 Tower kernel: for (md(9,5))

Feb  4 01:50:52 Tower kernel: reiserfs: checking transaction log (device md(9,4)

) ...

Feb  4 01:50:52 Tower kernel: for (md(9,4))

Feb  4 01:50:56 Tower kernel: reiserfs: checking transaction log (device md(9,3)

) ...

Feb  4 01:50:56 Tower kernel: for (md(9,3))

Feb  4 01:51:00 Tower kernel: reiserfs: checking transaction log (device md(9,2)

) ...

Feb  4 01:51:00 Tower kernel: for (md(9,2))

Feb  4 01:51:11 Tower kernel: md(9,5):Using r5 hash to sort names

Feb  4 01:51:11 Tower emhttp[801]: remount: /dev/md5

Feb  4 01:51:11 Tower kernel: md(9,5):can't shrink filesystem on-line

Feb  4 01:51:14 Tower kernel: reiserfs: checking transaction log (device md(9,7)

) ...

Feb  4 01:51:14 Tower kernel: for (md(9,7))

Feb  4 01:51:18 Tower kernel: reiserfs: checking transaction log (device md(9,6)

) ...

Feb  4 01:51:18 Tower kernel: for (md(9,6))

Feb  4 01:51:19 Tower kernel: hde: dma_timer_expiry: dma status == 0x60

Feb  4 01:51:19 Tower kernel: hde: timeout waiting for DMA

Feb  4 01:51:19 Tower kernel: PDC202XX: Primary channel reset.

Feb  4 01:51:19 Tower kernel: hde: timeout waiting for DMA

Feb  4 01:51:19 Tower kernel: hde: (__ide_dma_test_irq) called while not waiting

Feb  4 01:51:19 Tower kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComple

te Error }

Feb  4 01:51:19 Tower kernel: hdf: dma_intr: error=0x84 { DriveStatusError BadCR

C }

Feb  4 01:51:20 Tower kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComple

te Error }

Feb  4 01:51:20 Tower kernel: hdf: dma_intr: error=0x84 { DriveStatusError BadCR

C }

Feb  4 01:51:20 Tower kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComple

te Error }

Feb  4 01:51:20 Tower kernel: hdf: dma_intr: error=0x84 { DriveStatusError BadCR

C }

Feb  4 01:51:20 Tower kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComple

te Error }

Feb  4 01:51:20 Tower kernel: hdf: dma_intr: error=0x84 { DriveStatusError BadCR

C }

Feb  4 01:51:20 Tower kernel: PDC202XX: Primary channel reset.

Feb  4 01:51:21 Tower kernel: ide2: reset: success

Feb  4 01:51:21 Tower kernel: reiserfs: checking transaction log (device md(9,1)

) ...

Feb  4 01:51:21 Tower kernel: for (md(9,1))

Feb  4 01:51:21 Tower kernel: md(9,2):Using r5 hash to sort names

Feb  4 01:51:21 Tower emhttp[798]: remount: /dev/md2

Feb  4 01:51:21 Tower kernel: md(9,2):can't shrink filesystem on-line

Feb  4 01:51:21 Tower kernel: md(9,7):Using r5 hash to sort names

Feb  4 01:51:21 Tower emhttp[808]: remount: /dev/md7

Feb  4 01:51:21 Tower kernel: md(9,7):can't shrink filesystem on-line

Feb  4 01:51:21 Tower kernel: md(9,6):Using r5 hash to sort names

Feb  4 01:51:21 Tower emhttp[807]: remount: /dev/md6

Feb  4 01:51:21 Tower kernel: md(9,6):can't shrink filesystem on-line

Feb  4 01:51:21 Tower kernel: md(9,3):Using r5 hash to sort names

Feb  4 01:51:21 Tower emhttp[799]: remount: /dev/md3

Feb  4 01:51:21 Tower kernel: md(9,3):can't shrink filesystem on-line

Feb  4 01:51:21 Tower kernel: md(9,4):Using r5 hash to sort names

Feb  4 01:51:21 Tower emhttp[800]: remount: /dev/md4

Feb  4 01:51:21 Tower kernel: md(9,4):can't shrink filesystem on-line

Feb  4 01:51:42 Tower kernel: hde: dma_timer_expiry: dma status == 0x60

Feb  4 01:51:42 Tower kernel: hde: timeout waiting for DMA

Feb  4 01:51:42 Tower kernel: PDC202XX: Primary channel reset.

Feb  4 01:51:42 Tower kernel: hde: timeout waiting for DMA

Feb  4 01:51:42 Tower kernel: hde: (__ide_dma_test_irq) called while not waiting

Feb  4 01:51:42 Tower kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComple

te Error }

Feb  4 01:51:42 Tower kernel: hdf: dma_intr: error=0x84 { DriveStatusError BadCR

C }

Feb  4 01:51:43 Tower kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComple

te Error }

Feb  4 01:51:43 Tower kernel: hdf: dma_intr: error=0x84 { DriveStatusError BadCR

C }

Feb  4 01:51:43 Tower kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComple

te Error }

Feb  4 01:51:43 Tower kernel: hdf: dma_intr: error=0x84 { DriveStatusError BadCR

C }

Feb  4 01:51:43 Tower kernel: hdf: dma_intr: status=0x51 { DriveReady SeekComple

te Error }

Feb  4 01:51:43 Tower kernel: hdf: dma_intr: error=0x84 { DriveStatusError BadCR

C }

Feb  4 01:51:43 Tower kernel: PDC202XX: Primary channel reset.

Feb  4 01:51:44 Tower kernel: ide2: reset: success

Feb  4 01:51:44 Tower kernel: md(9,1):Using r5 hash to sort names

Feb  4 01:51:44 Tower emhttp[797]: remount: /dev/md1

Feb  4 01:51:44 Tower kernel: md(9,1):can't shrink filesystem on-line

Feb  4 01:51:45 Tower emhttp[786]: shcmd (8): killall -w smbd nmbd

Feb  4 01:51:45 Tower nmbd[782]: [2007/02/04 01:51:45, 0] nmbd/nmbd.c:terminate(

56)

Feb  4 01:51:45 Tower nmbd[782]:  Got SIGTERM: going down...

Feb  4 01:51:47 Tower emhttp[786]: shcmd (9): /usr/sbin/nmbd -D

Feb  4 01:51:47 Tower emhttp[786]: shcmd (10): /usr/sbin/smbd -D

root@Tower:~#

Well I fixed it.  I unplugged the cable that seemed to have the DMA errors on it.    Now its building parity in no time.    But I'm still not sure what is wrong.  Is it a bad drive or drives? 

I'm also having a very similiar problem.  See here http://lime-technology.com/forum/index.php?topic=430.30.

 

What I find very strange is that before I replaced my parity drive, I had 4 sata drives and one ide drive.  One of the SATA drives was used for parity.  When copying data to any of the drives including the ide drive, I had no problems speedwise nor with building parity.  Everything just sailed along quite nicely.  I then replaced my parity drive with a new 500gb ide drive.  As soon as I did that everything crawled to a halt.  Parity took 3 days, copying files to any drive ide or sata takes forever.  For ex I copied over a dvd and it took 1.5hrs!  If this is a problem with the motherboard's southbridge chip how come I didn't have a problem before replacing the drive?  Something somewhere doesn't make sense.  Is the problem making the ide drive the parity or having two drives on the ide channel that's causing the problems.? 

Archived

This topic is now archived and is closed to further replies.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.