I setup the foundation for a new media server (P5B-VM DO // 2GB Crucial ram // 750GB WD HD // 400GB Hitachi HD // 1GB Usb Stick)

 

It boots unraid, recongizes both drives, allows me to select the devices to use as parity and data....

 

I start a parity sync, and then every time it nears completion, I receive a string of error messages...

 

(Interestingly enough, I receive 288 write errors EVERY time - I remember someone else complaining about exactly 288 errors in another thread - I would be suspect of coincidence)

 

I have tried multiple different cables, and even different SATA ports on the same board.

 

I know the Ram is good (Pulled from another machine), the MB is good (I have two - same thing both boards), the Hitachi is good (Pulled), and the PSU is a high quality PSU.  It powers another system in the house without glitches.

 

These are the error messages:

 

Sep 30 05:34:40 Tower kernel: [12365.858028] md0: write error!

Sep 30 05:34:40 Tower kernel: [12365.858030] handle_stripe write error: 12038499

44/0, count: 1

Sep 30 05:34:40 Tower kernel: [12365.858032] md0: write error!

Sep 30 05:34:40 Tower kernel: [12365.858034] handle_stripe write error: 12038499

52/0, count: 1

 

The only unknown is the WD 750GB, as it is new.  Any thoughts?

 

A search of the board for a similar error message found two posts, one ended up to be a failing, then failed, drive.  The second one was a likely bad drive (no followup by the OP).  The exact error was handle_stripe READ, not WRITE, however.

 

Infant mortality in drives is not uncommon.

 

 

Bill

The error location reported is about at the 587GB mark of your drive.  Since this is beyond the size of your 400GB data disk, the system is just writing zeros to every sector of your parity disk beyond 400GB.

 

The reason 288 errors are reported is because parity sync queues up 288 write operations to the unRAID driver (which is a little more than a megabyte).  When a write error occurs, the driver fails that particular write, plus the 287 ones queued up, hence 288 gets reported as the error count.

 

It would help to see the complete system log after parity sync gets terminated.  Might tell us if it's a media error, or something else.

Thanks for the info.

 

I actually picked up another 750GB drive, and it had no problem.  I tested this drive in WD's DLG Tools, and it ended up failing miserably (After passing the first time).  It ended up being a drive failure.

 

As an FYI, while testing, I 'borrowed' a MB that I intended to use for another project, to remove that from the list of culprits, and it worked great.  An Intel DQ35MP (Recently released).  6 internal SATA, Intel gigabit controller, support port multipliers (New ICH9DO chipset)....  EXCEPT, I had to disable ACPI in the syslinux config file for the system to boot, and had to config the formatting of the USB drive as a zip drive.  Bizarre.

 

Equally bizarre: I had Xfer mode error messages on my 400GB Hitachi drive (7k400) on every MB I tried unless I passed the nolapic directive at boot.  Otherwise it would be recongnized by linux only half the time, and drop out eventually.  Any Ideas on that one?  If I enable lapic and add the drive back, any ideas on the system performance hit?  (I was getting reads of close to 95MB/s, and Parity syncs of up to 65MB/s with the twin WD7500AAKS drives)

 

Thanks!

I configured the sytem with "ACPI=off noapic", and it works perfectly now (as far as I can tell).

 

I am assuming that the ACPI problem is related to this being a new board, with only 2 bios updates, and will be fixed in time.  Wasn't necessary on the Asus board.  It does not appear to be affecting performance at all, however.

 

I am wondering if anyone can fathom why I would need to use either noapic or nolapic for this Hitachi 7k400 400GB drive to boot and be recognized in Linux reliably.  This is the case on both motherboards I tried (Asus P5B-VM DO and Intel DQ35MP), which were based on different chipsets, even.  The WD drives worked fine without the boot directives.  Any Ideas?

 

I guess I can try a live cd or two, perhaps its the kernel version unRAID is using?

I had to use noapic with my nForce 570 board, with unRAID 4.1, in order to get it to finish booting (had 'kernel panic').  With the newer kernel release in 4.2, I no longer need it, and thank you, Tom.

 

ACPI is a complex specification and many bios don't get it right.

Transfered some data to the drive (the 400GB Hitachi).

 

I watched 5 different DVD streams on computers all around the house at the same time, from the same drive, without a hiccup  Apparently the noapic and acpi=off dont seem to be hampering performance too badly!

 

For anyone else with this Hitachi drive, apparently they made some kernel changes to the 2.6.x line recently with broke this particular drive (it is not fully SATA compliant....doesnt it figure).  The fixes are supposed to be worked into the next kernel release (fingers crossed).