A little background first.  I'm migrating from WHS to unRaid v4.7.   I've built a new unRaid server with:

 

Gigabyte GA-MA770T-UD3  (six Sata II)

4gb DDR3 Ram   {memcheck'd for 2 full days}

4 Port SATA Serial ATA PCI RAID Controller Card - Silicon Image (Monoprice #2667 - SATA I -- yea, I know now... tbd fixed later)

Two - ISTAR BPU-350SATA cages

video card:  Sorry, forgot to get that info before going to work....  it's in an x16 slot

 

So far, I've migrated/moved/purchased/etc 8 drives of varying capacities.  My largest is 2tb, parity to match size.  No cache drive at this time.

 

Ok, so for several days now I've been in the shampoo mode.   Copy data, remove drive from WHS, install drive into UnRaid, rinse/repeat.

 

(Once done, I'll be moving over a 8-bay Rosewill enclosure from the old WHS to the UnRaid server... but that's later)

 

---

 

History done.   This morning a copy was still running from over night -- a Drag/Drop using an external Windows 7 box between a share on WHS and a share on unRaid.    About 120gb was in the process of being moved -- probably about half way through I would guess.

 

UnRaid box has been up for about 15 days, with out a single issue.

 

I received an error on the machine doing the copying that the unRaid server/file was not available  ("Try again / skip / cancel")

 

Could not ping the unraid box, could not SSH/telnet, etc.

 

Checked the console on the unRaid box and had this message:

 

Kernel Panic - not syncing: CRED: put_cred_rcu() sees c3760080 with usage -1

 

UnRaid box locked up hard.  Could NOT GET SYSLOG from this.   Had to hard-boot the unRaid box.

 

Of course, it came back up, mounted the drives and started a parity check/sync...  which is still going on.

 

I'm attaching a Syslog -- but keep in mind, it's the syslog AFTER rebooting the server -- where reiserfs logs are being replayed, etc.

 

 

Fluke that it panic'd?   Something I should be checking?

syslog-2011-04-28.txt

Update:  Sometime during the parity sync/check,  it rebooted again.

 

Similar error:

 

Kernel Panic - not syncing: CRED: put_cred_rcu() sees caaffb80 with usage -894438656

 

Same as before, unRaid locked up hard.  Attached to this note is the syslog *AFTER* bringing back up the system

 

Parity Sync/Check auto-running again.  ETA is about 18 hours for it to complete.

 

 

Kernel Panic - not syncing: CRED: put_cred_rcu() sees c3760080 with usage -1

 

UnRaid box locked up hard.  Could NOT GET SYSLOG from this.   Had to hard-boot the unRaid box.

 

syslog-2011-04-28-afternoon.txt

The very long parity check is due to the poor choice of which hard drives to place on the PCI card -you are running the smaller drives (500GB, 750 GB) from the motherboard ports and the larger ones (1 -2TB) from the PCI bus. If you are going to use multiple HDs on PCI controllers then you should select the smallest HDs for this as to minimize the impact of the limited bandwidth - in this way once you pass the 500 GB mark in your case the parity check (and rebuild) will speed up considerably.

You also have a potential problems with your 750 GB Seagate and 500GB Samsung drives - you should perform short and long SMART tests and post the results here. It wont hurt to at least do a short SMART test on the other HDs. Check the cabling and the power spiltters.

 

And as usual - make sure you are using the latest MB BIOS, place the SATA ports in AHCI mode and disable any hardware feature you are not planning to use (serial and par ports, audio, floppy cntrl, even the IDE cntrl if not going to use any PATA drives). You should also take look at this PCI SATA card and if possible try to flash the latest noRAID firmware available.

 

The very long parity check is due to the poor choice of which hard drives to place on the PCI card -you are running the smaller drives (500GB, 750 GB) from the motherboard ports and the larger ones (1 -2TB) from the PCI bus. If you are going to use multiple HDs on PCI controllers then you should select the smallest HDs for this as to minimize the impact of the limited bandwidth - in this way once you pass the 500 GB mark in your case the parity check (and rebuild) will speed up considerably.

You also have a potential problems with your 750 GB Seagate and 500GB Samsung drives - you should perform short and long SMART tests and post the results here. It wont hurt to at least do a short SMART test on the other HDs. Check the cabling and the power spiltters.

 

And as usual - make sure you are using the latest MB BIOS, place the SATA ports in AHCI mode and disable any hardware feature you are not planning to use (serial and par ports, audio, floppy cntrl, even the IDE cntrl if not going to use any PATA drives). You should also take look at this PCI SATA card and if possible try to flash the latest noRAID firmware available.

 

 

Thanks.  I have all of the drives in "ISTAR" cage #1 running off the MoBo connectors.  And then the other cage running off the PCI card (except 1 drive, using the 6th connector on MoBo)

 

I'll re-arrange the drives to get a faster Parity check time.   I'm basically OK with the time,  I posted it more FYI.   The goal, as I understand it, is to get the "biggest" drives running off the MoBo 6 SATA II connectors, and move on to the smaller drives off the slower PCI card.

 

I'm more concerned with the hang & error.    But I'll rerrange the drives by size as you suggested.   It makes plenty of sense.  Get "over" the SATA I side of the parity recalcs as soon as possible, and use the smaller drives on the SATA I / PCI controller, to make that happen.

 

The MoBo has all SATA's set to AHCI mode.  And all unnecessary devices (Parallel, serial disabled) that the MoBo allows.

 

The 750 is a refurbed drive back from Seagate -- I sent in one that failed SMARTs.    I'll double-check and re-run the smarts on everybody installed.

 

I think the 500gb Samsung drive is the one with 24000 hours on it (from WHS) -- it will be pulled when my shampoo cycle is done.   I needed it to get space to move data from WHS, and will pull it.   Samsung says while it's in the warranty period, that it wasn't made "for this country" and I'll just toss it.

 

The MoBO Bios was updated upon installing -- I'll check if it's still the latest

 

And I have NOT checked the Firmware on the controller card -- will do.  

 

 

You have some probable cable issues, but I don't think they are related to your Panics.  Both syslogs show a number of BadCRC flags, which are generally always caused by poor SATA cables, but could possibly be drive power related too.  Most of these were related to the Samsung HD501, but there was also one occurrence related to the Seagate 1TB, and one occurrence related to the Seagate 750GB.  I would replace their SATA cables with better quality ones.

 

The only other thing I can think of is that you are setting up NFS support, something that is relatively new in unRAID, and therefore may not be as rock solid.  I can't tell if you have been actually using it though.

 

I don't recall ever seeing a "CRED: put_cred_rcu()" phrase before, so I know nothing about which modules it is related to.  Just did a bit of research, and this apparently refers to "Task credentials management" in the kernel, rather low level stuff.  With no other reports of this, you may be out of luck here, unless a later kernel version works better for you.

You have some probable cable issues, but I don't think they are related to your Panics.  Both syslogs show a number of BadCRC flags, which are generally always caused by poor SATA cables, but could possibly be drive power related too.  Most of these were related to the Samsung HD501, but there was also one occurrence related to the Seagate 1TB, and one occurrence related to the Seagate 750GB.  I would replace their SATA cables with better quality ones.

 

The only other thing I can think of is that you are setting up NFS support, something that is relatively new in unRAID, and therefore may not be as rock solid.  I can't tell if you have been actually using it though.

 

I don't recall ever seeing a "CRED: put_cred_rcu()" phrase before, so I know nothing about which modules it is related to.  Just did a bit of research, and this apparently refers to "Task credentials management" in the kernel, rather low level stuff.  With no other reports of this, you may be out of luck here, unless a later kernel version works better for you.

 

Some new SATA cables are already on order from Monoprice  {I wasn't happy with the ones that were 'freebies'}, and the NFS -- well,  I just filled in "NFS" in that field -- should I just remove that entry?   I don't use NFS..  Just Samba shares.

 

Most appreciative you to, and others, in this thread.    I'm working down my issues to get a good, solid, UnRaid system.... and retire {except for the ability to do good 'bare metal' backups - will have about 3tb there for that} my WHS server -- all file/share storage - about 10tb+ is moving -- shampoo -- to unRaid

... which are generally always caused by poor SATA cables, but could possibly be drive power related too.  

 

For 'neatness' -- because I have 10 sata cables,  I wire-tied them in nice rows.   Was this a bad choice?   I've never had this many live sata cables in one case.

For 'neatness' -- because I have 10 sata cables,  I wire-tied them in nice rows.   Was this a bad choice?   I've never had this many live sata cables in one case.

 

I'm not an electrical expert here, Joe L or others may have more authoritative answers, but I do have one concern with wire-tying.  I believe you should be careful to never squeeze too tightly or overly distort a data cable, because you could diminish its internal wire spacing, possibly leading to increased interference and/or cross-talk.  I believe that is why in the IDE days an 80-wire flat ribbon cable was better than a round or 40-wire cable, because the 80-wire cable enforced consistent wire spacing and signal separation.

For 'neatness' -- because I have 10 sata cables,  I wire-tied them in nice rows.   Was this a bad choice?   I've never had this many live sata cables in one case.

 

I'm not an electrical expert here, Joe L or others may have more authoritative answers, but I do have one concern with wire-tying.  I believe you should be careful to never squeeze too tightly or overly distort a data cable, because you could diminish its internal wire spacing, possibly leading to increased interference and/or cross-talk.  I believe that is why in the IDE days an 80-wire flat ribbon cable was better than a round or 40-wire cable, because the 80-wire cable enforced consistent wire spacing and signal separation.

 

Yes, I wasn't suggesting I "gorilla tied" them to the point of distortion/compression.  Just enough to get them to lay flat together in groups.  Otherwise, I didn't see how I'd keep from having spaghetti flopping all over the place with 10 SATA cables...

Update:  Sometime during the parity sync/check,  it rebooted again.

 

The third time it's now completely resynced/checked parity.  Zero errors.   And no reboots.

 

I can't confirm cause/effect -- but I did flip the switch on one of the iStar sata chassis to "high" (the other was on high already) and cracked the case and put an external "tiny office" style fan to occalate and blow on the mobo and disk cages -- with all those drives,  spun up at once, to do the parity check/sync -- it was running 41-42 degrees on some of them.   Much better now.   I have a 120mm fan to install on the side case,  it's another part of the project.

 

I'm happy with the fact it finished parity check/sync without errors... and we're not hanging (with human hard boot) now....

 

The project for the morning is to work on updating all the bios, muscial chairs with the hard drives (MoBo connectors for the big ones, add-in PCI card for the smaller ones) etc.    And my WHS is moving out the last hard drive that will allow me to move the Rosewill cage over.  I'm quite close to having my full unRaid box alive, and leaving my WHS just with USB-style "WD Book" drives for backups...   WOL is my next project to have that box (WHS) come awake and go to sleep at night to back up what I want.

 

The very long parity check is due to the poor choice of which hard drives to place on the PCI card -you are running the smaller drives (500GB, 750 GB) from the motherboard ports and the larger ones (1 -2TB) from the PCI bus. If you are going to use multiple HDs on PCI controllers then you should select the smallest HDs for this as to minimize the impact of the limited bandwidth - in this way once you pass the 500 GB mark in your case the parity check (and rebuild) will speed up considerably.

You also have a potential problems with your 750 GB Seagate and 500GB Samsung drives - you should perform short and long SMART tests and post the results here. It wont hurt to at least do a short SMART test on the other HDs. Check the cabling and the power spiltters.

 

And as usual - make sure you are using the latest MB BIOS, place the SATA ports in AHCI mode and disable any hardware feature you are not planning to use (serial and par ports, audio, floppy cntrl, even the IDE cntrl if not going to use any PATA drives). You should also take look at this PCI SATA card and if possible try to flash the latest noRAID firmware available.

 

 

Thanks.  I have all of the drives in "ISTAR" cage #1 running off the MoBo connectors.  And then the other cage running off the PCI card (except 1 drive, using the 6th connector on MoBo)

 

I'll re-arrange the drives to get a faster Parity check time.   I'm basically OK with the time,  I posted it more FYI.   The goal, as I understand it, is to get the "biggest" drives running off the MoBo 6 SATA II connectors, and move on to the smaller drives off the slower PCI card.

 

I'm more concerned with the hang & error.    But I'll rerrange the drives by size as you suggested.   It makes plenty of sense.  Get "over" the SATA I side of the parity recalcs as soon as possible, and use the smaller drives on the SATA I / PCI controller, to make that happen.

 

The MoBo has all SATA's set to AHCI mode.  And all unnecessary devices (Parallel, serial disabled) that the MoBo allows.

 

The 750 is a refurbed drive back from Seagate -- I sent in one that failed SMARTs.    I'll double-check and re-run the smarts on everybody installed.

 

I think the 500gb Samsung drive is the one with 24000 hours on it (from WHS) -- it will be pulled when my shampoo cycle is done.   I needed it to get space to move data from WHS, and will pull it.   Samsung says while it's in the warranty period, that it wasn't made "for this country" and I'll just toss it.

 

The MoBO Bios was updated upon installing -- I'll check if it's still the latest

 

And I have NOT checked the Firmware on the controller card -- will do.