unRAID Server Release 5.0-beta12a Available


limetech

Recommended Posts

It does work, but I was told that it only takes 2TB instead of the total 3TB.. my supplier confirmed this after talking to Supermicro.

 

Finally found the thread which I was looking for :

 

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

 

As you can see from the screenshot multiple 3tb drives (although on beta9)

 

Which saslp firmware are you running ? .21 ?

 

I tested this card with 4 3TB drives and it worked fine.

Link to comment
  • Replies 383
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I tested this card with 4 3TB drives and it worked fine.

 

My read of the problems we've seen is that the card/driver works great until an attached drive has a problem. Whether it's a matter of the drive not responding quickly enough or with error conditions I have no idea, but threads elsewhere over the last year suggest the driver doesn't do a great job with exceptions.

Link to comment

I tested this card with 4 3TB drives and it worked fine.

 

My read of the problems we've seen is that the card/driver works great until an attached drive has a problem. Whether it's a matter of the drive not responding quickly enough or with error conditions I have no idea, but threads elsewhere over the last year suggest the driver doesn't do a great job with exceptions.

 

That is what happened in my case.  The only time I have seen these errors was when I had a drive that had read failures (smart reported it was unable to read).  and then unraid was miserable and full of these blk log entries and was unresponsive.  since having a new drive in havent seen these blk entries again....

Link to comment

I am curious though, this card is the one that is recommened by limetech, did these errors not exist in the 4.7 builds?

The SASLP cards work fine with 4.7.  The update to a newer kernel and other changes with the latest beta seems to have brought out issues with the SASLP driver that is used.

 

Well that is good to know at least, so it was working well at some stage so should be able to again :).

Link to comment

 

I am fully aware of the BETA stages and I respect them, but let's say 4.7 works without the  "BLK_NOT_HANDLED" issue, why would this be an issue in the new beta serie (5bxx)?

 

 

I'd say the answer to that is very simple. 5.0 is not just an update of unraid code on the same old Linux base. The base Slackware has been moved to a much more current version. Probably to provide support for new hardware (and also to support newer AFP software). To me, an outsider, it looks like there have been changes to a bunch of drivers, that may not be as mature as we would like. Fixing other developer's drivers might not be the easiest thing. I hope it can be done soon.

 

/Lars Olof

Link to comment

Hello,

 

I do not think my problem is inherent to this distro but since this is what I am running so there it is.

I cannot get my shares to work, no matter what.

So please, in a few words what are the minimal conditions to build a share across multiple disks and see the content?

Exemple"

 

Nas is the name of the Unraid nas

/disk1/MEDIA/VIDEOS

/disk2/MEDIA/VIDEOS

 

I want to be able to type \\Nas\MEDIA and see the content such as VIDEOS/.......

 

Thanks

 

Link to comment

Hello,

 

I do not think my problem is inherent to this distro but since this is what I am running so there it is.

I cannot get my shares to work, no matter what.

So please, in a few words what are the minimal conditions to build a share across multiple disks and see the content?

Exemple"

 

Nas is the name of the Unraid nas

/disk1/MEDIA/VIDEOS

/disk2/MEDIA/VIDEOS

 

I want to be able to type \\Nas\MEDIA and see the content such as VIDEOS/.......

 

Thanks

 

Turning on user Shares should present on the network a \\Nas\MEDIA folder with the Videos folder in there.

Link to comment

Hello,

 

I do not think my problem is inherent to this distro but since this is what I am running so there it is.

I cannot get my shares to work, no matter what.

So please, in a few words what are the minimal conditions to build a share across multiple disks and see the content?

Exemple"

 

Nas is the name of the Unraid nas

/disk1/MEDIA/VIDEOS

/disk2/MEDIA/VIDEOS

 

I want to be able to type \\Nas\MEDIA and see the content such as VIDEOS/.......

 

Thanks

 

Turning on user Shares should present on the network a \\Nas\MEDIA folder with the Videos folder in there.

 

 

I don't understand. If you mean that the MEDIA share has to show up in the Shares tab and be active then it is.

When I drill down into it I can see the VIDEOS folder. But if I drill down again into the VIDEOS folder then it is empty although if I go to /disk2/MEDIA/VIDEOS/ it is full of subfolders themselves full of data.

 

I haven't got a clue.

Link to comment

Hello,

 

I do not think my problem is inherent to this distro but since this is what I am running so there it is.

I cannot get my shares to work, no matter what.

So please, in a few words what are the minimal conditions to build a share across multiple disks and see the content?

Exemple"

 

Nas is the name of the Unraid nas

/disk1/MEDIA/VIDEOS

/disk2/MEDIA/VIDEOS

 

I want to be able to type \\Nas\MEDIA and see the content such as VIDEOS/.......

 

Thanks

 

Turning on user Shares should present on the network a \\Nas\MEDIA folder with the Videos folder in there.

 

 

I don't understand. If you mean that the MEDIA share has to show up in the Shares tab and be active then it is.

When I drill down into it I can see the VIDEOS folder. But if I drill down again into the VIDEOS folder then it is empty although if I go to /disk2/MEDIA/VIDEOS/ it is full of subfolders themselves full of data.

 

I haven't got a clue.

First: lets that this discussion to another thread (one in the General help area)

Second: Post a syslog there

Third: Start and stop the array, then reboot the computer and/or server if need be.

Link to comment

I'm on Beta12a, and I just upgraded to another 4x 3TB, this time the SATA3 EZRX models. Precleared all drives using v1.13 of the preclear script, no errors on any. Added them to array one at a time. Everything went fine. Restarted my server, started array, one of the disc just sits at "resizing" even though the array has been up for over a day. This feels like a rather critical bug that may only be affecting the SATA3 3TB drives, but my knowledge with this stuff is slim. The drive isn't shown in my share in Windows, and doesn't seem to be exporting. Yet I can access all my other drives, and there is no red dot next to any drive. I would assume this would throw parity off, causing parity sync issues, resulting in complete corruption of rebuilt data? This is pretty scary stuff.

 

I think this kernal error is the cause, but i'm not sure. Full system log is attached.

 

UPDATE: Stopping the array hanged the entire server. Let it sit there for an hour before improperly restarting the server. I did a cold boot, and everything seems to be working now - but this did happen for a reason and it seems like a software bug, not a hardware bug. This drive was completely empty with just an empty share folder in it.

 

Sep 22 09:09:28 SERVER kernel: BUG: unable to handle kernel NULL pointer dereference at   (null)
Sep 22 09:09:28 SERVER kernel: IP: [] queue_delayed_work_on+0x33/0xbf
Sep 22 09:09:28 SERVER kernel: *pdpt = 000000002fbee001 *pde = 0000000000000000 
Sep 22 09:09:28 SERVER kernel: Oops: 0000 [#1] SMP 
Sep 22 09:09:28 SERVER kernel: Modules linked in: md_mod xor sata_mv e1000e i2c_i801 i2c_core [last unloaded: md_mod]
Sep 22 09:09:28 SERVER kernel: 
Sep 22 09:09:28 SERVER kernel: Pid: 2170, comm: emhttp Not tainted 3.0.3-unRAID #7 Supermicro X7SB4/E/X7SB4/E
Sep 22 09:09:28 SERVER kernel: EIP: 0060:[] EFLAGS: 00210246 CPU: 1
Sep 22 09:09:28 SERVER kernel: EIP is at queue_delayed_work_on+0x33/0xbf
Sep 22 09:09:28 SERVER kernel: EAX: f8a2c138 EBX: ffffffff ECX: f8a2c134 EDX: 00000000
Sep 22 09:09:28 SERVER kernel: ESI: 00000000 EDI: f8a2c134 EBP: ec8fbe40 ESP: ec8fbe34
Sep 22 09:09:28 SERVER kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Sep 22 09:09:28 SERVER kernel: Process emhttp (pid: 2170, ti=ec8fa000 task=f0092f40 task.ti=ec8fa000)
Sep 22 09:09:28 SERVER kernel: Stack:
Sep 22 09:09:28 SERVER kernel:  f8a1c000 f0370f54 f0370f00 ec8fbe4c c1038c8e 0000000a ec8fbeb0 c10d87fe
Sep 22 09:09:28 SERVER kernel:  f8a1c000 00000012 00000000 f6c42a10 00000000 03b26a10 00000000 00000010
Sep 22 09:09:28 SERVER kernel:  f0370f18 00000012 00000004 f8a1c000 0000004b 00000000 f7baa000 f0f841e0
Sep 22 09:09:28 SERVER kernel: Call Trace:
Sep 22 09:09:28 SERVER kernel:  [] queue_delayed_work+0x1b/0x1e
Sep 22 09:09:28 SERVER kernel:  [] do_journal_end+0x747/0x92a
Sep 22 09:09:28 SERVER kernel:  [] journal_end_sync+0x5b/0x63
Sep 22 09:09:28 SERVER kernel:  [] reiserfs_sync_fs+0x32/0x51
Sep 22 09:09:28 SERVER kernel:  [] __sync_filesystem+0x53/0x65
Sep 22 09:09:28 SERVER kernel:  [] sync_filesystem+0x2c/0x3f
Sep 22 09:09:28 SERVER kernel:  [] do_remount_sb+0x4c/0xd3
Sep 22 09:09:28 SERVER kernel:  [] do_remount+0x74/0xc6
Sep 22 09:09:28 SERVER kernel:  [] do_mount+0x10b/0x1c6
Sep 22 09:09:28 SERVER kernel:  [] sys_mount+0x61/0x94
Sep 22 09:09:28 SERVER kernel:  [] syscall_call+0x7/0xb
Sep 22 09:09:28 SERVER kernel:  [] ? quirk_usb_disable_ehci+0x84/0x129
Sep 22 09:09:28 SERVER kernel: Code: d6 53 89 c3 f0 0f ba 29 00 19 d2 31 c0 85 d2 0f 85 9d 00 00 00 83 79 10 00 74 04 0f 0b eb fe 8d 41 04 39 41 04 74 04 0f 0b eb fe  06 02 b8 08 00 00 00 75 19 89 c8 e8 02 e5 ff ff 85 c0 74 08 
Sep 22 09:09:28 SERVER kernel: EIP: [] queue_delayed_work_on+0x33/0xbf SS:ESP 0068:ec8fbe34
Sep 22 09:09:28 SERVER kernel: CR2: 0000000000000000
Sep 22 09:09:28 SERVER kernel: ---[ end trace f8be7fa413f5555b ]---
Sep 22 09:09:28 SERVER kernel: REISERFS (device md17): Using r5 hash to sort names
Sep 22 09:09:28 SERVER kernel: REISERFS (device md18): Using r5 hash to sort names
Sep 22 09:09:28 SERVER kernel: REISERFS (device md13): Using r5 hash to sort names
Sep 22 09:09:28 SERVER emhttp: shcmd (72): chmod 770 '/mnt/disk17'
Sep 22 09:09:28 SERVER kernel: REISERFS (device md19): Using r5 hash to sort names
Sep 22 09:09:28 SERVER kernel: REISERFS (device md2): Using r5 hash to sort names
Sep 22 09:09:28 SERVER kernel: REISERFS (device md6): Using r5 hash to sort names
Sep 22 09:09:28 SERVER kernel: REISERFS (device md9): Using r5 hash to sort names
Sep 22 09:09:28 SERVER kernel: REISERFS (device md16): Using r5 hash to sort names
Sep 22 09:09:28 SERVER kernel: REISERFS (device md4): Using r5 hash to sort names
Sep 22 09:09:28 SERVER emhttp: shcmd (73): chown nobody:users '/mnt/disk17'
Sep 22 09:09:28 SERVER kernel: REISERFS (device md14): Using r5 hash to sort names
Sep 22 09:09:28 SERVER kernel: REISERFS (device md3): Using r5 hash to sort names
Sep 22 09:09:28 SERVER kernel: REISERFS (device md11): Using r5 hash to sort names
Sep 22 09:09:28 SERVER kernel: REISERFS (device md12): Using r5 hash to sort names
Sep 22 09:09:28 SERVER kernel: REISERFS (device md1): Using r5 hash to sort names
Sep 22 09:09:28 SERVER kernel: REISERFS (device md8): Using r5 hash to sort names
Sep 22 09:09:28 SERVER kernel: REISERFS (device md5): Using r5 hash to sort names
Sep 22 09:09:28 SERVER kernel: REISERFS (device md15): Using r5 hash to sort names
Sep 22 09:09:28 SERVER kernel: REISERFS (device md10): Using r5 hash to sort names
Sep 22 09:09:28 SERVER kernel: REISERFS (device md20): Using r5 hash to sort names
Sep 22 09:09:28 SERVER emhttp: shcmd (74): chmod 770 '/mnt/disk18'
Sep 22 09:09:28 SERVER emhttp: shcmd (75): chown nobody:users '/mnt/disk18'
Sep 22 09:09:28 SERVER emhttp: shcmd (76): chmod 770 '/mnt/disk13'
Sep 22 09:09:28 SERVER emhttp: shcmd (77): chmod 770 '/mnt/disk2'
Sep 22 09:09:28 SERVER emhttp: shcmd (78): chmod 770 '/mnt/disk9'
Sep 22 09:09:28 SERVER emhttp: shcmd (79): chmod 770 '/mnt/disk14'
Sep 22 09:09:28 SERVER emhttp: shcmd (80): chown nobody:users '/mnt/disk13'
Sep 22 09:09:28 SERVER emhttp: shcmd (81): chmod 770 '/mnt/disk8'
Sep 22 09:09:28 SERVER emhttp: shcmd (82): chown nobody:users '/mnt/disk14'
Sep 22 09:09:28 SERVER emhttp: shcmd (83): chown nobody:users '/mnt/disk8'
Sep 22 09:09:28 SERVER emhttp: shcmd (84): chown nobody:users '/mnt/disk2'
Sep 22 09:09:28 SERVER emhttp: shcmd (85): chown nobody:users '/mnt/disk9'
Sep 22 09:09:28 SERVER emhttp: shcmd (86): chmod 770 '/mnt/disk16'
Sep 22 09:09:28 SERVER emhttp: shcmd (87): chmod 770 '/mnt/disk1'
Sep 22 09:09:28 SERVER emhttp: shcmd (89): chmod 770 '/mnt/disk3'
Sep 22 09:09:28 SERVER emhttp: shcmd (90): chmod 770 '/mnt/disk4'
Sep 22 09:09:28 SERVER emhttp: shcmd (88): chmod 770 '/mnt/disk5'
Sep 22 09:09:28 SERVER emhttp: shcmd (91): chmod 770 '/mnt/disk20'
Sep 22 09:09:28 SERVER emhttp: shcmd (92): chown nobody:users '/mnt/disk16'
Sep 22 09:09:28 SERVER emhttp: shcmd (93): chmod 770 '/mnt/disk10'
Sep 22 09:09:28 SERVER emhttp: shcmd (94): chown nobody:users '/mnt/disk20'
Sep 22 09:09:28 SERVER emhttp: shcmd (95): chown nobody:users '/mnt/disk4'
Sep 22 09:09:28 SERVER emhttp: shcmd (96): chown nobody:users '/mnt/disk3'
Sep 22 09:09:28 SERVER emhttp: shcmd (97): chmod 770 '/mnt/disk15'
Sep 22 09:09:28 SERVER emhttp: shcmd (98): chown nobody:users '/mnt/disk5'
Sep 22 09:09:28 SERVER emhttp: shcmd (99): chown nobody:users '/mnt/disk1'
Sep 22 09:09:28 SERVER emhttp: shcmd (100): chown nobody:users '/mnt/disk10'
Sep 22 09:09:28 SERVER emhttp: shcmd (101): chown nobody:users '/mnt/disk15'
Sep 22 09:09:29 SERVER emhttp: shcmd (102): chmod 770 '/mnt/disk6'
Sep 22 09:09:29 SERVER emhttp: shcmd (103): chmod 770 '/mnt/disk19'
Sep 22 09:09:29 SERVER emhttp: shcmd (104): chmod 770 '/mnt/disk12'
Sep 22 09:09:29 SERVER emhttp: shcmd (105): chmod 770 '/mnt/disk11'
Sep 22 09:09:29 SERVER emhttp: shcmd (106): chown nobody:users '/mnt/disk6'
Sep 22 09:09:29 SERVER emhttp: shcmd (107): chown nobody:users '/mnt/disk19'
Sep 22 09:09:29 SERVER emhttp: shcmd (108): chown nobody:users '/mnt/disk11'
Sep 22 09:09:29 SERVER emhttp: shcmd (109): chown nobody:users '/mnt/disk12'
Sep 22 09:09:29 SERVER emhttp: shcmd (110): mkdir /mnt/user
Sep 22 09:09:29 SERVER emhttp: shcmd (111): /usr/local/sbin/shfs /mnt/user -disks 2097022 -o noatime,big_writes,allow_other,default_permissions,use_ino 
Sep 22 09:09:29 SERVER emhttp: shcmd (112): crontab -c /etc/cron.d -d &> /dev/null
Sep 22 09:09:29 SERVER emhttp: shcmd (113): /usr/local/sbin/emhttp_event disks_mounted
Sep 22 09:09:29 SERVER emhttp_event: disks_mounted
Sep 22 09:09:29 SERVER emhttp: shcmd (114): :>/etc/samba/smb-shares.conf
Sep 22 09:09:29 SERVER emhttp: Restart SMB...
Sep 22 09:09:29 SERVER emhttp: shcmd (115): killall -HUP smbd
Sep 22 09:09:29 SERVER emhttp: shcmd (116): ps axc | grep -q rpc.mountd
Sep 22 09:09:29 SERVER emhttp: _shcmd: shcmd (116): exit status: 1
Sep 22 09:09:29 SERVER emhttp: shcmd (117): /usr/local/sbin/emhttp_event svcs_restarted
Sep 22 09:09:29 SERVER emhttp_event: svcs_restarted

 

full_syslog.txt

Link to comment

I am getting really upset with my unraid server, because smb seems to constantly die on me, I can right now still connect via telnet, however I cannot reach the machine anymore on smb. I also cannot get into the web interface anymore, this is no occurring every 2 days. I am contemplating to downgrade to 4.7, however because I started my server with 5.x I don't have a super.dat file from 4.x, what is the procedure to downgrade to get a more stable server? I also have the AOC controller which is where the problems started.

 

Will post log later.

syslog1.txt

Link to comment

I am getting really upset with my unraid server, because smb seems to constantly die on me, I can right now still connect via telnet, however I cannot reach the machine anymore on smb. I also cannot get into the web interface anymore, this is no occurring every 2 days. I am contemplating to downgrade to 4.7, however because I started my server with 5.x I don't have a super.dat file from 4.x, what is the procedure to downgrade to get a more stable server? I also have the AOC controller which is where the problems started.

 

Will post log later.

 

It states you should only update to 5.0 beta on a server with a fully working unraid 4.7, So this shouldn't be a case, but since it is... If I was in your shoes, i'd screenshot the unRAID UI so I know where every drive is and i'd backup the 'pro' file (or whatever your registeration file is called) on your flash drive. Then i'd wipe the flash drive, and follow the fresh install steps for all-in-one 4.7, after files are transferred i'd put your registrated file back in the same directory (assuming you have a paid version of unRAID), start the server and reassign all drives to the exact same spots as they were before and redo your unRAID settings. Make sure you put your parity drive in a the parity slot, and not a data drive.. You will lose data on a data drive if you accidently put it in the parity slot and start the array.

 

This method will require you to re-sync parity. There's probably faster ways but these are the original steps you should of taken for a new server.

Link to comment

Don't know what now happened, my unRaid was behaving strangely so I tried to downgrade to 4.7, formatted my USB key however was not getting any network, so I formatted again and put beta 12a back on, but still no network, don't know what to do anymore, completely frustrated.

You must have a ms-windows background.

 

You system log clearly shows:

Sep 24 19:15:01 Tower lsmod[5816]: sata_sil24              8934  0

Sep 24 19:15:01 Tower ifconfig[5819]: eth0      Link encap:Ethernet  HWaddr 20:cf:30:f3:07:1e 

Sep 24 19:15:01 Tower ifconfig[5819]:          UP BROADCAST MULTICAST  MTU:1500  Metric:1

Sep 24 19:15:01 Tower ifconfig[5819]:          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

Sep 24 19:15:01 Tower ifconfig[5819]:          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

Sep 24 19:15:01 Tower ifconfig[5819]:          collisions:0 txqueuelen:1000

Sep 24 19:15:01 Tower ifconfig[5819]:          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Sep 24 19:15:01 Tower ifconfig[5819]:          Interrupt:41 Base address:0x6000

Sep 24 19:15:01 Tower ifconfig[5819]:

Sep 24 19:15:01 Tower ethtool[5824]: Settings for eth0:

Sep 24 19:15:01 Tower ethtool[5824]:        Supported ports: [ TP ]

Sep 24 19:15:01 Tower ethtool[5824]:        Supported link modes:  10baseT/Half 10baseT/Full

Sep 24 19:15:01 Tower ethtool[5824]:                                100baseT/Half 100baseT/Full

Sep 24 19:15:01 Tower ethtool[5824]:                                1000baseT/Full

Sep 24 19:15:01 Tower ethtool[5824]:        Supports auto-negotiation: Yes

Sep 24 19:15:01 Tower ethtool[5824]:        Advertised link modes:  10baseT/Half 10baseT/Full

Sep 24 19:15:01 Tower ethtool[5824]:                                100baseT/Half 100baseT/Full

Sep 24 19:15:01 Tower ethtool[5824]:                                1000baseT/Full

Sep 24 19:15:01 Tower ethtool[5824]:        Advertised pause frame use: Symmetric Receive-only

Sep 24 19:15:01 Tower ethtool[5824]:        Advertised auto-negotiation: Yes

Sep 24 19:15:01 Tower ethtool[5824]:        Speed: Unknown!

Sep 24 19:15:01 Tower ethtool[5824]:        Duplex: Full

Sep 24 19:15:01 Tower ethtool[5824]:        Port: Twisted Pair

Sep 24 19:15:01 Tower ethtool[5824]:        PHYAD: 0

Sep 24 19:15:01 Tower ethtool[5824]:        Transceiver: internal

Sep 24 19:15:01 Tower ethtool[5824]:        Auto-negotiation: on

Sep 24 19:15:01 Tower ethtool[5824]:        MDI-X: Unknown

Sep 24 19:15:01 Tower ethtool[5824]:        Supports Wake-on: pumbg

Sep 24 19:15:01 Tower ethtool[5824]:        Wake-on: g

Sep 24 19:15:01 Tower ethtool[5824]:        Current message level: 0x00000033 (51)

Sep 24 19:15:01 Tower ethtool[5824]:        Link detected: no

 

Fix your network connection.  Currently, unRAID does not see anything attached to the network.

stop thinking that re-loading the flash drive will help.  re-loading it does not fix a loose network cable/bad network cable/bad network port/bad router port.

 

Joe L.

Link to comment

Joe L you seem to be correct it appears that my network port on my motherboard is malfaction, it just flashes every couple of sec red/orange and does not get a green led, tried different cables and ports on the router/switch so it must be the nic on the motherboard, which is extremely annoying, so will need to source a new NIC quickly

Link to comment

 I am running 9 (Nine) 3TB drives using this card, and 5B12 with no issues of any kinds. So maybe your issues start with other hardware choices you made.

After I run pre_clear I did have a couple issues with one drive. It was showing 723TB free at one point, I wish I had taken a screen shot. I did take one and post it here when showing much less than that, but well over the 3TB capacity of the drive.

But I have been up and running for a couple weeks now, and all is good on the home front.

 

@Lars Olof, don't be sorry for the 'rant' .. I can take it ;-)

 

I didn't start with 4.7 as I wanted to start with 3TB drives, but along the road I came to the conclusion that

my "Supermicro 8-Port SAS/SATA Cards (3xAOC-SASLP-MV8) don't support >2TB.

 

I am fully aware of the BETA stages and I respect them, but let's say 4.7 works without the  "BLK_NOT_HANDLED" issue, why would this be an issue in the new beta serie (5bxx)?

 

We perform regression tests to keep the current functional design operational not sure how that works for Lime.

 

We will wait and see.

 

 

 

 

 

Link to comment

I am having trouble with the PowerDown. It seems like the system is hanging on the powerdown. It does not matter if it is a cron job or a manual powerdown from unmenu. I am able to access \\tower:8081 -sickbeard and \\tower:8082 - sabnzbd but cannot access \\tower or \\tower:8080. I can access the shares just to the gui's. It is set to powerdown at 6:00 am, it runs the script but never powers down. I have attached a syslog.

 

Mike

syslog.zip

Link to comment

I am having trouble with the PowerDown. It seems like the system is hanging on the powerdown. It does not matter if it is a cron job or a manual powerdown from unmenu. I am able to access \\tower:8081 -sickbeard and \\tower:8082 - sabnzbd but cannot access \\tower or \\tower:8080. I can access the shares just to the gui's. It is set to powerdown at 6:00 am, it runs the script but never powers down. I have attached a syslog.

 

Mike

 

Does it power down without problems if you do not run sickbeard and sabnzbd (and any other extra software) ?

Link to comment

Precleared 14 drives. All OK. Running 5 B12a

 

I was gone for the weekend.

 

The server is running 100% idle, nothing to do.... and there you are again:

 

Sep 25 06:51:20 Goliath kernel: sas: command 0xee5d6180, task 0xf7600640, timed out: BLK_EH_NOT_HANDLED

 

By default (within 2-3 days max) it results in a BLK_EH_NOT_HANDLED. Looks like 4.7 is the only other option for now. It's probrably in another topic, but can you switch from version 5 bxxx to 4.7 without too many bumps?

 

@MikeL

 

What's your hardware besides the AOC card

 

 I am running 9 (Nine) 3TB drives using this card, and 5B12 with no issues of any kinds. So maybe your issues start with other hardware choices you made.

After I run pre_clear I did have a couple issues with one drive. It was showing 723TB free at one point, I wish I had taken a screen shot. I did take one and post it here when showing much less than that, but well over the 3TB capacity of the drive.

But I have been up and running for a couple weeks now, and all is good on the home front.

 

@Lars Olof, don't be sorry for the 'rant' .. I can take it ;-)

 

I didn't start with 4.7 as I wanted to start with 3TB drives, but along the road I came to the conclusion that

my "Supermicro 8-Port SAS/SATA Cards (3xAOC-SASLP-MV8) don't support >2TB.

 

I am fully aware of the BETA stages and I respect them, but let's say 4.7 works without the  "BLK_NOT_HANDLED" issue, why would this be an issue in the new beta serie (5bxx)?

 

We perform regression tests to keep the current functional design operational not sure how that works for Lime.

 

We will wait and see.

 

 

 

 

 

Link to comment

I am having trouble with the PowerDown. It seems like the system is hanging on the powerdown. It does not matter if it is a cron job or a manual powerdown from unmenu. I am able to access \\tower:8081 -sickbeard and \\tower:8082 - sabnzbd but cannot access \\tower or \\tower:8080. I can access the shares just to the gui's. It is set to powerdown at 6:00 am, it runs the script but never powers down. I have attached a syslog.

 

Mike

 

Does it power down without problems if you do not run sickbeard and sabnzbd (and any other extra software) ?

 

no I shutdown both and It still will not power down. I even tried rc.unRAID stop and I get the following.

 

 

root@Tower:/etc/rc.d# rc.unRAID stop

Capturing information to syslog. Please wait...

version[23578]: Linux version 3.0.3-unRAID (root@Develop) (gcc version 4.4.4 (GC                                      C) ) #7 SMP Fri Sep 2 16:44:33 MDT 2011

ls: cannot access /dev/hd[a-z]: No such file or directory

 

and then it hangs. When it was working I would get this but it would power down.

 

Mike

Link to comment

 Mav;

Here is the list.

 

Case - Norco RPC-4224

 

Motherboard - SUPERMICRO MBD-X8SIL-F-O Xeon X3400 / L3400 / Core i3 series Dual LAN Micro ATX Server Board w/ Remote Management

 

CPU - Intel Core i3 Processor i3-540 3.06GHz 4MB LGA1156 CPU BX80616I3540

 

Memory - Kingston 8GB (2x4GB) DDR3

 

SATA Expansion Card - 2 X SUPERMICRO AOC-SASLP-MV8

 

Cooling - 120mm fan wall bracket for RPC-4224, RPC-4220

3x Noctua NF-P12-1300 120mm fans

2x ARCTIC COOLING ACF8 Pro PWM 80mm Case Fans. (Also two extras for my 4220)

 

Drives - Parity - HITACHI Deskstar 0S03230 3TB 5400 RPM 32MB Cache SATA 6.0Gb/s 3.5" Internal Hard

Data - 7 HITACHI Deskstar 0S03230 3TB 5400 RPM 32MB Cache SATA 6.0Gb/s 3.5" Internal Hard,

1 - 2TB Seagate 5900 RPM drive, and 1 - 1.5TB WD WD15EARS drive

Cache - an old 750GB WD

 

OS - UnRAID 5.0b12a on an internally mounted 2GB firefly memory stick

 

Power Supply - CORSAIR Enthusiast Series TX650 V2 650W ATX12V v2.31/ EPS12V v2.92 80 PLUS BRONZE Certified Active PFC High Performance Power Supply

 

Cables - 4x Molex 79576-3007 Mini SAS/SATA Cable (1 Input - 4 outlets)

4x 1m 30AWG Internal Mini SAS 36pin (SFF-8087) Male to Mini SAS 36pin (SFF-8087) Male Cable - Black

 

 

@MikeL

 

What's your hardware besides the AOC card

 

Tower02_screen_shot.jpg.6bd8afc517a94429f5800700d71580a3.jpg

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.