I have just built my first unRaid - 1-2T parity, 5-2T data, 1-500G cache, running version 4.7.  All has gone pretty well, but my system seems to run a parity check all the time. 

 

Yesterday, it started one are 6:01AM, continued until noon time (I was not at home); restarted another around 1PM ran until 8PM when I did a clean shut down and restart (parity has not completed).  System came up and displayed parity as valid. The the system started another parity check at 1:05AM - now 87% complete at 6:20am)

 

Since the system restart last night, there has been no new data written to the system;  the only thing it has been accessed for is Plex server running on a mini-mac to pull video files a few hours prior to the 1AM parity check start.

 

Is this normal behavior?

This is not normal. Post a syslog.

Syslog attached.  Seems my system restarted on its own this morning at 11:40AM and ran another parity check.    Guidance appreciated.

 

syslog-2012-04-09.txt

Please can you also describe the system spec?

System:

 

ASUS P8Z68-V LX mother board with 6 onboard SATA; Intel i5-2300, 2.8Ghz; 2-2G RAM

Additional SATA card (4 port) - no name chinese card

Antec 750W PSU

5- 2TB data, 1- 2TB Parity, 1- 500G Cache - all Seagate drives

Antec 300 case

Sony 4GB flash drive

 

Installed 4.7 unRaid

unMenu

Additional Packages:

"C" Compiler

Mail & ssmtp

UnRaid-Web

 

3 User Shares that include all disks.

 

Something is causing the system to restart abnormally. Use the telnet-tail method describe here to capture the syslog before a shutdown: http://lime-technology.com/forum/index.php?topic=9880.0

System rebooted at 1:01am on its own.  Attached is the syslog as of 6:08am.  I am guessing that something is causing the system to shut down (not cleanly), then restart - thus invoking a parity check.  now the big question is why?  I will try to capture something later that is close to the shut down.

 

syslog_20120410.txt

Another syslog.  Seems my system restarted at 2PM this afternoon while I was at work - running a parity check again!  Uhg!  Any thoughts on how to grab a syslog from the prior "session" to be able to better diagnose the cause of the shutdown and restart?

 

Thanks

 

SH

syslog_20120410_2.txt

as dgaschk mentioned and linked to two posts up, use tail to pipe the syslog into your telnet/putty/whatever session and then just copy and paste the results after a crash (if you're using putty obviously don't click OK on the 'lost connection' dialog 

 

The command you want is:

 

tail -f /var/log/syslog

 

BQ

 

OK  - here is a log file through the shutdown - file attached, but here are the last few lines after I telnet'd in and fed the syslog

 

 

Apr 11 06:22:31 HAL_9000 login[4931]: ROOT LOGIN  on `pts/0' from `192.168.11.10'

Apr 11 07:43:26 HAL_9000 kernel: mdcmd (33): spindown 0

Apr 11 07:43:27 HAL_9000 kernel: mdcmd (34): spindown 1

Apr 11 07:43:28 HAL_9000 kernel: mdcmd (35): spindown 2

Apr 11 07:43:29 HAL_9000 kernel: mdcmd (36): spindown 3

Apr 11 07:43:30 HAL_9000 kernel: mdcmd (37): spindown 4

Apr 11 07:43:31 HAL_9000 kernel: mdcmd (38): spindown 5

 

Thoughts?

syslog_20120411.txt

I think your PSU is falling over when all the drives spin up at once. Try disabling the spindown and see if it stays stable for a longer period of time. That PSU isn't designed for server duty, it's meant for a gaming rig.

Just reading this again - you're on 4.7 and using a z68-based board.  I'd recommend trying a beta build (b14 should be fine looking at your hardware).  Essentially the chipset on your board is much newer than the drivers etc in the kernel that is in 4.7.

 

Give b14 a crack and see how you go.  Could also be the PSU as mentioned.

Thanks.  I have attached my latest syslog that has a few different items (sorry for my ignorance) prior to the uncontrolled shut down.

 

i will give an upgrade to 5b014 later this week

 

SH

 

 

Apr 11 08:12:59 HAL_9000 in.telnetd[3959]: connect from 192.168.11.10 (192.168.11.10)

Apr 11 08:13:01 HAL_9000 login[3960]: invalid password for `UNKNOWN'  on `pts/0' from `192.168.11.10'

Apr 11 08:13:03 HAL_9000 login[3960]: ROOT LOGIN  on `pts/0' from `192.168.11.10'

Apr 11 11:44:48 HAL_9000 emhttp: shcmd (37): /usr/sbin/hdparm -y /dev/sdc >/dev/null

Apr 11 13:51:29 HAL_9000 kernel: md: sync done. time=22015sec rate=88735K/sec

Apr 11 13:51:31 HAL_9000 kernel: md: recovery thread sync completion status: 0

 

Message from syslogd@HAL_9000 at Wed Apr 11 16:14:37 2012 ...

HAL_9000 kernel: Disabling IRQ #17

Apr 11 16:14:37 HAL_9000 kernel: irq 17: nobody cared (try booting with the "irqpoll" option)

Apr 11 16:14:37 HAL_9000 kernel: Pid: 0, comm: swapper Not tainted 2.6.32.9-unRAID #8

Apr 11 16:14:37 HAL_9000 kernel: Call Trace:

Apr 11 16:14:37 HAL_9000 kernel:  [<c10451cf>] __report_bad_irq+0x2e/0x6f

Apr 11 16:14:37 HAL_9000 kernel:  [<c1045305>] note_interrupt+0xf5/0x13c

Apr 11 16:14:37 HAL_9000 kernel:  [<c1045a14>] handle_fasteoi_irq+0x5f/0x9d

Apr 11 16:14:37 HAL_9000 kernel:  [<c1004a82>] handle_irq+0x1a/0x24

Apr 11 16:14:37 HAL_9000 kernel:  [<c1004285>] do_IRQ+0x40/0x96

Apr 11 16:14:37 HAL_9000 kernel:  [<c1002f29>] common_interrupt+0x29/0x30

Apr 11 16:14:37 HAL_9000 kernel:  [<c116d019>] ? acpi_idle_enter_bm+0x216/0x23f

Apr 11 16:14:37 HAL_9000 kernel:  [<c12108e8>] cpuidle_idle_call+0x63/0x9b

Apr 11 16:14:37 HAL_9000 kernel:  [<c1001a14>] cpu_idle+0x3a/0x4e

Apr 11 16:14:37 HAL_9000 kernel:  [<c128a8bf>] rest_init+0x53/0x55

Apr 11 16:14:37 HAL_9000 kernel:  [<c13f580c>] start_kernel+0x27b/0x280

Apr 11 16:14:37 HAL_9000 kernel:  [<c13f5091>] i386_start_kernel+0x91/0x96

Apr 11 16:14:37 HAL_9000 kernel: handlers:

Apr 11 16:14:37 HAL_9000 kernel: [<f826a58b>] (sil_interrupt+0x0/0x26d [sata_sil])

Apr 11 16:14:37 HAL_9000 kernel: Disabling IRQ #17

Apr 11 17:51:33 HAL_9000 kernel: mdcmd (18): spindown 0

Apr 11 17:51:34 HAL_9000 kernel: mdcmd (19): spindown 1

Apr 11 17:51:35 HAL_9000 kernel: mdcmd (20): spindown 2

Apr 11 17:51:36 HAL_9000 kernel: mdcmd (21): spindown 3

Apr 11 17:51:37 HAL_9000 kernel: mdcmd (22): spindown 4

syslog_20120411_1.txt

OK - I think I found the the source of my problem.  All had been running well on 5b14 until the disk started to spin down.  The log from last night/this am, the disks were spinning down when out of use.  I was using a couple disks until 11:30PM, thus the 3:30am spin down (4 hour lag).  System reset itself.

 

This morning, I tried a manual spin down, thinking that when the disks all spin down, the system was resetting for some reason - yes it did. 

 

Also, if I use the power down command in unMenu/user scripts - the system powers down cleanly, but automatically restarts.

 

Now the question is why?  Is it a BIOS issue, or a is it something else?  I am not sure why the power supply would fall over when the disks are spinning down.

 

Thoughts?

 

SYSLOG from early this AM

 

Apr 13 22:59:33 HAL_9000 unmenu-status: Starting unmenu web-server

Apr 13 23:56:58 HAL_9000 kernel: mdcmd (52): spindown 1

Apr 13 23:56:59 HAL_9000 kernel: mdcmd (53): spindown 4

Apr 14 02:14:14 HAL_9000 kernel: mdcmd (54): spindown 3

Apr 14 03:26:31 HAL_9000 kernel: mdcmd (55): spindown 0

Apr 14 03:31:53 HAL_9000 kernel: mdcmd (56): spindown 2

 

SYSTEM reset and went into a parity check upon start up

 

root@HAL_9000:~# tail -f /var/log/syslog

Apr 14 04:40:01 HAL_9000 syslogd 1.4.1: restart.

Apr 14 10:06:28 HAL_9000 in.telnetd[12875]: connect from 192.168.11.10 (192.168.11.10)

Apr 14 10:06:30 HAL_9000 login[12876]: invalid password for 'UNKNOWN'  on '/dev/pts/0' from '192.168.11.10'

Apr 14 10:06:32 HAL_9000 login[12876]: ROOT LOGIN  on '/dev/pts/0' from '192.168.11.10'

Apr 14 10:07:21 HAL_9000 kernel: md: sync done. time=23674sec

Apr 14 10:07:23 HAL_9000 kernel: md: recovery thread sync completion status: 0

Apr 14 10:07:32 HAL_9000 emhttp: Spinning down all drives...

Apr 14 10:07:32 HAL_9000 kernel: mdcmd (39): spindown 0

Apr 14 10:07:33 HAL_9000 kernel: mdcmd (40): spindown 1

Apr 14 10:07:34 HAL_9000 kernel: mdcmd (41): spindown 2

Apr 14 10:07:35 HAL_9000 kernel: mdcmd (42): spindown 3

Apr 14 10:07:36 HAL_9000 kernel: mdcmd (43): spindown 4

Apr 14 10:07:37 HAL_9000 kernel: mdcmd (44): spindown 5

Apr 14 10:07:38 HAL_9000 emhttp: shcmd (59): /usr/sbin/hdparm -y /dev/sdb &> /dev/null

Apr 14 10:07:38 HAL_9000 kernel: ata5.00: exception Emask 0x10 SAct 0x0 SErr 0x4090000 action 0xe frozen

Apr 14 10:07:38 HAL_9000 kernel: ata5.00: irq_stat 0x00400040, connection status changed

Apr 14 10:07:38 HAL_9000 kernel: ata5: SError: { PHYRdyChg 10B8B DevExch }

Apr 14 10:07:38 HAL_9000 kernel: ata5.00: failed command: STANDBY IMMEDIATE

Apr 14 10:07:38 HAL_9000 kernel: ata5.00: cmd e0/00:00:00:00:00/00:00:00:00:00/40 tag 0

Apr 14 10:07:38 HAL_9000 kernel:          res 50/00:ff:00:00:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error)

Apr 14 10:07:38 HAL_9000 kernel: ata5.00: status: { DRDY }

Apr 14 10:07:38 HAL_9000 kernel: ata5: hard resetting link

 

This was a manual spin down via the GUI - after the disks all were down, the system reset.

This usually indicates a bad SATA cable. See here: http://lime-technology.com/wiki/index.php/The_Analysis_of_Drive_Issues#Drive_Interface_Issues

Checked the cables, swapped out a couple fro good measure. 

 

Spun down the drives on by one.  Once the last drive spin down command is given - BOOM, whole system powers down and reboots.  I have tried spinning down in different orders, same result.  Every time the command to spin the last drive down, the system drops power and resets. Also - time to rename this thread.

 

I am at a complete loss.

 

 

 

Apr 14 16:52:05 HAL_9000 login[4810]: ROOT LOGIN  on '/dev/pts/0' from '192.168.11.10'

Apr 14 16:52:43 HAL_9000 kernel: NTFS driver 2.1.30 [Flags: R/W MODULE].

Apr 14 16:53:24 HAL_9000 kernel: mdcmd (39): spindown 5

Apr 14 16:53:24 HAL_9000 kernel:

Apr 14 16:53:34 HAL_9000 kernel: mdcmd (40): spindown 4

Apr 14 16:53:34 HAL_9000 kernel:

Apr 14 16:53:41 HAL_9000 kernel: mdcmd (41): spindown 3

Apr 14 16:53:41 HAL_9000 kernel:

Apr 14 16:53:47 HAL_9000 kernel: mdcmd (42): spindown 2

Apr 14 16:53:47 HAL_9000 kernel:

Apr 14 16:53:52 HAL_9000 kernel: mdcmd (43): spindown 1

Apr 14 16:53:52 HAL_9000 kernel:

Apr 14 16:53:58 HAL_9000 kernel: mdcmd (44): spindown 0

Apr 14 16:53:58 HAL_9000 kernel:

The only other thing I can think of is PSU (mentioned earlier with regards to spinning up.. but a forced reboot like that just doesn't make sense) - have you got another one you can connect up outside the case and power things from there to test?

I don't have another PSU - will have to get one. 

 

It seems counter-intuitive that the PSU would drop out and re-boot when the drives spin down (lowest power usage).  It always happens when the last drive is given the command to spin down - I can spin down the drives one by one using Disk Management tab in unMenu.

 

I have check the MB BIOS and turned off all energy management, thinking that the MB goes into some sleep mode when the drives doing down. 

 

I have set the disk spin down delay to "never" at this point, but not ideal for energy consumption (though there are different schools of thought on running continuously or spinning down a drive for life).

 

I am at a loss for were to turn next

 

 

Yeah my only thought at this stage is that for some reason, the power supply is dropping its voltage to the motherboard when it gets to a certain level, enough to force a cold reboot (assuming a cold reboot is what you are seeing.)  Good luck in any case, no idea what else it could be. 

Or a marginal power supply.  How many disks?  What specific make/model power supply?

 

To power down it would probably have to park all the disk heads, that might induce a spike on the power supply.

Joe,

 

Running all 2TB Seagate drive; 1 Parity, 5 Data; 1-500M Seagate Cache.

 

The PSU I am running is as follows (cut an paste from spec sheet):?

 

?Antec HCG-750

HIGH CURRENT GAMER SERIES

??SPECIFICATIONS:

• 750watts Continuous Power

• NVIDIA®SLI®-Ready certified, ATICrossFireTMcertified

• 80PLUS®Bronzecertified–up to 88%efficient

• QuadHighCurrent+12V rails

• Quiet135mm double ball bearing cooling fan

• Fourgold-plated8-pin(6+2)-pinPCI-Econnectorsformultiple-graphicscardconfigurations

• AllJapanese-brandcapacitorsforreliability

• Gold-platedHighCurrentterminalsforoptimalconductivity

• UniversalInput–worksonany100V-240Vgrid

• ActivePFCwithPF:0.99

• MTBF:100,000hours

• MeetsErPLot6:2010requirement:5Vsb<1W

• AQ5AntecQuality5-yearlimitedwarrantyonpartsandlabor

 

INPUT:

?Input Voltage 100 ~ 240 Vac ± 10%

Input Frequency Range 47 Hz ~ 63 Hz

Efficiency Up to 88%

?Operating Temperature 0°C – 50°C

 

OUTPUT:  Max Load

+3.3V      25A

+5V        25A

+12V1    40A

+12V2    40A

+12V3    40A

+12V4    40A

-12V        0.5A

+5Vsb      3A

 

Everything starts up OK.  It is only at shut down, or spinning down the disks - always when the last disk is spun down, it's like the reset button is hit.  The system goes "black" and restarts.

 

I found my issue.  I went back to my MB to check the BIOS version and settings.  I thought I had the latest BIOS based on the January 2012 build date.  But on further investigation, found that the BIOS rev I had was not even listed on the ASUS website for my MB (how this BIOS got on the MB is a mystery to me).  But after a reflash of the BIOS to the latest, all is good.

 

The lesson learned: Do not assume your BIOS is correct or up to date.  Check out all your hardware and BIOS versions first.

 

I was pleased that ASUS had a very easy built-in tool to reflash from the USB.

 

SH

Good news, I was interested in the resolution for this.  Glad to hear it was as easy as a BIOS update!